nRF52840 SDK16 - High data rate Tx

[Nikosant03]

Hi everyone,

We design an application using the nRF52840 and SDK16. This application is intended to be used for gait analysis and one of the requirements is a real-time data process. We are using nRF52832 as a central device to receive raw data and then UART protocol to communicate nRF52832 with the main MCU. The gait analysis requires a high sampling rate (from 100 to 300Hz). What is the best approach to limit data loss and maintain power consumption as low as possible?

I use notifications (the API sd_ble_gatts_hvx) to send data from the peripheral to the central. I know also that notifications can be transmitted within a connection event of 7.5 ms (this is a frequency of around 133Hz). What if I want to use a sampling rate of 200Hz (32Bytes x 8bits x 200Hz = 12.8Kbps)? What procedure should I follow?

Also when I try to transmit with 100Hz the sd_ble_gatts_hvx function returns too often NRF_ERROR_RESOURCES and I have to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE event. This creates a lug between the real-time readings and the data received by the central (remember that we need real-time data processing)

Any advice?

Nick

[Susheel Nuguru]

Hi Antoniou,

nRF52 is a single core chip. And you can have only only one strictly real time thread in it. When using BLE stack, which needs to follow very hard time constrained events, it takes up the highest interrupt priority reserved for it. When there is any BLE activity, there is both pre and post processing of that BLE data transmitted and or received. The throughput greatly depends on

1. Connection interval
2. Connect event length
3. Data size in the packet (using DLE and bigger packet size needs bigger event length)
4. PHY used
5. data to be sent out already being queued as fast as they can
6. minimal application post processing of data transmitted and or recieved to give maximum CPU time for application to queue data.

The suggestions for event length for a connection can be found here.

You need to understand how much time your application is spending on pre and post processing of data on notifications.
You also need to understand how many packets you are able to squeeze into one connection interval (how many connection events within a connection interval) based on the data size within a packet. In our thoughput examples we demonstrated that you can achieve very close to theoretical maximum throughput (1.4Mbps) with some room for application pre and post processing. But there is always a balance to make that an Architect of your application will be able to calculate/design and answer. 

In your case, if you are getting NRF_ERROR_RESOURCES with that low throughput, means that you application has not calibrated the connection correctly OR spending a lot of time in pre or post precessing of data.

[Nikosant03]

Thank you for your prompt responce Susheel Nuguru

Could you elaborate more on 6. "minimal application post processing of data transmitted and or recieved"?

What do you mean by pre and post processing and how this affect the throughput? Could you provide an example?

[Susheel Nuguru]

Every notification data packet your application queues, needs some pre processing (and most likely some post processing after sending) apart from other things your application does. The CPU time used up by the softdevice is mostly fixed per BLE procedure and data transmit/receive. So you need to benchmark how much time your application is using the CPU on preparing each data packet and other logics that needs to maintain the housekeeping of your application. 

In short, 6) points to the need to benchmark your application CPU time doing different things, you can use GPIOs to toggle at different logics to get an idea on application CPU usage. It seems that the application is sometimes queueing the notifications too fast (and hence get NRF_ERROR_RESOURCES  in the HVX operation) and sometimes have idle periods where it is not utilizing the connection events to transmit data (as the application might be busy doing other stuff).

[Nikosant03]

Susheel Nuguru said:

Every notification data packet your application queues, needs some pre processing (and most likely some post processing after sending) apart from other things your application does

The preprocessing is done by the SD when I call the sd_ble_gatts_hvx?

Susheel Nuguru said:

It seems that the application is sometimes queueing the notifications too fast

The queueing time is basically the time intervals between the sd_ble_gatts_hvx calls?

[Susheel Nuguru]

Nikosant03 said:

The preprocessing is done by the SD when I call the sd_ble_gatts_hvx?

 Yes, but the application probably is also preparing the packet to be sent? it would become a bit easier if you can share some code snippets of how you are getting/preparing your data to be transmitted. Also try to change the PHY to 2M to have higher throughput.