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

Originally Posted by Vicne

I'm using the one of post 36 except that the 18K resistors at the bottom have been replaced by 10K ones.
You can't just use a MAX232 the standard way because it inverts the signal, hence the use of an RS>TTL as an inverter.

max202 with only some ceramic caps (0.1uF)?it's the same?

pep

Originally Posted by Vicne

a mystery remains about the 10th byte of the "PLAYING" frame. E.g. in the following frame :
3D 8B 0B 47 03 01 00 11 34 13 00 00 02 00 CC ?
Track=3, CD time=11m34s, Track time=0m02s, but what does the "13" mean ?

Err... maybe I have the answer actually :-).
I took a sample of all values I had for this byte in one of the dumps and here are the different values (sorted, duplicates removed):
00 07 11 13 15 17 19 20 22 29 34 36 37 40 64 67 70 71

Observations :
- numbers look random (they are not sorted in the actual logs)
- only numbers, no letters (hex), so strong probability of BCD
- maximum observed value : 71. Nothing in the range 72-99
- this byte is always 00 for the first track of each CD

And here's my explanation :
CDs are divided into elementary chunks referred to as sectors (or more frequently frames, but let's not use that term here to avoid confusion with frames of the protocol), each sector being 2352 bytes for CD audio (see wikipedia). Each second of sound corresponds to 75 sectors (44100 samples/sec x 2 (stereo) x 2 bytes (16bits) / 2352 bytes/sector = 75 sectors/second).

So my guess is that the time is not stored as hour:minute:second (BCD) as we thought but as hour:minute:second:sector (BCD) :
- As the CDC sends one frame every second, this "decimal" part is constant for the whole track (1:05:12:62 + 0:0:1:0 = 1:05:13:62)
- As the first track begins at 0:0:0:0, this "decimal" part is always 0 for the first track
- As tracks have arbitrary lengths (with decimal part), if the first track's length is 0:3:35:22, when we skip to the second track, it starts playing at 0:3:35:22 (cd time) or 0:0:0:0 (track time), and one second later, we get 0:3:36:22 (cd time) or 0:0:1:0 (track time)
- That would also explains the last 00h (14th byte) of the frame

So here we go for a potential decoding of the following PLAYING frame :
3D 8B 0B 47 03 01 00 11 34 13 00 00 02 00 CC

3D = header
8B = id
0B = data length
47 = payload_type (PLAYING)
03 = track number
01 = ?
00:11:34:13 = cd time (BCD encoded h:m:s:f)
00:00:02:00 = track time (BCD encoded h:m:s:f)
CC = frame control sequence

So that would leave us with only one unknown byte for this frame, but as it has the fixed value of "01h" in all frames I have analysed, I guess we can safely say it is constant...

Originally Posted by peppuz79

max202 with only some ceramic caps (0.1uF)?it's the same?

Well, not the same, but after a look at the datasheet, I think you can use it as a drop in replacement indeed. The 3232 I used is of a newer generation (min power supply of 3.3V, higher data rate) but you don't need that if you use a 5V power supply (I'm using a 4.5V battery).

Although, maybe you should check the input thresholds to make sure they are siimilar.

Beware : on their typical operating circuit, they use some 6.3V caps, so if you have 6.3V rated caps too, be careful that wiring of pin 2 is different from the one in my schema.

Oh, yes, I also followed Ale's advice and put a 10uF capacitor in parallel with the 0.1uF one at the chip's power supply to minimize noise.

Originally Posted by Vicne

I bought a LM324 and a few variable resistors and I intend to use this Op Amp as a comparator to do the conversions, adding hysteresis with a positive feedback

Yes, but at what level are you setting the threshold? Going from 232 to the HU is easy (we have the rs232 standard as a reference, so we can set it at 3v) but we don't know what value to use for the HU->rs232 transition. I don't have a (good enough) tester at home, but connecting directly the HU to the serial port I had the receiver led constantly lit, so either my rs232 adapter is more sensible (though it has worked well with all kinds of rs232 devices) or the level is already >3v.
I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply because you have closed the circuit with the standard cd changer, and this could also explain the differences in levels observerd by you and mox.

Edit: my adapter uses an hin213eca as an rs232 level translator, and that detects a low to high transition at 1.7v and gives (typical) +-9v of output.

Originally Posted by pippolippi

I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply because you have closed the circuit with the standard cd changer, and this could also explain the differences in levels observerd by you and mox.

