Renault "Tuner List" Head Unit/CD changer hacking - Controls - Page 32

Vicne · 03-27-2006, 03:24 AM

Quote: Originally Posted by pippolippi

I saw something similar, so removing the optocoupler that indicates that the HU is on wasn't actually a good idea

I don't think so. We could simply wait a bit longer before we consider the HU is off...
That's just a symptom I noticed, but not blocking at all (unless you use HU OFF to power off your PC). For now, I just ignore it...

Quote:

...my program is not multithreaded (though the rs232 input buffer can receive data while transmitting).

Yes, and it's interesting to see that you have the exact same symptoms.
So the question is : how does the actual CDC deal with such a saturation. I'll go back to my logs and see if I can find traces of intense operations...
I'm still thinking it can be due to the fact that serial port drivers (*) wait for a "timeout" on the serial port before they release the call to "read()", so when we get multiple commands in a row, the "timeout" is not reached until the last HU command has been issued, and that is longer than the HU accepts to wait for the acknowledge...
The problem is made worse by a snowball effect : we don't reply in time because there are too many frames coming in, so the HU still sends more retry frames...
(*) Maybe not OS drivers, but the layers we have in between, Python interpreter for you and JVM + RxTx library for me

Quote:

In my latest (unreleased) test version, after sending a packet I check if the reply is 3d, in that case I receive that packet (that the HU sent at the same time I was sending mine) and then go on to see if I get the c5. I retry to send the packet several times if I don't receive the c5.
The problem is that this approach hasn't been very successful, but I hadn't time to investigate further. As in your case I get no more commands from the HU but it is happily acknowledging my messages.

Yes, that's weird. Tell us if you get some success with an "intelligent behaviour" such as the one you describe above... It'd also be interesting to know how-PIC based emulators behave when the HU saturates them with commands...
Mox ?
Peppuz ?
Ale ?

Quote:

Oh, just for the record, I'm also sending every possible command (0,1,2,....) each time I pull the stalk control (just to check if there's some command that we could use) and I found that if I send 21 (15 hex) the HU displays 'HI TEMP' and stops sending commands to the cdc.

Now link that with your Mobo's temperature sensor and you have one more useful information :-)

And are all these trial frames acknowledged by the HU or only some of them (which would discriminate valid/invalid frames) ?

pippolippi · 03-27-2006, 03:39 AM

Quote: Originally Posted by Vicne

I'm still thinking it can be due to the fact that serial port drivers (*) wait for a "timeout" on the serial port before they release the call to "read()", so when we get multiple commands in a row, the "timeout" is not reached until the last HU command has been issued, and that is longer than the HU accepts to wait for the acknowledge...
The problem is made worse by a snowball effect : we don't reply in time because there are too many frames coming in, so the HU still sends more retry frames...
(*) Maybe not OS drivers, but the layers we have in between, Python interpreter for you and JVM + RxTx library for me

In the case of pyserial the timeout only kicks in if there's no character waiting in the input buffer. In case the character is there it should return immediately. There may be some delay due to the fact that I issue several calls (one to read the 3d, one to read the sequence number, one to read the length and finally one to read the data), but I don't think that's significant.

Quote:

And are all these trial frames acknowledged by the HU or only some of them (which would discriminate valid/invalid frames) ?

The funny thing is that all of them seems to be acknowledged, even when I was sending obviously wrong data (i.e. in one of the tests I was sending the command code followed by three 'A', you know what I was looking for

)

Vicne · 03-27-2006, 05:31 AM

Quote: Originally Posted by pippolippi

In the case of pyserial the timeout only kicks in if there's no character waiting in the input buffer. In case the character is there it should return immediately. There may be some delay due to the fact that I issue several calls (one to read the 3d, one to read the sequence number, one to read the length and finally one to read the data), but I don't think that's significant.

Yes, that's what I read from your code.
What I don't understand is how the CDC can handle such intensive switching correctly. I can't tell if there are retries sometimes, but I can tell you that in months of usage, I never noticed it skipping 3 tracks instead of 2 (which is frequent with my emulator) and I am 100% sure the CDC never ever "crashed" the HU.

Quote:

