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

[Edvin]

Hello Lasse,

It is true, like Nathan says, a phone will give an application 100% of the radio time, so a phone will typically not allow a connection interval too low.

The minimum connection interval allowed by the BLE stack is 7.5ms. At this connection interval, you will not have time to send 6 packets (because 1 packet takes longer than 7.5ms/6). However, phones would typically allow 15ms or 30ms connection intervals.

What is the critical part for your application? Do you need updates every 10ms (low latency), or do you need a high throughput?

Low latency => short connection interval => more. but shorter packages => more headers => less throughput.

High latency offers longer packs which could mean less headers and more throughput.

So do you need to transfer data continuously, and is it important that the phone receives these packs as soon as possible, or is it OK for the application to gather up several packs and send it as one big pack?

Best regards,

Edvin

[LWittland]

Hi Edvin,

the throughput is definitively our priority. A latency of ~100 ms is no problem, and even if it gets larger we can accept it as long as no notifications get lost.

You say that a high connection interval is preferrable for our application due to the lesser overhead. So far I consent, but my problem is that no matter if the interval is 200ms or 20 ms, only one notification is transferred per interval (5 at 200ms, (nearly) 50 at 20 ms).

Is there an option i've overlooked (or uintentionally set) that has to be set (or unset) to enable the soft device to gather several notifications in one big packet?

Best regards,

     Lasse