NRF52840 - 10 kHz ADC sampling and continuous signal transmission via BLE - Is it possible?

RE: NRF52840 - 10 kHz ADC sampling and continuous signal transmission via BLE - Is it possible?

Einar Thorsrud — Tue, 17 Aug 2021 10:28:33 GMT

You need to count the amount of data transferred. You can for instance refer to the Experimental: ATT_MTU Throughput Example. This example is also good if you want to experiment with different configurations to see which impact it has on throughput.

RE: NRF52840 - 10 kHz ADC sampling and continuous signal transmission via BLE - Is it possible?

Thiago — Sun, 15 Aug 2021 05:51:55 GMT

Hello, Einar.

Thank you for your answer. I modified the configuration of the connection interval as you suggested. Could you suggest to me a way to read the throughput of my application? I would like to know if the module is already working next to the limit or if it is still possible to increase the performance.

RE: NRF52840 - 10 kHz ADC sampling and continuous signal transmission via BLE - Is it possible?

Einar Thorsrud — Mon, 09 Aug 2021 13:20:23 GMT

Hi,

[quote user=""]Can it be done using an nrf52840?[/quote]

Looking at your samples, if you have 10 ks/s and transfer each sample as an uint_16, that means that the raw dat would be 10 ks/s * 16 bit/s = 160 kbps. You will of course have some overhead, but it should be OK from a throughput perspective. With everything optimal you can get about 700 kbps of throughput with BLE (1 Mbps PHY) and 1400 kbps (2 Mbps phy). (Practical real life throughput will typically be significantly lower though, for several reasons.)

[quote user=""]Is there any problem with how I configured the module?[/quote]

You use a too short connection interval. To achieve higher throughput it is better to use longer connection intervals, and ensure that the event length is as long as the connection interval. This way you can send many packet per connection interval. With NRF_SDH_BLE_GAP_EVENT_LENGTH set to 400 (*1.25 ms) you can set the connection interval to 0.5 s, which may be a sensible value. Then transfer data using long indications (> 200 byte).
There is a trade-off with long event lengths and connection intervals, though. Whenever there is a packet loss the retransmission happens in the next connection event. So in this case you will spend a long time before being able to retransmit. And in that case you would have to buffer up the data. This also makes the whole think a bitt less rea-time, and this is a limitation of BLE.