Thread: Renault "Tuner List" Head Unit/CD changer hacking - Controls

Originally Posted by Vicne

It'd also be interesting to know how-PIC based emulators behave when the HU saturates them with commands...

If I flood the Connects2 with NEXT/PREV commands by turning the stalk dial encoder thing like mad, it seems as if the commands are queued in a small FIFO buffer. The sound mutes and unmutes at every click of the stalk rotary switch and this continues about 10 to 15 times after I stop spinning the switch. Apparently the FIFO stack is capable of buffering a number of commands in order to have them processed properly.

I have tried my best to crash the HU, but to no avail.

Originally Posted by pippolippi

Attached is a new version of cdc.py
It still has some problems but I didn't manage to hang the HU neither to produce LINK ERRORs with this program.

Very good. I'll upload it to SourceForge.
Not crashing the HU is my next goal too.

It has the test function (i.e to send commands starting from 0 each time you pull the stalk control) and some of them do interrupt the sending of commands by the HU.

As not all stalk controls are the same, what do you mean by "pull the stalk control" ? Is it NEXT ? PAUSE ?

I still see some duplicates packet (maybe I'm not acknowledging them fast enough) but the filtering on the sequence number is effective.

I also thought it was fixed in my program, but it seems I sometimes get so many retries that the HU increments the sequence number, so I'm still getting duplicate commands in the output...

Note that the "playingCD" packet is necessary for the HU to recognize the simulated CD changer, but it's not taken into account everytime to show the cd number (i.e. if I turn off and on the HU with the program running it won't show the cd number).

Well, CD number is not contained in PLAYING frames, so I think that's why the HU cannot "take it into account" :-)
As far as I can tell, CD number is only sent as last byte of frame 20h (STATUS) and second byte of frame 26h (TRAY_STATUS) during the CDC boot process, plus second byte of frame 22h (TRAY_OPERATION) when changing CD.
If you want the CD number to change without the user pressing any button and without faking a reboot of the CDC, you can simulate that the current CD has reached its end and CDC loads a new one. There's a log here containing this sequence (around 480s).

Originally Posted by mox

If I flood the Connects2 with NEXT/PREV commands by turning the stalk dial encoder thing like mad, it seems as if the commands are queued in a small FIFO buffer. The sound mutes and unmutes at every click of the stalk rotary switch and this continues about 10 to 15 times after I stop spinning the switch. Apparently the FIFO stack is capable of buffering a number of commands in order to have them processed properly.
I have tried my best to crash the HU, but to no avail.

That's very interesting. It makes me think that :

1) Connects2 guys don't crash HUs. Good news for them and their customers

2) The FIFO thing obviously shows that even if it is counter-intuitive, it's probably not good to reply too fast to the HU. My emulator currently tries to follow as quickly as possible, acknowledging requests immediately and queuing all reply frames asap, even before dispatching events to plugins. But maybe during the time the HU mutes/unmutes, it is not able to read incoming frames, so its buffers overflow, it looses queued answers and it concludes that if there are no answers, the command has to be sent again...
There's definitely much work that can be done regarding timing.

3) You have the same mute/unmute sequence as I do, while with the actual CDC (but you can probably test this if you have single CD too), the sound mutes only once, then the dashboard display follows your quick rotary switch movements but with sound still off, then finally sound unmutes when you have finished playing like mad. So I re-parsed old dumps with intense skipping on the actual CDC and formatted them in Excel (attached). The very interesting thing is that track change sequence is interruptible : while a minimum "stand alone NEXT" goes like (without header, ID, length and FCS) :

Code:

27h 80h <track#> 22h
21h 0Ah
21h 05h
27h 10h <track#> 22h

, when you queue multiple "NEXT", you only get a "27h 80h ..." per request, and only after you stop your mad skipping, the full sequence goes on and terminates with a "27h 10h ..." which causes the HU to un-mute.
This is much more elegant of course but a bit harder to deal with.

I'll get back to that as soon as I have a little time.

Originally Posted by Vicne

