In which subsequent process is the random_static_addr_cfg function reflected?
Does the ID change with each build?
If the ID changes, will it affect Bluetooth connections?
In which subsequent process is the random_static_addr_cfg function reflected?
Does the ID change with each build?
If the ID changes, will it affect Bluetooth connections?
Hello,
What are you seeing? Does it change the address on every boot? Or is it the same from boot to boot?
If the ID changes, will it affect Bluetooth connections?
It shouldn't. If you are using bonding, it will exchange an IRK (Identity Resolving Key), so that the bonded device will be able to resolve the original address even if the address changes. If they do not bond, then the central will typically not depend on the address of the peripheral either way. It will look for some advertising name or an advertised UUID to decide whether or not to connect.
In the case where you use bonding, and you delete the entire flash of the nRF, then you need to delete the bonding information on the central as well, but this is independent of the address.
I hope this clears some of your questions. But if this was not what you were asking, please let me know.
Best regards,
Edvin
Please tell me function by function how the flow of connecting with CIS in the nRF5340 Audio source is done.
I am not familiar with Bluetooth LE Audio, unfortunately, but having a look at the nrf5340_audio application in the SDK, it depends on whether you are using the broadcast or the unicast application. I assume you are using the unicast, since you mentioned "the flow of connecting".
The way it works is quite similar to a normal BLE connection. In the unicast client/server samples that we have (ncs\nrf\applications\nrf5340_audio\unicast_server/client, the server will advertise with it's name, and the client will scan with a filter that looks for that specific name in it. When it finds a device with that specific name, it will connect to it. So this is all regardless of the BLE address.
Please check out the files:
bt_mgmt_scan.c
bt_mgmt_scan_for_conn.c
both found in ncs\nrf\applications\nrf5340_audio\src\bluetooth\bt_management\scanning.
That being said, the address will be different on every nRF device. It uses an address located in the FICR. From the top of my head, I can't remember whether it changes the address on every reset, but I think it doesn't that is only if it uses a resolvable address, in which case, a bonded device that has the IRK (Identity Resolving Key) will be able to tell that the seemingly random addresses all belong to the same device.
Best regards,
Edvin
I am not familiar with Bluetooth LE Audio, unfortunately, but having a look at the nrf5340_audio application in the SDK, it depends on whether you are using the broadcast or the unicast application. I assume you are using the unicast, since you mentioned "the flow of connecting".
The way it works is quite similar to a normal BLE connection. In the unicast client/server samples that we have (ncs\nrf\applications\nrf5340_audio\unicast_server/client, the server will advertise with it's name, and the client will scan with a filter that looks for that specific name in it. When it finds a device with that specific name, it will connect to it. So this is all regardless of the BLE address.
Please check out the files:
bt_mgmt_scan.c
bt_mgmt_scan_for_conn.c
both found in ncs\nrf\applications\nrf5340_audio\src\bluetooth\bt_management\scanning.
That being said, the address will be different on every nRF device. It uses an address located in the FICR. From the top of my head, I can't remember whether it changes the address on every reset, but I think it doesn't that is only if it uses a resolvable address, in which case, a bonded device that has the IRK (Identity Resolving Key) will be able to tell that the seemingly random addresses all belong to the same device.
Best regards,
Edvin
