Re: 3C8

Posted by Karlis on Sep 08, 2016; 4:43am
URL: http://bluesaab-forum.90.s1.nabble.com/3C8-tp9p665.html

I did some more sniffing of an actual CD changer and here are my findings:

To begin with we are currently reporting CDCs (BlueSaab's) status on the bus with a frame containing static data: 0x3C8 : 0xE0 0xFF 0x3F 0x41 0xFF 0xFF 0xFF 0xD0. This is a bit wrong and here's why:

There's this frame that CDC puts on the bus when it's in an idle state:

0x3C8 : 0x20 0x00 0x01 0x01 0xFF 0xFF 0xFF 0xD0

Notice the first byte. I believe that means "I'm (CDC) ok, I'm not doing anything. Sending this frame on 'basetime' (1000ms) and I'm still married to the car". This is sort of a health check.

Now, when IHU activates CDC there's this frame on the bus:

0x3C0 : 0x80 0x24 0x00 0x00 0x00 0x00 0x00 0x00

We already know that 0x80 means "There's a new event on the bus. Please pay attention!" and 0x24 means "CD/RMD button has been pressed twice on IHU".

Immediately (~50ms) after this, CDC replies with:

0x3C8 : 0xE0 0x00 0x01 0x31 0xFF 0xFF 0xFF 0xD0

First byte now has changed to 0xE0 which I believe now means "Ok, I heard you, I'm replying to you know as per your (IHU's) request. I'm ready to work and I'm still married to the car".

Then CDC starts putting a pair of two frames on the bus with ~50ms delay between the two and then 1000ms between current and next pair:

0x3C8 : 0xA0 0x00 0x01 0x41 0x02 0x01 0x48 0xD0 and
0x3C8 : 0x20 0x00 0x01 0x41 0x02 0x01 0x48 0xD0...

...which essentially means "Ok, so I'm (CDC) playing 48th second of 1st minute of track number 2. I have six disks loaded in the magazine. I'm sending this out as an update triggered by myself and there are no other changes (0x20 of the second frame)". This keeps on going with seconds, minutes, tracks being incremented accordingly.

I believe for the purpose of BlueSaab, we could implement code changes, that would recognize in what state CDC is supposed to be with regards to IHU and if there are some changes, acknowledge them by sending a frame on a "remotely triggered event" (0xE0) and then keep sending frames with 0x20 as the first byte because essentially we are not changing anything from BlueSaab's side till IHU tells us to go back into idle state and the whole "acknowledgement" process begins again.