Announcement

Collapse
No announcement yet.

Renault Radiosat 6010 / Philips D2B cd changer emulator

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Renault Radiosat 6010 / Philips D2B cd changer emulator

    Hi everyone,

    Here's a new thread to keep this work separate from Vicne's overflowing Tuner List thread. I got hold of a Philips RC026 CD changer. I snooped at communications between the changer and my Renault Radiosat 6010 aka. Philips 22/dc461 (or some other number, can't remember out of my head).
    This one is in Renaults prior to 2000. After 2000, Tuner List and Update list are the radios of choice. Please refer to Vicne's thread here.

    The Renault Radiosat 6010 is quite basic. When playing CDs, it displays only CD and track number, no run time info. Other Philips branded HUs display run time info. I used one for testing, and found data traffic on the D2B bus is massively increased compared to the 6010.
    While I have quite a batch of data from the Philips branded radio (I don't have the model right now), I probably won't bother analysing it, as that particular radio has a setting to toggle between Aux in and cd changer on that port, so no need to emulate.

    Basics
    Basic communication is dual-rail asyncronous.
    After power on, the voltage of the two pins rises to about 2.48V. Data is encoded as 0 = ca. 250mV voltage difference (125mV per rail), or 1 = 0 voltage difference plus a spike. So a zero would be mostly 250mV, plus a short return-to-0 pulse at the end. A one would be a short start spike, then return to 0. This ensures several zeros or ones are separable. If there is a 1-0 or 0-1 transition, then the short spikes are merged/ omitted.
    Current flowing on the bus is between 0 and 2.5mA (from CD to HU) or -1mA (from HU to CD), which seems too low for current mode signaling. [Thanks for the suggestion, Theo!]
    The basic protocol consists of init-recipient-sender-message_start-message

    init is 0 [270us] 1 [60us] 0 [20us] 1 [120us]
    recipient is a 13 bit address, sent at different timing than the rest of the message. 0=250mV,30us;0mV,20us or 1=250mV pulse (2us); 0mV,40us. Total length of 0 is 50us, 1 is 40us.
    sender is 14 bits, the 13 bit address to be used for response plus one bit that I haven't made sense of (maybe odd parity). From now on, a faster timing is used. 0=250mV,24us;0mV,4-6us 1=250mV,6us;0mV,20us.
    message_start is 11100
    message is sent in 10 bit chunks, with either a pause or an ack pulse between each. (this one needs tbc as well)

    Addresses
    I tested with two head units, one Renault one Philips [Thanks again for lending me the radio, Theo!]. HU address was constant in both cases.
    Address 13'b1 seems to be used by the HU to send a message to advertise its address. Assumed to be "to all"
    HU to CD changer will send 13'b0000111001000 (recipient) and 14'b10001100100000 (sender)
    CD to HU = 13'b0000110010000 (recipient) and 14'b00001110010001 (sender)


    Messages
    Message split in 10 bit chunks - 8 bits of data, 1 bit "end of message", 1 bit odd parity. After each chunk, recipient responds with '1' as ack.

    1st chunk = number of chunks in message (including this one)
    2nd chunk seems to depend on sender
    3rd chunk = ?
    4th chunk command / previous command (when responding)
    5th chunk parameter 1
    6th chunk parameter .
    ....

    More random info
    commands start with 1100, status reports with 0100 (tbc)
    Data/ parameters seem to have constant first four bits (0011) and then payload encoded as binary coded decimal, with each digit in a separate data chunk.


    Further reading/ files
    cd1-tr1->tr2.zip - sample raw waveform exported to CSV&EPS, directly from 'scope. Command executed was 'next track'.
    Channel 1 = d2b to ground (plus or minus, I can't remember)
    Channel 2 = d2b+ to d2b- (or vice versa)

    data_spreadsheet.zip - transcribed data, as in ODS (open document spreadsheet). Some annotations.

    The ugly further reading: If you understand patent-eze, here are some. Google patents is your friend and will give you full text + images:
    5187708 -- has quite similar message structure to what I found
    4429384 -- fundamental patent on d2b, shows some circuits and message structure
    I found those two the most useful, as they have concrete circuits/ message description.

    Any help and comments greatly appreciated!
    Attached Files

  • #2
    Hi,
    Did you success to create your cd changer emulator?

    I have a Peugeot 406coupe MY97 with a Philips radio and cd changer. Some years ago I begin to analyse the cd changer protocol to design an emulator and replace it by MP3 player. Finally I renounced because I had not success to understood its protocol.

    During my protocol analysis, I did same observations as you about voltage and timing.
    To record messages, I used a RS485 device to convert low dual voltage signals to TTL, connected to a laptop by LPT port, from software side, I used a small program, like data logger, running in kernel mode under Linux to save signal state and timing transition with better accuracy possible.
    Next I tried to recognise a protocol, here I failed!!!

    So, I will re analyse my logs with your informations. I hope I will able to identify cmd and so on... And give a feedback...

    Comment


    • #3
      Oh cool.

      Hi Titiben,

      great to hear that there are more people wanting to use such an emulator.

      The current status is that I have written some PIC code that should be working, but I got a bit lazy and haven't de-bugged it nor have I compled the driver circuit for the radio. It isn't too far off completion, but I got busy first, then lazy. I will let you know when I give it the final push!

      PCP

      Comment


      • #4
        what radio do you have?

        Oh.. and also - what radio do you use?
        Does it look like the Renault one? Does it show you minutes + seconds when playing cds?
        I tested another Philips radio that required the cd changer to report the timing, which I haven't implemented in my variant. That radio had a basic setting which allowed the Aux in to be enabled, even without a cd changer, so I figured it would be wasted effort.

        Comment


        • #5
          Hi PCP,

          Which kind of driver do you use between your PIC and cd changer bus?
          Is my RS485 hypothesis valid?

          I try to re analyse my data next week-end.

          Titiben

          Comment


          • #6
            Hi Titiben,

            I was going to use a simple two transistor circuit and some resistors. I found a diagram in one of the patent documents. HOWEVER, I haven't tested it to check that it gives appropriate voltage levels, nor that it is fast enough. Basically the resistances are known (and the values I measured were the same as in that patent document), so adding some transistors to switch should work, if a bit crudely.

            I haven't explored the RS485 direction, so I can't say whether it works.

            I won't have time myself this weekend, but might after that. It is good that I have a reason to complete the task that has been lying around for so long!

            PCP

            Comment


            • #7
              Hi PCP,

              My radio is 4050 and my CD changer is DC012. The radio display is not include in radio but located in dashboard and this radio does not display cd time information just track and cd number.
              In fact it is a quite basic system!

              Titiben

              Comment


              • #8
                Hi PCP, I've read your post and your documentation and started to put up together something. There is though one thing, at the moment, I would need some help with. As far as I understood, the communication on this physical channel is some king of pulse coded binary. So every bit is a pulse, with a "zero" being longer than a "one" (in short words). Now, I've looked at your samples and tried to plot something to get a picture of what is going on(I will add it if someone interested). It is very clear that reference level is 2.5V(the 2.48V sampled is probably because noise) and a data pulse has an amplitude of 2.5V (pulse duration gives the bit value 0 or 1). At first I thought it is differentially transmitted on both wires but then, plotting both "+" and "-" (based on your sampling) I realized that "-" is just a shifter with 2.5V for "+" signal to increase immunity to noise (on the ground line), sort of reference voltage. Now, you were talking about some mV values which I can't fit anywhere. Further, there are some spikes(close to 5V, very short ones), I would say periodically but not sure yet, can you tell me what is it about those. Are they start bits? I need to clarify first physical channel basics and then I will proceed with data link layer above. Please assist me with any comments.

                Thanks,
                Radu.

                Comment


                • #9
                  OK, I've took some time to look more over PCP's samples and things started to make sens. But not entirely. I've plotted the samples and tried reproduce the binary information PCP added in the other document posted. I've added a snapshot of a sequence (part of 13bit recipient address). My binary understanding of it is 0000111001000 while PCP is 1111001101111. Regarding the plotted image, my premises were a period of around 23us and a long pulse means "0" while a short pulse means "1" (this was taken from a patent file PCP referred to). The timing is in us and the amplitude in V (pulses at about 2.5V). The timing for following fields/frames(like sender ...) have different timings (shorter) - I will come back on them in future posts.
                  PCP, or anybody else, please give me some info on how to interpret this signal correctly. Thanks.

                  Comment


                  • #10
                    I've decided to design and prepare myself a data acquisition device, capable to trace this bus. I'll come back to you with updates when I have some

                    Comment


                    • #11
                      After reading carefully PCP's sheets I've noticed that everything is fine. On sheet one data is inverted, the reference should be sheet two, at least that is for me at this point. Still working at my driver for this. Coming back when I have some results.

                      Comment


                      • #12
                        information on the input selection processor

                        Hi, I have a Philips Radiosat 6010
                        I was looking for a way to install an AUX port so I put the radio to pieces.


                        The switching between sources is managed by a TDA7342

                        datasheet dowloadable there :
                        http://www.datasheetcatalog.org/data...onics/4059.pdf

                        I don't know if you have look at the datasheet but to summarize;

                        there are 4 inputs :

                        - Mono IN (pin 8) -> AM radio input No -> pin unallocated

                        - IN1 : FM radio input + AM radio
                        -> (pin 7) IN R1 : FM radio right
                        -> (pin 13) IN L1 : FM radio left

                        - IN2 : tape input
                        -> (pin 6) IN R2 : tape right
                        -> (pin 12) IN L2 : tape left

                        - IN3 : CD input
                        -> (pin 5) IN R3 : CD right
                        -> (pin 11) IN L3 : CD left
                        -> (pin 10) CD GND : CD ground

                        The selection of the input is done by the I2C bus
                        -> pin 28 (SCL) -> clock line
                        -> pin 27 (SDA) -> data line
                        -> pin 26 (DIG GND) -> ground for communication bus


                        I also tracked the D2B signal pin of the CD connector -> it seem that it goes (almost) directlly to the TA7342 (I mean it just go trough some capacitor or resistor), all D2B signal pin from FM/tape/CD are parallel mount on the same bus (call i2C bus) NO -> D2B signal from the CD connector goes to M6307 (a D2B / I2C translater) and become a I2C signal.


                        On pages 7 there is an explanation of the I2C bus interface (for the signal format)


                        Pages 8 to 12 explain the protocol specification : message to transmit for function selection (input selection, volume control ,...) -> it seems that you can control all the car radio by this protocol

                        The interface protocol comprises:

                        - A start condition -> no real explanation on this (part of the I2C communication control)

                        - A chip address byte,(the LSB bit determines read/write transmission) -> the diagram show 1000100W (W-> 0 to write and 1 to read)

                        - A subaddress byte -> for input selector it's "11100000"

                        - A sequence of data (N-bytes + acknowledge) -> for IN 3 (CD) with +11.25dB input gain that give "00100000" (or 0x20 in hexadecimal)

                        - A stop condition -> no real explanation on this (part of the I2C communication control)


                        I hope that can help you a little
                        in fact I use a different approach -> I use the internal I2C communication bus to select the CD source intead of the D2B communication bus

                        Comment


                        • #13
                          As you said "Any help and comments greatly appreciated!" I felt like you won't chop my head off if I try to help. :P

                          Well, I have a damn simple old Philips car headunit with D2B input and I would like to use it as a aux input, so what would really matter to me are the pins 10, 9 and 8 (accordingly to http://elektron.pol.lublin.pl/users/...e/philchan.htm these are ground, left and right channels - hopefully analog signal). But somehow I gotta be able to fool the HU to believe there's a CD changer there, so the HU has to amplify whatever is coming on the pins said above - and I believe this is exactly what you're trying to do.

                          Well, now it's time to introduce my potentially stupid idea.
                          I don't really care about using the HU to control my music playing device, just want a aux input, so what if we just put some random (digital or amplified analog) noise into pins 2 and 3 (D2B+ and D2B-)? The HU would be all confused and showing random stuff on the display, but maybe this would keep the audio input enabled. Of course there's a great chance this would not work, but as I've not studied the protocols yet this idea does not sound so senseless to me after all. :P I don't really know what the HU wants to 'listen' before enabling the aux input, but maybe the random noise (or some 555 timer oscillating) could keep the HU 'entertained enough' so it won't be shutting off the aux input. Or, if the random noise can't do the trick, maybe a constant voltage at those pins?

                          In case everything I've guessed is a complete failure, there's still a last resort: someone who owns an headunit (pcp?) could record the relevant part of the digital communication going on, then just upload it to a microcontroller and make it play what the HU 'wants to hear'. No actual communication going on between the MCU and the HU, the MCU just ignores what the HU says and plays a loop of the previously recorded signals. Then there would be no need to reverse engineer the protocol used.

                          I know this is absolutely not scientific, just a workaround to make the aux input work. But it would be enough for me.

                          So, what you guys think?

                          Comment


                          • #14
                            I was looking around on the internet for more documentation on DB, aka IEC 61030, and it seems IEC has withdrawn this standard in 2006, as stated in http://regsys2008.iec.ch/cgi-bin/pro...=&Fr=&TR=&Ed=1

                            That's funny. Without proper documentation it's much harder to get the information we need to understand how this thing work, unless Philips still provides this kind of documentation. Guess the only way to figure out what the data mean is by staring at it and trying to guess something which makes sense, like pcp has been doing since the beginning. Reverse engineers around?

                            BTW, I found a product in a UK shop which turns the D2B audio input into a aux input. And it costs just 81.74! Yeah, guess I'll be buying a new HU if I can't make one of these by my own...

                            Comment


                            • #15
                              Originally posted by eliasalberto View Post
                              Well, now it's time to introduce my potentially stupid idea.
                              I don't really care about using the HU to control my music playing device, just want a aux input, so what if we just put some random (digital or amplified analog) noise into pins 2 and 3 (D2B+ and D2B-)? The HU would be all confused and showing random stuff on the display, but maybe this would keep the audio input enabled. Of course there's a great chance this would not work, but as I've not studied the protocols yet this idea does not sound so senseless to me after all. :P I don't really know what the HU wants to 'listen' before enabling the aux input, but maybe the random noise (or some 555 timer oscillating) could keep the HU 'entertained enough' so it won't be shutting off the aux input. Or, if the random noise can't do the trick, maybe a constant voltage at those pins?
                              I think the random noise might not work -> if the HU can't understand what it receive, nothing happen


                              Originally posted by eliasalberto View Post
                              In case everything I've guessed is a complete failure, there's still a last resort: someone who owns an headunit (pcp?) could record the relevant part of the digital communication going on, then just upload it to a microcontroller and make it play what the HU 'wants to hear'. No actual communication going on between the MCU and the HU, the MCU just ignores what the HU says and plays a loop of the previously recorded signals. Then there would be no need to reverse engineer the protocol used.

                              I know this is absolutely not scientific, just a workaround to make the aux input work. But it would be enough for me.
                              This one might work.
                              to improve it;
                              -> you have to clean the recorded digital communication from the HU respond (1 bit of acknowledgement for some order)
                              -> record differents situations; "CD unit selection", "playing", "pause", "stop" (in the case where you have to keep alive the CD unit selection)

                              Comment

                              Working...
                              X