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

Putput · 02-11-2006, 04:51 PM

The party ended a little sooner then expected so here it is:

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
   FCS  : integer;
   w_i  : integer;
   w_ii : integer;
   w_b  : byte;
begin
   // Line pointer in Listbox
   for w_i := 0 to ListBox1.Items.Count - 1 do
      // Check for correct string length
      if length(ListBox1.Items.Strings[w_i]) = 56 then
      begin
         FCS := 0;
         // Byte counter in frame
         for w_ii := 1 to 14 do
         begin
            // Move string hex byte into binairy byte
            HexToBin(StrLower(pchar(copy(ListBox1.Items.Strings[w_i], ((w_ii - 1) * 4) + 1, 2))), @w_b, 2);
            // XOR with previous Result
            FCS := FCS XOR w_b
         end;
         // Add FCS result to listbox
         ListBox1.Items.Strings[w_i] := ListBox1.Items.Strings[w_i] + ' FCS=' + IntToHex(FCS, 2)
      end;
end;

Its written in Delphi and its the procedure that runs when you push the Calculate button in the program.

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

Quote: Originally Posted by pippolippi

It seems that the CDC replies with an acknowledgment (C5, I don't use ACK since it's ascii code 06) when it receives a command (disclaimer: I only looked at the first version of the dump without the reformatting, so I don't know if command/reply are synchronized).

Yes, you're right, the acknowledgement byte (C5h) is not the ACK character. And indeed, it's send by the head unit as a reply after each frame coming from the CDC, but also by the CDC after each command coming from the head unit, so it's really an "OK" message.

Quote:

Also note that 3D and 3F only differ in one bit (2), maybe the bit is used to signal something.

Yes, indeed.

Quote:

Can you try to capture the communication while powering up the HU and with the cd player not playing?

I'll do my best to have a more complete capture, along with annotated operations, but I have to tweak the capture program first. I think I'll dump Rx and Tx into separate files, with each byte being timestamped and numbered, so that I can then mix them in Excel or something.
I'm thinking of the following operations :
start capture from scratch / head unit off / head unit on, with tuner as source / switch to CD changer / play / pause / next/previous tracks / change CD / fast forward/backward / random / switch back to tuner / head unit off

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

Quote: Originally Posted by Putput

The party ended a little sooner then expected so here it is:
...
Its written in Delphi and its the procedure that runs when you push the Calculate button in the program.

Excellent ! Thanks a lot. So it's really easy to implement. Cool.

We'll have to solve the mystery of the other frames now...

pippolippi · 02-11-2006, 06:00 PM

Quote: Originally Posted by Vicne

Status of the 15-byte frames decoding :
0 : ?? (3Dh or 3Fh)
1 : frame id ?
2 : frame length - 4 ? (0bh)

Yes, remaining length of the frame minus the checksum. The same seems to apply to commands from the HU, e.g. in the first dump (20060211_001701_SerialDump_cd_changes.log):

0: 3D
1: 14
2: 02 --> 2 "useful" bytes
3: 26 --> first useful byte
4: 01 --> second useful byte
5: 0C --> xor of bytes from 0 to 4

Ale · 02-12-2006, 06:01 AM

Quote: Originally Posted by Putput

When the frame starts with 3D it calculates the FCS perfectly, only when it starts with 3F it goes wrong. When I change the 3F to 3D the result is ok again, so maybe the 3F could be a glitch?

I have load the data in excel and with a small function in VBA i calculated the CRC, and can confirm that the frame that start with 3F results in wrong CRC, changing it with 3D it's OK.
the function accept a range of cell like =MyXor(B3:P3), if you include the crc in the range, when the result is zero the received data is correct (the last xor operation is between the calculated crc and the received one)
Here is the function:

Code:

Function MyXor(MyInput1 As Range)
crc = 0

For I = 1 To MyInput1.Cells.Count
    crc = Val("&h" & MyInput1.Cells(1, I)) Xor crc
Next I
MyXor = Hex$(crc)
End Function

So the byte in the frame:
0 : 3Dh, start frame
1 : nn a sequence number, cycling from 00h,01h...FFh,00h,01h

I have found error (3F) also in the sequence number and changing it with the next expect value, fix the CRC error.

I think that there is a software(buffer overrun) or hardware(threshold of the receiver) bug...

Vicne · 02-12-2006, 06:27 PM

I modified MTTTY today and here are new raw logs of a session.
Changes :
- I dumped each serial port to a separate file, to avoid buffer flushing and thread synchronization problems
- I numbered each received byte uniquely (even across com ports)
- I also timestamped each byte received. The PC clock isn't that accurate to get a different timestamp for each byte, but it gives valuable information on the timing of the protocol. Time is given in seconds[.milliseconds]
- I removed the ascii conversion that was useless.

I then manually executed the following "script of operations", with and estimated precision of +/- 2 seconds :

Time : operation
-----------------
0 : start capture
30 : turn head unit on (Changer starts playing the beginning of TR1 of CD1)
60 : press "Next" (track 2)
75 : press "Next" (track 3)
90 : press "Next" (track 4)
105 : press "Next" (track 5)
120 : press "Next" (track 6)
135 : press "Next" (track 7)
150 : press "Next" (track 8)
165 : press "Next" (track 9)
180 : press "Next" (track 1 again, because CD only had 9 tracks)
195 : press "Next" (track 2)
210 : press "Previous" (track 2 restarts at the beginning)
225 : quickly press "Previous/Previous" (track 1 starts at the beginning)
240 : press and held "Next" (Fast forward, display shows ">>")
255 : release "Next" (playing)
270 : press and held "Previous" (Fast reverse, display shows "<<")
284 : release "Previous" (playing)
300 : press "CD 2" (CD loads and starts after ca. 5 seconds)
315 : press "CD 3" (idem)
330 : press "CD 4" (idem)
345 : press "CD 5" (idem)
360 : press "CD 6" (idem)
375 : press and hold "CD1" (random on)
378 : release "CD1" after the beep (skips to track 10, I think)
390 : press "Next" (skips to track 2, I think)
405 : press and hold "CD1" (random off)
408 : release "CD1" after the beep (continues in track 2, I think)
435 : eject CD tray from changer (head unit switched to tuner)
465 : insert CD tray and let the changer load each CD in turn
495 : eject CD tray again
525 : insert CD tray again
530 : switch head unit source to CD changer (display shows "CD CHECK"). Playing starts around 548
570 : switch head unit source to Tuner
585 : switch head unit source back to CD changer
600 : press "Pause" (music stops)
615 : press "Pause" again (music starts again)
630 : turn head unit off

Apart from the 2 raw files in the zip, you'll also find an Excel version compressed in a rar, combining both logs (ordered by byte number ;-)) and the manual operations.

I think it would be interesting to find a rule and automate the splitting into frames, because manually formating 12kBytes of data seems rather lengthy...

Happy hacking :-)

