Introduction
The I-BUS is a serial communication bus used in BMW vehicles to manage data exchange among various multimedia and control devices. It is based on the ISO 9141 standard and primarily handles communication for the radio, CD player, navigation, telephone systems, and steering wheel controls. This bus system allows for the integration and control of various entertainment and information systems within the car, enhancing the driving experience with seamless connectivity.
The I-BUS is prevalent in several BMW models, notably those equipped with advanced multimedia systems. While this article focuses on building a USB interface for the I-BUS, it is important to note that the information is derived from studies conducted on the E39 model. The principles and techniques discussed may vary slightly in other models, but they provide a solid foundation for understanding and working with the I-BUS.
Physical Layer
The I-BUS operates as a single-wire communication system, utilizing an open collector topology. This means the bus wire is normally held at a high voltage level of +12 volts, which is the vehicle's battery voltage. Devices on the bus can communicate by pulling the line low, momentarily shorting it to ground to send a bit. This setup contrasts with many digital communication systems where a high voltage signifies a bit transmission.
The wire used for the I-BUS is typically white with red and yellow stripes, easily identifiable at connection points like the CD changer or navigation system connectors. This open collector design allows multiple devices to share the same communication line without interference, as each device can pull the line low independently when transmitting data.
Communication Parameters
The I-BUS employs a communication protocol with specific parameters: a baud rate of 9600 bps, 8 data bits, even parity, and 1 stop bit. This configuration ensures reliable data transmission across the bus, accommodating the needs of various connected devices.
Devices on the I-BUS can initiate communication when the bus is idle. However, if a device detects that the line is pulled low without its intervention, it must cease transmission to avoid collisions. This mechanism is crucial for maintaining orderly communication and ensuring data integrity across the network.
Packet Structure
An I-BUS packet is structured to include several key components: the Source Device ID, Length, Destination Device ID, Data, and an XOR Checksum. The Source Device ID identifies the sender, while the Destination Device ID specifies the intended recipient. The Length field indicates the number of bytes in the packet, excluding the Source ID and Length itself.
The Data field contains the message content, and the XOR Checksum is calculated by performing a byte-wise XOR operation on all bytes in the packet. This checksum is crucial for verifying the integrity of the message, as the receiver will compare it against its own calculation to determine if the packet has been received correctly.
Device ID Table
The I-BUS system utilizes specific device IDs to identify connected components. Here is a complete list of known device IDs used in the E39 model:
- 00 - Broadcast
- 18 - CDW - CDC CD-Player
- 3B - NAV Navigation/Videomodule
- 50 - MFL Multi Functional Steering Wheel Buttons
- 60 - PDC Park Distance Control
- 68 - RAD Radio
- 6A - DSP Digital Sound Processor
- 80 - IKE Instrument Kombi Electronics
- BB - TV Module
- BF - LCM Light Control Module
- C0 - MID Multi-Information Display Buttons
- C8 - TEL Telephone
- D0 - Navigation Location
- E7 - OBC TextBar
- F0 - BMB Board Monitor Buttons
- FF - Broadcast
Collision Detection & Arbitration
The I-BUS employs a collision detection mechanism to manage data transmission among multiple devices. When a device begins to transmit, it monitors the bus for any other active signals. If another device is detected pulling the line low, the transmitting device must abort its transmission to prevent data collisions.
This arbitration process is managed by the Instrument Kombi Electronics (IKE), which acts as a central controller to ensure orderly communication. By enforcing this protocol, the I-BUS maintains efficient data flow and prevents conflicts that could disrupt the operation of connected systems.
Hardware Interfacing
Building a USB interface for the I-BUS involves selecting appropriate integrated circuits and designing a compatible circuit. Options for ICs include the TH3122, TH8080, and MCP2025, each offering specific advantages for interfacing with the I-BUS.
A common approach is to use an FTDI FT232 chip for USB connectivity, coupled with pull-up resistors to maintain the open collector topology of the bus. The circuit can be powered directly from the bus, simplifying installation and integration. A detailed bill of materials and PCB layout is essential for constructing a reliable interface.
Software Tools
Several software tools are available for analyzing and interacting with the I-BUS. NavCoder is a popular choice, allowing users to monitor and decode I-BUS messages in real-time. It provides facilities for sending messages and analyzing the bus's communication patterns.
Other tools include terminal programs that can connect to the I-BUS via a USB interface, providing a platform for sending custom commands and receiving data from the bus. These tools are invaluable for diagnostics and customizing the behavior of connected devices.
Practical Example
Consider a practical example of sending a message to the radio (Device ID 68) from the steering wheel controls (Device ID 50). The message structure might look like this:
50 03 68 01 72In this example, '50' is the Source Device ID for the steering wheel controls, '03' is the Length of the message, '68' is the Destination Device ID for the radio, '01' is the Data indicating a specific command (e.g., volume up), and '72' is the XOR Checksum calculated for the packet. This message instructs the radio to perform an action based on the steering wheel input.