Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Frequency of Notifications with Android BLE Library

I am working on a derivative of the Glucose sensor code from nRF Toolbox. The sensor peripheral accumulates a number of readings. The central  sends a command to the Record Access Control Point characteristic asking for the readings. The peripheral sends the requested data as a sequence of Notifications from the Glucose Measurement Characteristic, then sends a status message as an Indication from the Record Access Control Point characteristic.

For a small number of readings this works as expected: I see the Notifications arriving at the central (in the Notification callback code onDataReceived() ).

However, I find that when the number of characteristics exceed about 6, the central stops receiving the Notifications. The peripheral hangs up as it sends the Notification AFTER the last one received by the central.

If I insert a delay of about 8ms on my device, to throttle the Notification stream, then it starts working again. I am doing some work on the incoming Notification data (checking validity) then add it to an Array List for later processing, so probably not spending a huge amount of time.

The question is whether there are limitations at the central on the rate at which it can receive Notifications. Are Notifications queued by the OS? Do I need to do somewthing with threads? etc.

I get the same result with two tablets running Android 7.

Parents
  • The peripheral hangs up as it sends the Notification AFTER the last one received by the central.

    Could be a problem in your peripherial code.

    After about 6 notification you will get the BLE_ERROR_NO_TX_PACKETS, and IIRC this condition gets cleared only when the app processed the following BLE_EVT_TX_COMPLETE.

    A tight loop just calling sd_ble_gatts_hvx() repeatedly can simply hang when other BTLE events cannot be processed.

Reply
  • The peripheral hangs up as it sends the Notification AFTER the last one received by the central.

    Could be a problem in your peripherial code.

    After about 6 notification you will get the BLE_ERROR_NO_TX_PACKETS, and IIRC this condition gets cleared only when the app processed the following BLE_EVT_TX_COMPLETE.

    A tight loop just calling sd_ble_gatts_hvx() repeatedly can simply hang when other BTLE events cannot be processed.

Children
No Data
Related