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

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

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.

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.

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

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

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 ?

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.

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.

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

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

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