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

Originally Posted by pippolippi

Breaking news
it seems this folk connected directly the changer to a pc rs232 port and saw this: 3D 01 FE FD 3D 01 FE FD 3D 01 FE FD.
Sounds familiar?

I think that something go wrong with level 0 threshold becouse the recalculated CRC of the frame 3D 01 FE FD isn't correct (3F instead of 0).

Originally Posted by Ale

I think that something go wrong with level 0 threshold becouse the recalculated CRC of the frame 3D 01 FE FD isn't correct (3F instead of 0).

Right, but that's just a start sequence (CristianC calls it connection attempt, repeated 3 times) and you can also see that there aren't 254 (FE) bytes in these packets.
Next frame is 3D 01 01 93 AE C5 and that has the correct checksum (plus the confirmation=C5, probably to the connection attempt).

You probably took care of everything but make sure that you connect all 0V 's together. I've seen strange things happen when using multiple power sources not grounded to the same level.

Originally Posted by Ale

I have added some suggestion onto your breadboard

Thanks for your help. As I said, I once knew electronics theory but never put it in practice.

So OK for the clips at the power source.

Just to be sure of the other changes you propose, let me first explain my photograph (hopefully also useful for others) :
- the power are the two black/red lines on the top left. Black is currently not plugged, so the circuit is not powered. When connected, black goes to the top row of the breadboard, which is the ground. Red immediately goes to the Vcc of the MAX3232 while the ground pin of the MAX3232 is linked to the top row via the thin red () wire
- the grey shielded cable above comes from the hu/cdc connection. As you can see, shield (ground) is immediately connected to the top row too, while red (Rx) and black (Tx) go through the 18k resistors, then to the MAX3232 through resp. white and grey wires
- the grey shielded wire below goes to the PC serial ports. The shield (ground) is connected to the top row via a white wire and red and black (Rx of resp. COM1 and COM2) are linked to outputs of the MAX3232 via resp. green and yellow wires
- the 2 red bridges at the bottow right connect the output of the TTL/RS buffers to the input of the TTL/RS buffers.

From your edited drawing I guess what you mean is :
- secure power lines connections with a clip
- put the resistors just before the MAX3232 pins
- add a 10 uF capacitor in parallel with the 0.1uF one.

Is that correct ?

Thanks again for your help. It's much appreciated.

Originally Posted by Ale

I think that something go wrong with level 0 threshold becouse the recalculated CRC of the frame 3D 01 FE FD isn't correct (3F instead of 0).

Well, indeed :
- either this frame is a special connection attempt "Anybody there ?" that doesn't follow the normal format. Not only is the CRC wrong, but also the length which should be 0
3D : start frame
01 : frame ID
FE : length (not !)
FD : CRC (not !)

- or there's a decoder error. But it would be perfectly reproductible 3 times in a row, while bytes 3D and 01 are decoded OK ? Strange...

I'd be tempted to think it's a special message that isn't in the "frame format"...

BTW, just to make sure : that's the message he saw when reading the Tx from the HU while no changer was connected, right ?

Originally Posted by pippolippi

connects2 uses an ba8270f to interface to the head unit and I don't see how this chip could be used if HU interface is compatible with a simple rs232

I don't understand either. This chip seems targeted at synchronous communication while here we obviously have asynchronous dialog. Even if I direct connection is not reliable, putting a MAX chip seems much easier than using this specific circuit.
Maybe all Connects2 devices share the same multifunctional hardware to make scale savings, and only the software and external connections vary from model to model ? Just an idea...

Originally Posted by Vicne

BTW, just to make sure : that's the message he saw when reading the Tx from the HU while no changer was connected, right ?

Well, as I said I don't really understand romanian but I think so. What I found interesting is that he connected the pc directly, with no interface.

I took both logfiles (COM1 and COM2 dump files by Vicne) and tried to parse them with the info gathered so far. I don't think that it needs much explaining, just try to load the log files (or any log files in the same format) and see what happens. As you can see, there are still some errors (in parse code or logging ) that we need to exclude before everything is clear. I think that most of the errors (sorry Vicne ) are logging and communication errors, mostly its just 1 bit wrong thats why I'm assuming that they are communication errors. I also recalculated the FCS for each frame, when something is wrong the FCS is written in red and after the 'x' the correct FCS is stated for the frame as it was logged.

Before going further, I really want to find where these errors come from.
Here are my observations :
- They seem to affect almost always the first byte. Moreover, this byte doesn't get a random value, but almost everytime BD or BF.
- The most affected frame seems to be the second one after a track change...
- Most errors consist in '1's read instead of '0's : We get BD (10111101) or BF (10111111) while we should get 3D (00111101)

Possible causes :
- Ambiant noise.
- Level problem.
- Software problem.

I really don't think it comes from software. Not only because I'm better in software than hardware, but mostly because it works most of the time, and errors are so localised.
The fact that many errors come after a track change can be due to the spikes generated by motors inside the changer, or to the motors drawing so much current that voltage drops temporarily and levels are pulled down...

Anyway, when I have time, I'll try the changes advised by Ale and will take some mesures again to check levels and threshold