BLE connection processing with nRF5340 Audio - 2

[SNJY]

This would be a continuation from a previous discussion on the topic of Bonding information and the process of bonding between the peripheral aka headset and central device aka gateway. I have read through the previous one and have a couple of more questions to understand how to handshaking process happens between two devices.

So far we know that the connection is initiated by the peripheral by advertising type ADV_IND and the central accepts the connection for the connection to be esrtablished. After the first successful connection, the random ID generated by the central is stored by the peripheral. This ID is somehow retained by the peripheral throughout any reboots/resets and is used to connect to the cental using ADV_DIRECT_IND advertisement type.

Looking at the code and debug logs for the unicast_server example, the peripheral always try to establish a directed advertisement to connect to the known gateway and if that fails, it will resort back to open connection advertisement.

• Is the above understanding true?
• How is the ID retained in the peripheral?
• Is it possible to setup a static ID for the central and let the perihperal always try connecting to it? If so, how?

[Amanda Hsieh]

Hi, 

Is the above understanding true?

That's correct. 

How is the ID retained in the peripheral?

When using Resolvable Private Addresses (RPA) in Bluetooth LE, the device's identity is retained through the Identity Resolving Key (IRK), which is exchanged during the bonding process.

Is it possible to setup a static ID for the central and let the perihperal always try connecting to it? If so, how?

You can set CONFIG_BT_PRIVACY=n in the prj.conf.

Regards,
Amanda H.

[SNJY]

Thanks,

After setting a static ID by CONFIG_BT_PRIVACY=n, the local address is retained over multiple connections as expected. I also want  to provide the connection details for the central to the peripheral. (if we can store the ID on the other device)

Assuming that we have multiple such pairs, how do i bond these pairs.One way i learnt is that central can have an accept list to connect to known peripherals

Can you provide the right direction?

[Amanda Hsieh]

I recommend checking out the Bluetooth Low Energy Fundamentals course, which covers these concepts in detail.

[SNJY]

Yes i am also looking into that, alternatively is there an example where this is applied?

[Amanda Hsieh]

Check the Exercises in that course. 

[SNJY]

I tried adapting the exercise for the existing nrf5340 unicast_client example. I also referred to another discussion for an extended implementation. 

While it might work seperately, i am not able to make it work with the unicast_client example.

I figured that instead of using the filter, the unicast client passed the peripheral device name in bt_mgmt_scan_start() which is eventually used to compare with any new device connection (in the device_name_check() function)

Do i need to disable/bypass this complete loop if i am trying to implement filters in the central device?

[Amanda Hsieh]

You can modify or replace that function if you don't want to check the advertising data for the matching device name.