Unexpected incrementation of instance IDs with Laird characteristics despite bonding

[JoLo33]

Hi,

I got a new problem from our Android developer team:

Tested with GA1.2 and GA2.2

When our app queries the GATT server of the module, we receive a list of UUIDs and their corresponding handles. The characteristics can then be addressed using these handles. Handle = Instance-ID.

We have noticed that the handles of Laird's proprietary characteristics increase by 11 with each connection, contrary to their own documentation: https://www.lairdconnect.com/support/faqs/what-handle-respect-gatt-server We have tested it with and without bonding.

This poses a problem for us on the app side because we now have to clear the UUID cache with each connection to be able to enter the new instance IDs. Android does not normally allow this, but it is still possible through reflections. We are concerned because reflections are somewhat unconventional and may soon be restricted by Android.

Question: Why do the instance IDs increment with each connection despite bonding? Is this a bug?

Here are some Logs:

PHONE 1
*************** CONNECTED BUT NO DATA TRANSMISSION

           I  ---------------Service: 00001801-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3
           I  ---------------Descriptor: 00000000-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------------Service: 00001800-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 7
           I  ---------Characteristic: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 9
           I  ---------Characteristic: 00002a04-0000-1000-8000-00805f9b34fb, Handle: 11
           I  ---------Characteristic: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 13
           I  ---------------Service: 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0
           I  ---------Characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063, Handle: 16
           I  ---------------Service: 569a1101-b87f-490c-92cb-11ba5ea5167c
           I  ---------Characteristic: 569a2001-b87f-490c-92cb-11ba5ea5167c, Handle: 41
           I  ---------Characteristic: 569a2000-b87f-490c-92cb-11ba5ea5167c, Handle: 43
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------Characteristic: 569a2003-b87f-490c-92cb-11ba5ea5167c, Handle: 46
           I  ---------Characteristic: 569a2002-b87f-490c-92cb-11ba5ea5167c, Handle: 48
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0

--------------------------------------------------------------------------------------------------------
CONNECTED DATA TRANSMISSION

           I  ---------------Service: 00001801-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3
           I  ---------------Descriptor: 00000000-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------------Service: 00001800-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 7
           I  ---------Characteristic: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 9
           I  ---------Characteristic: 00002a04-0000-1000-8000-00805f9b34fb, Handle: 11
           I  ---------Characteristic: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 13
           I  ---------------Service: 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0
           I  ---------Characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063, Handle: 16
           I  ---------------Service: 569a1101-b87f-490c-92cb-11ba5ea5167c
           I  ---------Characteristic: 569a2001-b87f-490c-92cb-11ba5ea5167c, Handle: 52
           I  ---------Characteristic: 569a2000-b87f-490c-92cb-11ba5ea5167c, Handle: 54
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------Characteristic: 569a2003-b87f-490c-92cb-11ba5ea5167c, Handle: 57
           I  ---------Characteristic: 569a2002-b87f-490c-92cb-11ba5ea5167c, Handle: 59
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0

--------------------------------------------------------------------- DISCONNECT AND RECONNECT

           I  ---------------Service: 00001801-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3
           I  ---------------Descriptor: 00000000-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------------Service: 00001800-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 7
           I  ---------Characteristic: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 9
           I  ---------Characteristic: 00002a04-0000-1000-8000-00805f9b34fb, Handle: 11
           I  ---------Characteristic: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 13
           I  ---------------Service: 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0
           I  ---------Characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063, Handle: 16
           I  ---------------Service: 569a1101-b87f-490c-92cb-11ba5ea5167c
           I  ---------Characteristic: 569a2001-b87f-490c-92cb-11ba5ea5167c, Handle: 63
           I  ---------Characteristic: 569a2000-b87f-490c-92cb-11ba5ea5167c, Handle: 65
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------Characteristic: 569a2003-b87f-490c-92cb-11ba5ea5167c, Handle: 68
           I  ---------Characteristic: 569a2002-b87f-490c-92cb-11ba5ea5167c, Handle: 70
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0

