NCS multiple connection and save bond information

[Chaoyue Ying]

If there have a peripheral sample support for multiple central?

How NCS realize saving bonding information and distinguish different devices that bond with my board?

Whether NCS have a manager method like peer_id and I can get conn_handle by it?

I want to create a application that support multiple phones connect with.

At mean while,the application need to support pairing and bonding.Besides,I need a method like peer_id to manage.

I don't know the method need realized by myself or it already exit in NCS.

[Einar Thorsrud]

Hi,

If there have a peripheral sample support for multiple central?

There are samples that support being bonded to multiple device (that is just a matter of settng CONFIG_BT_MAX_PAIRED to a high enough number for your requierments. I am not aware of a sammple that demonstrate multiple simultanious connections in the peripheral role. It is possible, though.

How NCS realize saving bonding information and distinguish different devices that bond with my board?

Bonds are stored in the internal flash with the settings page. You can iterate through bonds using bt_foreach_bond(), this gives you the address of the bond which is how you refer to it.

Whether NCS have a manager method like peer_id and I can get conn_handle by it?

No, it is a bit different. You iterate through the list and identify the peer by address.

[Chaoyue Ying]

Hi,

Does it mean that when application support bonded to mutiple device,it will use address to do any things like send data by gatt and so on?

And by this way,peripheral how to identify mobile phone?Because my application with nRF SDK17 get the mobile phone address is a variational random address.Therefore I used peer_id to identify everyone phone that connect with my application that developed with nRF SDK17.

[Einar Thorsrud]

Hi,

Chaoyue Ying said:

Does it mean that when application support bonded to mutiple device,it will use address to do any things like send data by gatt and so on?

No, for any connection related events of APIs you have the connection object (bt_conn) which you use. This is similar to the conn_handle in the nRF5 SD

Chaoyue Ying said:

And by this way,peripheral how to identify mobile phone?Because my application with nRF SDK17 get the mobile phone address is a variational random address.Therefore I used peer_id to identify everyone phone that connect with my application that developed with nRF SDK17.

This is handled automatically by the Bluetooth stack. If the device device use privacy and the IRK was shared during bonding (which is normal and a requierment in ordre to resolve it), the stack will resolve the random resolvable addresses automatically. Unlike in the nRF5 SDK and SoftDevice, this is not visible outside of the stack.

[Chaoyue Ying]

Hi, 你好,

I still can not understand how the address to use in application with NCS.我仍然不能理解如何在NCS应用程序中使用地址。

To be specific,when I using nRF5 SDK, I will get peer_id by pm_peer_id_get() and check a whether device is a special user.The special list is saved in flash by FDS so that don't be afraid to lose power.

But if NCS application still get a random resolvable address from connected phone,that means every connection with a same phone have different address.

So that every time reget power,application will restart and the special flag of the connection will lose and maybe never recover.

So I need to know if something or some way that can deal with it.

具体来说，当我使用nRF5 SDK时，我将通过pm_peer_id_get()获取peer_id，并检查设备是否为特殊设备

[Einar Thorsrud]

Hi,

If you bond with the device, the BLE stack will do the identity resolution so you can use the address as a handle to the bonded device even though that is not the address that is currently used by the device (as it changes regularily based on it's IRK). The result is that the address that is used in pairing/bonding related Zephyr API's serve the same purpose as the peer ID in the nRF5 SDK, and you can use it the same way.

[Chaoyue Ying]

Hi，

I know how it work by you explain.But it still a question of the detail to operation.

In my understanding,I can save the address that using now and it can be used in next time that the connection have been established.

But there should be some functions to change or resolute because it will return false that compare the two address directly.

If it as I said above,which functions need I used?

[Einar Thorsrud]

After bonding (when the IRK) is exchanged, the API's will always give you the same address even if the random resolvable address on air changes. (There are helper functions you can use to check address type if needed, bt_addr_le_is_rpa(), andbt_addr_le_is_identity()).

You can see this if you experiment with an example that log the addresses, like the Bluetooth peripheral UART sample. This address you can save and it will always be a "handle" to that devices (until the bond is deleted). I suggest you experiment a bit with that to see, as there are no other APIs for this but it is also not needed, but it may be unfamiliar as it is handled differently here than in the old nRF5 SDK.

[Chaoyue Ying]

Hi,

I test about address and find as follow.

If it mean that board connect with bonded device using the public address so that I can realize whether a device bonded by the address type?If it is random,it mean the device is new bonding?

[Einar Thorsrud]

Hi,

Chaoyue Ying said:

If it mean that board connect with bonded device using the public address so that I can realize whether a device bonded by the address type?

Not per se. But the Bluteooth host will resolve the address basedon the IRK that was transfered during bonding and the random resolvlable address that is used when connecting. And from that will know which peer device it is, and always use the public address for the APIs. You can see this if you wait and re-connect with the phone that the public address you see on the nRF for that device will be the same. And if you use a sniffer you will see that the adress used on air is the random resolvable address.

Chaoyue Ying said:

If it is random,it mean the device is new bonding?

Not nesesarily. It could be that the peer always us a non-resolvable random address, for instance. There is no specific API for thecking if a bond exists (though it has been discussed).  But it is possible to iterate through all bonds with bt_foreach_bond().