BLE_DB_DISCOVERY_MAX_SRV implications?

[nhalden]

Hello all -

I'm trying to learn about the db discovery module from the perspective of the BTLE central and I'm a little confused by the client architecture. The SDK documentation indicates client_a_init() and client_b_init() as if each one of those is for Service A and Service B. Is the application intended to have a client per service on the peer? What if we're writing a generic central and don't know what/how many services the peer will have?

I feel like I'm misunderstanding that because in the ble_app_hrs_c a single client is used to discover both the HRS and he BAS.

Could somebody please explain the limitations of that module and how it is intended to be used with peers that might have many services (10+ for example)?

Edit: bump.

Edit: tags

[Petter Myhre]

The database discovery module

I'll try to explain it, with the SDK documentation as a reference. There are a few inconsistencies between the flow chart and the code, but nothing critical.

I'll use ble_app_hrs_c as an example. HRS is service A and BAS is service B.

HRS is initiated from main.c (Application Main) with ble_hrs_c_init() (client_a_init). The return of ble_hrs_c_init() registers a database discovery event handler together with the HRS UUID, using ble_db_discovery_evt_register(&hrs_uuid, db_discover_evt_handler);.

Then BAS is initated from main.c with ble_bas_c_init() (client_b_init). The return of ble_bas_c_init() registers a database discovery event handler together with the BAS UUID, using ble_db_discovery_evt_register(&bas_uuid, db_discovery_evt_handler);.

So the ble_app_hrs_c actually uses two clients.

(NB. BLE_DB_DISCOVERY_MAX_SRV limits the number of clients, this is set to 2 in the example)

BLE_GAP_EVT_CONNECTED indicates that a peripheral has connected to the central, then ble_db_discovery_start() is called. ble_db_discovery_start() calls sd_ble_gattc_primary_services_discover() with the first registered UUID (the HRS UUID) as an argument.

The HRS is discovered followed by the heart rate characteristics and descriptors, then the BAS is discovered followed by the Battery characteristics and descriptors.

(NB. Only BLE_DB_DISCOVERY_MAX_CHAR_PER_SRV characteristics will be discovered, per service, this is set to 3 in the example)

When service discovery is complete, discovery_complete_evt_trigger() is called. This function collects the database discovery event handlers of the found UUIDs in m_pending_user_evts[], and then calls pending_user_evts_send();.

pending_user_evts_send(); triggers the db_discover_evt_handler in ble_hrs_c.c and then the db_discovery_evt_handler in ble_bas_c.c

The database discovery event handler finds the CCCD handle and sends the discovery complete event (BLE_HRS_C_EVT_DISCOVERY_COMPLETE) to the hrs_c_evt_handler in main.c.

The BLE_HRS_C_EVT_DISCOVERY_COMPLETE event enables notifications of the heart rate measurement characteristic by writing 0x01 to its CCCD.

Limitations

I believe the database discovery module is only limited by memory. It has two important parameters;

#define BLE_DB_DISCOVERY_MAX_SRV          2 
#define BLE_DB_DISCOVERY_MAX_CHAR_PER_SRV 3

As said above max services limit number of services or clients that can be registered to the module. Max characteristics per service limit the number of characteristics that is discovered per service.

What if we're writing a generic central and don't know what/how many services the peer will have?

I think writing a true generic central would be challening with or without the database discovery module. If you don't know what or how many services the peer will have, I don't see any other option than to write client modules for all possible services. You would run out of memory.

Edit 11.08.2015: Possible solution for a generic central.

It should be possible to increase the number of different services and I have it on good authority that increasing max services to 4 and increasing max characteristics per service to 3 should work, but it depends on how much memory the rest of your application requires.

You can also have multiple peripherals with the same service connected, like in the ble_app_multilink example. Then you would need some way to identify the different peripherals. It uses the connection handle.

Could somebody please explain the limitations of that module and how it is intended to be used with peers that might have many services (10+ for example)?

As I see it, it is only memory limitations, and it has less to do with the database discovery module, and more to do with how many client modules you can fit into memory. If you have a peripheral with 10 known services, I can't see any other option than to test and see if there is enough memory for 10 client modules, and 10 clients in the database discovery module.