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

Originally Posted by pippolippi

What I found interesting is that he connected the pc directly, with no interface.

I just tried that and it doesn't work
I connected just pins 15 (gnd) and 13 (edit: 14 actually, anyway I tried both) to the serial port and got nothing at all while switching on the HU. The led on the serial adapter (which indicates reception or transmission) stays forever lit. The serial adapter still works and I hope I didn't fry the HU.
In case anyone is interested, attached is the quick hack I wrote (in python) to test, but since the connection didn't work I couldn't really see if it works.
It needs a python interpreter (obviously) and pyserial.
(the forum doesn't accept .py files, so I added a .txt to the extension)

Originally Posted by pippolippi

I just tried that and it doesn't work
I connected just pins 15 (gnd) and 13 (edit: 14 actually, anyway I tried both) to the serial port and got nothing at all while switching on the HU. The led on the serial adapter (which indicates reception or transmission) stays forever lit. The serial adapter still works and I hope I didn't fry the HU.

Mmmh, my guess is that your serial port is less tolerant than his, and probably you're stuck on a "high" level.
However, what do you mean exactly by "serial adapter". Do you mean you have an external serial adapter ? I never saw a motherboard with an activity led for the serial port...
What you could try is either divide the voltage by the means of a resistor (like I did) or offset it down with one or two diodes in series.

In case anyone is interested, attached is the quick hack I wrote (in python) to test, but since the connection didn't work I couldn't really see if it works.
It needs a python interpreter (obviously) and pyserial.
(the forum doesn't accept .py files, so I added a .txt to the extension)

For debugging purpose, don't hesitate to
use my MTTTY. It's not 100% stable, but it works rather well...

Originally Posted by Vicne

However, what do you mean exactly by "serial adapter". Do you mean you have an external serial adapter ?

Yes, an usb one (my laptop doesn't have an integrated serial port)

What you could try is either divide the voltage by the means of a resistor (like I did) or offset it down with one or two diodes in series.

I thought about putting a divider (like CristianC), but until next weekend I don't think I'll have time to tinker with it (edit: btw, I put a diode in the tx line, in order to avoid to inject negative voltages to the hu, but I didn't connect it. Oh, and since I don't have a blue mini iso connector I just used 2.8mm fastons with a little tape to avoid contact between adjacent pins )

For debugging purpose, don't hesitate to
use my MTTTY. It's not 100% stable, but it works rather well...

I don't have a cdc, so my little program is an attempt at an emulator. edit: and I doubt MTTTY would work under Linux

Originally Posted by Ale

I'll add some explaning text tomorrow becouse i'am late...

Let me try to do this as a homework and correct me if I'm wrong, OK ? :-)

1) On the HU Tx and Remote, you just put a pull-down resistor then a buffer, to increase input impedance compared to the direct serial port.
2) The buffers make sure that output levels are 0/12V. This is not RS232 compliant but should be RS232 compatible.
3) The PC TX is linked to a 5.1 kOhm resistor to the ground, presenting a 5K input impedance.
4) Same for the DTR, except that 3 buffers are wired in parallel to provide enough current for the relay, which has its freewheel diode.
5) The hex buffer chip is powered by the head unit, the resistor and 12V zener limit potential overvoltage to protect the IC, and the voltage is stabilised with 2 capacitors for both high and low frequency noise.
6) Grounds are linked together, and with the IC ground

Is that globally correct ?

A question : If the HU TX is terminated with a transistor and a pull-up resistor, don't you fear the 22k resistor will drag the voltage down too much ?

Originally Posted by Vicne

Let me try to do this as a homework and correct me if I'm wrong, OK ? :-)

yes that is all correct, almost all rs232 threshold shuold be near 1.5-2V, so our buffered out 0/12V should work well.

Originally Posted by Vicne

A question : If the HU TX is terminated with a transistor and a pull-up resistor, don't you fear the 22k resistor will drag the voltage down too much ?

Yes, we can choose a higher value like 47K, but i think that HU-TX line to guarantee the noise immunity doesn't has a high impedance value.
The R1 and R2 protect the buffer from negative voltage of rs232, thanks to the internal diodes protection, limiting the negative input current to -12v/47K=255uA.

