Racechrono should request HIGH BLE connection priority on Android to increase message rate?

maxpp

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 ₃₀-40 Hz. Apps can explicitly request a priority for a given connection docs, picking between 4 presets.

In my experiments I used the nRF Connect 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 PrioData Rate [Hz] default₄₅ HIGH>60 BALANCED₄₅ LOW_POWER7

(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?

Andrea84Pagg

HI, I also have the same problem with a Huawei P9 Lite with Android 7.0 I'm using race chrono pro app v8.0.8 with Race Box Mini antenna (25Hz). If I connect the antenna I normally get a variable refresh rate that fluctuates around 10 Hz. If I force the HIGH priority with your method I immediately get 25 Hz, but then it is reduced to oscillating at 20 Hz. I confirm that an update of the race chrono pro app would solve the problem by automatically (perhaps periodically) sending the command to set the priority to HIGH. Let's hope the developers follow the forum :-)

maxpp

Quick update on this. I did a lot of testing around different configuration parameters, code optimizations, etc. With this I managed to achieve a stable 330 Hz update rate over BLE, i.e. enough bandwidth for 3 CAN PIDs at 100Hz. Here are the code changes and a short write-up: https://github.com/pudelkoM/RaceChronoBleDevice/pull/7

Hope this is useful for other devs!

aol

Ok, thanks for the info, I'll have a closer look at it after next release.

maxpp

Hey, looking forward to the next release.

In the meantime, tsjiller on discord and I found that you can, in fact, set the connection interval on the server side. If done, this seems to make the connection priority request from the client side unnecessary. Whether you still want to request it from RC side for users that don't have control over the server is up to you, I guess.

Here are the updated results from my synthetic BLE notification benchmark:

// Results, 12 bytes payload
// 7.5ms intervals set by ESP: 1015-1040 notifications/s
// Request HIGH on phone:      1015-1040
// Request BALANCED:           150-300
// Request LOW:                40-130

// Results, 20 bytes payload
// 7.5ms intervals set by ESP: 960-980 notifications/s
// Request HIGH on phone:      960-970
// Request BALANCED:           220-350
// Request LOW:                50-100

// Results, 496 bytes payload, request 517 MTU on phone
// 7.5ms intervals set by ESP: 215-250 notifications/s
// Request HIGH on phone:      210-250
// Request BALANCED:           155-250
// Request LOW:                210-300

PR: https://github.com/pudelkoM/RaceChronoBleDevice/pull/13

Joel61

Great find. Any update on getting support for this in the app?

aol

Will be in v9.2 release. Sorry for sitting on this.