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

Originally Posted by Ale

Hello, after some weeks here i'am!. working on the PIC firmware but slowly (i do not have so much free time) finally i have the first PIC emulator!

Great !
Maybe that's not the first emulator as Peppuz seems to have had some success already (see here) - not counting the Connects2 guys :-) - but that's really encouraging.

The first test in the car pass ok, but after a few second the HU show LINK-ERR, if i restart the PIC the HU display TRACK CD 1, the track number is blank and after few second come back to LINK-ERR.
I don't know if is a hardware problem (the pullup of tx transistor) or a protocol error, becouse after the play cmd(HU 13h) i answer with these packet:

Code:

3D	C	2	21	5	17					
3D	D	6	20	1	3	9	5	1	19	
3D	E	6	20	1	3	9	5	1	1A					
3D	F	2	21	5	14									
3D	10	6	20	1	3	9	5	1	4					
3D	11	B	47	1	1	0	0	59	0	0	0	57	0	6E

This seems to be correct, and the fact that the HU accepts to switch to CDC confirms that, so I doubt it's a hardware problem... Are you sure your emulator goes on sending frames like the last one every second (with incrementing ID and corresponding FCS) ? In all cases, the HU showing LINK ERR seems to be due to the HU "timing out" because it didn't receive an "I'm alive" (either 47=PLAYING or 20=STATUS) frame in time (e.g. it's the case if you cut the Tx line with the an actual CDC plugged)

Anyway i will arrange the project file (C languge with microchip 16f688)and post here a sample of the project the next week.

Yes, please do. You're still definitely on the contest to be the first to publish your PIC-based emulator how-to :-)
And anyway, like for the PC-based emulator, I think that for now, the more versions we have the better.
Keep on the good work.

Well, guys, I finally proudly announce that my hardware adapter reached its final version. I'll post the details in the next few days, but apart from some values and the relay switching, it's exactly Pippolippi's design. It's now in place in the car, the HU and PC are back at their place and I could check all the functionality with the sound coming from the PC that was actually emulating the CDC :-). And well, it's cool.

I've also improved the Java emulator : fixed numbering above track 16 and a brand new "contextual" event mapping Plugin called RRExtendedPlugin, among other things, allowing NEXT/PREV to change track in the AUDIO screen and Zoom in/out in GPS screen (this is even cooler :-) ). It's in CVS but not yet "packed".

However, playing intensely with the emulator, I observed several things :
- the duplicate frames are really frequent, and sometimes up to the point where the HU increments the ID, so we cannot distinguish them from a second separate command...
- the HU can become so saturated that it doesn't acknowledge commands (or not quickly enough). After 3 missed tries, I consider HU was switched off and I reset the emulator, causing false "HU_OFF" events
- Saturating further, I succeeded in "crashing" the HU 2 or 3 times. Well, it's not really crashed, it remains on CDC position, it still acknowledges PLAYING frames, but SPDIF is muted and it does not send any command to the PC anymore. Turning the HU off and back on restores the normal behaviour.

I really think there's a timing problem behind those problems. Maybe we should insert a delay between frames we send or make the emulator half-duplex (currently, it is multi-threaded and full-duplex : it can send a frame while receiving a command, for example)

Well, enough for today. I'm happy the hardware part is behind me because that definitely was the hardest from my point of view.

Have a nice day/evening/morning

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

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

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 ?

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

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.

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

Originally Posted by pippolippi

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