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

mox · 02-15-2006, 03:11 PM

Quote: Originally Posted by Vicne

By the way, it would be very interesting to know if the connects2 follows the same "3V/12V" convention. It would be easier to do 0V/12V if it's compatible, but if connects2 bothered making 3V/12V, it's probably a requirement...

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.

Horizontal: 2ms/div -- Vertical: 5V/div

Horizontal: 0.2ms/div -- Vertical: 5V/div

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

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.

Putput · 02-15-2006, 03:20 PM

Quote:

Yes, thanks, that can be a helpul source of inspiration.
Today 09:10 AM

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

Ale · 02-15-2006, 03:30 PM

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

Ale · 02-15-2006, 03:44 PM

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.

Vicne · 02-15-2006, 05:09 PM

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" :-)

Vicne · 02-15-2006, 05:30 PM

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

Quote:

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.

Vicne · 02-15-2006, 05:51 PM

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

Vicne · 02-15-2006, 06:58 PM

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

Vicne · 02-15-2006, 07:06 PM

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

Quote:

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.

Quote:

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

Vicne · 02-15-2006, 07:53 PM

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.

Putput · 02-16-2006, 03:28 AM

Great news that you have the hardware part up and running with no errors

.

And now my comments:

Quote:

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

A complete set of data for all the possible actions that can be performed between both units should be sufficient. Of course there's still the question of what will happen when one of the devices gets disconnected (power off) in the middle of a data exchange or when you change CD's. Perhaps this has to be tested so that a prog knows how to handle when connection restarts. This should be relatively easy to do, hook up the logging circuit and power down the CDC and after restart the HU and see what happens.

Quote:

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.

I have no objections to open source, reminds me that I still need to post the source for the Parser tool. (If you still think its necessary, it was rather quick and dirthy

)

Quote:

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 ?

I think a have no objections to use Delphi as a programming tool

. If someone has a particular reason not using Delphi, I could live with VC. But I have major objections in using any .Net descendant! (Yes I know its easy, wide spread, used by professionals, ..... but I can tell you a different story that costed our company a huge amount of money and a lot of discontented customers.) Besides, our prog has to run on systems that are usually not loaded with heavy hardware and huge amounts of disk space so offer 20 or 30 megs of disk space just to install a framework to get a prog of 100k running is if you ask me a wast of disk space. You could add another 10 mp3's for that

.

