Inconsistent latency with ble_app_uart sending via ble

[Shri1395]

Hi,

We are trying to optimize the speed at which we send data over BLE UART with the nrf52832. Currently, we are using the ble_nus_data_send() function in a while loop with no delay to send as fast as possible. On the nrf toolbox app and the Adafruit BLE app, however we are getting a few sets of 20 bytes with very inconsistent latency (burst sends and hangs and bursts again at random intervals). How do we have the nrf52 send our 20 byte data consistently with low latency. Here is our latency output from our testing software.

Connected to device!

data received: 20 bytes

LATENCY: 8079

data received: 20 bytes

LATENCY: 241

data received: 20 bytes

LATENCY: 658

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 5468

data received: 20 bytes

LATENCY: 50

data received: 20 bytes

LATENCY: 481

data received: 20 bytes

LATENCY: 490

data received: 20 bytes

LATENCY: 2

data received: 20 bytes

LATENCY: 528

data received: 20 bytes

LATENCY: 480

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 238

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 4

data received: 20 bytes

LATENCY: 475

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 238

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 176

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 61

data received: 20 bytes

LATENCY: 241

data received: 20 bytes

LATENCY: 181

data received: 20 bytes

LATENCY: 477

data received: 20 bytes

LATENCY: 840

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 5936

data received: 20 bytes

LATENCY: 241

data received: 20 bytes

LATENCY: 59

data received: 20 bytes

LATENCY: 241

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 179

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1263

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 235

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 1

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 0

data received: 20 bytes

LATENCY: 238

data received: 20 bytes

LATENCY: 3

Connection status: Disconnected from device.

When we try the same setup in SDK 12, we are able to get consistent latency. Using Adafruit's bootloader and library we are getting 5 ms consistent latency on SoftDevice 0.5.0 and 60 ms consistent latency on SoftDevice 5.0. All of these involve sending a 20 byte packet over the BLE UART.

Our current setup is with SDK 15 and SoftDevice 6.0 and we would like to optimize our sending to be as fast as it was with Adafruit's library. How do we acheive this consistent low latency via BLE? I've read that data rates can be as high as 128 kBps.

[bjorn-spockeli]

How are you measuring the latency?Is it the time exeeding the time since the last packet was recieved + the connection interval? Which connection interval are you using? When you say that it hangs, you are referring to the nRF Toolbox app? Have you tried using nRF Connect ?

[Shri1395]

The latency is from a testing software we created that simply measures the time between two consecutive receiving packets of 20 bytes, but this latency is also the same that we've seen from the nrf toolbox app and the adafruit ble connect app. Our max connection interval is currently 30 ms and min is 20 ms, but we have changed them from 7.5 to 400 and it hasn't made any significant difference. It still continues to have irregular slow downs in latency as seen in our output above.

[bjorn-spockeli]

Ok, so is the testing software is running on another nRF52 device? Or are you using something else as a BLE central? Could you capture the packets on air with a BLE protocol sniffer available or nRF Sniffer v2 so that we can see if  the packets are sent with the correct interval on air or not. 

[Shri1395]

Our testing software is running on a Windows machine using the UWP BLE API. https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/bluetooth-low-energy-overview. The Windows machine acts as the BLE central. Our current problem is not the inconsistent latency though, its more aligned towards how fast we can send the data (since, we fixed the inconsistent latency problem). 

When we tested the blue_app_uart  with SDK 11, we are getting an average latency of around 5ms, whereas with SDK 15, we are getting the latency values to be around 21ms. 

Is there any way we can send the data with SDK 15 as fast as with the SDK 11? I was wondering whether this is possible or not, and if yes, how? We are using the default ble_app_uart codes for both.

[bjorn-spockeli]

You could try to queue up the notifications as shown in variant 2 in the GATTS Handle Value Notification Message sequence chart. You could make the data sending interrupt driven by waiting for the BLE_GATTS_EVT_HVN_TX_COMPLETE event before calling sd_ble_gatts_hvx() function again. 

 

[Shri1395]

Hi,

We tried using this function, and it did actually make the data send rates a bit more faster. To be more precise, the SDK 11 was 4 times more faster than SDK 15, but after this test, we found out that SD15 is now almost as fast as the SDK 11. That means the speed did increase.

We set the transmission queue to 20.

My question is: We usually get a lot less speed in the beginning and then it fastens. Is there a way to constantly get the same speed, in order to perform better than SDK 11. 

PS: Quick information:

SDK 11, 20K bytes in 5.6 seconds.

SDK 15 before setting the hvn_tx_queue_size to 20 , 20k bytes in 21 seconds.

SDK 15 after the TX_COMPLETE function with hvn_tx_queue_size set to 20, 20k Bytes in 5.8 sec. 

[bjorn-spockeli]

Could you elaborate on what you mean by "We usually get a lot less speed in the beginning and then it fastens." 

If you want to maximize the throughput then I suggest that you increase the ATT MTU Size, i.e. increase the number of payload bytes in the packet. This is done by increasing NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config.h

The S132 SoftDevice specification lists the throughput for different ATT MTU, connection interval and method configurations, it can be found under Bluetooth low energy data throughput.