How to increase the sampling rate of the ble_app_uart__saadc_timer_driven__scan_mode example?

[Michael01101]

Hi,

in my project I have a custom board with a nRF52832 chip that reads SAADC data and transmits this data (peripheral role). This data is received by a nRF52840-DK board (central role) and written into a COM-Port of a pc. I flashed the "ble_app_uart_c" example into the nRF52840-DK and the "ble_app_uart__saadc_timer_driven__scan_mode" example into the custom board with the nRF52832 chip (nRF5_SDK_17.0.0_9d13099). This configuration works fine. The SAADC data gets transmitted by the nRF52832 custom board, received by the nRF52840-DK and written into the COM-Port of my PC.

My problem is the SAADC sampling rate (SAADC_SAMPLE_RATE) of the "ble_app_uart__saadc_timer_driven__scan_mode" example. By default the SAADC sampling rate is 250ms (4Hz). I need to increase this sampling rate to 1ms (1000Hz). But if I choose the SAADC_SAMPLE_RATE < 10ms (>100Hz) an error occured and the chip resets and tries to reconnect. I receive the following error code if I debug the ble_app_uart__saadc_timer_driven__scan_mode example:

which is produced by the ble_nus_data_send(...) function in main.c:

Unfortunaly, I am not able to find a error description for this error code.

Can you please tell me, how to increase the sampling rate of the "ble_app_uart__saadc_timer_driven__scan_mode" example to 1ms (=1000Hz)?

[Michael01101]

Hello,

thank you for your response.

Karl Ylvisaker said:

Have you monitored your connection interval while you are in a connection, using the nRF Sniffer?

I haven´t done this yet. I tried to use the nRF52840 dongle for the nRF Sniffer, but unfortunaly the dongle is not supportet by the nRF Sniffer. I already ordered a nRF52-DK for this, which will arrive soon.

Karl Ylvisaker said:

I see that you are ok with a delay up to 100 ms before sending, this gives us a lot of leeway.

A delay up to 100ms is okey.

Karl Ylvisaker said:

What do you think about either of these alternatives?

I would prefer the 20ms alternative. I implemented this with a MIN_CONN_INTERVAL and a MAX_CONN_INTERVAL of 20ms and it works fine.

I also tried to use an 40ms (32 x 1,25ms) interval (MIN_CONN_INTERVAL and MAX_CONN_INTERVAL of 40ms). So every 40ms the ble_nus_data_send() function gets called with 200 bytes of data. This should be within my MTU size. But nearly immediatly after a connection is established between central und peripheral, I receive a NRF_ERROR_RESOURCES. Although I receive for every call of the ble_nus_data_send() function an BLE_GATTS_EVT_HVN_TX_COMPLETE event and it doesn´t looks like a buffer overflow.

Do you know why this is happening?

Karl Ylvisaker said:

please remember that shorter connection intervals increases power consumption

My goal is the largest possible connection interval for lower power consumption.

Thank you very much in advance.

[Karl Ylvisaker]

Hello,

Michael01101 said:

thank you for your response.

No problem at all, I am happy to help!

Michael01101 said:

I haven´t done this yet. I tried to use the nRF52840 dongle for the nRF Sniffer, but unfortunaly the dongle is not supportet by the nRF Sniffer. I already ordered a nRF52-DK for this, which will arrive soon.

That is great! The nRF Sniffer is a very powerful tool to wield when developing BLE applications.
It makes it a lot easier to see what is actually going on in your links.

Michael01101 said:

I would prefer the 20ms alternative. I implemented this with a MIN_CONN_INTERVAL and a MAX_CONN_INTERVAL of 20ms and it works fine.

I am glad to hear that is is working as intended now!

Michael01101 said:

nearly immediatly after a connection is established between central und peripheral, I receive a NRF_ERROR_RESOURCES. Although I receive for every call of the ble_nus_data_send() function an BLE_GATTS_EVT_HVN_TX_COMPLETE event and it doesn´t looks like a buffer overflow.

Do you know why this is happening?

An exempt from the sd_ble_gatts_hvx function ( which is used in ble_app_uart_send ) reads:

The number of Handle Value Notifications that can be queued is configured by ble_gatts_conn_cfg_t::hvn_tx_queue_size When the queue is full, the function call will return NRF_ERROR_RESOURCES. A BLE_GATTS_EVT_HVN_TX_COMPLETE event will be issued as soon as the transmission of the notification is complete.

What is your queue size defined to?

Michael01101 said:

My goal is the largest possible connection interval for lower power consumption.

Then I would go for the largest possible payload with the longest acceptable connection interval, to minimize active radio time.
Have you seen our Online Power Profiler? It is very useful to see the difference in estimated power consumption for different connection parameters.

Best regards,
Karl

[Michael01101]

Hello, 

sorry for my late response.

After I had installed the nRF Sniffer, I found the issue. In the ble_app_uart_c example, which I use in my central device, something called ECHOBACK_BLE_UART_DATA was enabled.

If this is enabled, all data which is received over NUS by the central is sent back to the peripheral over NUS. After I disabled this, I managed to get a stable 40ms connection intervall with 200 bytes for every interval.

Karl Ylvisaker said:

Have you seen our Online Power Profiler

Thank you for this. I will take a look to this Power Profiler. But I am good for now.

Finally, thank you for providing such a great support and developing tools.

[Karl Ylvisaker]

Hello,

Michael01101 said:

sorry for my late response.

It is no problem at all! :) 

Michael01101 said:

After I had installed the nRF Sniffer, I found the issue. In the ble_app_uart_c example, which I use in my central device, something called ECHOBACK_BLE_UART_DATA was enabled.

If this is enabled, all data which is received over NUS by the central is sent back to the peripheral over NUS. After I disabled this, I managed to get a stable 40ms connection intervall with 200 bytes for every interval.

Fantastic, I am happy to hear that you were able to find the source of the issue, and achieve the desired connection interval and MTU transfer size!

Michael01101 said:

Thank you for this. I will take a look to this Power Profiler. But I am good for now.

Great - it is a very useful tool to estimate the power consumption for different connection parameters, it will definitely be useful to take a look at if you are looking to power optimize your application.

Michael01101 said:

Finally, thank you for providing such a great support and developing tools.

It is no problem at all, I am happy to help.
I am glad to hear you say that, thank you!

Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl
 

[usmanmehmood55]

Hi Michael. 

I was facing a very similar issue a for a long time. I was trying to achieve 1000Hz ADC readings over BLE on the nRF connect app. 

I started from 200Hz and kept playing around with the settings and parameters until I reached 970Hz just recently. 

Can you share your latest code and development with me so I can give any help that I can? 

Regards,

Usman