The funny thing is that all of them seems to be acknowledged, even when I was sending obviously wrong data (i.e. in one of the tests I was sending the command code followed by three 'A', you know what I was looking for

)

Yes, I see you're after the Holy Grail.
Well, so the acknowledge probably means "grammar OK" (I guess it doesn't acknowledge commands with incorrect FCS, right ?), not "command recognized". Bad luck, but well, it's interesting anyway.

But you're right, I guess many other commands exist, because currently there are huge holes in the frame type numbering : 12 identified (now 13) with a maximum of 71 (47h)
(Note however that it's worse in the opposite direction: 12 identified with a maximum of 148... and I can't see 136 more messages the HU could send to the CDC...)

pippolippi · 03-27-2006, 06:04 AM

Quote: Originally Posted by Vicne

Yes, I see you're after the Holy Grail.

Unsuccessfully, I should add

Quote:

Well, so the acknowledge probably means "grammar OK" (I guess it doesn't acknowledge commands with incorrect FCS, right ?), not "command recognized". Bad luck, but well, it's interesting anyway.

I cannot say it's incidental or by design, but this is probably what allows the mp3 vdo changer to support cd text/track title: it would just send them as a different packet type which the tuner list will simply acknowledge and ignore, while a different head unit would display.
Bacwards and forwards compatibility. That won't last long since VDO has been acquired by Siemens

Quote:

But you're right, I guess many other commands exist, because currently there are huge holes in the frame type numbering : 12 identified (now 13) with a maximum of 71 (47h)

Why 71, I think the maximum is 256 [0..255]. Anyway I was hoping that the hu would reject invalid messages, in order to concentrate on the valid ones. Since that's not the case I think it's an impossible task. Not that's really necessary, since what we know already is enough.

Quote:

(Note however that it's worse in the opposite direction: 12 identified with a maximum of 148... and I can't see 136 more messages the HU could send to the CDC...)

well, not all of them have to be defined and valid commands

Vicne · 03-27-2006, 12:10 PM

Quote: Originally Posted by pippolippi

Quote:

But you're right, I guess many other commands exist, because currently there are huge holes in the frame type numbering : 12 identified (now 13) with a maximum of 71 (47h)

Why 71, I think the maximum is 256 [0..255]

If I had to define a protocol, I'd start with 1 and use numbers incrementally. And as the maximum observed value is 47h (or 71 decimal) for PLAYING, I would be tempted to think other values up to 71 are defined, even though it seems doubtful...

pippolippi · 03-27-2006, 01:07 PM

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.
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.
I still see some duplicates packet (maybe I'm not acknowledging them fast enough) but the filtering on the sequence number is effective.
It seems it is possible to receive one or more packets from the HU after sending a command and before receiving an acknwledgment. To keep the program simple (i.e. not multithreaded) if the reply is 3d instead of c5 I receive the packet, and wait for a new reply (eventually the c5 comes, if it doesn't I retry using the same sequence number).
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). OTOH when the HU recognizes the command it sends a "Play" command.
There are now two levels of "verboseness" (3 if you count verbose off): 10 (only error and other important messages) and 20 (every packet sent or received), you invoke the program with the "verboseness" level as the second parameter, e.g.:

Code:

python cdc.py 1 20

will use the first serial port and show everything while

Code:

python cdc.py 1 10

will use the first serial port and show only errors. With no parameter at all

Code:

python cdc.py 1

it will show only normal messages (i.e the decoded commands from the HU).

mox · 03-27-2006, 01:36 PM

Quote: 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.

Vicne · 03-28-2006, 02:50 AM

Quote: 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.

Quote:

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 ?

Quote:

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...

Quote:

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).

Vicne · 03-28-2006, 04:02 AM

Quote: 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.

pippolippi · 03-28-2006, 07:58 AM

Quote: 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

Quote:

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.

pippolippi · 03-28-2006, 08:02 AM

Quote: 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.

Vicne · 03-28-2006, 10:37 AM

Quote: 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...

Quote:

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...

Vicne · 03-28-2006, 10:44 AM

Quote: 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

Quote:

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...

pippolippi · 03-28-2006, 11:27 AM

Quote: 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.

Vicne · 03-28-2006, 01:00 PM

Quote: 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

Quote:

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...