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

Vicne · 02-22-2006, 05:37 PM

Quote: Originally Posted by mox

Except for those who own a Connects2

By the way, when do we begin spying on it ? :-)

Putput · 02-23-2006, 04:26 AM

Quote: Originally Posted by Vicne

(I have the strange feeling that everybody's coding hard...:-) )

Some of us have to work from time to time

. And I'm not only working, I'll be on holiday next week so coding will have to wait a while. (No my laptop is not going with me, my girlfriend is

)
As soon as I'm back I'll start coding again and this time a serial interface will be included so that the prog can be directly linked to the HU. It would also be very interesting to know how the Connects2 interface fools the HU. It would probably send CD 1 TR1 and zeros in the time fields, I don't think that the HU will keep track of elapsed CD playing times, or controls any of the data send by the CDC. As long as the telegrams fit the description everything is ok for the HU (I think). But perhaps by the time I get back this question will be solved and perhaps a tested and working hardware circuit??

Keep up the good work guys!!!

peppuz79 · 02-23-2006, 05:11 AM

Quote: Originally Posted by Vicne

(I have the strange feeling that everybody's coding hard...:-) )

I do not have much time to disposition: family, work and the Olympic Games :-) hold me a lot engaged, however in the night something i can do.

Actually I'm sniffing the signal from the HU using PALM PSION but something in my in interface is wrong which type of interface using you?

bye
pep

Vicne · 02-23-2006, 05:37 AM

Quote: Originally Posted by Putput

Some of us have to work from time to time

Jeez, that's it.
I was sure I had something to do but couldn't remember what, but now that you remind me it's true : I have a job !

Quote:

It would probably send CD 1 TR1 and zeros in the time fields, I don't think that the HU will keep track of elapsed CD playing times, or controls any of the data send by the CDC. As long as the telegrams fit the description everything is ok for the HU (I think)

I think too. I don't think the HU checks these frames for consistency, because when a CD is scratched or there are bumps in the road, time doesn't follow a correct sequence (but maybe the changer sends a specific 'read error' message in this case ? Anyway, I'm not going to scratch a cd just to test :-))

Quote:

But perhaps by the time I get back this question will be solved and perhaps a tested and working hardware circuit??

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 (see page 8 of this document)
As I won't have any inversion in this case, I think I'll use this principle for both Tx and Rx, and get rid of the MAX altogether. The only thing that will be missing is the negative voltage output, but it seems it's not needed at all for most PCs. I'll let you know when I have something working...

Vicne · 02-23-2006, 05:42 AM

Quote: Originally Posted by peppuz79

Actually I'm sniffing the signal from the HU using PALM PSION but something in my in interface is wrong which type of interface using you?

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.

Vicne · 02-23-2006, 06:47 AM

For those who have too much free time, here are a few remaining questions :
- 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 ?
If it has to be consistant with the remaining information, then we *must* generate the correct value !
- what is needed to make the disc number change on the display ? Do we have to simulate a complete cd change (which probably mutes the sound ?)
- do we have to respond in a particular way if we receive a button press or can we just acknowledge it

And a few more tests I have to do :
- what if some places are empty in the tray ? What happens if I press on this CD number ? If nothing gets sent, it means the CDC has to declare the available CDs to the HU beforehand and the HU only transmit commands if they are "allowed". We must then analyse what exact frames are needed for such a declaration, so that all buttons are active...
- let the track change automatically at the end of the previous one and see what message gets sent
- let the CD change automatically at the end of the previous one and see what message gets sent
- let the track change automatically in random mode at the end of the previous one and see what message gets sent
- let the CD change automatically in random mode (does it do that ?) at the end of the previous one and see what message gets sent

peppuz79 · 02-23-2006, 07:37 AM

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

Vicne · 02-23-2006, 07:54 AM

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

Vicne · 02-23-2006, 08:11 AM

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

pippolippi · 02-23-2006, 10:37 AM

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

Putput · 02-23-2006, 02:52 PM

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

pippolippi · 02-23-2006, 03:15 PM

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

Ale · 02-23-2006, 05:03 PM

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

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

Vicne · 02-23-2006, 05:11 PM

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

Quote:

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

Quote:

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

Quote:

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 ?

Quote:

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

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

Finally, to answer your question

Quote:

but at what level are you setting the threshold?

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

Vicne · 02-23-2006, 06:28 PM

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