After we have a working Test Setup and properly working tools its time to start digging into bits and bytes.

I started looking at just the Multimedia can bus of the Scenic 3 Cluster without any other connected devices.

There is a LOT going on. even without any connected devices. This is why its important your tools are FAST. 

This is our baseline. We really know everything we see here is not from the Radio.

You can see a lot of those "A2" Bytes. These are filler Bytes. Now we know the cluster uses A2 fillers to make all messages 8 Byte long.

The bytes are all static in all 9 Messages. Nothing is changing. No obvious signs of anything trying to connect to anything.

The next step was to connect the radio to the cluster and see if something changes.

Oh yes. Things have happened. Awesome. 

We have new 81 Filler bytes. These come from the Radio. Now we have 15 Messages. 4 Messages have 81 filler Bytes ... wait a minute... 15 minus 4 isnt 9 (we had before) its 11 ... 

So we got 2 new ID´s coming from the Cluster....

Also noteworthy only one of the new messages from the radio is sent periodically.  The other 3 new messages from radio and the 2 from cluster only appear when something changes on the display or the radio and the display are connected together.

Thats calling for a "trace". A trace is a recording of the can network. You can see all the messages that were sent in the time you recorded the trace.

Because the messages are spread around pretty much the entire range of IDs a Filter is not useful. At least for now...

Pcan-View can export traces and Open Office Calc an open these traces as a some kind of usable Spreadsheet.

After i removed all the IDs with messages that have not changed when i connected the radio i was left with just the communication between Cluster and Radio...

Some more cleaning and colouring later and i had a pretty understandable representation of what is happening.

 Lets explore whats happening in short form first.

Handshake:

- In the first Row i connected the Radio. The Radio starts to send 0x00 at ID 5B8. 

- Also the Radio starts to send 0x28 0x00 at ID 3DF.

- When this happens the cluster stops sending ID 3CF.

- After that the Radio changes the content of ID 3DF to 0x28 0x08

- The cluster sends a 0x70 at ID 1C1.

- Radio sends a 0x74 at ID 5C1

- The Radio sends a last time ID 3DF and stops using it.

- Radio sends a 0x70 at ID 121

- Cluster answers with a 0x74 at ID 521.

Ok thats a lot to take in before we even saw anything that looked like Display data. Lets see whats has happened here in a little bit more detail. 

ID 5B8 is used by the Radio to tell its general state. It just used to tell us if the Radio is off (0x00) or on (0x10). It also turns to 0x11 for a short time if a Button on the radio was pressed.

The first message we saw from 3DF was 0x28 0x00. Thats the Radio telling us it is available for a connection to a display.

3CF is the same as 3DF but from the cluster side. That it went away after the Radio started using 0x28 0x08 on 3DF is the cluster telling us it has seen that the radio has seen the display :D. 

This is why 3DF also goes away. 3CF and 3DF are just used to tell each other that there is somebody to connect to.

The following 0x70 on ID 1C1 is the cluster asking the Radio if it is possible to establish a connection to 5C1 (notice +400 in the ID).

The Radio answers with a 0x74 on ID 5C1. Thats the OK to the Cluster for a connection from 1C1 to 5C1.

At this point we have started the Handshake and 3DF stops sending. The Radio and the cluster are sure there is somebody to properly talk to.

Now the Radio also sends a 0x70 on ID 121 (question to ID 521 for a connection) [notice again +400 ID]

The cluster promptly says "I saw your question and everything is ok" by sending 0x74 on ID 521.

And thats the whole Handshake of the protocol. Some hellos. A little bit of asking each other. and some Yes.

Once we have done this handshake we "basically just" start to send data to display.

Display data:

If the Radio wants to show something it starts to send on ID 121. 

Because you all have read my small writeup on wich tools i use you already have noticed that the Data the Radio wants to send to the Display looks really familiar to a ISO-TP data Block.

In row 20 the Radio sends on ID 121 a 0x10 followed by a 0x3F ... wich tells us that we have a First frame (FF) of a split data transmission (0x10). And that 62 Bytes of data (0x3F) will follow. Awesome.

Row 21 is the cluster telling us on ID 521 that it has seen the radio asking to send more data (0x30). also it tells the radio it should just send 1 block of the following data (0x01). And it tells the radio that no delay is needed (0x00) for sending the next block. This is a Flow control frame (FC)

Row 22 : The radio sends the first Packet wich contains only data. The First byte 0x21 is not data. instead it tells us that this is the first message of the whole Data Packet we will recieve. Thats a Consecutive frame (CF)

Again the cluster does its 0x30 Flow control thing in row 23.

Row 24 is like row 22. But its the second block of Data wich is indicated by the first byte saying 0x22.

This goes on until Row 38 where the Radio sends its last Byte of Data followed by 0x81 filler Bytes.

This is acknowledged from the cluster by sending a 0x74 on ID 521. (I recieved all Data Blocks OK)

 Our main display data transmission is done.

After everything happened the cluster sends 0x03 0x60 0x00 0x00 on ID 121. (0x03 tells us that 3 Bytes will follow). (A ISO-TP single frame message)

The radio sends on 5C1 a 0x74 ( a OK to 1C1).

That was the whole transmission. After that the Radio goes back to sending its status on 5B8 like in the beginning.

If the Cluster needs to be updated by a new Display message it just starts all over at Row 20.

In this Blog we have learned wich messages are used for communication. We also learned how the Protocol works and that ID 121 contains the display Data. 

In the next part we will have a closer look at a complete data packet from ID 121 and explore its bytes.