Part 2: Hardware
Infotainment/NAVI system in Honda Odyssey 2007 is a huge monster – it has a luxury audio unit with 6 CD changer, a DVD-player, large NAVI screen in the dashboard, dashboard and steering wheel controls, rear screen with controls, IR remote and IR headphones. Awesome, isn't it?
Well, the problem is that we live in 2016 and it really does suck when you are stuck with the only choice between CDs and DVDs. If you want MP3, computer video, USB input, Bluetooth or anything else – your only option is the AUX input (composite video + stereo audio). It's definitely something, but if you are a maker, you can't be really satisfied with it, can you?
So I thought – why don't I look into how the hell this DVD works and if it would be possible to replace it with something more interesting and flexible – think a Raspberry PI or alike.
I googled the car (Honda Odyssey 2007), the DVD-player etc, and found a video on how to remove the DVD from the car:
Pretty fast I found a few diagrams of the audio/NAVI system wiring, it seems to be really the same for Honda Pilot 2005-2010, too.
|DVD-drive 22 pin connector pinout|
Interesting, so DVD actually seems to be spitting out composite video and stereo. This will definitely work with a Raspberry PI, that's what I thought. Too easy.
That's unless the audio head knows that somebody is messing with the DVD-drive. Try unplugging the drive, and it will not even be possible to switch to DVD source. Bummer. So, OK, not a big deal – on the pin out diagram there are two COMM wires, let's tap in there and see what's going on there.
At this stage I deviated from the right path because I found a seemingly very similar TOYOTA Corolla MP3 Player Project, and convinced myself too easily that it is gonna be the same communication protocol. I built hardware and spent some time troubleshooting it because it was not doing the job. Finally I decided to see what's actually going on on the buss, hooked up my scope to see… this:
I'll not go into a lot of details on how I was actually able to figure that this was an inverted UART 9600b/s with 8e1 (that is 1 start, 8 data, 1 even parity and 1 stop bits) protocol, although that is somewhat entertaining: involves luck and interesting effect of moire when printing the waveform chart from LibreOffice, that produced specific pattern so I was kinda able to see unique bits in that communication with a naked eye - ikr).
Once I figured that out, things became a little easier. I built an adapter so I was able to connect the DVD drive back to the car and tap on their conversation (WARNING! There's ALWAYS +12V present on this connector, even when ignition is off!):
You will have to use some dirty CIA techniques or black magic to make me remember how I figured that 0x86 in this is actually the byte, signaling the start of a frame. Knowing this, we can parse it to make more human readable:
86 3C 0F 00 00 51
86 3D 0F 00 00 52
86 3E 0F 00 00 53
86 3F 0F 00 00 54
Just so you understand, by now I was listening to a single line, i.e. this is not both devices talking to each other, but rather what one says. After playing a little with the data I had, I was able to figure the frame format:
|Byte 1||Frame start||0x80|
|Length of frame||0x06|
|Byte 2||Frame ID|
|Byte 5 (n-1)||data|
|Byte 6 (n)||checksum|
Checksum here is 7 LSB bits of sum of all bytes of the frame.
Then it was time to put this knowledge into perspective. I built a device that would listen to both lines simultaneously and send this information to me to process. I built a sniffer out of STM32VL-Discovery (it has three UARTs – just what I needed: one for the Audio head, one for DVD drive, and one to send info to computer).
Some time to adjust the parser, and we now can see data in a few different formats, that help analyzing the exchange:
1F (H) 04 01 (d) 01 03 22 00 03 55 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00
20 (H) 04 01 (d) 01 03 22 00 03 56 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00
21 (H) 04 01 (d) 01 03 22 00 03 57 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D
22 (H) 04 0F (d) 0F 00 00 (d) 0F 01 00
23 (H) 04 01 (d) 01 03 22 00 03 58 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00
24 (H) 04 01 (d) 01 03 22 00 03 59 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00
25 (H) 04 01 (d) 01 03 22 00 04 00 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00
26 (H) 04 01 (d) 01 03 22 00 04 01 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D
27 (H) 04 0F (d) 0F 00 00 (d) 0F 01 00
And unique commands:
These are different slices of (different) parts of exchange, but they also allow (after a few hours of staring at this) to guess all we need to make things work:
- The head pings the DVD every second or so with frame:
Example 85 1C 04 01 26
Byte 1 Frame start 0x80
Length of frame 0x05 5 bytes Byte 2 Frame ID 0x1C
Byte 3 Status 0x04 0x02 – idle
0x04 – active (when DVD source is selected)
Byte 4 Command 0x01 0x0F – keep alive
0x01 – media status
0x02 and 0x03 – some extended status commands (e.g. current action, type of media etc)
Byte 5 checksum 0x26
- DVD may respond with
“all OK, no changes”
Example 86 26 0F 00 00 3B
Byte 1 Frame start 0x80
Length of frame 0x06 5 bytes Byte 2 Frame ID 0x26
Byte 3 Command 0x0F Always repeats command in request (see Byte 4 of the request) Byte 4 Response byte #1 0x00
Byte 5 Response byte #2 0x00
Byte 6 checksum 0x26
But it may also tell the head it wants to make an update. In this case it would respond with the type of update it has:
Byte 4 Response byte #1 0x03 0x03 – changes in media, e.g. disk is inserted, disk is being identified, DVD or CD media has been identified, the media is being read etc. Byte 5 Response byte #2 0x00
- To which the head sends a different request (note 04 01 !!):
85 20 04 01 2A
And then the DVD would respond with lots of data:
I'll not go into details on how this frame is composed ( I was able to figure out only about 30% of it anyways), but there's media type information, time stamps, number of current and total tracks for CD, number of titles and chapters for DVD and I also bet there's information about audio tracks as well.
I built a PIC16F1827-based circuitry to emulate DVD and verified that with just a few commands it is able to enable video pass-through to the rear screen.
In the next part I'll describe the hardware setup that was used for the hack and can be useful to connect your own media source to the vehicle RES (Rear Entertainment System).
P.S. It was risky and I had a few solid chances to fry some/all electronics in the car. There's always +12V present on the connector. Please please please think twice before doing something, especially doing something stupid. It's always better when you know what you are doing, or have what seems to be unlimited amount of luck (such as in my case).
P.S.S. Please support this blog by clicking some ads or using Donate button.
P.S.S.S. Meanwhile if your hands itch, check out this hack that allows to mirror RES screen to NAVI screen. Nothing is worse when your kids needing help starting video and you having to get out of the car, walk to the other side, jump in the back, wait till all the ads and warnings play through, click through long animated menus and all of this sitting on the laps of your kids feeling like sardines in a can.