Page 6 of 81 FirstFirst 1234567891011121314151656 ... LastLast
Results 51 to 60 of 801
Like Tree1Likes

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

  1. #51
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326

    Here we go again

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

  2. #52
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326

    Frame format status

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

  3. #53
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    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 ?

  4. #54
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326

    Head unit command frames

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

  5. #55
    Constant Bitrate Putput's Avatar
    Join Date
    Sep 2005
    Location
    Belgium
    Posts
    181
    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.

  6. #56
    Constant Bitrate
    Join Date
    Feb 2006
    Posts
    113
    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.

  7. #57
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    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...

    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.

  8. #58
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326

    Blue connector

    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 !
    Attached Images Attached Images  

  9. #59
    Constant Bitrate Putput's Avatar
    Join Date
    Sep 2005
    Location
    Belgium
    Posts
    181
    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.

  10. #60
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    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 :-)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •