I-BUS Packet Structure and Checksum Calculation

Introduction

The I-BUS is a communication protocol used in BMW vehicles to manage multimedia and informational peripherals. It is a single-wire bus system primarily found in models like the E31, E38, and E39, and it facilitates communication between devices such as the radio, CD player, navigation system, and telephone. The I-BUS is based on the ISO 9141 and K-Bus protocols, which are also used in OBD-II systems. This protocol is crucial for integrating various entertainment and informational systems within the vehicle, allowing seamless interaction between components.

The I-BUS is not linked to safety-critical systems like airbags, making it a safer option for hobbyists and developers looking to interface with vehicle electronics. Its use is limited to multimedia and informational systems, which include steering wheel controls for audio and phone functions. This article will delve into the technical aspects of the I-BUS, including its physical layer, communication parameters, packet structure, and more.

Physical Layer

The physical layer of the I-BUS operates as an open collector setup. This means the bus is normally pulled high to +12V (battery voltage) and is pulled low by the transmitting device. The wire used for the I-BUS is typically a white/red/yellow wire, and it can be found at various connectors within the vehicle, such as the CD changer connector and the phone connector.

This setup is akin to RS232 signaling, where an interface IC is required to convert the signal into a TTL digital format that microcontrollers can process. The open collector design ensures that the bus remains at +12V when idle, and data transmission involves pulling the line low momentarily to represent bits.

Communication Parameters

The I-BUS operates at a baud rate of 9600 bps with 8 data bits, even parity, and 1 stop bit (9600, 8E1). These parameters are standard for serial communications and ensure reliable data transfer across the bus. The protocol does not have a specific start-of-packet indicator, so software must detect packet boundaries by identifying delays between messages.

Devices on the I-BUS can initiate communication when the bus is idle. However, if a device detects the line being pulled low without its own action, it must cease transmission. This collision detection mechanism helps maintain orderly communication on the bus.

Packet Structure

An I-BUS packet consists of several 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 receiver. The Length byte indicates the number of bytes in the message, excluding the Source ID and the Length byte itself.

The Data section contains the message payload, and the XOR Checksum is used to verify message integrity. The checksum is computed by XORing all bytes in the packet, excluding the checksum byte itself. This ensures that any corruption during transmission can be detected by the receiver.

Device ID Table

Collision Detection & Arbitration

The I-BUS employs a simple collision detection mechanism where any device can start transmitting when the bus is idle. If a device detects that the line is pulled low without its own action, it must stop transmitting to avoid data collision. This is managed by the Instrument Kombi Electronics (IKE), which acts as a gateway and helps coordinate communication among devices.

Arbitration on the I-BUS is based on device priority, where certain devices may have higher priority to transmit over others. This ensures that critical messages can be communicated without delay. The IKE plays a crucial role in managing these priorities and ensuring smooth operation of the bus.

Hardware Interfacing

Interfacing with the I-BUS requires specific hardware components to convert the bus signals into a format that can be processed by microcontrollers or computers. Commonly used components include the Melexis TH8080 and TH3122 transceivers, which are designed for LIN and K-Bus applications. These transceivers handle the conversion of bus signals and provide additional functionalities like contention detection.

For RS232 communication, the Maxim MAX232A is often used to convert TTL levels to RS232 levels, enabling connection to computers or other devices. Building an interface from scratch involves using these components to ensure safe and reliable communication with the I-BUS.

Software Tools

Several software tools are available for analyzing I-BUS communications. The I-Bus Analyser Software (V1.00) is a popular choice, allowing users to monitor and decode I-BUS messages in real-time. It supports features like filtering packets by source or destination ID, and it can automatically calculate checksums for transmitted messages.

NavCoder is another tool that facilitates I-BUS analysis. It requires a connection between the I-BUS and a computer, which can be established using interfaces like Resler’s I-Bus interface or a USB to TTL serial converter. These tools enable hobbyists and developers to decode and interpret I-BUS messages effectively.

Practical Example

Consider the following I-BUS message intended to display "CD 7-04" on the Radio MID Display:

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, the Source ID is 68 (RAD Radio), the Length is 17, and the Destination ID is ff (Broadcast). The Data section contains the ASCII representation of "CD 7-04", and the final byte 45 is the XOR checksum. This checksum is calculated by XORing all preceding bytes, ensuring the integrity of the message.

Such practical examples help illustrate how I-BUS messages are structured and transmitted, providing a foundation for further experimentation and development with BMW's I-BUS protocol.