SDK15 paring problem

Question

Hi nordic, 
 
 I am using SDK15.0 (NRF52840) to design a watch producation which needs pairing. I have a problem that if NRF52840 (peripheral ) has been paired with a smartphone (central), and then I remove the bonded deivce on smartphone side and try to connect the NRF52840 device which bond is removed, the smartphone will be rejected to pair (both android and iphone). As I know, the SDK11.0 has no same problem. If we do the samething between NRF52832 (SDK11.0) and smartphone, when reconnect, the users just need to repair them with no problem. 
 And If I remove the bonds on NRF52840 side (use function delete_bonds()), then the smartphone will successfully repair the NRF52840. 
 
 So I have the following questions: 
 1 Whether can I implement the same experience as SDK11.0 about the above problem? 
 2 What is the main difference of bond manager between SDK11.0 and SDK15.0 function? 
 3 I can define the maximum bonds can be stored in SDK11.0, but SDK15.0 seems to have no same feature. Then what is the purpose of the new (SDK15) design? 
 
 If any wrong understanding, please kindly correct me. 
 
 Thanks.

Einar Thorsrud · Accepted Answer

Hi, 
 1. A bond is typically about 38 words (152 bytes), but it can be a bit higher with multiple CCCDs. 
 2. The Peer manager will replace the existing bond in this case. 
 3. The application will get a PM_EVT_STORAGE_FULL event from the peer manager if it is unable to store a bond due to full FDS. The examples will do a FDS garbage collection at that point, but it will only free space if some data has already been marked as deleted. You can free more space by deleting the oldest peer first. (Generally managing bonds is up to the application, but the peer manager provides the necessary tools with API functions like pm_peer_count() , pm_peer_ranks_get() , pm_peer_delete() etc.) 
 4. Yes, you can delete a specific bond as you suggest. However, there are no API for searching for peers with a specific BT address or similar. You could implement that yourself though (but I fail to see the typical use case for such a feature). Typically you would want to delete the oldest peer (longest time since it was connected) if you run out of storage for bonding information. This is handled by ranking peers by when they were last seen, as is done in the SDK examples.

Einar Thorsrud · Answer

Hi Wang, 
 The Peer manager in SDK 15 does not allow re-pairing by default. This means that it will reject a pairing request from an already bonded peer, which is what you are seeing. 
 1. You can allow repairing by setting allow_repairing to true in the pm_conn_sec_config_t that you pass to pm_conn_sec_config_reply in the handling of the PM_EVT_CONN_SEC_CONFIG_REQ event. For instance like this (Modified from rom the ble_app_hrs example in SDK 15.0): 
 case PM_EVT_CONN_SEC_CONFIG_REQ:
 {
 // Reject pairing request from an already bonded peer.
 pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
 pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
 } break; 
 2. The bond manager and peer manager are different in many ways (totally different libraries, though both handle paring and bonding). The relevant difference in this case is that the examples in SDK 15 don't allow re-pairing by default in order to be more secure, but this can be changed by the application developer if needed (as above) if user friendliness is more important than security (which it often is in practice). 
 3. The Peer manager does not have a fixed maximum number of bonds. However, it will be limited by the available space in FDS (flash), which you can configure by setting FDS_VIRTUAL_PAGES in sdk_config.h . You can achieve a fixed number if you like by checking the number of peer using pm_peer_count() every time a new bond is made, and delete the oldest pair if the number is higher than the limit you would like. 
 Best regards, 
 Einar

SDK15 paring problem

Top Replies

core_v2_widget.Hide()