The MCU acts as an intermediary between your vehicle’s CAN bus system and your Android head unit. It intercepts, filters, and translates vehicle data before forwarding it to Android.

Unfortunately, there is no universal standard for MCU communication. Every MCU manufacturer is free to define its own protocol and packet structure. As a result, the same button press may be represented by completely different byte sequences depending on the MCU vendor.

This application allows you to inspect the raw byte streams being exchanged between the MCU and Android. While the exact structure varies between manufacturers, many MCUs follow a similar packet-based format consisting of:

• A header or start byte
• An identifier byte
• A length byte
• One or more data bytes
• A checksum byte

A typical packet might look like this:

0x2D, 0x22, 0x02, 0x84, 0x01, 0x56

This sequence can be broken down as follows:

In this example, 0x2D appears to be the start of a new packet. The identifier 0x22 is likely used to indicate button-related events. The length byte 0x02 tells us that the next two bytes contain the actual payload data.

The first payload byte, 0x84, most likely identifies the specific button that was pressed. The second payload byte, 0x01, may represent a button-down event. This assumption can often be verified by observing a second packet that is transmitted when the button is released, where the same sequence is repeated but with a value of 0x00 instead.

The final byte, 0x56, is likely a checksum used by the MCU to verify packet integrity. One indication of this is that the following byte in the stream starts a new packet with another 0x2D header, suggesting that 0x56 marks the end of the current packet.

Different MCU Vendors Use Different Formats

Not every MCU follows this exact structure.

For example, many KSW-based systems use a packet layout similar to:

Header, Update, Identifier, Length, Data, Checksum

Other MCU vendors may choose entirely different approaches. Some packets may not contain a checksum at all. Others may omit a dedicated header byte or use fixed-length packets where a length field is unnecessary.

Identifying Packet Structures

When reverse-engineering an unknown MCU protocol, repetition is your most valuable clue.

Look for:

• Bytes that consistently appear at the start of messages.
• Bytes that change when different buttons are pressed.
• Bytes that remain constant regardless of the button pressed.
• Values that increase or decrease with rotary knobs or scroll wheels.
• Similar packets that differ only by a single byte, indicating button-down and button-up events.
• Repeating patterns that suggest a length field or checksum.

By observing these patterns across multiple button presses and vehicle actions, you can gradually determine the structure of the protocol and identify which bytes are relevant for remapping purposes.

Remember that there is rarely a need to fully understand every byte in a packet. In most cases, identifying the bytes that uniquely represent the desired button event is sufficient to create reliable mappings.