-------------------------------- ANOTHER PHONE ----------------------------------------------

           I  ---------------Service: 00001801-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3
           I  ---------------Descriptor: 00000000-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------------Service: 00001800-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 7
           I  ---------Characteristic: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 9
           I  ---------Characteristic: 00002a04-0000-1000-8000-00805f9b34fb, Handle: 11
           I  ---------Characteristic: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 13
           I  ---------------Service: 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0
           I  ---------Characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063, Handle: 16
           I  ---------------Service: 569a1101-b87f-490c-92cb-11ba5ea5167c
           I  ---------Characteristic: 569a2001-b87f-490c-92cb-11ba5ea5167c, Handle: 85
           I  ---------Characteristic: 569a2000-b87f-490c-92cb-11ba5ea5167c, Handle: 87
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------Characteristic: 569a2003-b87f-490c-92cb-11ba5ea5167c, Handle: 90
           I  ---------Characteristic: 569a2002-b87f-490c-92cb-11ba5ea5167c, Handle: 92
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0

-----------------------------------

           I  ---------------Service: 00001801-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a05-0000-1000-8000-00805f9b34fb, Handle: 3
           I  ---------------Descriptor: 00000000-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------------Service: 00001800-0000-1000-8000-00805f9b34fb
           I  ---------Characteristic: 00002a00-0000-1000-8000-00805f9b34fb, Handle: 7
           I  ---------Characteristic: 00002a01-0000-1000-8000-00805f9b34fb, Handle: 9
           I  ---------Characteristic: 00002a04-0000-1000-8000-00805f9b34fb, Handle: 11
           I  ---------Characteristic: 00002aa6-0000-1000-8000-00805f9b34fb, Handle: 13
           I  ---------------Service: 1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0
           I  ---------Characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063, Handle: 16
           I  ---------------Service: 569a1101-b87f-490c-92cb-11ba5ea5167c
           I  ---------Characteristic: 569a2001-b87f-490c-92cb-11ba5ea5167c, Handle: 96
           I  ---------Characteristic: 569a2000-b87f-490c-92cb-11ba5ea5167c, Handle: 98
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0
           I  ---------Characteristic: 569a2003-b87f-490c-92cb-11ba5ea5167c, Handle: 101
           I  ---------Characteristic: 569a2002-b87f-490c-92cb-11ba5ea5167c, Handle: 103
           I  ---------------Descriptor: 00002902-0000-1000-8000-00805f9b34fb, Permissions: 0

Best Jonas

[FlorianBaumgartl-Ezurio]

Many thanks, @JoLo33. We are currently investigating the cause of this issue.
I will keep you updated with any new findings, suggestions, and developments.

[JoLo33]

Hi @FlorianBaumgartl-Laird,

did you find something, or do you have any suggestion for us? Can we provide you with more information?

[FlorianBaumgartl-Ezurio]

Hi @JoLo33. We are still trying to better understand (and isolate) the root cause of the problem. Quick question: Would you be able to run some additional tests with your app on Android? It would be important to know if the same behaviour can be replicated in non-VSP mode (without any data transmission) when creating a custom GATT database as explained in the following document: https://www.lairdconnect.com/documentation/application-note-custom-gatt-database-command-set-lyra-series in section 6.2 and 6.3 on pages 8 – 10. Please do not forget to issue the ATS 100=0 command followed by AT&W and ATZ in this case. Let us know. Thanks.

[ChrisCA]

Hi @FlorianBaumgartl-Laird !
I'm a colleague of @JoLo33 .

We did not yet followed your last suggestion by creating a custom GATT, but we tried to isolate the issue we are facing from our app. We're now able to reproduce the issue with the EFR Connect app on Android, as well as on iOS.
We tested with up to date iOS version, which is 17.2 for today and on the Android, we covered Android 10, 13 and 14 from different brands of manufacturers as Samsung, Google Pixel and Oppo.
The behaviour was all the same so I think we can exclude a device specific behaviour.
We also used several Lyra P dev modules to reduce the chance for a HW defect.
The effect we are seeing can also be observed in our app, where we discovered it first but which I cannot share.
Nordic's nRF Connect app is another app which can be used to reproduce the same behaviour.
As EFR and nRF are freely accessible in the PlayStore/AppStore, I think that should be suitable for testing.
Following is a step by step instruction how to reproduce the issue:

