Skip to main content
BlueBus is a Bluetooth module designed for BMW vehicles with I-Bus communication. The system acts as a bridge between the vehicle’s I-Bus and modern Bluetooth devices, enabling audio streaming and hands-free calling.

​
Core components

The BlueBus architecture consists of several key components that work together to provide seamless Bluetooth integration:

​
Main application loop

The main application loop runs on a PIC24FJ microcontroller and orchestrates all system operations. Located in main.c:152-157, the loop continuously processes three main tasks: 
while (1) {
    BTProcess(&bt);
    IBusProcess(&ibus);
    TimerProcessScheduledTasks();
    CLIProcess();
}
  • BTProcess: Handles Bluetooth module communication and events
  • IBusProcess: Processes I-Bus messages and maintains vehicle state
  • TimerProcessScheduledTasks: Executes scheduled operations like power management
  • CLIProcess: Manages debug command-line interface

​
Handler subsystem

The handler acts as the central coordinator between Bluetooth and I-Bus subsystems. It maintains a context structure (HandlerContext_t) that tracks:
  • Bluetooth connection status and selected device
  • I-Bus module status (GT, BMBT, MID, etc.)
  • Vehicle state (ignition, power, telephone status)
  • User interface mode and playback state
Initialized in handler.c:24-82, the handler registers event callbacks and scheduled tasks to respond to system events.

​
Data flow

Data flows between multiple subsystems through a event-driven architecture:

​
I-Bus to Bluetooth flow

  1. Message reception: I-Bus UART receives messages at 9600 baud with even parity
  2. Message parsing: IBusProcess() validates checksums and extracts packet data
  3. Module handlers: Dedicated handlers process messages from each I-Bus device (IKE, RAD, GT, etc.)
  4. Event triggering: Handlers trigger callbacks registered by other subsystems
  5. Bluetooth commands: Handler translates I-Bus commands to Bluetooth operations
For example, when the radio sends a CDC play command: 
if (pkt[IBUS_PKT_DB1] == IBUS_CDC_CMD_START_PLAYING) {
    ibus->cdChangerFunction = IBUS_CDC_FUNC_PLAYING;
    EventTriggerCallback(IBUS_EVENT_CD_STATUS_REQUEST, pkt);
}

​
Bluetooth to I-Bus flow

  1. UART reception: Bluetooth module sends events via UART at 115200 baud
  2. Module processing: BC127 or BM83 specific processor parses responses
  3. State updates: Bluetooth context updated with metadata, connection status
  4. Event callbacks: Events trigger registered handlers
  5. I-Bus transmission: Handler sends appropriate I-Bus messages to vehicle modules
The system uses two different Bluetooth modules depending on hardware version:
  • BC127 (Sierra Wireless) for hardware v1.x
  • BM83 (Microchip) for hardware v2.x
Both modules are abstracted through a common API in bt.c.

​
Component initialization

System components initialize in a specific order in main.c:116-150:

​
Low-level initialization

EEPROMInit();    // Configuration storage
TimerInit();     // System timers
I2CInit();       // Audio codec communication

​
Protocol initialization

struct BT_t bt = BTInit();
struct IBus_t ibus = IBusInit();
Each protocol object maintains its own:
  • UART configuration and buffers
  • State tracking variables
  • Transmit and receive queues

​
Audio subsystem

Depending on hardware version:
  • v1.x: WM8804 S/PDIF receiver + PCM5122 DAC
  • v2.x: DIT4096 S/PDIF transmitter + PCM5122 DAC

​
Handler and UI initialization

The handler initializes last and sets up the appropriate UI mode: 
HandlerInit(&bt, &ibus);
if (Context.uiMode == CONFIG_UI_CD53) {
    CD53Init(bt, ibus);
} else if (Context.uiMode == CONFIG_UI_BMBT) {
    BMBTInit(bt, ibus);
} else if (Context.uiMode == CONFIG_UI_MID) {
    MIDInit(bt, ibus);
}

​
Event system

The event system enables decoupled communication between components. It supports up to 192 registered callbacks (event.h:9).

​
Event registration

Components register callbacks for specific events: 
EventRegisterCallback(
    UI_EVENT_CLOSE_CONNECTION,
    &HandlerUICloseConnection,
    &Context
);

​
Event triggering

When an event occurs, all registered callbacks execute: 
EventTriggerCallback(IBUS_EVENT_MODULE_STATUS_RESP, &detectedModule);
This pattern is used throughout the codebase for:
  • I-Bus message handling (70+ events)
  • Bluetooth state changes (20+ events)
  • UI interactions
  • Timer-based callbacks

​
Memory architecture

The system uses static memory allocation to avoid heap fragmentation:

​
Circular buffers

  • I-Bus RX: 255-byte circular buffer for incoming messages
  • I-Bus TX: 24-slot ring buffer for outgoing messages
  • UART queues: Separate RX/TX queues for each UART module

​
Message buffers

I-Bus messages use a structured packet format: 
typedef struct IBus_t {
    uint8_t rxBuffer[IBUS_RX_BUFFER_SIZE];
    uint8_t txBuffer[IBUS_TX_BUFFER_SIZE][IBUS_MAX_MSG_LENGTH];
    uint8_t txBufferReadIdx;
    uint8_t txBufferWriteIdx;
    // ...
} IBus_t;
Messages are processed in IBusProcess() which handles:
  • Buffer timeout (70ms)
  • Checksum validation
  • Message routing to appropriate handlers

​
Power management

The system includes automatic power management in handler.c:141-162: 
if (lastRx >= HANDLER_POWER_TIMEOUT_MILLIS) {
    if (context->powerStatus == HANDLER_POWER_ON) {
        UARTDestroy(IBUS_UART_MODULE);
        context->powerStatus = HANDLER_POWER_OFF;
        IBUS_EN = 0;  // Disable TH3122 transceiver
    }
}
When no I-Bus activity is detected, the system:
  1. Disables the UART module
  2. Powers down the TH3122 I-Bus transceiver
  3. Reduces power consumption
The system automatically re-enables when bus activity resumes.

​
Error handling

The system includes comprehensive error handling:

​
Trap handlers

Hardware traps are caught and logged in main.c:163-217:
  • Oscillator failure
  • Address errors
  • Stack errors
  • Math errors
  • NVM errors
Each trap increments an error counter in EEPROM and resets the system after a 5-second delay.

​
I-Bus error handling

  • Checksum validation: Invalid messages are logged and discarded
  • Buffer overflow: Prevents buffer overrun with size checks
  • Timeout handling: Clears stale data from receive buffers

​
Bluetooth error handling

  • Connection timeout: 15-second timeout for connection attempts
  • Pairing error tracking: Maintains error count for problematic devices
  • Retry logic: Automatic reconnection attempts with backoff

Build docs developers (and LLMs) love

Get started for freeTalk to us