Note : I also attach here my modified MTTTY app. If you want to make your own logs, just make sure you have a C:\Temp directory or create it if needed (hardcoded path for log files), then start the app, check the com port settings (9600/even/1) and click File > Connect.
Source - quickly hacked - available on demand.

Vicne · 02-12-2006, 06:55 PM

So if I summarize, we have :

<frame>=
byte #0 : 3Dh (sometimes 3Fh - maybe erroneously)
byte #1 : frame id (incremented at each frame, cycling to 00h after FFh)
byte #2 : <data> length
bytes from #3 to #(length + 2) : <data>
byte #(length + 3) : CRC = XOR of all other bytes

<data>=
byte #0 : data type (e.g. : 47h = "playing")
other bytes : data type dependant

for the particular case of the "playing" data type, we have the following bytes :
byte #1 : track number
byte #2 : ?? 01h
byte #3 : ?? 00h (could be elapsed cd time, hours (BCD))
byte #4 : elapsed cd time, minutes (BCD)
byte #5 : elapsed cd time, seconds (BCD)
byte #6 : ?? constant byte per track
byte #7 : ?? 00h (could be elapsed track time, hours (BCD))
byte #8 : elapsed track time, minutes (BCD)
byte #9 : elapsed track time, seconds (BCD)
byte #10 : ?? 00h

For the elapsed time hours, I just thought of it while writing. I'll have to check with a longer CD...

So this one is almost done, except byte #6 (constant per track) ... No idea...

Vicne · 02-12-2006, 07:08 PM

Quote: Originally Posted by Putput

When the frame starts with 3D it calculates the FCS perfectly, only when it starts with 3F it goes wrong. When I change the 3F to 3D the result is ok again, so maybe the 3F could be a glitch?

