Introduction
The I-BUS protocol is a key component in BMW's automotive electronics, specifically designed for handling communication between various in-car systems such as the radio, CD player, navigation, and telephone. It is based on the ISO 9141 and K-Bus protocols, widely used in automotive applications. The I-BUS is essential for the integration of multimedia and telecommunication systems within the vehicle, facilitating seamless interaction between components like the steering wheel controls and the infotainment system.
The I-BUS protocol is utilized across various BMW models, although this article does not specify a particular chassis. It is particularly relevant for vehicles equipped with the BMBT (Bordmonitor) system, which uses the I-BUS for managing display messages and user inputs. The Bordmonitor interacts with other systems through specific commands and messages, allowing for control over display settings and navigation menus.
Physical Layer
The physical layer of the I-BUS is characterized by an open collector topology, which is a common configuration in automotive communication systems. This setup involves a single wire bus that is pulled high (+12V) by default and is pulled low by the transmitting device. The idle state of the bus is +12V, similar to RS232 signaling. This design allows multiple devices to communicate over the same bus without interference.
The I-BUS wire is typically a white/red/yellow cable, accessible at various points within the vehicle, such as the CD changer connector or the center console phone connector. This physical configuration supports the robust and reliable transmission of data between the vehicle's electronic components.
Communication Parameters
The I-BUS operates at a baud rate of 9600 bps, with 8 data bits, even parity, and 1 stop bit. These parameters are critical for ensuring accurate and reliable communication between devices. The use of even parity helps detect errors in transmission, while the stop bit ensures proper synchronization of data packets.
Packet timing on the I-BUS requires careful management, as there is no explicit start-of-packet indicator. Instead, the protocol relies on detecting delays between messages to determine packet boundaries. This necessitates precise timing and control within the software managing the I-BUS communication.
Packet Structure
An I-BUS packet consists of several key components: the source address, length, destination address, data bytes, and an XOR checksum. The source address identifies the sending device, while the destination address specifies the receiving device. The length byte indicates the number of data bytes included in the packet, excluding the source and length bytes themselves.
For example, a packet might look like this: 68 17 FF 23 C0 30 07 20 20 20 20 20 08 43 44 20 37 2D 30 34 20 20 20 20 45. In this example, '68' is the source address for the radio, '17' is the length, 'FF' is the destination (broadcast), and the data bytes encode the message 'CD 7-04'. The final byte '45' is the checksum, ensuring the integrity of the packet.
Device ID Table
The I-BUS protocol uses specific addresses to identify different devices within the vehicle. Here is a comprehensive list of device IDs relevant to the I-BUS:
- 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
On the I-BUS, collision detection and arbitration are managed by the Instrument Control Electronics (IKE). The IKE plays a crucial role in ensuring that multiple devices can communicate over the bus without conflicts. It monitors the bus for collisions and manages the arbitration process, allowing devices to take turns transmitting data.
This arbitration process is essential for maintaining the integrity and reliability of the communication network, preventing data loss or corruption due to simultaneous transmissions. The IKE's ability to manage these aspects of the I-BUS is a key factor in the protocol's effectiveness in automotive environments.
Hardware Interfacing
Interfacing with the I-BUS requires specific hardware components to convert the bus signals into a format that can be processed by a microcontroller or computer. Several off-the-shelf interface/transceivers are available for this purpose, including the Melexis TH8080 LIN/K-Bus Transceiver and the Motorola MC33290 K-Line Serial Link Interface.
These components are designed to handle the physical layer requirements of the I-BUS, including voltage level conversion and bus contention management. Using these transceivers simplifies the process of building an I-BUS interface, allowing hobbyists and engineers to focus on the software aspects of their projects.
Software Tools
Several software tools are available for analyzing and interacting with the I-BUS. These tools can capture and decode I-BUS messages, providing valuable insights into the communication between vehicle systems. Popular tools include the OpenBMW Yahoo! Group and the HackTheIBus Yahoo! Group, which offer forums for discussion and information sharing among enthusiasts and professionals.
These tools and communities provide a wealth of knowledge and resources for anyone interested in exploring the I-BUS protocol, from hobbyists building custom interfaces to engineers developing new automotive electronics solutions.
Practical Example
A practical example of an I-BUS message is the command to adjust the radio volume. The BMBT sends a command to the radio with the following message: F0 04 68 32 10 BE. Here, 'F0' is the source address for the BMBT, '04' is the length, '68' is the destination address for the radio, '32' is the command for volume adjustment, '10' specifies the volume step, and 'BE' is the checksum.
This message structure allows the BMBT to control various aspects of the radio, such as increasing or decreasing the volume, by sending specific commands over the I-BUS. Understanding these message structures is essential for anyone looking to develop custom interfaces or diagnostic tools for BMW vehicles.