Re: VW Golf5 interior parts | Posts 48+

Short question about network management.
Is it sufficient if I periodically send a 'ring' (is this equivalent to 'injecting' something into the network)?
If I do that, then the bus will at least not fall asleep .
Should.
Is the device ID not located in the first byte of the Telegram?

First, a certain ID needs to be submitted ('registered').
59,404 40D 6 0D 02 C0 00 00 00
Then, before entering the ring, warn him if he's using a fake ID.
59,405 40C 6 00 01 00 00 00 00
59,414 40D 6 0C 12 00 00 00 00
And finally, these will be transmitted cyclically (following in the ring):
59,768 40D 6 00 11 00 00 00 00


When I press the 'instant heat' button on the Climatronic system, the following happens, as described in the attached trace.

Which NM telegrams relate to the Climatronic control unit? STG 08
http://team-dezent.fimanist.com/CAN/ClimaSofortheizen.trc
For G4, it would be 0x408, but I have no idea what it would be for G5.
You have 8 STGs (400-403, 40a-40d). STG 40d started up a little later (@59,404).

The IDs are the same for the Golf 4 and 5.

First, a certain ID needs to be submitted ('registered').
59,404 40D 6 0D 02 C0 00 00 00


Okay, I understand that without any problems.


Then, before entering the ring, warn him if he's using a fake ID.
59,405 40C 6 00 01 00 00 00 00
59,414 40D 6 0C 12 00 00 00 00


And how do I know that, specifically, 40C is my predecessor?
In this case, it's simple, because if I were a 40D, I would just wait to be a 40C.

If I now want to simulate my auxiliary heater, I'm at 427.
How can I then infer that 40D is my predecessor?


For G4, it would be 0x408, but I have no idea what it would be for G5.
You have 8 STGs (400-403, 40a-40d). 40d woke up a little later (@59,404).

408 seems incorrect because that ID isn't being transmitted by the bus.
If you look at the trace, the first message is from 40C.
I think that 40C is the Climatronic control panel.

SGM

Sorry, that was my mistake (I've been messing around with the settings too much). 08 refers to the speedometer, and 0C was the climate control.

0d is the pdc I'm also unfortunately not sure why it wakes up later.

Then, before entering the ring, warn him if he's using a fake ID.
59,405 40C 6 00 01 00 00 00 00
59,414 40D 6 0C 12 00 00 00 00

And how do I know that, specifically, 40C is my predecessor?
In this case, it's simple, because if I were a 40D, I would just wait to be a 40C.

If I now want to simulate my auxiliary heater, I'm at 427.
How can I then infer that 40D is my predecessor?

Okay, I understand. Please provide the German text you would like me to translate into English.
Think about it. You want to be part of the process. When you realize you've been left out of the loop, you complain about it.
If the message has an ID lower than yours and the next ID is higher than yours (or if the first ID is lower than the sender's), you are excluded from the chain. In this case, you should send a 'warning' message to the sender of the incorrect message, which should then include you in its subsequent message. Of course, the same applies to you; you have to deal with such messages as well.

English is no problem for me .
I have one further question: Is the ID (4)00 handled with a higher priority than mine (427)?
Is there always a controller with ID 400 present in the system?
If that's the case, it can always be treated as the highest ID.

Hi,

In the ring, you count all the way around: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, and so on.

Let's say you have three items: 3, 7, and F. The item 3 states that the next item is 7. The item 7 states that the next item is F. Since there's nothing logically following F, F takes the first position in the sequence again.

In a German Volkswagen Golf 5 or EU-spec car, there should generally be a 'Stg 400' module, but it's possible that some configurations might not include it.

As I mentioned in my email, it's theoretically also possible to program it statically, especially during testing.

Okay, that means I need to remember all the Alive/Ring messages and determine the successor based on them.

exactly

And if you do everything correctly, you can display really amazing things on the screen .

The fundamental prerequisite here is also the correct operation of the NWM .

As with other aspects, the correct operation of the NWM is also a fundamental requirement .

The nwm is, but I find that the easiest part of it; tp 1.6 and ddp are 1000 times more complex to understand.

As with other aspects, the correct operation of the NWM is also a fundamental requirement here.

I don't know, but I find that part to be the simplest. I think TP 1.6 and DDP are much more complex to understand.


There are also some nice commonalities in the NWM community , such as skipping rings, etc.

Ignition: ID 2C3, Byte 1, Bit 1.
Reverse light: ID 531, Byte 1, Bit 5.

They should fit...

Hey Maxx,

Does anyone know how to interpret the bits of the ignition switch status message (0x2C3)? I believe that the 8-bit field is a bitwise combination, not a set of constants. Here, I'm seeing values like 0x7 and 0x11, as well as 0x1, on the CAN monitor when I turn the key...

Only constant power cables run to the passenger door through the door coupling point. I'm wondering if the door control unit (window lifter) might also require terminal 15 for information, and if message 0x2C3 could be relevant in that context...

The power windows and central locking also work without the ignition being turned on .

Connect to the CAN bus in 'listen only' mode, close your car, and wait until no more messages are received over the bus. Then, use radio frequency to unlock it and observe what happens. That way, you'll understand how door control units (and most other control units connected to the CAN bus) work.

I once recorded a (longer) log from the comfort bus. I've now used this log to 'feed' the passenger door that I removed, meaning I'm replaying the recorded log to make the door think it's connected to a (disconnected) Golf V. After a while of silence in the bus, it seems the door control unit shuts down. Then, the window switch also stops working. Unfortunately, it seems that log replay alone is not yet sufficient.

I want to keep the door control unit operational, even without the rest of the vehicle, so that it can, for example... Window controls (from the driver's door) continue to be accepted and executed.

Could this NM-Ring protocol be causing me problems? If only I knew which messages or message sequences are important. I'll keep trying...

Could this NM-Ring protocol be causing me problems? If only I knew which messages or message sequences are important. I'm going to keep trying...
That's going to be your problem.