This is certainly a possibility, I know that a few years ago in industrial environments (with lots of noise) current (Current Loop) was more frequently used because its less sensitive to noise compared to serial (RS232). These days its mostly RS422/485 with balanced differential drivers.

Originally Posted by Putput

This is certainly a possibility, I know that a few years ago in industrial environments (with lots of noise) current (Current Loop) was more frequently used because its less sensitive to noise compared to serial (RS232). These days its mostly RS422/485 with balanced differential drivers.

But then both current loop and rs422 would need 4 wires, so I was probably wrong

Originally Posted by pippolippi

I don't have a (good enough) tester at home, but connecting directly the HU to the serial port I had the receiver led constantly lit, so either my rs232 adapter is more sensible (though it has worked well with all kinds of rs232 devices) or the level is already >3v..

Are we sure that HU pin 13 is TX and not RX? RX with a sort of pullup giving the strange level of 3V on the 5K input impedance of RS232?
Our measurement is always done with CDC connected...

Originally Posted by pippolippi

I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply because you have closed the circuit with the standard cd changer, and this could also explain the differences in levels observerd by you and mox.

If the HU comunication is based on current, not necessarily a industrial standard 20mA current loop, but an open collector interface for TX and a current sense at RX, i suggest the circuit in the attachments...
What do you think about?

Originally Posted by pippolippi

Going from 232 to the HU is easy (we have the rs232 standard as a reference, so we can set it at 3v) but we don't know what value to use for the HU->rs232 transition. I don't have a (good enough) tester at home, but connecting directly the HU to the serial port I had the receiver led constantly lit, so either my rs232 adapter is more sensible (though it has worked well with all kinds of rs232 devices) or the level is already >3v.

Not sure what you mean in the last sentence.
Based on the specification, any input voltage between -3V and +3V is in the "no man's land", an undefined region. It means that a device that would consider:
- an input voltage between -3 and -25 as a logical 1
- an input voltage between +3 and +25 as a logical 0
- and anything in between as "not enough to toggle the output" (hysteresis of 6V)
... would be perfectly RS232-compliant in the strict sense. If this is the case of your adapter, well, it's a good adapter but it cannot be used as is.

I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply
because you have closed the circuit with the standard cd changer

That's be a possibility, but AFAIK, current loops are not used that much nowadays, mainly in hi-fi. Moreover, CristianC did decode bytes without anything attached to his HU.
To be sure, you could put a resistor to terminate the wire and measure the voltage if you want...

and this could also explain the differences in levels observerd by you and mox.

Regarding this difference, I could confirm that the oscilloscope introduced an offset when changing scale. I connected the probes together and adjusted the "signal" on the baseline at 10mV/div, then switched scale and the signal was around 2V when I reached to the 5V/div scale.
I'm really sorry but that's the only 'scope I could find... Maybe I should buy one, one day :-)...

Edit: my adapter uses an hin213eca as an rs232 level translator, and that detects a low to high transition at 1.7v

Low to high, you mean logical 0 (positive voltage) to logical 1 (negative voltage. In that case, it should work indeed, and for sure with a 10K/10K resistor. Can't you test your receiver by feeding it a variable voltage (100K potentiometer on a 9V battery) and see when the led toggles ?

and gives (typical) +-9v of output.

It seems "rather good", but I have no idea if it's sufficient...

Finally, to answer your question

but at what level are you setting the threshold?

... well, that's the goal of the variable resistors : adjusting till the led flashes :-)

Originally Posted by Ale

Are we sure that HU pin 13 is TX and not RX?

*Very interesting remark*. Ale is definitely the best to spot inverted things.

I just followed the wires backwards with paper and pen in hand and he's right. Bear with me :

- We are reading PLAYING frames coming from CDC on COM1. COM1 is linked with a black wire to pin7 of the MAX, this T2OUT comes from T2IN, pin 10, which is bridged to pin 9, R2OUT coming from R2IN, pin 8. This pin is linked via a 10K resistor to another black wire which comes from connector pin 14 labeled UART- or UART RxD.

- We are reading command frames coming from HU on COM2. COM2 is linked with a red wire to pin 14 of the MAX, this T1OUT comes from T1IN, pin 11, which is bridged to pin 12, R1OUT coming from R1IN, pin13. This pin is linked via a 10K resistor to another red wire which comes from connector pin 13 labeled UART+ or UART TxD.

Conclusion :

You have to link pin 3 (Transmit Data) of the serial port to pin 14 (RxD) of the blue connector to send PLAYING frames.
You have to link pin 2 (Receive Data) of the serial port to pin 13 (TxD) of the blue connector to read HU commands.