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

OK. First I know you're all waiting for new data, so here are 4 new sets of data, and here's the story :

First, I added the 10 uF capacitor Ale recommended. Then I let the radio play for around 20 minutes on "tuner" position (1st set).

I then tested a few conditions I had not tested before (back and forth between cd changer and tuner, CD over 1 hour). Here's the script for the second set :
0 : Start capture
15 : Turn head-unit on (it's on tuner position)
30 : Switch to CD changer
45 : Switch to CD 2
60 : Press PREV / PREV (Track 13, over 1h)
75 : Switch to CD 3
90 : Press PREV / PREV (Track 14, over 1h)
105 : Switch to tuner
120 : Turn head off

Then I wanted to push the system to the limits :-) and made intense skipping inside the same CD (lots of PREV / NEXT not waiting for the CD to start playing), then between CDs (3 - 2 - 1 - 2 - 3 - 4), and again inside the same CD (3rd set).

Finally, I moved the resistors closer to the chip inputs as advised (which was not so simple. I'll have to rewire the breadboard). And started an intense skipping session again (4th set).

After a bit of analysis (thanks again Putput for the Parser), there are still a few CRC errors, but much less than in the first data sets. The 3 first sets only have errors 100ms after HU starts. The last set has more errors, but it may be due to a loose wiring.

Side-note : Putput, a few **minor** notes about the Parser : the checkboxes don't seem to be applied on file load : if you first check "only show errors", then load a file, then everything is displayed. Uncheck and recheck the option and it's OK.
And for the sake of perfection, I think the labels are reversed : left should be "Load CDC", not "Load HU" :-)

Originally Posted by mox

Ok, here is the result, straight from my garage The signal below was taken from pin 14 of the blue ISO connector, with a connects2 VRNX001 interface hooked up instead of the stock CDC.

Ground level was set at the vertical center. As you can see, low signal level is not entirely 0V, but definitely not 3V. It turned out to be less than 1V. High level is pretty much 12V, as could be expected. Data at pin 14 appears about once every second. Pin 13 seems idle, unless keys are pressed on the HU or stalk. Low and high levels at pin 13 are equal to those on pin 14, i.e. 1V/12V

Now that's interesting (and confirms the feeling I had when capturing a few minutes ago) : I'm beginning to wonder if the oscilloscope I'm using is correct regarding DC offset. On the 5V/division scale, I'm getting roughly 3V/12V, but if I go to 2V/division, the low level seems to be around 2.5V and if I switch to 1V/division, the low level is around 2V... So it looks like the 0V is not on the center line. However, I see no way to know the offset it's at. Moreover, I even resetted the scope to factory settings and still get that offset.

Once again, it's not mine and I don't have the manual, but at least it's not obvious.

Did you make a precise measure of low level on pin 13 (from HU) ? We can't be 2Volts apart...

My suggestion to you to get rid of the annoying 3V bias would be a comparator like a simple LM324 with a threshold set at around 6V.

Yes, that would work. Although, I'd like to keep the circuit as simple as possible and if the level is around 1V, I normally don't even have to use a divider (and that would explain why CristianC could connect it directly to his PC serial port)

Anyway, thanks very much for the measures. They also mean that we can probably don't need to offset our output. A simple pull up resistor and a transistor to the ground would most probably do the trick.

Originally Posted by Putput

Here it is, Idon't know where I picked it up but I assume that it works. Never tested it.

Well, apart from the values of the capacitors (which are different because I used a low-power MAX3232 - don't know if it was a good idea after all), there isn't much difference :
- V+ (pin2) is connected to a capacitor linked to the ground and not VCC in my case, but the data sheet says either VCC or Ground is OK, see bottom right of page 12
- it also uses one of the converters as an inverter :-)

Thanks for sharing.

Originally Posted by Ale

Here i extract the list of HU command in excel: the only command i can't correct with the help of crc was the "random-on".
The yellow are the one i suppose the corrected value with the help of crc-check.

Nice work indeed.

I just rewired the breadboard and got 2 full dumps without any error :-) :-). Hopefully, once soldered, I won't have those silly loose connections. Thanks again.

