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?

[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.

[SNJY]

Hi Amanda,

I was able to partially implement what i was aiming for. But I am stuck at something related and is required for my implementation.

Since i have multiple peripherals, i have resorted to pairing and have removed the bonding process for now. I am implementing scan filters on the gateway to control which specific peripherals to connect to.

For this implementation, i want to add a custom string to the advertisement packet of the peripheral which i can look for on the central side. In the unicast server sample, the advertisement packets are populated with uuids for a couple of services which also includes the manufacturer ID.

I tried appending data to the same buffer before it gets populated but when i add the custom data, the device throws error stating 'Failed to set advertising data: -22' and 'Failed to create extended advertisement: -22'

I add the following snippet to the ext_adv_populate() function - 

ret = bt_mgmt_manufacturer_uuid_populate(&uuid_buf, CONFIG_BT_DEVICE_MANUFACTURER_ID);
if (ret) {
	LOG_ERR("Failed to add adv data with manufacturer ID: %d", ret);
	return ret;
}

/* USER CODE */

NET_BUF_SIMPLE_DEFINE_STATIC(str_buf, CONFIG_EXT_ADV_UUID_BUF_MAX);

ret = custom_name_populate(&str_buf);
if (ret) {
    LOG_ERR("Failed to add adv data with name", ret);
	return ret;
}

 ext_adv_buf[ext_adv_buf_cnt].type = BT_DATA_NAME_SHORTENED;
 ext_adv_buf[ext_adv_buf_cnt].data = str_buf.data;
 ext_adv_buf[ext_adv_buf_cnt].data_len = str_buf.len;
 ext_adv_buf_cnt++;
 
 /* USER CODE */
 
 ret = unicast_server_adv_populate(&ext_adv_buf[ext_adv_buf_cnt],
					  ext_adv_buf_size - ext_adv_buf_cnt);

Could you please shed some light into what is wrong in the implementation?

[SNJY]

An update on this,

I was able to add custom string to one of the data types and append it to the advertisement packet. I did this by inserting the same information in the unicast_server_adv_populate() function using bt_mgmt_adv_buffer_put. I was under the assumption that adding the data in the main.c/ext_adv_populate() would do the trick but adding it to unicast_server.c/unicast_server_adv_populate() made it work.

int unicast_server_adv_populate(struct bt_data *adv_buf, uint8_t adv_buf_vacant)
{
.
.
.


size_t brdcast_name_size = strlen(CUSTOM_NAME);

ret = bt_mgmt_adv_buffer_put(adv_buf, &adv_buf_cnt, adv_buf_vacant,
			     brdcast_name_size, BT_DATA_BROADCAST_NAME,
			     (char *)CUSTOM_NAME);
if (ret) {
	return ret;
}


.
.
.
}

Let me know if there is a better way.