I want to use my notebook for the test but it has only a IRDA interface on COM3, so i looking for an adapter RS232-IRDA that i will connect to my interface so i don't have to worry about spike or short circuit with the notebook.
My first goal will be to test the emulator protocol, I have found a MSCOMM32.OCX that i want to use with VBA & EXCEL.
The second goal will be to build an hardware interface for AUX input.
When i have a well working sw i will think how to port it to a PIC (but i haven't experience with PIC).
It will be very interesting to find a Analog/SPDIF small module becouse assembling a test board will be very difficult without a industrial printed-circuit.

Originally Posted by pippolippi

Yes, an usb one (my laptop doesn't have an integrated serial port)

OK, I see.

I thought about putting a divider (like CristianC), but until next weekend I don't think I'll have time to tinker with it (edit: btw, I put a diode in the tx line, in order to avoid to inject negative voltages to the hu, but I didn't connect it. Oh, and since I don't have a blue mini iso connector I just used 2.8mm fastons with a little tape to avoid contact between adjacent pins )

Better avoid that indeed :-) .

I don't have a cdc, so my little program is an attempt at an emulator.

Oh, yes, that's true !
But in this case, don't despair. I myself never saw anything coming from the HU while the CDC was in "remote off" mode (see this post and the attached log.
Only CristianC said he saw data coming from the headunit when no CDC was connected... So either he doesn't have the exact same HU as me, or he made a certain operation on the head unit that I didn't do to get data on there (try to change source maybe ?)...

In my case, it' always the CDC that does the first step, so I guess you'll have to do actual emulation before you receive anything...

and I doubt MTTTY would work under Linux

Yes, that's a "detail" I missed :-)

Originally Posted by Ale

Yes, we can choose a higher value like 47K, but i think that HU-TX line to guarantee the noise immunity doesn't has a high impedance value.

That's where experience speaks :-)

The R1 and R2 protect the buffer from negative voltage of rs232, thanks to the internal diodes protection, limiting the negative input current to -12v/47K=255uA.

OK, I see.

I want to use my notebook for the test but it has only a IRDA interface on COM3, so i looking for an adapter RS232-IRDA that i will connect to my interface so i don't have to worry about spike or short circuit with the notebook.

Yes, that'd be super safe indeed... If you put it at one meter or so behind plexiglass, the adapter can even explode without your PC being endangered :-)

My first goal will be to test the emulator protocol, I have found a MSCOMM32.OCX that i want to use with VBA & EXCEL.
The second goal will be to build an hardware interface for AUX input.
When i have a well working sw i will think how to port it to a PIC.

With a little bit of chance, we'll soon have :
- A delphi emulator
- A python emulator
- A visual basic emulator
- A pic emulator
- An mp3 player speaking directly to the head unit

Wow, I like that :-). I'm rethinking of Visual C, because it'd be so coooool to have one emulator more :-). Then we can make a contest and distribute prizes :-)

(but i haven't experience with PIC).
It will be very interesting to find a Analog/SPDIF small module becouse assembling a test board will be very difficult without a industrial printed-circuit.

I think you might team up with mox who had the same idea from the beginning.
As for the Analog/SPDIF, here is the Connects2 solution :

Originally Posted by mox

Analog-to-SPDIF:
TL064 (stereo AF amp), linked to a 5331AKS (stereo A/D converter with serial output), linked to a CS8405A (SPDIF encoder), linked to the HU's SPDIF input.

(see Renault Scenic II - SPDIF PC )

OK, here's an Excel file summarizing the status of the decoding.
The second sheet is the data from the last two logs, formated thanks to Putput's decoder and interleaved along with the "script". Operations and results come in the first few columns, then data coming from the head unit and finally on the right data coming from the cd changer.

As usual, take care that due to multithreading issues and my own imprecision in executing commands, some lines may be swapped between the three sets (acknoledgements before command, etc).

The first sheet summarizes the general frame format, as well as all frames encountered in the (rather comprehensive) logs, a tentative explanation, a symbolic name and an example. Note that most of the HU > CDC part was directly taken from Ale's decoding. The CDC > HU was where I put the most work, but is still far from complete. The first column of this sheet represents my estimation of the reliability of our decoding (V = ok, I = incomplete, ? = speculation)

Of course, we don't need 100% completeness to write a successful emulator, but the more we understand, the easier troubleshooting will be.

Side note about CRC errors and re-synchronization (Putput) :
These logs didn't have any error except that the head unit was once turned off while CDC was sending a frame. In that case, Putput's parser read the following bytes as if they were an actual frame, found what he thought was the "CRC", and dropped the whole "frame" as CRC was wrong, starting with the next byte and propagating the de-synchronisation. A more robust approach would probably be that if the first byte of a frame isn't 3Dh, we just skip that *byte* and go on with the next one *without dropping any frame*. The XLS version attached has been fixed manually in that regard

Feel free to check, complete, enhance, document or correct this information, of course.

**OUT OF DATE. AN UPDATE OF THE ROSETTA STONE IS AVAILABLE IN A POST FURTHER BELOW **

Hello

My HU is Philips 22DC229/62

When I start the HU, I see on the PC terminal screen: 3D 01 FE FD 3D 01 FE FD 3D 01 FE FD

!!! The terminal was set to display hex format

CristianC