How to increase notification throughput on nRF52840?

[LWittland]

Hello there,

I'm developing a C++ application on the BLE654 development bord which shall be able to generate and send 100+ BLE notifications per second on a single BLE connection.

On my first try it managed 5.

After some digging, I found that the soft device (s140, Ver 6.1.0) got a BLE_GAP_EVT_CONN_PARAM_UPDATE event, which set the minimum and maximum connection interval to 200 ms, wich was the defined MAX_CONN_INTERVAL (the code burrowed from the blinky example). After setting this to 20 ms I could get (close to) 50 notifications per second, but further decreasing the value again reduced the throughput (maybe the Android on the 'other side' of the BLE connection prohibited a further decrease).

I read somewere that soft devices from s120 up were able to process up to 6 notifications in a 7.5 ms connectipon interval, but here it looks as is the sd only does one notification per interval. What can/must be done to further increase the througput to reach at least 100 notifications per second?

Notes:

-in our application, we send the notifications with sd_ble_gatts_hvx(). I don't have exact numbers, but the internal queue of the soft device seemd rather small and we got a NRF_ERROR_RESOURCES error quickly, after wich we wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE until we call sd_ble_gatts_hvx() again. I am certain the soft device at all time had notifications in its queue.

-as recipient of the notifications we used two tablets with Android 6.0.1 and 7.0, respectively. Both showed similar throughputs, and the final application shall also run on an Android device.

Regards,

     Lasse

[Nathan]

Hi Lasse,

Although your device can do better than what it's currently handling, you won't get 6 notifications in 7.5ms connection intervals on pretty much any phone out there. The phone operating system has to allow an arbitrary number of Bluetooth apps to run simultaneously, so it won't allow a single application to hog the entire radio interface for itself. On the latest OS's it might be a bit better, but a couple years ago I found that most phones at the time would allow either 6 notifications at 30ms connection intervals max, or 4 notifications at 20ms connection intervals max, which both come out to ~4KB/s theoretical max rate assuming 20 byte packets for BLE 4.0 level operation. You can now take advantage of BLE 4.2 and 5.0's longer packet sizes to increase the throughput though. 

One thing you could do that could help right away is in your application, from the Bluetooth GATT class call the requestConnectionPriority function with the CONNECTION_PRIORITY_HIGH argument. What this will do is cause Android to pick the lowest connection interval that both the phone and the device will support, so you can keep reasonable MIN_CONN_INTERVAL and MAX_CONN_INTERVAL values in your device code. When you're done with high transfer rate, you can call requestConnectionPriority again with either the balanced or the low priority settings to save battery power. 

To queue up multiple notifications, push the data you want to output to the phone onto a software queue, and call a function that tries to write them out to the softdevice in a loop. The softdevice call that handles putting a packet onto its outgoing queue is sd_ble_gatts_hvx, and once it has all the notifications it can handle it will return with the error code NRF_ERROR_RESOURCES. Basically whenever sd_ble_gatts_hvx returns success, remove the packet from your software queue and try pushing the next one. If you get an error or run out of packets to queue up, break out of the loop and retry after getting a BLE_GATTS_EVT_HVN_TX_COMPLETE event from the BLE events handler. The event will tell you how many notifications were sent successfully during the connection interval associated with the event. 

Also I'm pretty sure you've check this already but just to double check, make sure you're using notifications and not indications, as indications are limited to one at a time max. 

Edit: Whoops, needed to read your notes, you're already doing the NRF_ERROR_RESOURCES thing. The exact size of the internal queue should be 6, so you could write a piece of test code to verify it. And definitely check that you aren't accidentally doing indications instead of notifications. 

[LWittland]

Ih Nathan,

I'm using sd_ble_gatts_hvx() with BLE_GATT_HVX_NOTIFICATION type, so unless there is some hidden overruling at work I'm certain that it ain't indications.

Thanks for the CONNECTION_PRIORITY_HIGH advice, I'll forward it to our android programmer (I'm programming the embedded side only) and let you know how it worked.

Best regards,

     Lasse