Hi,
As many other Racechrono BLE DIY devs, I have been struggling to get high message update rates out of my DIY CAN-bus reader.
I did some digging and found a few reports around the BLE connection interval and its impact on throughput and latency. So I tried to experiment with it. The following is a copy&paste from my GitHub README (
https://github.com/pudelkoM/RaceChronoBleDevice?tab=readme-ov-file#android-connection-priority--ble-connection-interval):
The BLE stack operates on two connection interval values (min, max), which
effectively determine the maximum possible update rate for CAN-bus messages
transmitted from the ESP32 device to the phone. While we can set the _preferred_
values on the server side with `pAdvertising->setMinPreferred(0x06);`, it's the
client (phone) which ultimately chooses the values. By default, my Android Pixel
4 seems to pick a balanced value resulting in a update rate of ~30-40 Hz. Apps
can explicitly request a priority for a given connection [docs](
https://developer.android.com/reference/android/bluetooth/BluetoothGatt#requestConnectionPriority(int)), picking between 4 presets.
In my experiments I used the [nRF Connect](
https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp)
app to both log and set BLE parameters. When following these steps, I could
significantly increase the observed CAN message rate:
0) Enable Bluetooth
1) Open nRF Connect app and connect to data logger
2) From drop-down, open "Request connection priority" and pick `HIGH`
3) Confirm change in logs
4) Open Racechrono
5) Start new recoding session
6) Open sensor menu `^` and confirm "Bluetooth LE CAN-bus" update rate
Here are the different rates observed with different settings:
| Connection Prio | Data Rate [Hz] |
|-----------------|----|
| default | ~45 |
| HIGH | >60 |
| BALANCED | ~45 |
| LOW_POWER | 7 |
(End of paste)
It's pretty clear to me that choosing HIGH improves the message send rate, as all my CAN ARBIDs were delivered at the desired update rates. Unfortunately it is up to the client app (i.e. RaceChrono) to request a non-default priority. The server (data logger) cannot force this.
Has this topic been explored before? Can others try the same experiment to confirm my findings?
Maybe RaceChrono should request that HIGH priority by default to give us better performance?
