Page 18 of 81 FirstFirst ... 891011121314151617181920212223242526272868 ... LastLast
Results 171 to 180 of 801
Like Tree1Likes

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

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

  2. #172
    Newbie
    Join Date
    Feb 2006
    Posts
    28
    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

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

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

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

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

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

  8. #178
    Ale
    Ale is offline
    Newbie
    Join Date
    Feb 2006
    Location
    Italy
    Posts
    42
    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?
    Attached Images Attached Images  

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

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

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

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
  •