As not all stalk controls are the same, what do you mean by "pull the stalk control" ? Is it NEXT ? PAUSE ?

Sorry, I should have been more specific. The thing that you have to pull is the wheel that skip tracks or changes the radio station, the result while listening to the radio is switching from tuner preset->tuner list->tuner manual

Well, CD number is not contained in PLAYING frames, so I think that's why the HU cannot "take it into account" :-)

I know, I was referring to the frame that says the selected CD

Code:

  def playingCD(self,number):
    """Sends the cd number currently playing"""
    return self.sendPacket('\x20\x01\x03\x09\x05%s' % chr(number))

that I send in the start sequence as well as I receive a cd change command. However not everytime it is accepted by the HU and it displays a blank cd number.

Originally Posted by Vicne

2) The FIFO thing obviously shows that even if it is counter-intuitive, it's probably not good to reply too fast to the HU. My emulator currently tries to follow as quickly as possible, acknowledging requests immediately and queuing all reply frames asap, even before dispatching events to plugins. But maybe during the time the HU mutes/unmutes, it is not able to read incoming frames, so its buffers overflow, it looses queued answers and it concludes that if there are no answers, the command has to be sent again...

I doubt that they took the pain of implementing a FIFO for outgoing commands and then forgot to implement an input buffer. Anyway it's easy to test, just wait a while before sending the c5 back.

Originally Posted by pippolippi

I doubt that they took the pain of implementing a FIFO for outgoing commands and then forgot to implement an input buffer.

True...

Anyway it's easy to test, just wait a while before sending the c5 back.

I think I'll still send the C5 asap, but wait before sending the "27/21/21/27" frames...

Originally Posted by pippolippi

Sorry, I should have been more specific. The thing that you have to pull is the wheel that skip tracks or changes the radio station, the result while listening to the radio is switching from tuner preset->tuner list->tuner manual

???

I didn't know one could pull that wheel !!!

Not sure it's the case in my car. I'll test when I get back home in a few minutes... If it does, for sure I should have RTFM of the HU

I know, I was referring to the frame that says the selected CD

Code:

  def playingCD(self,number):
    """Sends the cd number currently playing"""
    return self.sendPacket('\x20\x01\x03\x09\x05%s' % chr(number))

that I send in the start sequence as well as I receive a cd change command. However not everytime it is accepted by the HU and it displays a blank cd number.

Oh, I see... That's weird...
Well, otoh, I admit I never saw these packets while CDC was playing, only while it was doing operations...

Originally Posted by Vicne

???

I didn't know one could pull that wheel !!!

and not only switches between tuner preset->tuner manual->tuner list, if you keep it pulled for a while it will start the search to fill the "tuner list" memory, and I think that last function is independent of the source selected.
Anyway, the "short pull" is sent as 24 (hex) to the cdc.

Originally Posted by pippolippi

Anyway, the "short pull" is sent as 24 (hex) to the cdc.

Jeez, ...
Yes, I just tested that and noticed the 24h frame
I tried it on CDC position and it skips to the next CD (CD1 > CD2 > CD3 ... > CD6 > CD1 ...). Now it would be interesting to spy the protocol for that event too, but unfortunately my spy setup is dismantled now... Although, I still have a spare M/F mini-iso set (coming from my previous "pass-through" setup) so I might rebuild a spy circuit one of these days

And not only switches between tuner preset->tuner manual->tuner list, if you keep it pulled for a while it will start the search to fill the "tuner list" memory, and I think that last function is independent of the source selected.

Edit: Confirmed : When holding the wheel for a long time, the tuner seems to begin searching for stations.
The "NEXT_CD" event has been added to the protocol page on Sourceforge, along with new info about frame TRAY_STATUS

Anyway, that's a very interesting interface for a tree menu navigation (up/down/enter + timeout to cancel), for example for navigation in your mp3 filesystem...

Edit :
It's really a pity all these commands mute the sound though :-(
If displaying ID3 tags is the Holy Grail, preventing the HU from muting is second on my wishlist...