Problem to get a device address information from the trusted device bond database

[JoLo33]

Hey there,

I work with the Lyra P Module. I use it atm to figure out if it fits our needs. I play around with the settings and connect with the EFR Connect mobile app. The Module is in VSP Mode and I set the Setting ATS 102=1 to enable bonding. After I connect via the App I bond and get

• RING 025A6387937720, U
• ENCRYPT
• CONNECT 0, 025A6387937720, 47500, 5000000, 0

I'm wondering when I try to check if the given Address in the RING or CONNECT Response is in the trusted device bond database via AT+BNDT 025A6387937720 I always get

0 OK

also the RING response has always a U at the end and never a T. But if I check the devices in the trusted device bond database via ATI 2009 I get a 1. I also cleared the database and connect again, the counter get set to 0 and after connection and bonding again to 1. So something is inside this database but I can't get it via the Address given by RING or CONNECT.

What I'm doing wrong? Thanks for helping me out here.

Cheers Jonas

[FlorianBaumgartl-Ezurio]

Hi Jonas − Many thanks for reporting and bringing this to our attention. While investigating, could you please kindly confirm the GA release and/or software version you are testing with? You can also issue the ATI 3 command via UART to request the firmware version which is currently running on your Lyra module as described in our Lyra Series - AT Interface Application User Guide on page 11. Thanks, Florian.

[JoLo33]

Hi, sure. Here is a full List of all commands I send and also the status of some settings.

Module Restarted
Check Setting
ATS 102? =
1
OK
ATI 2009? =
0
OK
ATI 2041? = 
0
OK
ATI 3? = 
126.3.1.173
OK

So bonding table on the module is cleared, bonding is enabled on the module. The bonding in phone is cleared as well. I connect via nRF Connect app this time.

RING 026BC7A3FD7CD5, U
ENCRYPT
CONNECT 0, 026BC7A3FD7CD5, 47500, 5000000, 0
NOCARRIER 90

First connection, phone has not initiated the bonding, that was done by the module when I wrote 0x01 to the modem in characteristics.

RING 025544DA0810A1, U
ENCRYPT
CONNECT 0, 025544DA0810A1, 47500, 5000000, 0
NOCARRIER 90

RING 025544DA0810A1, U
ENCRYPT
CONNECT 0, 025544DA0810A1, 47500, 5000000, 0
NOCARRIER 90

Second and third connection, address changed, Ring still with U at the end. I restart the module and request the settings again and if the two given addresses are in the database.

Check Setting
ATS 102? = 
1
OK
ATI 2009 = 
1
OK
ATI 2041 = 
1
OK
ATI 3 = 
126.3.1.173
OK
AT+BNDT 026BC7A3FD7CD5 = 
0
OK
AT+BNDT 025544DA0810A1 = 
0
OK

If I connect after the restart, the same

RING 025544DA0810A1, U
ENCRYPT
CONNECT 0, 025544DA0810A1, 47500, 5000000, 0
NOCARRIER 90

[FlorianBaumgartl-Ezurio]

Sorry for not coming back to you earlier, Jonas. The issue with the AT+BNDT {address} command has been added to our recent Lyra Series − Release Notes document and the "Known Issues" section. Further tests also showed that this issue is related to the incorrect RING response event where you see 'U' flags instead of 'T' flags when reconnecting to Lyra after you have completed the pairing / bonding process within the EFR Connect mobile app. I can confirm that our engineering team is working on resolving both issues, but unfortunately at this time I cannot give you any ETA for this as we just released the GA2 software for Lyra here on GitHub 2 weeks ago. We will keep you updated on any new developments.

[FlorianBaumgartl-Ezurio]

This is for future reference and documentation purposes only. The following bug IDs for the non-working AT+BNDT command (24072) and incorrect RING event message (24176) have been assigned. They are highlighted and listed in the brackets above.

[FlorianBaumgartl-Ezurio]

The issue with the RING event has been resolved in the Lyra GA2.1 release (https://github.com/LairdCP/Lyra_Firmware/releases/tag/GA2.1). Additionally, we've added the following note to the latest Lyra 22 P/S & Lyra 24 P/S AT Interface Application User Guide document for the AT+BNDT command:

Due to underlying SDK limitations this command currently does not work with random resolvable addresses as the address stored in the bond database does not correspond to the ‘random’ address given at connection. If you require a bond check in your application, please make sure to only use public (00) and/or static (01) address types with your end device(s) instead. A random resolvable address is a security feature of BLE that prevents tracking by randomizing the MAC address. Common portable devices such as a smartphone, tablet or notebook are most likely to enforce a random resolvable address and thus trigger the issue outlined.