Quote:

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 suggest that the first goal should be an 'extended' Connects2 dll. Something that connects with HU to enable the SPDIF input and translate HU commands into events. When using Asyncpro serial toolkit (=> Open Source = http://sourceforge.net/projects/tpapro/) for handling the serial communications I can have a dll like this ready before the end of next week. Another thing could be a program that connects to the HU and emulates keystrokes (including Multimedia keys) on HU commands, translation between HU commands and keystrokes could be done by a simple text or XML file. When this file is blank or if it doesn't exist the program simply enables the SPDIF and nothing else.
We could contact frontend developers to integrate it, even if only the pause function works it would be a great thing to have, perhaps they are more interested in a dll.

Quote:

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

Didn't you knew that

?
This is going to sound hard to believe but I'm one of those lucky guys that owns a 'Update List' radio with AUX input and it works great. But as I mentioned before, that pause key was the one thing that made me decide to help in this project.

Vicne · 02-16-2006, 03:39 AM

Ale,

Conditions inside the car will be different, but I'd like to think more about ways to improve noise immunity without making the circuit over complicated.

Re-reading your post about the possibility of the errors being due to threshold problems, I thought again about the issue and maybe have another explanation of the bad noise immunity I have.

As I said, most of the errors were due to 0's becoming 1's. For example, 010... would have been read as 011...
Going backwards through the circuit, it means the original signal (including start bit) was something like HHLH but was read as HHLL (H=high,12V and L=low, around 3V(*)). So it looks like sometimes the LH transition is not enough to reach the Low to High threshold. According to the data sheet, this point is around 1.8V but can be as high as 2.4V (max).
And the input resistance which should be around 5K typ could be as low as 3K (min). Clearly, the 3K-7K range shows they just put it there as a "pull-down", not with a precise value people should rely on to make a divider...

So taking these two limits, reaching 2.4V with a 18K:3K resistor bridge would need an input voltage of 16.8V ! OK, it's unlikely that I got such an extremely rated component, but it is quite understandable that even if it works most of the time at 12V, a slight voltage drop at the input can cause the voltage not to reach the sufficient level to step over the threshold.

In this case, adding hysteresis would make the problem worse of course.

If this reasoning is correct, I might lower the 18K to a 15K, for example, but other chips might have other resistor or threshold values - still in the spec - that would cause the opposite problem (low voltage not low enough to reach HL threshold, and I'd like to avoid one of the readers having difficulties with a circuit he build according to mine.

So I think it would be good to make the gap wider between high and low input levels (increasing S/N ratio by increasing Signal), and that's why I'm coming back with the idea of diodes that would offset the input voltage. Let's say if I put 5 diodes with a drop of 0.6 each, for a total of 3V drop, then when input signal is at 12V, it would set the input pin at 9V, far above the 2.4 maximal threshold, and when signal is at 3V, diodes wouldn't let current flow at all, with the internal resistor forcing the input pin at 0V, far below the 0.6 minimal threshold.

OK, spikes wouldn't be "divided" like with a divider, but levels would be more frankly determined...

OTOH, if the chip has the minimum resistor value of 3K, it would mean a 3mA (9V/3K) current would be drawn when level is high, and maybe that's not so good for the HU.

I'd like to hear your opinion on that.

Thanks

Vicne.

(*) Please note that according to the latest measurements by Mox, I begin to seriously doubt of this value...

Putput · 02-16-2006, 06:35 AM

I made a new version of the parser program, the data field in the CDC log is splitted in Type and Data, 2 buttons added to save parsed data into a CSV file. This way you can directly import it into Excel and save a lot of cut and paste work.

BUG!! Please check which file you downloaded, Parser.rar containes a bug when parsing the data. Parser1.exe is OK.

Vicne · 02-16-2006, 06:40 AM

Quote: Originally Posted by Putput

A complete set of data for all the possible actions that can be performed between both units should be sufficient. Of course there's still the question of what will happen when one of the devices gets disconnected (power off) in the middle of a data exchange

Err... not likely to happen for the CD changer in real conditions. And for the HU, I can't remember having seen any "stop" command when the HU is turned off. That raises an interesting question : why doesn't the CD go on playing ? Permanent 12V is still there (you can eject the changer tray when HU is off) and no stop command. I see 2 possibilities :
- "Remote out" pin (also called "Antenne+") gives the signal that HU is Off (it would be different than ACC then)
- The CDC doesn't receive any acknowledges to its messages and concludes the HU is off.

Quote:

or when you change CD's.

This was included in my first logs (2x eject/reinsert cycles, one letting the changer check everything before switching source to CDC, one trying to switch to CDC immediately, in which case it displays CD CHECK while it loads CDs in turn. Tell me if you meant something else.

Quote:

Perhaps this has to be tested so that a prog knows how to handle when connection restarts. This should be relatively easy to do, hook up the logging circuit and power down the CDC and after restart the HU and see what happens.

You mean, what if the CD changer is powered on while head unit is already on ? The good question being if CD changer presence is checked on every HU boot or at regular interval. In the second case, it would mean having to power the HU OFF/ON once PC is booted up :-( - or going the PIC way as Mox first suggested.
I think I'll try first to let my "spy pass-through" plugged into the HU only, without the CD changer connected, and see what comes from the HU (hopefully something like CristianC saw) then plug the CDC while HU is on (hope it won't fry anything) and see what happens.
The only one thing we won't be able to do without a PIC is let the HU source on "CD changer" forever. On my current setup, it's the case: when I start the car in the morning, control wires make the HU think the CD changer will start playing, then during PC boot I hear nothing (no SPDIF signal) and once it's booted, music starts.
[Well, actually, in my case, that will be possible as I intend to delay the relay switch until PC is booted up, so I'll listen to the CD changer while the PC boots and will then switch to PC output while emulator is ready :-)]

Quote:

reminds me that I still need to post the source for the Parser tool. (If you still think its necessary, it was rather quick and dirthy

)

:-)
Let's make an example : I'll post the ugly MTTTY source tonight and you'll post the quick and dirty Parser source, so the shame will be shared :-)

Quote:

I think a have no objections to use Delphi as a programming tool

. If someone has a particular reason not using Delphi, I could live with VC. But I have major objections in using any .Net descendant!

I completely agree. I'm definitely not a .NET fan.
BTW, which version of Delphi are you using ?

Quote:

Besides, our prog has to run on systems that are usually not loaded with heavy hardware and huge amounts of disk space so offer 20 or 30 megs of disk space just to install a framework to get a prog of 100k running is if you ask me a wast of disk space. You could add another 10 mp3's for that

.

I completely agree. For the same reason I refrain myself from using Java although I'd like to.

Quote:

I suggest that the first goal should be an 'extended' Connects2 dll. Something that connects with HU to enable the SPDIF input and translate HU commands into events. When using Asyncpro serial toolkit (=> Open Source = http://sourceforge.net/projects/tpapro/) for handling the serial communications I can have a dll like this ready before the end of next week.

Excellent. This library looks promising indeed.

Quote:

Another thing could be a program that connects to the HU and emulates keystrokes (including Multimedia keys) on HU commands, translation between HU commands and keystrokes could be done by a simple text or XML file. When this file is blank or if it doesn't exist the program simply enables the SPDIF and nothing else.

Strangely enough, I have the feeling your architecture is the mirror of mine :
I thought of a standalone executable (service maybe) speaking to the HU, and optionally loading a DLL plugin to speak to a client app, while you propose a DLL to speak to the HU and an executable loading it to speak to the client.
The advantages I see in the former is the 1-n relationship :
- Executable with no plugin is sufficient to emulate the CDC
- Executable with one plugin talks to a client app
- Executable with multiple plugins talks to multiple apps either at the same time or separately (NEXT/PREV talk to Winamp, 1-2 talk to frontend to switch to Music/GPS screen. 3-4-5-6 talk to custom app to select by artist/genre/year

Anyway, exe and dll are not fundamentally different, it's just a matter of point of view.

What would be really cool would be to follow an already existing "client side standard" like the ATI one : we could then load any plugin they've already written and make the HU behave like a remote control for the PC. A simple mapping from HU keys to ATI keys would then suffice to control ACDSee, QuickTime, PowerDVD or WinTV, to only cite a few. Imagine presenting your PowerPoint slideshow to your colleagues in your car, flipping slides with your HU stalk controls ! Geeky, isn't it :-) :-)
ATI's SDK user licence agreement explicitely says "Licensee may create the Extensions solely for use with the Remote Wonder™". But we won't be creating them and I don't see an article forbidding to use them for another purpose, or create a compatible "host application", as long as we don't "decompile, reverse engineer, disassemble or otherwise reduce the Software contained in the SDK to a human-perceivable form"...
So I guess the use here would be perfectly legal.

But IANAL, so if someone knows of an open-source equivalent, it would probably be safer

Note that we can always do that later, defining our own simpler plugin interface first, and then write an "in between" plugin, loaded by our CDC emulator and loading in turn an ATI-compatible plug-in...

Quote:

We could contact frontend developers to integrate it, even if only the pause function works it would be a great thing to have, perhaps they are more interested in a dll.

Once again, I'd prefer that our app communicates information to the front-end instead of the front-end loading our app. Not only does it need zero-effort from the frontend developers-apart from telling us what to send (keystrokes, WM_messages, network requests, whatever), but I also have the feeling it's cleaner on the long term (if we change versions, fix bugs, etc).

Quote:

Didn't you knew that

?
This is going to sound hard to believe but I'm one of those lucky guys that owns a 'Update List' radio with AUX input and it works great. But as I mentioned before, that pause key was the one thing that made me decide to help in this project.

Funny enough : we're 3 in here (you, Mox and I) that don't need this as we have an alternative solution (respectively AUX input, Connects2 and CD changer) :-) :-).

Personally, what I'm missing most is NEXT/PREV. When I'm alone on the road in "full shuffle" mode and Winamp picks one of my daughter's favourite songs (7 years), you bet I'd like to have easy access to "NEXT" :-)

peppuz79 · 02-16-2006, 07:09 AM

Quote:

Funny enough : we're 3 in here (you, Mox and I) that don't need this as we have an alternative solution (respectively AUX input, Connects2 and CD changer) :-) :-).

Hi Guys,
thanks everybody for all dump's, i'm working to develop everything in little interface with atmel and max233(232/202), i think my yampp project can be work fine (After the new code of course), i'm avaible for everythink you have need....

Best Regards
pep