ESP32/ESP32s3 DIY build progress

making decent headway on the DIY route. i have a few PIDs decoded for G8X m3/m4

50hz RPM
25hz GEAR

RPM and PEDAL come in at 100hz but the Bluetooth LE drivers on all the Arduino devices are terrible. nRF52 or ESP32!

My basic design is an Adafruit Feather ESP32s3 (or Adafruit Huzzah32 ESP32) with Feather Wing CAN bus transceiver (ESP32 has a SJA1000-like CAN controller built into the chip) The ESP32s3 is newer chip with Bluetooth 5.0, but drivers are so terrible, there is not real gains, I just prefer the USB-C vs USB micro B.

I started out with a nRF52 chip, but its performance was maybe 100 frames / second total. The ESP32s3 I can get about 350 frames / second before the Bluetooth stack starts dying.

I have developed my own CAN bus driver, so i can take lots of shortcuts since i only care about reading data. I can get over 2500 frames / second (the max my car broadcasts over the PT-CAN bus) without issue.

The ESP32 is dual-core, so i have CAN bus on one core, Bluetooth on the other, use a FreeRTOS Queue to pass data from the CAN bus interrupt handler to the bluetooth core and send that over Bluetooth LE to racechrono.

RaceChrono screenshot:
ESP32 build:

Next steps are to see if i can write my own BLE slimmed down driver with the ESP32 SDK and get past that 350 frames / second mark.

It would be nice to have a WiFi interface to RaceChrono for DIY devices, as that I feel is much more stable / performance drivers in the arduino world, vs trying to use BLE for performance path. BLE is fine for basic communication, but none of the Arduino drivers are hardened for performance on the BLE side.


  • edited September 24
    one other idea i had, since i have so many free CPU cycles on the ESP32 side, was to aggregate PIDs into one BLE message. right now all data is basically 1 or 2 bytes, but the CAN frame is 8 bytes. i could aggregate say all the 50hz messages into one pid, 25hz into another, etc, then use the same PID and different offsets on the RaceChrono iOS/Android side, reducing the BLE messages by potentially 4x, but adding some latency with the aggregation step, but at 25/50/100 hz, it may not matter...

    could also just reduce the BLE payload to PID + value, instead of sending all the extra CAN data so each BLE message would be 4 bytes for PID and 1-2 bytes for data. that would reduce the data payload in each BLE from 12 bytes total to 5-6 bytes total
  • Nice project!
  • edited October 11

    email me at if you are interested in trying out my integrated ESP32-S3 CAN board with built in 12V power support from car/bike
Sign In or Register to comment.