[51822][S110] How to understand device_manager

Question

Hello, 
 When I learned the demo of 51822, I mentioned that device_manager is a core module to automatically save connection related info. But it's too huge to understand it for me now. 
 I think it's not only because the size of code, but also because of my lackage of some BLE protocol. Especially lackage for pairing / bonding detailed knowledge. 
 Anyone can give me advice how to learn, or some resoure? 
 Thanks,
Tao

Petter Myhre · Accepted Answer

The source code of the device manager was not written with a purpose of teaching users about pairing and bonding. So I wouldn't really recommend studying it to understand pairing and bonding. I would either use at it as a black box, use the API in a similar way it is used in the examples in our SDK, or use it as a starting point/alternative for handling pairing and bonding, and for storing bonding information persistently in flash (after you have understood pairing and bonding). 
 If you want to learn more about pairing and bonding I would recommend studying the relevant sections in the Bluetooth Core specification and/or buy a book about BLE, and then study the relevant API functions that the SoftDevice provides. Try to for example get Just Works pairing to work first in an example that doesn't include the device manager, for example ble_app_uart. If you get stuck at some point, or you have specific questions about anything, please post them here. 
 One thing that I find very helpful is the MSCs included in the SDK documentation. Here you can find the most relevant to pairing and bonding. For example this for Just Works pairing. 
 So to pair as a peripheral you need to get a pairing request from the central device. With S120 you can send this at any time you want, a smart phone usually sends it if tries to read or write an attribute value that requires encryption to be read or written. When the SoftDevice receives a pairing request it will send the BLE_GAP_EVT_SEC_PARAMS_REQUEST event to the application. So add a case for it somewhere in ble_evt_dispatch(). When this event is received fill a ble_gap_sec_params_t struct and reply with sd_ble_gap_sec_params_reply(). ble_gap_sec_keyset_t is not relevant for pairing, only bonding. If you fill the ble_gap_sec_params_t correctly, pairing should work fine. 
 Another thing I would recommend is to use a sniffer, for example the nRF Sniffer, to study what is actually happening on the air, what packets are exchanged, and what the content of these packets are.