Reverse Engineering the Boosted Board Remote

I recently spent some time reverse engineering the Boosted Board remote protocol. This was partly out of curiosity and partly because they're out of business and no longer selling remotes. Used remotes go for around $300 (im too cheap for that)

The Boosted Board remote is a fascinating piece of hardware. It uses Bluetooth Low Energy (BLE) to communicate with the board, but with some interesting quirks in the implementation. The protocol itself is relatively straightforward once you understand what's happening under the hood.

Credit to Jonathan Chiu who did the initial reverse engineering work (GitHub). His work laid the foundation for understanding the BLE services and characteristics.

The Technical Details

The remote implements four main BLE services:

• Controls Service - Handles throttle data and button inputs
• Connectivity Service - Manages pairing and connection state
• Device Info Service - Standard BLE service for device information
• OTAU Service - Over-the-air updates (though I haven't fully explored this)

The most interesting part is how the throttle data is transmitted. The remote sends throttle values between 128-896, which map to the full range of the board's speed control. This is done through a characteristic that sends notifications with a specific structure:

Throttle packet structure:
  [Throttle High Byte][Throttle Low Byte][Button States][Reserved]
  

BLE Protocol Details

The throttle control implementation was particularly interesting. The remote maps throttle values between 128-896, where:

• 128 = Full brake
• 512 = Neutral position
• 896 = Full acceleration

The throttle data packet structure looks like this:

[Throttle High Byte][Throttle Low Byte][Button States][Reserved]
  - Button States: Bit 8 = Power Button, Bit 9 = Trigger

Key Implementation Challenges

Some of the trickier aspects of the implementation included:

• Timing requirements - The board expects throttle updates every ~50ms
• Power management - Needed to balance responsiveness with battery life
• Pairing mode - Had to implement a 20-second window for pairing new boards
• Connection reliability - Required careful handling of BLE disconnections and reconnections

BLE Services Structure

The implementation required four main BLE services:

1. Controls Service (0x78FE...)
  - Throttle characteristic
  - Trigger state characteristic
  - Configuration characteristics

2. Connectivity Service (0x667C...)
  - Pairing characteristics
  - Connection state management

3. Device Info Service (Standard BLE)
  - Model number
  - Serial number
  - Firmware version
  - Hardware version

4. OTAU Service (0xA5A5...)
  - Firmware update characteristics

Power Management

The ESP32's power management was crucial for battery life. Key optimizations included:

• Using BLE power saving features
• Optimizing the notification interval
• Implementing sleep modes when idle
• Careful timing of ADC readings

Implementation Challenges

The trickiest part was getting it to be reliable with good battery life. This required a good amount of improvising.

A common instructable or hobbyist guide would've probably made a custom PCB with some buttons and screws and stuff. I'm far too lazy (and cheap) for that.

There was no way around using some sort of hardware for the throttle itself. I ripped out a potentiometer from a broken remote and designed a case for it.

I ended up implementing this on an ESP32 using FreeRTOS for task management. The ESP32's BLE stack made this relatively straightforward, though there were some gotchas around how Boosted implemented their protocol.

Some Interesting Findings

During the reverse engineering process, I discovered several interesting things about how Boosted implemented their protocol:

Manufacturing Process

For the hardware implementation, I chose the ESP32-H2 module, which offers built-in Bluetooth 5.2 support and significantly lower power consumption than its predecessors. This off-the-shelf solution dramatically reduced development time while keeping unit costs under $5 per remote.

Adventures in Chinese Manufacturing

Manufacturing in China has been an exercise in extreme documentation detail. I quickly learned that what I considered obvious instructions were far too vague. For instance, when I initially requested "solder the ESP32-H2 module to the PCB," I received boards with cold joints and excess solder bridges. I had to create a 15-page manufacturing guide with photos of each step, and exact placement measurements.

What I initially thought would be straightforward assembly tasks required detailed flowcharts and checklists. Each step needed photos of both correct and incorrect examples. It was a stark lesson in leaving absolutely nothing to interpretation.

The project has evolved from a reverse-engineering exercise into a crash course in international manufacturing.

I secured ~$45k worth of orders so I decided it wasn't worth the time to continue manufacturing (sales are basically guarenteed to go down over time). I'm glad I did it though. I have unlimited Boosted Board remotes now.