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

Originally Posted by pippolippi

Well, that wasn't a good idea, since not only it doesn't work, but while rewiring the circuit to revert it the previous, working, one, I made a mistake and blew the transistor. I hope it's just the transistor and not the hu

Fortunately it was just the transistor
Everything is working fine now.
The only problem now (didn't see it before) is that sometimes either I'm not acknowledging fast enough or I'm too happily flushing the input buffer when I shouldn't, so I get the same message twice, and if I push keys too fast I'll get a link error (an interesting detail is that when I restart the program the link error clears and I get the queued up commands, so the hu has a fifo to send commands until they're acknowedged, and the link error is probably caused by this fifo filling-up, it was happily acknowledging my continuous "I'm playing" packet though).
Anyway, now that I have a working serial adapter and a working interface, I'll go and seek an spdif adapter to go on hacking. Probably not this week (I'm really busy).

Originally Posted by pippolippi

Fortunately it was just the transistor

Glad to hear that.

The only problem now (didn't see it before) is that sometimes either I'm not acknowledging fast enough or I'm too happily flushing the input buffer when I shouldn't, so I get the same message twice

Oh I'm "happy" to hear that, because I see that too since I'm using the RxTx library and I didn't know if it was a bug in the library (sending two calls for the same data) or a performance problem. I've optimized as far as I could (*) - well it's still Java, no assembly :-) - but it still happens. I worked around that by storing the ID of the last processed frame and discarding frames received twice...
(*) plugins are now called asynchronously so multiple frames can be processed by plugins in parallel while the program continues listening to HU commands...

and if I push keys too fast I'll get a link error (an interesting detail is that when I restart the program the link error clears and I get the queued up commands, so the hu has a fifo to send commands until they're acknowedged, and the link error is probably caused by this fifo filling-up

I never had that until now, but that still can happen, maybe I didn't saturate the HU enough :-)...

it was happily acknowledging my continuous "I'm playing" packet though).
Anyway, now that I have a working serial adapter and a working interface, I'll go and seek an spdif adapter to go on hacking. Probably not this week (I'm really busy)

OK let us know how it goes...

Originally Posted by Vicne

Glad to hear that.

Oh I'm "happy" to hear that, because I see that too since I'm using the RxTx library and I didn't know if it was a bug in the library (sending two calls for the same data) or a performance problem. I've optimized as far as I could (*) - well it's still Java, no assembly :-) - but it still happens.

I don't think it's a performance problem (it's just 9600bps), but because in the last revision I'm discarding the input buffer each time I start a transmission, and, since I also lowered the delay between transmissions from 0.5s to 0.2s (just to push the envelope, so to speak), this creates more probabilities to lose a packet.

I worked around that by storing the ID of the last processed frame and discarding frames received twice...

I don't consider it a workaround but good practice, after all the sequence number is there for a reason.

I never had that until now, but that still can happen, maybe I didn't saturate the HU enough :-)...

Yes today has been the first time I saw this. Probably related to the same flushInput() where it doesn't belong. OTOH is interesting to know (that the HU uses a send fifo I mean).

OK let us know how it goes...

Sure.

Pippolippi,
Just a question about your opto-coupled circuit :
Is the transistor on the HU Tx only used as an inverter, or did you put it there to bufferize the input. In other words, do you think is it dangerous to power the opto-coupler directly (through a resistor) from the HU Tx ?
If it's just an inversion problem, I think we can get the same effect by inverting on the other side, connecting the PC's Rx to pin4 and placing the resistor as a pull down between pin 4 and DTR instead of a pull up between pin5 and RTS...

All this to pursue the goal "simpler is better" of course :-)

Originally Posted by Vicne

Pippolippi,
Just a question about your opto-coupled circuit :
Is the transistor on the HU Tx only used as an inverter, or did you put it there to bufferize the input. In other words, do you think is it dangerous to power the opto-coupler directly (through a resistor) from the HU Tx ?

