The purpose of this web site is to present information about the General Motors entertainment and serial (E&C) bus. The E&C bus was used in certain 1987 to 2005 GM vehicles to allow for data transmission between the radio, CD changer, OnStar module, and HVAC system.
My motivation in understanding this bus is to be able to develop electronic interfaces that will allow newer electronic devices to be installed in these older cars. For example, OnStar hardware for these cars no longer works because of the 1 January 2008 analog cellular shutdown. It would be useful if the old OnStar modules could be removed and a Bluetooth tranceiver installed in its place. In fact, this modification has already been done for vehicles that use the newer Class 2 serial bus.
As of 15 February 2009, I have just started working on this project. I am sure that it will take several months and the assistance of others. I will endeavor to share what I learn on this web page.
The Entertainment and Comfort (E&C) serial bus allows for low-speed communication between various modules in the car. It is an event-driven interface; that is, data is not sent unless one device needs to communicate with another. Often communication results from a human action, such as pressing a button on the radio.
In my car (a 2005 Buick Park Avenue), the E&C bus is connected to four devices:
The IPM, in this particular application, bridges HVAC commands from the E&C bus to the car's more modern Class 2 bus. There are E&C HVAC signals in this car because there are temperature controls on the steering wheel, and the radio interprets all steering wheel control commands.
The E&C bus is circuit 835 in GM's wiring diagrams, and it is carried on a dark green wire. It is wired in a “star topology” from a centrally located splice point. The circuit is accessible at the diagnostic connector; on OBD-II cars, it is pin 14.
The E&C bus is a compartively old-fashioned serial connection. It is a 1000 bps pulse width-modulated bus that is pulled low to communicate. The table below summarizes what I know about it. The photograph to the right shows oscilloscope traces of both the logical 0 pulse and the logical 1 pulse (both triggered the oscilloscope during the camera's exposure).
| E&C bus characteristics | |||
| Media | single wire | ||
| Bit rate | 1000 bps | ||
| Bit encoding | pulse width modulated | ||
| Error detection | parity | ||
| Header length | 11-12 bits | ||
| Data length | 1-8 bits | ||
| Voltage at idle | ~12 V | ||
| Pulse voltage | ~0.4 V | ||
| Logical 0 pulse width | 100 μs | ||
| Logical 1 pulse width | 650 μs | ||
|
| Figure 1. Photograph of oscilloscope traces that capture both logical 0 and logical 1 pulses in an E&C data transmission. |
It is possible to read E&C serial bus data with a PC RS232 serial port. RS232 serial data has a fixed bit width, and is fundamentally incompatible with PWM data transmission. Fortunately, the E&C serial bus has some characteristics that give us a workaround.
RS232 uses two voltage states to represent logical 0s or logical 1s. When there is no data transmission, RS232 idles in the logical 1 state. To indicate that a byte is about to be sent, a device sends a logical 0 called the “start bit.” Then seven or eight bits follow, and finally the devices sends a logical 1 called the “stop bit.”
Looking at the table and the oscilloscope trace above, we see that many similarities to RS232:
Let us imagine how an RS232 serial port would interpret E&C bits. At right, we divide the oscilloscope trace into the ten bits of an RS232 byte. We expect to read only two possible sequences: one that is binary 11111111 and another that is binary 00000111. RS232 bytes are LSB first, so these correspond to hexadecimal codes 0xFF and 0xE0, respectively.
Using the interface above, we can view the output with a terminal. The common setting of 9600-8N1 works well enough. We obtain the expected result: the terminal prints a sequence of 0xFF and 0xE0 characters whenever an E&C data packet is sent across the bus.
What follows is the most recent development in this project. So far, I have just recorded the bit sequences that I can associate with obivious events. There may be significant complexity in some of these recordings. For example, one device sends out a packet, and then another device replies with another packet. To help diagnose which devices send which signals, I try recording the same event with some of the devices removed from the car. There are still a lot of recordings to be made and decoded.
Radio turned on, VIU present, CD changer not present1100001011111110010101111000101111111101 |
Radio turned on, VIU not present, CD changer not present1100001011111110010101 |
Radio turned off, VIU present, CD changer not present1100001011111110000100111000101111111101 |
Radio turned off, VIU not present, CD changer not present1100001011111110000100 |
Source button pressed on radio, CD changer not present111011110100110010 |
Temperature up (button on steering wheel pressed)11110010111001000011111100101111 |
Temperature down (button on steering wheel pressed)11110010111000000010111100101111 |
Radio displays a new time (every minute)10100010110mmmmmmhhhhh0001110pwhere m is minutes (LSB first), h is hours (not figured out yet), and p is parity. |
Car is staring up, radio is on, no VIU present10100010110mmmmmmhhhhh0001110p (radio clock time)1100001011111110010101 (radio powering on)pause 111011110100110010111110011001001101111011110100110010111011110100110010 |
Car turning off, radio was already off1100001011111111
|
Car turning off, radio was on11000010111111100100
|
VIU signal sent when car turns off (follows either preceding signal)111000101111111101
|
OnStar dot button pressed, radio is off1101100100010100000011111001101001111100pause 0010111111100011011110001011111111111100010111111110111011001001100000011110100101011pause 1101100100110000001001001110101101101110000011011011101001010110011100110111000101111100101101110100100pause 1100001101110100100telephone call happens now 1101100100110000000001011101001010111110011011111101100110100110110010011001110011010001111011101001010111100001011111110000100111000101111111101 |
Once I figure out how to “speak” E&C, I'll need to figure out how to make a microconroller that can interpret commands and issue appropriate replies. Personally, I have two goals for my car: (1) I would like to be able to initate fictitious OnStar sessions via a Bluetooth transceiver, and (2) I want to spoof the existence of a CD changer so that I can use the radio's auxiliary input.
To my knowlege, there are no public documents that describe the E&C serial bus and the messages that get sent on it. Some of what I have learned is from the following documents: