Project Logs

Collapse

• Communicating with the Instrument Cluster

  Justin R. • 03/28/2014 at 01:54 • 1 comment

  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...

  Read more »

• Project Requirements

  Justin R. • 03/10/2014 at 05:09 • 0 comments

  Requirements:

  • Show current song/artist on instrument cluster display
  • Allow basic song control (e.g. skip song) from re-purposed built-in controls on steering wheel stock
  • Be able to play music from the following sources:
    • Flash drive or SD card
    • Smartphone via AirPlay (wifi)
    • FM radio via USB TV tuner SDR (could also be used to pick up any other frequencies as well) - Optional (bonus)
    • Internet radio via wireless hotspot on smartphone - Optional (bonus)
  • Output audio in high quality to amplifiers via an external DAC

View all 2 project logs