RE: Getting my head around BLE multi-central with S120

Ulrich Myhre — Thu, 09 Jun 2016 17:00:39 GMT

Without diving too deep into the various modules, which I personally do not have the best insight of, I can offer you a general explanation of how the SoftDevice handle this.

When you connect to a peer, you are given an event that tells you:

The identity of the device you connected to, either with address or IRK.
The connection handle assigned to that connection.

To follow the Bluetooth Specification, you are required to remember a few things between connections for devices you are bonded to. These are things like encryption keys, identity resolving keys and the states of CCCDs (Client Characteristic Configuration Descriptors). So after connecting to a device, you need to look up in some internal database to figure out if this is a previously bonded device. If it is, you have to restore the CCCD states and make sure that you will be encrypting using the keys previously exchanged (instead of pairing anew). The Device Manager(/Peer Manager) module is responsible for these specific tasks. If you never bond with any device, you can safely remove this module. It is only example code, so you can also implement it yourself if you want something simpler.

Additionally, the security level of your connection defaults to "open" when connecting. If one of the links are encrypted, this is signaled through the BLE_GAP_CONN_SEC_UPDATE event. The DM module also keeps track of these things for you.

After connection, you usually want to do a discovery of the peer. Find the interesting services, enable notifications/indications, or read sensor values. This is usually done in steps, where you discover the services, then the characteristics within that service, and finally the descriptors of those characteristics. You are allowed to cache this information (if you're bonded), so luckily you do not have to do it a lot. But it's still quite hard to wrap your head around sometimes, which is why the [DB module](http://Client Characteristic Configuration Descriptors) is created to do this for you. It is not for creating your own DB, but to discover the peer DB.

So the answer to your question is that the connection information is given to you in the form of events, which you may pull at your own leisure. The event is bound to each connection by the use of connection handles, and you are required to remember what the events tell you - because there are few states you can actually extract after the fact.

A lot of this is covered in the SDS (PDF Warning), but knowing some Bluetooth basics are required to understand the various modules.