Music-Player gets CAN-BUS!

Lets’s get deeper in the car’s electronics

My XBMC-Mediacenter works pretty well. But the only way to skip a song is the I/R remote placed in my armrest and to see what song is playing, I need to switch the whole display to mediacenter mode.
Because I always wanted to take a closer look at the CAN-BUS in my opel astra, I decided to give the music player another update.

So I ordered a MCP2515 / MCP2551 CAN-BUS interface for a raspberry pi and started to scan the bus.

The opel astra h (2004-2010) has the following busses:

• SW-CAN (SingleWire) 33.3 kbps also known as “GMLAN”
• MS-CAN (MidSpeed) 95.0 kbps
• HS-CAN (HighSpeed) 500 kbps

The car body bus

The first was to capture some “base noise” with the bus awake and the ignition off. Then I performed some actions like pressing buttons, locking/unlocking the car etc.
That capture could be compared to the base noise to identify the messages only send in that capture. That gave me some results:

This means that when I send 160#0340C803, followd by 160#0300C803, the car locks! This point was a huge milestone!

The entertainment bus

What I really was interested on was the MS-CAN with the unusual 95 kbps!
So I did the same as above and found what I wanted:

206 # 01 91 00 - Steering Remote UP
206 # 01 92 00 - Steering Remote Down

I also found the outdoor temperature:

683 # 46 01 XX where the temp in celsius is XX/2-40 so 0x00 is -20.0°C and 0x76 is 19.0°C.

But the really cool data goes to the display:

6C1 # 10 2E C0 00 2B 03 01 01
6C1 # 21 00 20 23 03 00 41 00
6C1 # 22 75 00 78 10 0A 00 1B
6C1 # 23 00 5B 00 66 00 53 00
6C1 # 24 5F 00 67 00 6D 00 41
6C1 # 25 00 75 00 78 11 01 00
6C1 # 26 20 12 01 00 20 01 00

The first byte of the packet identifies a multi-packet message. It starts with 0x10, than follows 0x2X where X increments from 1 to F. So after 0x2F comes 0x20, 0x21…
The second Byte of the first packet is the number in Bytes. The last packet is always 8 Byte long but the rest is ignored (these are either filled with 0x00 or the same then the previous package).
Than are two byte of command or mode. This is 0x4000, 0xC000, 0x5000 or 0xA000. Don’t know what that means… Than comes the size and type of the following container. Type 0x03 seems to update the main screen.
Now follow some strings, starting with an ID (here 0x01,0x10,0x11 and 0x12), the number of characters and the characters in UTF-16 (where only very vew unicode-chars are supported but that comes in the next post).

That’s all…

This is a schematic view of the above packet:

With that knowledge, I generated my own packet:

6C1 # 10 54 C0 00 51 03 01 01 - 84 Bytes, mode 0xC000, 81 Bytes payload, type 0x03, id 0x01, 1 char
6C1 # 21 00 20 02 03 00 41 00 - Whitespace, id 0x02, A
6C1 # 22 75 00 78 10 07 00 48 - u x, mode 0x10, 7 chars, H
6C1 # 23 00 61 00 63 00 6B 00 - a, c, k
6C1 # 24 65 00 64 00 21 11 0C - e, d, !, id 0x11, 12 chars
6C1 # 25 00 76 00 69 00 73 00 - v, i, s
6C1 # 26 69 00 74 00 20 00 6A - i, t, Whitespace, j
6C1 # 27 00 62 00 30 00 2E 00 - b, 0, .
6C1 # 28 64 00 65 12 0C 00 68 - d, e, id 0x12, 12 chars, h
6C1 # 29 00 61 00 63 00 6B 00 - a, c, k
6C1 # 2A 61 00 64 00 61 00 79 - a, d, a, y
6C1 # 2B 00 2E 00 63 00 6F 00 - ., c. o
6C1 # 2C 6D 00 00 00 00 00 00 - m

And what happened? This:

Next: Fully working prototype