The Raspberry Pi will be able to communicate with the instrument cluster display to be able to give feedback to the User and show the current song/artist.This display is originally used to show Check Control messages (such as "Brake Light Out" or "Fasten Seat Belts", etc.) and info from the On Board Computer (such as time, MPG, outside temp,etc). It can show up to 16 characters at a time.

Information about the communication protocol used by the cluster can be found here: http://i-code.net/injecting-custom-uart-messages-into-the-bmw-750il-instrument-cluster-lcd/

As a first step in interfacing the Pi with the cluster, serial communications will be set up on the Pi.

Pinout of the P1 port (from http://www.hobbytronics.co.uk/raspberry-pi-gpio-pinout):

So pin 8 will be the primary one to focus on since it will be sending data out the cluster.

By default the Pi uses the UART port for the console, so this needs to be disabled to allow it to communicate with the cluster later on: http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/io-pins-raspbian/uart-pins

After reading the above link about the cluster communication, it seems there are two comm wires, the LAC and the DAC. The LAC seems to be a more of a handshaking/priority line where nothing else is allowed to transmit on the bus when it is pulled low. The DAC is the data line which operates at 9600 bps, 8 data bits, Even parity, and 1 stop bit.

Here's the steps for sending data to the cluster (from i-code link above):

The basic logic is as follows: every 100ms, the CCM/LKM do their status updates, and this results in a rising edge (0V -> 12V) on LAC.

1. Wait for a rising edge

2. drive LAC low with a transistor, MOSFET, etc

3. send 16 bytes of serial data using 9600 baud, 8 data bits, Even parity, 1 stop bit

4. send the checksum of the data using the same 9600 baud, 8 data bits, Even parity, 1 stop bit

5. release LAC; stop driving it LOW

The checksum is calculated as follows: take a running sum of the 16 data bytes in hexidecimal form, take the least significant byte of that sum, add 1.

Researching the Cluster Comm

I hooked up a USB oscilloscope to the DAC and LAC lines going to the cluster to see what is going on when the cluster is displaying a regular message (fuel range, in this case). In the following screen shots, blue is the the LAC line and red is the DAC line.

While nothing is shown on the display:

While a message is being displayed:

So, as mentioned in the i-code article, it seems that the Check Control Module (CCM) is doing an update every 100ms (shown in the first screen shot, while nothing is being displayed). Note that the LAC line is being pulled down during the CCM update.

Now looking at the screen shot of while a message is being displayed, after the LAC line is returned high, the message data is sent on the DAC after a short delay.

Now in the i-code article, he mentions that he didn't have a delay between the LAC going high and the On Board Computer (OBC) message starting. He got around this by driving the LAC low which would stop the OBC message from being sent. It is also mentioned the delay is meant to be a priority tool, where higher priority messages wait less time after the LAC going high to send their message (and once a device sees another device transmitting, it will not send its message).

Since I do see a delay between the LAC going high and the message data, I think I may be able to get away with not driving the LAC low. It looks like I also have the choice of making my message higher or lower priority than the OBC message. I'm thinking I would like to make it lower priority (wait a long delay before transmitting message) so that I will be able to see the OBC messages over the RPi messages when I want to.

Another interesting thing I see from the o'scope is that the LAC line goes low immediately after the OBC message data is finished transmitting. I suppose this is to prevent any other messages from being transmitted until the next 100 ms cycle. Right now, I am wondering whether it is the cluster who drives this low or is it OBC. I'm thinking it may be the cluster, but won't be sure until I send my message without pulling it low and see what happens.

First try at sending message to cluster

I haven't really decided what programming language to use for the coding portions of this project, but for this first test, I would like to try Python.

To control the GPIO pins from Python the RPi.GPIO package was installed

sudo apt-get install python-rpi.gpio

To control the serial UART, the following package was installed (don't forget the console needs to be disabled on the UART, see above)

sudo apt-get install python-serial

Allow programs to access serial port without root/sudo

sudo chmod 666 /dev/ttyAMA0

To be filled in soon...