Lyra P preparation:

1. apply LYRA_P_AT_Interface_480-00182-R126.3.1.414_OTA.gbl to the dev board
2. factory reset
3. apply ATS 100=1
4. apply ATS 102=1
5. run AT&W and ATZ

At this point we expect to module to be sufficiently configured for our use case in VSP mode.
We activated the encryption mode on the module side as convenience so that pairing is triggered on the Android side.
If encryption is deactivated on the module side, but forced on the Android side, the observed behaviour is the same.
If encryption is disabled on the module side and not forced by Android (no pairing happening), we do not face any issue at all.
The handlers are still increased as mentioned in @JoLo33 earlier post, but the iOS and Android BT stack seem to handle that topic silently by itself.

EFR procedure (Android):

1. First make sure that the Lyra P module is not bonded because e.g. earlier tests any more . Remove any bonding via the Android/iOS BT settings menu.
2. Open the EFR app and connect to the Lyra P board.
   
3. Navigate to the VSP characteristics and subscribe to the 2002 characteristic and enable notify
   
4. Accept the pairing. You can now see the 0x01 send by the characteristic.
   It's important to note, that the issue is also happening if we follow the exact timing and step by step instructions from the AT command document which are:
   Both TX_FIFO and MODEM_OUT characteristics need their notifications enabled for
   VSP operation. Additionally, the MODEM_IN characteristic must have the value 0x01 written to it to signal ‘CTS’.
   If the timeout occurs the above can still be done, but in this state VSP operation will be undefined. It’s important to
   follow the sequence, and the final step must be writing 0x01 to the MODEM_IN characteristic. If this is performed
   without the notifications having been enabled behaviour is undefined.
   I'm just providing here a minimum sample with the same effect.
   
5. Move back to the scan screen and disconnect from the Lyra P module
   
6. Repeat steps 2 to 5. The only difference in behaviour is that there is no pairing request.
7. Again repeat steps 2 to 5. But this time your will recognize that there is no 0x01 send by 2002.
   
   This always happens on the third try in the above described procedure, not matter which app we use.
   At the same time, also the OTA FW update process will be blocked from the module side. You can now switch phones but it will always fail with:
   

EFR procedure (iOS):
The observation on iOS is the same except of one difference.
An error occurs already on the 2nd try to enable notify on 2002 and produces the following error:

So for the moment, it appears to us that the either there is some magic happening with the Lyra P module (bug) or we are using wrong. We do not assume that there is a bug in our in house app as other well known apps, even cross platform, behave the same as our in house app. We did not yet do the investment setting up our own GATT services as we are planning to use the VSP mode and this ready to go solution is one of the main selling points of the product for us.

Best regards
Christian

[FlorianBaumgartl-Ezurio]

Hi @JoLo33 and @ChrisCA. Can you please check if the following workaround works for you? In addition to the AT&F, ATS 100=1 and ATS 102=1 commands, try also to apply AT+UFU 49,ATZ with AT&W. This will − automatically − reset in background the Lyra module once a BLE connection is dropped or terminated. It worked fine here (3x times in a row) with a Lyra P development board running the latest GA2.2 release. Tested on both Android and iOS in conjunction with EFR Connect.

[ChrisCA]

Hi @FlorianBaumgartl-Laird and thanks for the feedback.
We verified the hotfix and can confirm that this solves the particular issue we reported here.
We verified this by using the EFR Connect and other apps. We did not tested this with further prototypes as we are blocked by other known issues like e.g. Occasional data loss in VSP mode above 115200 baud rate. (Bug 22384) so we are not willing to invest more time to fully verify this, until there is a clean path for using this module.

Best regards
Christian

[FlorianBaumgartl-Ezurio]

Hi @ChrisCA. Okay, I totally understand. Thanks for verifying and confirming. I’ve passed your feedback internally to our engineering team. The bug with ID #22384 which you are referring to is going to be fixed in the next Lyra 22 GA3 release. This version is scheduled for May 2024.