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.

[Acutetech]

It has proved quite complex to get quality evidence. However I have some results, running a slightly modified version Nordic's Glucose App running on the PCA10040 dev kit, and two versions of nRF Toolbox, on three Android devices. I have used nRF Logger to view activity. In my experiments I simulate 0, 1, 2, 3, 4 and 5 glucose readings and download these (as Notifications) to nRF Toolkit by pressing the "ALL" button.

There is no fault with the nRF Toolbox downloaded from Play Store, on any device.

If I rebuild the Develop branch of nRF Toolbox from Github then I get different, incorrect, results, depending on which device I use.

With my Samsung Phone (Android 8), nRF Logger shows that all the Notifications contain the same payload. In every case the payload is of the final notification (determined by the "Sequence Number" which increments with each glucose reading).

With both tablets (Android 7), nRF Logger shows that the Notifications contain the correct payloads. However the nRF Toolbox misbehaves. The toast messages in nRF Toolbox are correct, but reading data is not displayed properly. When the peripheral has one record it is always displayed. When it has more than one record, records are almost always NOT displayed (I see "No values to display"). But very occasionally the readings are displayed correctly.

So: two bugs, or two manifestations of the same bug.

I can provide a more detailed report and nRF Logger files, if you want these.

[Aleksander Nowakowski]

Hi, I've just pushed some changes to nRF Toolbox. The master branch is not using BLE library 2.0. Also, I've fixed an issue with GLS, but that was related only to UI and refreshing the table. I've also updated BLE lib dependency from beta5 to final version, but the fix seems to be already there (https://github.com/NordicSemiconductor/Android-BLE-Library/commit/e5e054b5952ce6c85798895c8c84f973cf58a624). Nevertheless, I've tested with 20 notifications and they are all displayed on Pixel 2.

[Acutetech]

Hi Alexsander. It was not entirely clear from your post where you have made changes: both to nRF Toolbox and BLE Library? I assume that changes to BLE Library will be picked up if I collect the latest version of nRF Toolbox? Anyway, that is what I have done (the Master branch). I see some differences, as follows:

My two Android 7 tablets now seem to be working OK. Notifications are displayed correctly. Thanks. (Though I seem to have a bonding issue: I might post separately on this).

My Android 8 phone (Samsung AM-A520F, Android 8.0.0, API26) still misbehaves. Exactly one record is displayed by the app (if it has any), regardless of how many are downloaded. Previously one record was displayed if it contained one record, and no records were displayed if it had more than one record. nRF Logger shows that every notification contains the same payload (as before).

Have you seen the problem with Android 8 devices?

[Acutetech]

I have done further work on this. First: I have bought another tablet: Lenovo TB-710F (Android 8.1.0, API27) and tried it with nRF Toolbox built from Github. That does NOT show the problem (kinda rules out a generic Android 8 fault). So I now have 4 devices all of which work except my Samsung A5 (SM-A520F, Android 8.0.0) phone, and that only fails with the latest version of nRF Toolbox.

On the Samsung phone I looked at radio RX and TX signal timing and see they are the same with both versions of nRF Toolbox. So we can apparently rule out the problem as being due to some radio timing differences. The version from Playstore collects notifications correctly but the new version returns all notifications containing the same data.

With the Nordic dev kit containing 20 records (seq. no.s 0-19) I download all and over 3 cycles see notifications with these sequence numbers:
7, 7, 7, 15, 15, 15, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19
6, 6, 6, 15, 15, 15, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19
0, 8, 8, 17, 17, 17, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19

I have a CSR peripheral which I also load with 20 records (seq. no. 2-21). Notifications received were as follows (slightly different pattern?):
8, 8, 8, 8, 8, 8, 8, 9, 13, 13, 13, 13, 14, 21, 21, 21, 21, 21, 21, 21
8, 8, 8, 8, 8, 8, 8, 9, 16, 16, 16, 16, 16, 16, 16, 17, 21, 21, 21, 21
8, 8, 8, 8, 8, 8, 8, 9, 10, 11, 18, 18, 18, 18, 18, 18, 18, 19, 21, 21

There is clearly a bug here, but what???? Can you guys find a Samsung A5 phone to look at?

[Acutetech]

Hi Aleksander - is there any chance of a response from Nordic on this? Summary: the "latest" BLE Library returns the wrong Notification data but only on one of my 4 Android devices (Samsung A5). The problem is not present with the earlier BLE Library.

I think it is a real bug, even if it is obscure.