• State Not Answered
  • Replies 15 replies
  • Subscribers 70 subscribers
  • Views 7532 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 213870
Options
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

Acutetech

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.

  • 0

    Hi again

    You should be getting all notifications in the order they were sent. The limit how fast notifications can be sent and received is build into Att protocol, so the sender doesn't send more then it can, and the received doesn't confirm more then it can handle.

    Are you using the Ble Library v2 (nRF Toolbox from *develop* branch)?

  • 0 in reply to Aleksander Nowakowski

    Hi Aleksander

    I would like to press you further on this. While my code has changed (on both Peripheral and Central) since my earlier post, I am still seeing unexpected results - somewhat different from above but possibly with the same root cause. The top-level question is, can Nordic's Android library cope with a rapid succession of Notifications?

    Today I see correct operation with two tablets (Asus and Acer, Android 7, with no delay added between Notifications at the Peripheral end). But with a Samsung phone (Android 8), when I attempt to transfer 5 notifications in quick succession:

     - With no added delay between Notifications, the phone receives 5 notifications, but the payload of earlier Notifications have been lost and are replaced by the payload of later Notifications.  Example: each payload includes a sequence number. The BLE peripheral sends sequence numbers 300, 301, 302, 303, 304 but the app on the phone receives 302, 302, 302, 304, 304. The messages in nRF Logger show the same payload data. It looks as though the events are happening too quickly and some variables are being over-written before their contents are picked up by my own application code (and nRF Logger).

    - I have to add a delay of 50ms between Notification transmissions (on the BLE Peripheral)  before I can get reliable operation.

    I have looked at your source code. Can you tell me if I get this right:

    - The operating system gets a Notification and calls onCharacteristicChanged() in your MainThreadBluetoothGattCallback().

    - You grab the payload and call onCharacteristicChangedSafe() in BleManager.

    - That prints the messages I can see on nRF Logger, and then (somehow) passes the data back to the onDataReceived() callback in my app - which is where I pick up the payload and process it. But it looks like by the time I get the callback, earlier data has been overwritten by later data.

    Is there an inherent throughput problem with your library? Or something I need to do at my end so I can process an arbitrarily long sequence of Notifications?

    My build.gradle has this:

    implementation 'no.nordicsemi.android:ble-common:2.0-alpha6'
    implementation 'no.nordicsemi.android:log:2.1.1'
    implementation 'no.nordicsemi.android.support.v18:scanner:1.1.0'

    Thx - Charles

  • 0
    Acutetech said:
    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.

  • 0 in reply to Acutetech

    I will improve the lib in this aspect. Would there be a chance to get your firmware and app for testing?

  • 0 in reply to Aleksander Nowakowski

    Let me clean some stuff up before I send you something. However I am expecting to see the problem with your example Glucose app as the Peripheral and the corresponding receiver in the nRF Toolbox. Get the two bonded, then disable BLE on the phone, then get many readings pending in the Peripheral, then turn BLE back on. The Peripheral will then send all its readings as notifications quickly. As my code is derived from the Glucose app within nRF Toolbox, I think I will see the same problem. But perhaps not!

Related