Introduction
The I-BUS is a communication protocol used in BMW vehicles to control various multimedia and entertainment systems, including the radio, CD player, navigation, and telephone systems. Originating from the ISO 9141 and K-Bus protocols, the I-BUS serves as a secondary K-Bus in the car, facilitating the interaction between these components. It is especially crucial for steering wheel controls that manage radio, CD, and phone functionalities. Though initially reverse-engineered for specific projects, the protocol has been extensively documented, allowing for a deeper understanding of its operations.
This protocol is employed across multiple BMW models, although the specific implementation details can vary. The I-BUS allows for a single-wire communication system, making it relatively simple to interface with. This article focuses on the radio module (RAD) with address 0x68, detailing the messages it handles, including text display, source selection, and volume control.
Physical Layer
The I-BUS operates on a single-wire system that is identified by a white/red/yellow wire found at various connectors within the vehicle, such as the CD changer and phone connectors. The physical layer of the I-BUS is an open collector setup, which is pulled high to +12V by the bus and pulled low by the talker. This configuration ensures that the wire remains at battery voltage when idle, similar to RS232 signaling.
To interface with the I-BUS, a conversion from the +12V signal to a TTL digital signal is necessary, typically accomplished using an interface IC. This conversion is crucial for microcontrollers to interpret the bus signals accurately. The open collector design also means that the bus is less susceptible to electrical noise, improving the reliability of data transmission.
Communication Parameters
The I-BUS communicates using serial communication parameters of 9600 bps, 8 data bits, even parity, and 1 stop bit. These settings are standard for many automotive communication protocols, ensuring compatibility and ease of implementation. The choice of even parity helps in error detection, adding an additional layer of data integrity.
Packet timing is essential for identifying the start of a message since the I-BUS does not have a specific byte to denote the beginning of a packet. Instead, software implementation must detect a delay between messages to properly synchronize and decode the incoming data stream.
Packet Structure
An I-BUS packet consists of several components: the Source Address, Length, Destination Address, Data Bytes, and an XOR Checksum. The packet begins with the Source Address, identifying the sender, followed by the Length, which excludes the Source and Length bytes themselves. The Destination Address indicates the intended receiver of the message.
The Data Bytes contain the actual command or information being transmitted, while the XOR Checksum is used for verifying the integrity of the packet. The checksum is computed by XOR'ing all the bytes in the packet, excluding the checksum byte itself. For example, a command to display 'Hello' on the radio would be structured as follows:
C8 0A 80 23 42 32 48 65 6C 6C 6F 53 Here, C8 is the source (Telephone), 0A is the length, 80 is the destination (Radio), 23 is the function code, and 53 is the checksum.Device ID Table
The I-BUS protocol uses specific hexadecimal addresses to identify different devices within the vehicle. The following table lists the known device IDs for the E39 5-series, which are also applicable to other models with similar configurations:
| Id | Device Name |
|---|---|
| 0x00 | Broadcast |
| 0x18 | CDC CD-Player |
| 0x3B | NAV Navigation/Videomodule |
| 0x43 | MenuScreen |
| 0x50 | MFL Multi Functional Steering Wheel Buttons |
| 0x60 | PDC Park Distance Control |
| 0x68 | RAD Radio |
| 0x6A | DSP Digital Sound Processor |
| 0x80 | IKE Instrument Control Electronics |
| 0xBF | LCM Light Control Module |
| 0xC0 | MID Multi-Information Display Buttons |
| 0xC8 | TEL Telephone |
| 0xD0 | Navigation Location |
| 0xE7 | OBC TextBar |
| 0xED | Lights, Wipers, Seat Memory |
| 0xF0 | BMB Board Monitor Buttons |
| 0xFF | Broadcast |
Collision Detection & Arbitration
Collision detection and arbitration on the I-BUS are managed primarily by the IKE (Instrument Control Electronics). The open collector design of the bus allows multiple devices to attempt communication simultaneously. However, if a collision occurs, the device with the highest priority message (determined by the message identifier) will continue, while others will back off and retry.
This mechanism is crucial for ensuring that critical messages, such as those from the steering wheel controls, are transmitted without delay. The IKE's role in managing these collisions helps maintain the smooth operation of the vehicle's multimedia systems.
Hardware Interfacing
Interfacing with the I-BUS can be achieved using various off-the-shelf components. Popular choices include the Melexis TH3122 K-Bus Transceiver, the Motorola MC33290 K-Line Serial Link Interface, and the Atmel U6812B Single-Ended Bus Transceiver. These components simplify the process of converting the I-BUS signals to a format usable by microcontrollers or PCs.
For hobbyists, simpler circuits using transistors, diodes, and pull-up resistors can be employed. Such circuits provide a cost-effective way to interface with the I-BUS, although they may lack some of the advanced features of dedicated transceiver chips, like collision detection and voltage regulation.
Software Tools
Several software tools are available for analyzing and interacting with the I-BUS. These tools allow users to capture, decode, and send I-BUS messages, making them invaluable for both development and diagnostic purposes. Popular software includes the I-BUS Analyzer, which automatically calculates checksums and length bytes, and Docklight, which enables simulation of message sequences.
These tools are crucial for developers and hobbyists working on custom I-BUS projects, as they provide a platform for testing and refining I-BUS communication strategies. They also facilitate the creation of custom interfaces and control systems, expanding the functionality of existing BMW multimedia systems.
Practical Example
Consider a practical example where a message is sent to display the text 'Hello' on the Business radio. The message structure is as follows:
C8 0A 80 23 42 32 48 65 6C 6C 6F 53 Here, C8 is the source address for the Telephone, 0A is the length of the message, 80 is the destination address for the Radio, and 23 is the function code for text display.The data bytes 42 and 32 set the layout mode and clear the display, respectively, followed by the ASCII representation of 'Hello' (48 65 6C 6C 6F). The final byte, 53, is the checksum, ensuring the integrity of the message. This example demonstrates the straightforward yet powerful capabilities of the I-BUS protocol in controlling and customizing vehicle multimedia displays.