Text preview for : cd changer protocol.pdf part of all all CD changer cable wiring diagram
Back to : cd changer protocol.pdf | Home
Page 1 of 13
Blaupunkt ( DMS ?? )
for controlling a Blaupunkt car radio. It is basically a 2 wire (rx/tx) async. serial protocol with 9 bits of data where the 8th bit is used for synchronisation. That made it easy to interface it to a player or PC because you can use the serial port. The only documents that're left is one sheet of paper containing the initial communication between a cd changer and the radio and the source code. Here is the protocol cut:
radio baudrate 4800 0x17B 0x17C 0x17D 0x17E 0x17F 0x180 0x48 0x02 0x14F 0x180 0x9F 0x14F 0x180 0xA1 0x14F 0x180 0xAD 0x14F 0x180 0x48 0x01 0x14F 0x10F 0x48 0x01 0x14F 0x103 (3 times ) -> (3 times ) -> (3 times ) -> (3 times ) -> (3 times ) -> -> -> ->
direction,info
changer no response no response no response no response no response 0x180 0x48 0x02 no response 0x180 0x9F no response 0x180 0xA1 no response 0x180 0xAD no response 0x180 0x48 0x01 no response 0x10F 0x48 0x01 0x14F 0x103
->, change in baudrate to 9600 -> -> -> -> -> -> -> -> -> -> -> -> -> <<<<<-
10/07/2006
Page 2 of 13
0x20 0x09 0x20 0x00 0x14F 0x10B 0x20 0x14F 0x101 0x09 0x01 0x14F 0x10D 0x01 0x09 0x43 0x57 0x14F
<<<<<<-( text info ??? ) <- (8 times space ) <<-( disc / track info ??? ) <<<<- ( disc / track / time info ( BCD ) ?? ) <<<<<-
0x20 0x09 0x20 0x00 0x14F 0x10B 0x20 0x14F 0x101 0x09 0x01 0x14F 0x10D 0x01 0x09 0x43 0x57 0x14F
Kenwood
The protocoll used here is a synchron serial protocoll. First let us start with the connector pinout. The pins have a 2.54mm distance, so you can simply build a plug using some prototyping board .........
New connector pin-out (for head units >'99?) Thanks to Patrick Loef for this information.
pin 1 2 3 4 5 6 7 8
direction description O O I O I CH-REQH - Request output to changer; "Low" : Request Ground Vcc +12V CH-CON - Changer control; "High" : Operation mode "Low" : Standby CH-MUTE - Mute request from changer; "High" : Mute AGND - Audio Ground CH-RST - Reset output to changer Audio right channel
10/07/2006
Page 3 of 13
9 10 11 12 13
I I O I I/O
CH-REQC - Request input from changer; "Low" : Request CH-DATAC - Data input from changer CH-DATAH - Data output to changer Audio left channel CH_CLK - Clock input/output for changer
The following works only with newer kenwood radios. Older models have the same pinout but use some more simple protocol ... The clock low and high periods had a length of 4us. The data is transfered in bytes ( 8 bits ... MSB first ), data is valid at the rising clock edge.. The data transfer is initiated either by the radio or the changer, the initiator just pulls its fs line low. When the changer starts the communication it gets 40 clocks from the radio ( 4 bytes addr + 1byte data size ). The radio then sets its fs to low if it accepts the transfer. When a transfer is initiated by the radio by setting its fs low it waits for the changer to answer with a low fs, then it sends the 4 byte addr header, the size byte for the data and the data.
Packet header, direction: both byte 0 1 2 3 4 log value ( r->cdc) 0x29 0x10 0x1E 0x00 x description destination address destination address own address own address data size
10/07/2006
Page 4 of 13
in bytes 5 4+data size x x first data byte last data byte
From this point I only write the data part of a packet
initialisation handshake answer, direction: cdc->r byte 0 1 2 3 4 log value 0x11 0xA4 0x00 0x01 0x02 description command identifier cycle numer of the above packet ?? ?? ??
send after above packet, maybe radio identification and caps, direction: r->cdc byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 log value 0x20 0x00 0x11 0x01 0x03 0x0B 0x0B 0x07 0x05 0x83 0x84 0xC0 0xC1 0xC2 0xC3 0xC4 0xC5 description command identifier
10/07/2006
Page 5 of 13
17
0xC6
send after above packet, maybe init ack from radio, direction: r->cdc byte 0 1 2 3 4 5 6 7 log value 0x20 0x01 0x11 0x29 0x10 0x00 0x01 0x02 changer address changer address maybe last bytes of cmd 0x11(cdc->r) maybe last bytes of cmd 0x11(cdc->r) maybe last bytes of cmd 0x11(cdc->r) description command identifier
changer caps info, send after above packet, direction: cdc->r byte 0 1 2 3 4 5 6 log value 0x70 0x02 0x0A 0x3F 0x03 0x0C 0x02 maybe disc count description command identifier
play position info, direction: cdc->r byte 0 1 2 3 4 5 6 log value 0x60 0x02 0x00 0x00 0x00 0x00 0x02 error code, 0 is no error changer status ( load, eject, ..... ) play status (1 - play, 2 - pause ) description command identifier maybe sub command id
http://www.mictronics.de/?page=cdc_proto
Page 6 of 13
7 8 9 10 11 12 13 14 15 16 17 18 19 20
0x00 0x01 0x00 0x04 0xBB 0x01 0x0B 0x07 0x01 0x22 0x62 0x26 0x09 0x30 track number disc number min ( bcd ) sec ( bcd ) min disc ( bcd ) sec disc ( bcd ) min remain ( bcd ) sec remain ( bcd ) some bcd number field, displayed when field 3 != 0 track order mode ( normal 0, tscan 1, dscan 2,random 6, ...)
text info request, direction: r->cdc byte 0 1 2 3 4 5 6 log value 0x42 0x02 0x07 0x0A 0x00 0x00 0x80 text id ( 0x80 -> name 0x81 -> artist ) disc number track number text section number, sections had 12 bytes size here description command identifier
text info send after request, direction: cdc->r byte 0 1 2 3 log value 0x62 0x02 0x07 0x02 disc number description command identifier
Page 7 of 13
4 5 6 7 8 9..20
0x0A 0x00 0x09 0x00 0x80 x
track number ( 0 -> disc title transfer ) text section number, sections had 12 bytes size here
text id ( 0x80 -> name 0x81 -> artist ) text
commands send when keys on the radio were pressed, direction: r->cdc byte 0 1 2 3 4 5 log value fwd (toggle) (play) 0x50 0x02 0x02 0x00 0x07 0x00 bwd (toggle) disc(toggle) disc+ (toggle) description
0x50,0x50 0x50,0x50 0x50,0x50 0x50,0x50 command identifier 0x01,0x04 0x01,0x04 0x02,0x00 0x02,0x00 0x02,0x02 0x02,0x02 0x02,0x02 0x02,0x02 0x02,0x02 0x02,0x02 0x00,0x00 0x00,0x00 0x01,0x01 0x02,0x02 0x04,0x00 0x02,0x00 key id 0x05,0x05 0x06,0x06 0x00,0x00 0x00,0x00 maybe event id ( 0 all up, 01 down toggle, 04 up, 06 hold )
Using the information above you should have some starting point if you are intrested in doing your own project, it is simple to build a converter to send and receive these commands using a pc so you can find out the meaning of other commands and fields if you need.
Pioneer
The pioneer IP bus uses a 2 wire differential signal for communication. An equal level on both lines is a logical low while a high is encoded as a voltage difference of some 100mV. I think a CANbus tranceiver should work here. The data transfer is initiated by either the cd changer or the radio.The initiator generates a high pulse ( ca. 170us ) and a following low pulse ( Then the data transfer starts, a 1 is encoded as a high-low sequence with a duration of ap. 20us for both levels and a 0 consists of a 33 us high and a The data is now transfered in bytes with MSB first, the 8th bit is an odd parity bit.At the end of the 3 rd and all following Bytes there is an additional bit inserte receiver acknowledges the transfer. This is done by holding the data lines in a high state after the initiator sets them low.If this ack is missing the transfer is stopped. The timings may vary because the real data is encoded in the pulse to space length relation.
The first 3Bytes seem to be some kind of device address.The changer I used transfered a 0x88,0x68,0x00 here while the radio sended 0x88,0 x The next 4 bits were always high. After that a size byte and then size bytes were transfered. The last byte in the transfer is a checksum generated adding the with the 4bit sequence ( = 0x0F ). In the following part I only will write the raw data excluding size and cheksum field. Each command transfered was first answered by some acknowledge packet consisting of a single 0xA1. (which looks like: 0x88 0x08 0x06 0xF 0x02 0xA1 0xB2 -> 0xB0 is the checksum ).
Page 8 of 13
For now I just figured out some very basic things like the fields where time, track and disc number are encoded and also some key codes the radio sends. There are many more fields in the packets where i still don't know the meaning of. (I just got the radio from a friend for some days and so I couldn't do so much more on it ... however .. if somebody is intrested in some more information and is wiling giving me a radio and a changer for some weeks I'll try to do some more .... ) I have also designed a small circuit using a AT90S2313 controller which can be used for logging the transfer through the pc serial port and also to send commands. The following packet sended by the changer contained the time disc and track information.
Byte 0 Info command Data 0x61
modus:
1
2
3
4
5 modus
6
7 mcd
8
9
10
11
12 track
13
14
disc min sec
0x10 0x06 0x01 0x20 0x04
0x16 0x01 0x06 0x01 0x00 0x00 0x01 0x00 0x3
Value 0x02 0x07 Info ready track blink
0x08 0x10 pause
0x11
0x13
0x14
0x15 0x16
ready and disc disc blink blink
load and disc eject and disc load eject blink blink
cdt: bit0: (1:cdtext),(0:normal) The text information was encoded within this packet
Byte 0 Info command Data 0x61
1
2
3
4
5 modus
6
7
8
9
10
11
12
1322 text
text disc track seqence number 0x38 0x09 0x00 0x06 0x00 0x00
0x10 0x06 0x01 0x20 0x04
0x00 0x00
Possibly pinout of Pioneer headunit in Renault Espace III
10/07/2006
Page 9 of 13
Panasonic
The protocol panasonic uses is of the serial sync. type. There is one data line, a clock line and a sync line the changer uses to send data to the radio. The radio to changer communication is done by some signals known from standard IR remote controls (without a carrier) using one dataline. This remote control signal is pulse width modulated,the dataline is active high. After an initail high(9ms) low(4.5ms) there follows a 32 bit sequence with a 0 encoded as 550us high,550us low and a 1 as 550us high,1.7 ms low If the low pulse in the init phase is only 2.25ms long it is just a signal send periodical when a key is hold down and there are no data bits. The data is transfered lsb first, the 1st byte is 0xFF-0th byte and the 3rd byte is 0xFE-2nd byte.The 2nd byte is the command. The changer to radio communication transfers the data in bytes msb first, the data is valid at the falling clock edge and a low pulse of one half clock period is byte of the transfer on the sync line..The clock period is arround 8us. There was only one packet containing state, time, disc and track information.
Byte
0
1
2
3
4
5
6
7
10/07/2006
Mictronics
Michael's Electronic Projects
Page 10 of 13
Info Data
state:
disc(b0-b3) 0xCB 0x42
track 0x09
min
sec
state 0x30 0xC3
0x02 0x56 0x00
Value Info
0x00 normal
0x10 scan
0x20 random
0x04 random
0x08 repeat
Page 11 of 13
This should be the pinout for the Clarion 13-pin DIN connector which is used for Clarion C-Bus.
Ford ACP
Ford ACP is a network protocol used by the Head Unit to communicate with and control audio devices such as the Ford 6 disc CD Changer and the Nokia integ Telematics units. It is based on RS485 with 9 bit character data at 9600 baud. A MAX-481 low power RS485 transceiver will work as interface between a serial USART and ACP bus.
Pin Function 1 ACP + 2 ACP Shield 3 GND 4 n/c 5 Audio Left + 6 Audio Right + 7 ACP 8 CDENABLE 9 +12V Power (unfused) 10 Audio Shield 11 Audio Left 12 Audio Right + You will need an AMP plug to connect to the head unit. AMP Multilock Series 40 cable connector housing with 12 pins or sockets. The CDENABLE line is 0V when the radio is off and +10V when it is on and can be used as a standby switch for the yampp. It is not a power supply and can't drive a relay directly. Communication
10/07/2006
Page 12 of 13
* a delay of 1642us (16 Bit times) will indicate a start of new message * the 9th bit in a byte must be set in the last byte of message to indicate the end of message * Acknowledge is given with 0x06 Byte 0 - Medium/Priority, should be 0x71 Byte 1 - Changer functional address, should be 0x9A or 0x9B Byte 2 - Head unit address, 0x80 on receive, 0x82 on transmit Byte 3 - Command control byte
0xE0 - Handshake 1, byte 4 should be 0x04
0xFC - Handshake 2, byte 4 must be the same for transmit and receive 0xC8 - Handshake 3, byte 4 must be the same for transmit and receive 9xFF - Current disc status in byte 4 Byte 4 - 0x00 Disk OK Byte 4 - 0x01 No disc in current slot Byte 4 - 0x02 No disc at all Byte 4 - 0x03 Check current disk Byte 4 - 0x04 Check all disc 0xC2 and 0xD0 - Change or request current disc Byte 1 - 0x9A - command to change disc Byte 1 - not 0x9A - request current disc Byte 4 - disc number 0xC1 - Control command Byte 4 Bit 0 - Fast search Bit 1 Bit 3 Bit 4 - change Random status Bit 5 - change Loudness status Bit 6 - change Play/Stop status Bit 7 Send back byte 4 with actual mode 0xC3 - Next track Byte 4 - Track number 0x43 - Previous track Byte 4 - Track number
The last byte in all message is a checksum of all previous bytes. Simply add all bytes of message to calcu Message examples To display current play time, disc and track number: Byte 0 0x71 1 0x9B 2 0x82 3 0xD0 4 Disc No 5 Track No 6 Minutes
Seconds
No disc message:
Page 13 of 13
Byte 0 0x71
1 0x9B
2 0x82
3 0xFF
4 0x01
All informations are given without guarantee. Please mail for update or change requests.