3C0

[mcaldwelva]

Hey guys, I thought it might be helpful to start some threads specific to the messages we're dealing with. I think it's practical to think of 0x3C0 as a CDC command rather than a button press. The head unit does the work of interpreting the actual button presses, its own and the steering-wheel, depending on whether it's in TRACK or PLAY mode, a long press, etc. It looks like this message is sent every 0.5s. I believe this is a complete list of commands (data[1]) for the 9-3:

0x00 no command
0x14 deselect CDC
0x24 select CDC
0x35 next track
0x36 previous track
0x45 rapid play forward/fast-forward
0x46 rapid play reverse/rewind
0x59 next disc
0x68 select disc from data[2]
0x76 random toggle
0xb0 mute/pause
0xb1 unmute/resume

It looks like we don't get 0x84 or 0x88 from the SEEK mid-segment press on the 9-3.

During mute, 0xb0 is sent periodically (every 2 seconds) until the CDC responds with the correct state or the system is unmuted.

During "rapid" play, the head unit also expects the CDC to respond with a state change to stay in rapid play mode.

data[0] == 0x80 literally means this message is different from the last. So we will generally see this with each command, but we will get repeat messages (data[0] == 0x00) when holding down the << or >> buttons in PLAY or TRACK mode.

[Karlis]

Thanks, mcaldwelva! Great information. Yeah we're using 3C0 to control our module and the audio source over AVRCP.
In the beginning we look at the CAN message ID and act accordingly. For example if the ID is 0x290 (steering wheel buttons) and the [0] element of the message is 0x80 (something has changed since the last message) we look at the [1] element of the message to determine which button has been pressed and what AVRCP command we should relay to RN52 bluetooth module. If the [0] element of the message is not 0x80 we assert that a "long press" button event has occurred and we act accordingly. This gives us the freedom of using any button on IHU or steering wheel.
And yes, you're right about differences between IHUs on 9-3s and 9-5s. They both seem to use different systems (AS2/AS3?). We're in the process of sniffing the CAN messages that are seen on different button presses. So far we've seen differences in "SEEK" button functionality on IHU and the way 9-5s handle steering wheel buttons. As in if SEEK+ button is pressed on steering wheel - two CAN messages with different IDs come in resulting in two "jump to next track" commands being sent to RN52 bluetooth module over AVRCP...

[mcaldwelva]

Cool. I figured you had most of this info. Do we know if the only difference in 0x3c0 messages between the two is mute (0xb0 & 0xb1) being 9-3 only and scan (0x84 & 0x88) being 9-5 only?

I saw "dupes" when I acted on both the 0x290 message and the 0x3c0 message. Is that where it's coming from? Or are you actually getting two 0x3c0 messages?

On my 9-3, it seemed like I couldn't really detect a long-press from the 0x3c0 messages. If I press & hold some buttons (1 - 6 or NXT) I will only see a single message with that command for the entire time that the button is pressed. I do get multiple messages if I press and hold SEEK + or -, but in this case I think there's always an action for the CDC. The only exception I ran into was RDM. Every once in a while I'd press & hold and it would turn on and immediately turn off because of a repeat message, so now I check for 0x80 on this guy.

[Karlis]

Yeah, that's exactly what I'm seeing on my 9-5 with regards to the dupes. When we're handling both 0x290 (steering wheel buttons) and 0x3C0 (IHU) duplicate events (e.g. "jump to next track") take place. If we handle 0x3C0 only - both steering wheel and IHU buttons work. But on 9-5s only. If we handle 0x290 only, steering wheel buttons work on both 9-3s and 9-5s but then again IHU buttons don't.... That's one of the problems I'm trying to get my head around at the moment.

As for the "Mute" and "Scan" functionality - so far it looks like these are the only differences between 9-3s and 9-5s. This is still being researched and tested though...

As for long-press - so far I've noticed appropriate messages coming in only when a button that controls the "original" functionality of CDC. Example SEEK+ on steering wheel:

short press: 290 80 00 10 00 10 00 00 00
long press: 290 00 00 00 10 00 10 00 00

I also haven't been able to see any messages coming in for long press of "1-6" buttons on IHU. The only ones sending some messages on long press on IHU seem to be "SEEK" (in the middle), "SEEK+", "SEEK-" and "CD/RDM".

[mcaldwelva]

That's funny that you're not getting the next track events from the IHU on the 9-3... I do get all of the button commands on my 9-3 via 3c0...  I noticed that the IHU won't send any of the button commands via 3C0 if the CDC state was 0 or 3. It looks like you're already sending 4 for the state, so maybe there's something else in the message that's confusing the 9-3? This is the message I used for testing the CDC interface:

0xA0,0x00,0x3F,0x41,0x01,0x01,0x01,0xD0

The only real difference looks like data[1]. Maybe the 9-3 expects 0?