Re: VW Golf5 interior parts | Posts 64+

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.

What is the actual purpose of this MN protocol? However, I think I understand the process. Does a control unit disconnect from the CAN bus if the ring protocol fails? There are flags called SleepInd (Bit 12, Ind = Indicator???) and SleepAck (Bit 13), which, according to CAN bus measurements, appear to be linked to the Ring/Alive bits (Bits 8 and 9) already mentioned in this thread (resulting in values 0x11 and 0x12).

The protocol serves to inform other control units about what devices are connected to the CAN bus, and to wake up and put control units to sleep.

If a control unit wants to establish a communication ring but is unable to do so, and eventually no longer has any communication requests of its own, it goes back to sleep. If there are any communication requests, it goes into emergency mode.

Okay, I've now simulated the ring. I'm sending the NM messages for 0x00, 0x01, 0x0a, 0x0b, and 0x0e to the disconnected door control unit from the Golf 5. The address of the door control unit is 0x03. Actually, the door control unit also seamlessly integrates into the system, and it does so by:

ID: 0x403 DLC: 6 DATA: 0x0a 0x01

After a few ring cycles, the door control unit sends:

ID: 0x403 DLC: 6 DATA: 0x0a 0x11

That is, the ring signal bit (0x01) is linked with a SleepInd signal bit (0x10). The door control unit continues to participate in the ring cycles.

Why does it suddenly go into sleep mode (if SleepInd actually indicates that) despite being connected to the ring? How can I keep it 'awake'? I am also continuously sending the ignition status message (ID 0x2c3).

It is not turned off. It is simply indicating that it would like to go into sleep mode. As long as the other control units do not also indicate that they want to go into sleep mode, the door control unit will not enter sleep mode either. This is the case for all NWM control units.

And yes, you are sending the ignition status. But the wrong . You are sending the key status, but not what the body control module allows . Please check for the ignition signal in 0x575. That will be the correct one. This message is sent by the BSG. The other one from ZAS...

And yes, you are sending the ignition status. But the wrong . You are sending the key status, but not what the body control module allows . Please check for the ignition signal in 0x575. That will be the correct one. This message is sent by the BSG. The other one from ZAS...

I have now managed to send window and mirror control commands to the passenger door that has been detached from the vehicle. At a minimum, a functioning ring protocol and a cyclically transmitted Msg-ID 0x591 (window release = bit 1) are required here.

I have now wired up my second Climatronic control panel for testing.
Connected and linked to the CAN-Hacker, and there it is – NM messages are being sent.
I then experimented a bit with sending ring messages.
Now I'm having a problem where the control panel is no longer sending anything on the CAN bus.
Could it be that the control panel is in a fault state where it no longer sends any CAN messages (Bus-OFF)?
Is it possible to get this part working again without a VAG-Com diagnostic tool?

It needs to be triggered via CAN, but as mentioned several times, it simply cannot function securely with the CANhack. The CANhack uses a high-speed transceiver. The Climatronic system requires a low-speed transceiver.

Disconnect the control unit for a while to allow all capacitors to discharge, then connect it to the CANhack and turn the power supply back on. Then, the control unit should normally also start up briefly and send CAN messages.

But as I said... CANhack + LowspeedCAN = unpredictable reliability!

Okay, thanks for the information!
Then it's quite possible that what the CAN hacker 'saw' were simply coincidences.

Well, he will be seen doing more than she has, and without any action, she wouldn't even be portrayed in can tool, would she?

Yep. The interface must have sent an acknowledgment. But due to 'temporarily optimal' conditions, it might sometimes work. The rule will be that it simply won't work .

Have you already integrated a low-speed transceiver into the CAN Hacker Interface?

Okay, but not me. And I won't do it. I tried using an adapter. The adapter was supposed to connect to the CANhack and then switch to low speed. However, the adapter didn't work the way I wanted it to. Now he's lying in the corner and no one is paying him any attention.
Replacing a transceiver can be problematic because you need to disable the existing one and then also fit the new transceiver into the enclosure. This isn't very easy to do. It would be better if the interface came with both transceivers built-in and offered a switching option.

The longer disconnection from the power supply has caused the control panel to reactivate.
I'm going to start working on the NWM now.
Let's see if I can manage this.

Regarding the transceiver, I was considering replacing the high-speed version with a pin-compatible low-speed transceiver.
Assuming such a part exists.

SGM

Unfortunately, there are no pink-compatible low-speed transceivers.

That's obviously stupid .
Well, let's see what we can do.
Once the control panel reports that it's ready, I can continue testing with the high-speed transceiver.

SGM