Hello Thomas,
The basic principle seems to be very similar to that of the Passat.
'6C0 definitely refers to the display data, as all the text from your photo is contained within it.'
To determine what each individual control bit represents for the display, you would need to program your own module that precisely reads the data from your small log.
The AI sends something, and you initially receive the same output, but then you can modify individual bits.
If you have the option to program your own module, I would first try the following (the RNS unit should not be connected to the CAN bus):
1. Step: The module must register itself with the ring, following these principles:
- After powering on (connecting the power supply for the first time), you wait until you have received the CAN message with ID 428 five times.
- then you send it once:
436 6 16 02 C0 04 00 00 // RING-ID Navimodul : Statusmessage um sich im Ring anzumelden
// D0=16: eigene Adresse (16 + 420 = 436)
// D1=02: Status GerÀt will in den Ring
// D2,D3: irgendwelche Status Bits
- now you are only responding to the message:
428 6 16 01 00 00 00 00 // Ring-ID KI: KI spricht das nÀchste GerÀt im Ring an
// D0: Adresse vom nÀchsten GerÀt im Ring (16+420 =436)
// D1: 01 = normale Ringmessage
and then send the answer:
436 6 08 01 00 00 00 00 // Ring-ID Navigation: Navigation spricht das nÀchste Modul an ( da nur 2 GerÀt im Ring sind, ist dies wieder das KI)
// D0: Adresse vom nÀchsten GerÀt im Ring (KI) (08+420 =428)
// D1: 01=normale Ringmessage GerÀt ist betriebsbereit)
You also send a message in response to:
6C1 2 A1 0F
die Antwort:
6C0 1 A3
Don't forget your message 661, which also needs to be sent periodically.
This should be enough for your tests to ensure that the ring is running normally. Note for later: When the ignition is off, you should send a different value to D1 so that the bus can enter sleep mode. However, you need to log this separately first.
Probably, a connection test between 6c0 and 6c1 hasn't been run yet. This would be the next step you would need to address.
Once you have this running, please get back to me here, and I'll provide further information on how you can continue programming it.
Nevertheless, here are a few more details about the display data (much of this is based on assumptions
6C0 8 13 52 05 82 00 1B 40 30 // Single message 5 Datenbytes werden an das KI ĂŒbermittelt
// D0: 0x13 Highnibble 1=Single message, Low Nibble= 3 = 3.Message
// D1: Datentype ob Cursurmessage=52,Textmessage=57
// D2: LEN: Anzahl der Datenbytes fĂŒr die Message (incl. Options Bytes)
// D3-D5 Optionsbytes
// D6-D7 Textdaten
and not actual knowledge, but it helped me with my Passat):
The data exchange with the display can occur either using a single message or through a multi-part message.
Single:
6C0 8 24 52 05 02 00 1B 40 30 // Multipart 1.Teil (Aufbau wie oben beschrieben) Cursurmessage=52, 5 Datenbytes ( 3 Optionbytes u. 2 Datenbytes)
6C0 8 25 57 07 06 00 01 2D 2D // 2.Teil Textmessage=57, 7 Datenbytes ( 3 Optionsbytes + 4 Datenbytes) ==> '----'
6C0 8 26 2D 2D 57 05 06 00 09 // 3.Teil Textmessage=57, 5 Datenbytes (3 Options + 2 Data)
6C0 8 27 65 65 57 05 06 00 09 // 4.Teil Textmessage=57, 5 Datenbytes (3 Options + 2Data) ==>
6C0 8 28 4B 4D 52 05 02 14 1B // 5.Teil ==> 'km', Cursurmessage
6C0 8 29 2C 14 52 05 02 00 2D // 6.Teil Cursurmessage=52, 5 Datenbytes
6C0 3 1A 39 16
Multimessage: (Send multiple display lines at once)
6C1 1 BB // Quttierungs byte vom KI (Bx= LowNibble(vom letzten D0-Byte + 1): BB= B+ LowNibble(1A)+1
The first data byte (high nibble) serves as an identifier for the message type: 2x = multipart message, x = sequential counter.
The low nibble includes a continuous counter used to verify the communication. This counter is also used for the low nibble in the receipt byte (Bx).
Each data block is acknowledged by the AI.
:-)
I hope this is enough to get you started for now. I need a break now

.
Best regards,
Andi.
PS: If anyone has more information, please let me know.
-