The first dump (set #5) is simply a full song playing, including the automatic change to the next track (this is something we didn't have yet).
The second dump (set #6) is to help distinguish the commands that were "yellow" or "red" in your excel sheet. I ran the following sequence of operations :

0 : Start capture
15 : Turn HU on. CD starts playing where it stopped (in track 2 of CD 1)
30 : Press FFWD
45 : Release FFWD
60 : Press Rewind
75 : Release Rewind
90 : Press Random (takes a few seconds to turn ON)
105 : Press Random again (takes a few seconds to turn OFF)
120 : Press Random again (takes a few seconds to turn ON)
135 : Press Random again (takes a few seconds to turn OFF)
150 : Press CD 2
165 : Press CD 3
180 : Press CD 4
195 : Press CD 5
210 : Press CD 6
225 : Press FFWD in track 1 until we reach track 2
? : Release FFWD
? : Turn HU off

BTW, the dumps of today are only in raw flat files, but hopefully loading them in Excel is straightforward (open as fixed witdh text). If you want to mix HU and CDC dialog as I did in the first Excel, insert two empty columns between time and hex value in the sheet where you loaded HU, copy this sheet's contents and paste it at the bottow of the CDC sheet, then order them by byte number.

Originally Posted by Ale

Ok, no problem, just a training for my english writing... eh eh.
I wi'll try to explain my hypothesis:
I have read again the datasheet and i noticed that the Input Hysteresis is only 0.3V with typical low=1.5V and high 1.8V.
This means that there is about 1.1V margin to switch to opposite level from 0.65 to reach 1.8V and from 2.6 to reach 1.5V. But a difference of 1.1V means about 5V before the divider, i.e. in the input signal from HU. Too much for a spike?? And eventually enough to pass through the 2.5V offset of diodes.

Now I understand why diodes were not so good.

I think is more likely there is a shift of 1.1V at the GND pin of max232, that cause to change the input level. So my conclusion is to filter the power line near the max232 vcc/gnd.

Yes, that obviously highly improved the behaviour.

i was wrong about connecting the 33K resistor to -5V. But you can connect it between inp/out of the cascaded inverter for adding hysteresis. (it will low further the logical 0 level of 0.65V and increase the logical 1 level of 2.6V for better noise immunity).

Oh, so you mean a kind of feedback, dragging down level 0 and pulling up level 1 ? I see... Well, if needed, I might go that way, but it seems your good advices already made miracles :-). Thanks a thousand times

... and thanks again to Putput for the tool that allows me to say you made miracles :-)

For the 100th post of this thread, I think we're far enough to begin thinking of the emulation side...

Here are a few points, straight out of my (tired) brains :

1) Do you think of missing sequences of operations or special conditions that we could need logs for, before I begin rewiring my breadboard with PC > Head unit direction ? Currently, getting more logs is just a matter of extracting the head unit, plugging the mini-iso and launch my MTTTY on ecstasy. Once my breadboard is unassembled, it will be a real hassle...

2) Do we all agree that software we write here will be open sourced ? I'd rather not finish the project to hear someone say "hey, there's code I've written in there, if you want it, just buy it". If someone objects to the open-source nature, please say it now.

3) What language do we choose ? My own experience went through Basic 15 years ago, Pascal 12 years ago, Visual C 9 years ago, and exclusively Java for 6-7 years now. And I can tell you it was hard to go back to VC when you get used to Java :-). Unfortunately, I think Java is too heavy for a resident interface module so VC would be my choice if I was alone... I only used Delphi once or twice and it looked good, fast and relatively easy, but I am definitely not a specialist. However, Putput seems to have good experience, so why not ?

4) Once we have the "dumb" emulation (just faking a CD changer the way Connects2 does to activate the SPDIF input), where do we want to go ?
- I would advocate against any direct link to an app such as Winamp (although we can begin with that), and would prefer a more "building block" approach, with for example the ability so send custom windows messages or fake PC keyboard presses when we press head unit buttons. That would allow to control not only music but also video, GPS, whatever. Here are a few ideas:
- ATI Remote Wonder does almost that. See http://remotew.free.fr/plugins.htm .
- WinLirc also uses a plugin architecture, although they advertise only one : Winamp :-)
- (Please note that the plugins above are written in Visual C...)
- Wouldn't it be good to interface with major Frontends ? Maybe we should contact frontend authors to get their opinion on the best way to control them... What frontends are you using (RoadRunner for me) ?
- At first I thought next/previous + 6 buttons was very scarce, but with a little imagination, we can build a very interesting user interface : look at PhatNoise's VOIT...
- I'm also thinking of indexing my music collection (with Lucene for example) and allow to browse it by year, genre, artist, or any ID3 tag, and use speech-to-text to give feedback to the user... I think it's the most natural way of informing the driver...

5) Oh, and yes, am I the only one who will actually try the emulator ? :-)

Any comment is welcome as usual.