• State Verified Answer
  • Replies 1 reply
  • Subscribers 71 subscribers
  • Views 1185 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114401
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Getting my head around BLE multi-central with S120

Sensors

I've been trying to get my head around using a BLE central and making connections so I've loaded up the multi-central example to figure out just how everything works. I turned on the App Trace Log to try to get a feel for what's happening behind the scenes, and this is what it produces when the device starts and a peripheral is connected.

[DM]: >> dm_init.
[DM]: Initializing Application Instance 0x00000000.
[DM]: Initializing Connection Instance 0x00000000.
[DM]: Initializing Connection Instance 0x00000001.
[DM]: Initializing Connection Instance 0x00000002.
[DM]: Initializing Connection Instance 0x00000003.
[DM]: Initializing Connection Instance 0x00000004.
[DM]: Initializing Connection Instance 0x00000005.
[DM]: Initializing Connection Instance 0x00000006.
[DM]: Initializing Connection Instance 0x00000007.
[DM]: Initializing Peer Instance 0x00000000.
[DM]: Initializing Peer Instance 0x00000001.
[DM]: Initializing Peer Instance 0x00000002.
[DM]: Initializing Peer Instance 0x00000003.
[DM]: Initializing Peer Instance 0x00000004.
[DM]: Initializing Peer Instance 0x00000005.
[DM]: Initializing Peer Instance 0x00000006.
[DM]: Initializing Peer Instance 0x00000007.
[DM]: Storage handle 0x0003F800.
[DM]:[0x00]: Block handle 0x0003F800.
[DM]:[DI 0x00]: Device type 0x01.
[DM]: Device Addr 0xB6 0xAF 0x51 0x4F 0xEE 0xD5.
[DM]:[0x01]: Block handle 0x0003F844.
[DM]:[DI 0x01]: Device type 0xFF.
[DM]: Device Addr 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM]:[0x02]: Block handle 0x0003F888.
[DM]:[DI 0x02]: Device type 0xFF.
[DM]: Device Addr 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM]:[0x03]: Block handle 0x0003F8CC.
[DM]:[DI 0x03]: Device type 0xFF.
[DM]: Device Addr 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM]:[0x04]: Block handle 0x0003F910.
[DM]:[DI 0x04]: Device FF.
[MAFF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM]:05]cx0003F954.
[DM]05] eFF.
[cFF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM]:06] l0003F998.
[DM] 06]tFF.
[D FF 0xFF 0xFF 0xFF 0xFF 0xFF.
[DM][07]h0003F9DC.
[DM]:07]ixFF.
MAFF 0xFF 0xFF 0xFF 0xFF 0xFF.
ble_evt: [DM]: Request to allocation connection instance
[DM]:[00]: Connection Instance Allocated.
[DM]: Searching for device 0xB6 0xAF 0x51 0x4F 0xEE 0xD5.
[DM]:[DI 0x00]: Device type 0x01.
[DM]: Device Addr 0xB6 0xAF 0x51 0x4F 0xEE 0xD5.
[DM]: Found device at instance 0x00
[DM]:[00]:[Block ID 0x0003F800]:Loading bond information at 20002ec0, size 0x0000001C, offset 0x00000018.
[DM]:[0x00]:[0xFF]: Bond context Event
[DM]: Notifying application of event 0x21
[APPL]:[0x00] >> DM_EVT_LINK_SECURED
[APPL]:[0x00] << DM_EVT_DEVICE_CONTEXT_LOADED
[DM]:[00]:Loading service context at 20002fa0, size 0x0000000C, offset 0x00000034.
[DM]: --> gattc_context_load
[DM]: Notifying application of event 0x11
[APPL]:[0x00] >> DM_EVT_CONNECTION
[APPL]:[B6 AF 51 4F EE D5]: Connection Established

[APPL]:[CI 0x00]: Requesting GATT client create
[DB]: Starting discovery of service with UUID 0x9001 for Connection handle 0
[APPL]:[0x00] << DM_EVT_CONNECTION
ble_evt: ble_evt: ble_evt: ble_evt: [DB]: Discovery of service with UUID 0x9001 completed with success for Connectionhandle 0
ble_evt: [DM]: >> dm_security_setup_req
[DM]: << dm_security_setup_req, 0x00000000
ble_evt: [DM]: >> BLE_GAP_EVT_CONN_SEC_UPDATE, Mode 0x01, Level 0x02
[DM]: --> gattc_context_apply
[DM]: Notifying application of event 0x15
[APPL]:[0x00] >> DM_LINK_SECURED_IND, result 0x00000000
[APPL]:[0x00] << DM_LINK_SECURED_IND

So I understand DM is the Device manager, DB is the database and APPL is just the app logging miscellaneous events. A lot of the finer deatils like the block handle and service context I'm clueless about.

But what are the roles of the Device Manager and Database?

Where is the connection information stored and how can it be accessed?

How are the connections maintained?

I found the documentation on the example, but it's more about the setup and test than the software.... Is there any more detailed explanation of this software example? For many examples all you get is code and very little explanation which unfortunately doesn't make for a great learning resource.

Parents
  • 0

    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:

    1. The identity of the device you connected to, either with address or IRK.

    2. 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.

Reply
  • 0

    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:

    1. The identity of the device you connected to, either with address or IRK.

    2. 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.

Children
No Data
Related
Terms of service