It's not dangerous but it doesn't work.
In my first try I didn't use any transistor at all and it didn't work. Since I don't know which direction wasn't working (it did work in my loopback test outside the car), I added a transistor in both directions. When I saw that it worked, I tried to remove the transitor you mention (i.e. using the original circuit for the HU->TX connection, with the resistor and output taken from the collector instead of from the emitter) since I thought it wasn't necessary but I coulnd't establish a connection. I rewired the circuit on the breadboard in a hurry and that's when I blew the transistor
Now I won't touch the circuit anymore: I just removed the optocoupler that detects the HU on (I don't need it anymore) and lowered the remaining 3k3 pull-up resistor (on the right side) to 1650 (actually put the two 3k3 resistors in parallel): it works with 3k3 but the levels are better with a lower resistor (but I wouldn't lower it if it still had to supply two optocouplers instead of one).

Hi,

I'm sensing this is the forum I've been waiting for since I got this twingo car two years ago. I want to plug an Ipod and I'm sure I can use your info to do so, just not sure how yet
But Ipods have more information to give to the HU, like titles, and I suspect CD changers that support CDText also give more info than just CD index and title, do you have any idea wether it is possible to send the HU a track title ?
Also, do you have any idea about cheap SPDIF converters ?

Thanks a lot for all the info in any case, I would never plug an Ipod without being able to mute it from the handy remote the HU comes with !

Originally Posted by FroMage

Hi,

I'm sensing this is the forum I've been waiting for since I got this twingo car two years ago. I want to plug an Ipod and I'm sure I can use your info to do so, just not sure how yet
But Ipods have more information to give to the HU, like titles, and I suspect CD changers that support CDText also give more info than just CD index and title, do you have any idea wether it is possible to send the HU a track title ?
Also, do you have any idea about cheap SPDIF converters ?

Thanks a lot for all the info in any case, I would never plug an Ipod without being able to mute it from the handy remote the HU comes with !

Well, in brief, unfortunately, the answers are "not yet", "no" and "sort of" :-)

- Not yet : currently, the only implementations we achieved imply the use of a PC to send serial commands. The hardware part currently is a simple pass-through with level conversion. Several people here have indicated interest in developing a pic-based version of the emulator though, which means a PC wouldn't be needed anymore.

- No : Nothing more than "track number / cd number" can be displayed as far as we know. This seems to be a limitation of the head unit, because even with CDText-capable CD changers or mp3-compatible CD changers, nothing more than track #/cd # is displayed... (Well, we could bypass the head unit and try to connect directly to the display, but this is a completely different project)

- Sort of : AFAIK (but I might be wrong) Analog to SPDIF converters can be found easily, but they are often targeted at pros, and are neither cheap not easy to power and connect in the dashboard, so not really suitable here...

Well, in brief, you have 3 choices :
- you sell you Ipod and go the carPC way :-) Via Epia motherboards have both the Serial port and SPDIF out...
- you are very good in electronics and want to design and build a hardware interface(*)
- you are looking for the easy solution : an existing Adapter such as the one from Connects2. It should be checked if it forwards commands to the Ipod though...

Hope this helps


Vicne.

(*) The hardware part involves the PIC emulator, the SPDIF converter (info can be found in the description of the Connects2 here )and (as it seems to be your desire) conversion of HU and stalk commands to IPod ones.

Originally Posted by Vicne

- Not yet : currently, the only implementations we achieved imply the use of a PC to send serial commands. The hardware part currently is a simple pass-through with level conversion. Several people here have indicated interest in developing a pic-based version of the emulator though, which means a PC wouldn't be needed anymore.

You have reason I not have pubblished my work, but I have implemented a dummy interface with 16f84 (with only max232) that enable the CDC emulator and after the success I have asked my self now?the SPDIF audio?then I'm searching
new way to encoding/converting/emulating the SPDIF audio, for example using old standalone mp3 player but for now no good news.
Also work with Yampp3/USB (www.yampp.com) but the same problem SPDIF Source?

Originally Posted by Vicne

changers, nothing more than track #/cd # is displayed... (Well, we could bypass the head unit and try to connect directly to the display, but this is a completely different project)

I'm interessed too.
New thread discussion?


Anyway other solution in my mind is the follow (any suggestions are aprreciated):

MP3 Player based on:

ATMEL128L,MAX3587S(mp3 decoder with spdif output), USB Controller (MASTER mode ) and some LCD (like Nokia color/grayscale).
The decoder that I'm using now doesn't support the Digital output (VS10XX more info www.vlsi.fi).
So you can put your usb key in the mp3 player and listen the music in a car.

best regards
pep


Regard

one question:

What do you think about a frame that when sent to HU switch,it changes the audio input signal from the SPDIF to Analog?

pep