I have no explanation for these 3F. It could well be a glitch indeed, because a far as I can tell, there are no more (or at least much less) frames beginning with 3F in the last dumps... But why 3F ?? OK, it's only one bit away from 3D, but there are 8 such values...
It could well be a hardware threshold problem, or just a bug in MTTTY...
Anyway, for frames we'll generate, I don't see the point in introducing errors :-), and for frames we receive, we can always throw them away thanks to the check byte (that's why checks are there in the first place :-) ).
However, it could be interesting to see if the protocol includes things such as "try again" when a received frame has to be rejected.

By the way, FCS stand for Frame Check Sequence, right ?

Vicne · 02-12-2006, 07:37 PM

Quickly, before going to sleep, head unit commands have the same format as already said, and they seem to only reflect what is pressed, not the intended operation. That is, if you are on track 1 and press next, the message is "NEXT TRACK", not "GO TO TRACK 2".
"NEXT" frame is for example :

3D 07 02 17 01 2E

3D (classical frame start)
07 (frame id)
02 (data length)
17 (data type)
01 (data)
2E (fcs)

So actual "data" bytes are "17 01", which could mean "skip 1". I'd be interested in trying "17 02" :-)

Similarly, frame for "PREVIOUS" command is for example
3D 0F 03 22 01 02 10
from which data is "22 01 02" (3 bytes long)

There is also frequently an erroneous bit in the 'length' part, at the most significant (or sign) position : one can find 83h where it should be 03h. No idea if it's a decoding error or a bit set for an unknown purpose...

Putput · 02-13-2006, 03:32 AM

Quote: Originally Posted by Vicne

By the way, FCS stand for Frame Check Sequence, right ?

Yep, its another name for the same thing, I don't know the exact difference between FCS and CRC but I used to work with simular code using XOR in a serial protocol and they called it FCS. Cyclic Redundancy Check (CRC) is used for the same purpose as FCS.
When do you plan to start with CDC emulation, with the present info it must be possible to fake a CDC? When interfacing with the HU you can try to test some things that are not very clear at this moment. Of course you don't have to fry your HU just to satisfy my curiosity.

pippolippi · 02-13-2006, 03:48 AM

Maybe it's not relevant, maybe you already know it but...
Switch off the head unit, press (and keep) key 3, switch it on again.
Now each key you press (only on the HU, not the stalk control) will show its code on the display. Maybe it's the same code that's sent to the cd changer, maybe not.

Vicne · 02-13-2006, 03:52 AM

Quote: Originally Posted by Putput

When do you plan to start with CDC emulation, with the present info it must be possible to fake a CDC?

Yes, that's the goal of course. However, I think there's still some decoding work :
- Try to see if there are more "bit errors" (3F/3D, 03/83). If so, try to find where the problem comes from. If not, what's the meaning of that bit
- Run a "splicer" algorithm on the available data to see if we can reliably find frame boundaries.
- Decode frames sent while CDC is not playing
- Decode all command frames sent by the head unit, including the ones not beginning with 3Dh
- Get new data with more "extreme" conditions and see how it behaves. For example, press NEXT multiple times very quickly or with the "rolling wheel control" to see if it translates into multiple frames or one aggregated frame.

As for the question "when", well, I'd say when it's ready + when time permits. Maybe next week-end...

By the way, there's still a little hardware work to be done to generate the 3V/12V signal. Probably adding a transistor and a pull-up resistor to get to 12V, and a few diodes to get to 3V for logical 0...

Quote:

When interfacing with the HU, you can try to test some things that are not very clear at this moment. Of course you don't have to fry your HU just to satisfy my curiosity.

I'd rather not :-)

Honestly, unless there's great chance that a command works, I'm not intending to try every possible combination just to see :-) : I'll stick with frames I'm sure are valid.

Vicne · 02-13-2006, 03:56 AM

By the way, if someone wants to try to emulate a CD changer, the only hard to find component is the magic female blue connector.
It's available from http://stores.befr.ebay.be/ADAPTERSHOP : search for "blau" on the left and you should come across the following item (image (c) Adaptershop) at around 5 EUR + S/H.
Take care, other shops sell "mini iso blue connectors", but sometimes they don't include the contacts !

Putput · 02-13-2006, 04:50 AM

Quote: Originally Posted by Vicne

By the way, there's still a little hardware work to be done to generate the 3V/12V signal. Probably adding a transistor and a pull-up resistor to get to 12V, and a few diodes to get to 3V for logical 0...

Could this perhaps be the answer to the 3D - 3F phenomenon?

Quote: Originally Posted by Vicne

I'd rather not :-)

Honestly, unless there's great chance that a command works, I'm not intending to try every possible combination just to see :-) : I'll stick with frames I'm sure are valid.

No problem, I just wanted to see how eager you are to see it working.

Keep up the good work, in the meantime I'll work on my patience. I may have some time this week to start with the hardware so I'll give it a try. Question about wiring, can you tell me what to connect to pin 17? I found this URL http://perso.wanadoo.fr/sebire.phili...hargeur_cd.htm explaining all details except if pin 17 is in or out and what voltage it carries? I assume that its an input for the CDC telling that the HU is active but I have to be sure before I fry my HU.

Vicne · 02-13-2006, 05:45 AM

Quote: Originally Posted by pippolippi

Maybe it's not relevant, maybe you already know it but...
Switch off the head unit, press (and keep) key 3, switch it on again.
Now each key you press (only on the HU, not the stalk control) will show its code on the display. Maybe it's the same code that's sent to the cd changer, maybe not.

Never heard of that. Funny hack. I'll try tonight and see the results.
Where did you learn that, if not confidential ? Maybe the source of this trick also knows much more about this damn head unit :-)

User Name		Remember Me?
Password