I-BUS Radio (RAD) Messages Reference

Explore the I-BUS protocol for BMW's radio module, including message structure, device IDs, and interfacing techniques.

By OpenBMW Team · 2026-05-24 · Updated 2026-05-24 · 9 views

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:

IdDevice Name
0x00Broadcast
0x18CDC CD-Player
0x3BNAV Navigation/Videomodule
0x43MenuScreen
0x50MFL Multi Functional Steering Wheel Buttons
0x60PDC Park Distance Control
0x68RAD Radio
0x6ADSP Digital Sound Processor
0x80IKE Instrument Control Electronics
0xBFLCM Light Control Module
0xC0MID Multi-Information Display Buttons
0xC8TEL Telephone
0xD0Navigation Location
0xE7OBC TextBar
0xEDLights, Wipers, Seat Memory
0xF0BMB Board Monitor Buttons
0xFFBroadcast

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.

#I-BUS #RAD #radio #BM54 #messages
Frequently Asked Questions
What is the I-BUS used for in BMW vehicles?
The I-BUS is used for interfacing and controlling multimedia systems like the radio, CD player, navigation, and phone.
How does the I-BUS manage collision detection?
Collision detection is managed by the IKE, which prioritizes messages based on their identifiers.
What are some common I-BUS device IDs?
Common IDs include 0x68 for the Radio, 0x50 for Steering Wheel Buttons, and 0xC8 for the Telephone.
Can I build a custom I-BUS interface?
Yes, using components like the Melexis TH3122 or simpler transistor-based circuits, you can create custom interfaces.
What software can be used to analyze I-BUS messages?
Tools like the I-BUS Analyzer and Docklight are used to capture and decode I-BUS messages.