Thread: Renault Radiosat 6010 / Philips D2B cd changer emulator

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

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?

I was looking around on the internet for more documentation on D²B, 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...

Originally Posted by eliasalberto

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

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)

jedi83, that's exactly why someone who owns this HU would be needed for this task. As I don't own one of these HUs, I'm not able to record this signaling. And I don't even know if the memory inside the MCU would be enough to hold all data the MCU would need to "shoot" at the HU.

In fact, I'm having my car fixed this week so I'm not able to test things out, but I might do some testing when I receive it. I really hope I can enable the line in if I just apply the right voltage to the data pins. If it doesn't... back to the lab.

With an oscilloscope I try to monitor D2B+ and D2B- of the HU CD connector (in order to watch D2B transmission from the tape unit or the radio) but I can't see anything.

When I had disassembled my radio the D2B bus seem to be a ring with aux sources plugged in parallel to it. So I was thinking that all D2B data were visible once you connect the HU CD connector D2B pins.
-> If it does not come from my oscilloscope, that mean I was wrong with the D2B ring bus, and we can send D2B command without interfering with the other HU functionnality


NB: I used an analogic oscilloscope and an software oscilloscope ("Zlescope" that use my PC sound card line-in)

Jedi83, I do know Zelscope. I plan to build a buffer using op amps to be able to use my notebook as a basic portable oscilloscope. But I'm afraid it won't be able to read this kind of signaling because it happens at a much higher frequency. Human ears listen to sound up to 20khz but regular microphones are not designed for that range of frequency, as human voice does not go all the way up to 20khz; so, I'm assuming computer's mic port can record up to 5khz, meaning a sample rate of 10ksample/sec, thus 100us per sample. As the original poster said, signals could be as short as a few us (microseconds).

Hello! I have noticed that D2B interfacing is made by MSM6307 manufactered by Oki. It acts as D2B to I2C converter. Its datasheet explains briefly D2B protocol and MSM6307 internal registries.

I hope that can help you

What's happen? Did someone manage to emulate cd changer?