3C8

[mcaldwelva]

I think Tomi has pretty well documented this message, but I have a few additional bits:

data[0], bit 7 -- this is documented, but I wanted to note that we may need to turn this bit off for repeat messages so as not to overwhelm the head unit

data[0], bit 6 -- appears this is only used one time to notify that the CDC has turned on (transitioning from state 0 to state 3).  The 9-3 seems to be okay without it.

data[3], top half -- in addition to the documented states (0,3,4), 5 appears to be pause (head unit stops sending 0xB0 when muted and sid displays --:-- when not muted), 6 & 7 both appear to be related to rapid play

data[7], bit 5 -- display RDM on sid

[Seth]

Cool, thanks mcaldwelva! I was never able to get the RDM mode to work (ie, detect it) in my testing, but it would be cool if we could use that somehow (although, there isn't a AVRCP command for randomize to send to the device...).

I think Karlis was trying to implement the mute feature, but his 9-5 doesn't have a mute button. I was able to turn mute on by holding the SRC button on the steering wheel, and any volume change will turn it off. I'm sure this could be implemented.

[mcaldwelva]

In re. data[3], I'm not sure that there is a pause state after all. It looks like the head unit will only send the unmute/resume command when you press the mute button in state 4.

State 5 does seem to mean something to the head unit though. Possibly the real CDC used it to block commands while changing discs.

[Karlis]

I got a hold of an actual CD changer and did some sniffing.

We currently send this: 0xE0,0xFF,0x3F,0x41,0xFF,0xFF,0xFF,0xD0 every 1000ms (+/- 10%). I believe 0xE0 is somehow wrong in this frame as it has bits 5-7 set. From what I saw from the stock CD changer, that byte is 0x20 (bit 5 is set). This leads me to assume that:

byte 0, bit 7: 0 - sent on basetime, 1 - sent on event
byte 0, bit 6: 0 - status change due to internal operation, 1 - status change due to CDC_CONTROL frame
byte 0, bit 5: 0 - disc presence signal is not valid, 1 - disc presence signal is valid

Now this is untested and it also should include handling of a case when there's an incoming CDC_CONTROL frame. I'll do some more digging.

[Karlis]

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.

[mcaldwelva]

This is great that you can finally see what the actual CDC does. All I had to work with before were some iffy log snippets on ecuproject...

I've taken data[0], bit 7 to literally mean "this message is different from the last message I sent". I kind of assumed that it always appeared on the first message of each second because the time data changed. The only way I can think to verify this would be to pause the track. Or maybe switching back to radio after the CDC has started up.

I'm not certain about data[0], bit 5 is, but it appears to always be set. I think somewhere in this message is a bit that simply says the magazine is present (separate from the individual discs loaded). It might be this bit or it might be part of the "married" bits (0xd0).

One other thing... the head unit sends AT LEAST one 0x3C0 message per second. It may send more if a user presses buttons generating a command. Do you know if the CDC always sends 0x3c8 messages in pairs? Or did it send the second message as a response to a button press?

Looking forward to more findings! Thanks!

[Karlis]

mcaldwelva wrote

This is great that you can finally see what the actual CDC does. All I had to work with before were some iffy log snippets on ecuproject...

I've taken data[0], bit 7 to literally mean "this message is different from the last message I sent". I kind of assumed that it always appeared on the first message of each second because the time data changed. The only way I can think to verify this would be to pause the track. Or maybe switching back to radio after the CDC has started up.

Yeah, that's sort of what happens with "0xA0" and consequential "0x20" does. "0xA0" means "something changed on CDC side" (next second/minute of the track). "0xE0" means "CDC is complying to the command sent by IHU" (SEEK+/- button has been pressed on IHU). And then till the next event CDC just sends "0x20".

I'm not certain about data[0], bit 5 is, but it appears to always be set. I think somewhere in this message is a bit that simply says the magazine is present (separate from the individual discs loaded). It might be this bit or it might be part of the "married" bits (0xd0).

data[0], bit 5 is disc presence validation. Sort of a double check that CDC has validated spin-up and playback of a disc from magazine

One other thing... the head unit sends AT LEAST one 0x3C0 message per second. It may send more if a user presses buttons generating a command. Do you know if the CDC always sends 0x3c8 messages in pairs? Or did it send the second message as a response to a button press?

0x3C0 is put on the bus every 1000ms AND if there's a new event. CDC doesn't send frames in pairs. Instead it also puts frames on "basetime" (every 1000ms) and if there's a new event (local or remote | "0xA0" or "0xE0" respectively) with a 50ms delay from previous frame sent on "basetime".

Looking forward to more findings! Thanks!

Sure, I'll keep you updated.

[Karlis]

So I've implemented some changes in the code. Now BlueSaab takes action depending on what state it is. If IHU is off or is in non-CDC mode, we send the idle frame:

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

When IHU is on and goes into CDC mode, we immediately (50ms) react to that by sending an acknowledgement frame:

0x3C8 : 0xE0 0xFF 0x3F 0x41 0xFF 0xFF 0xFF 0xD0

Then we continue on with sending basetime frame (every 1000ms):

0x3C8 : 0x20 0xFF 0x3F 0x41 0xFF 0xFF 0xFF 0xD0

We do this till an event comes in from IHU (another button has been pressed or IHU gets powered off or goes out of CDC mode), then we acknowledge the fact again and either continue on sending basetime frames or switch back over to idle frames.

I'm using bitwise operations to alter data in cdcGeneralStatusCmd frame on the fly.

From what I've seen this is as close as it gets to the behavior of the real CD changer. Tested this out on my car tonight and wasn't able to break it. The code worked and serial output showed that frames are being sent in order and on events as necessary.

The code has been checked in Github. Feel free to give it a test. Any comments are welcomed.