Concurrent services discovery

RE: Concurrent services discovery

Hung Bui — Thu, 11 May 2017 12:07:22 GMT

Yes, you can always skip the library and use sd_ble_gattc_primary_services_discover () and sd_ble_gattc_characteristics_discover () directly. I think if we break the ble_db_discovery code down we can see it will call exact the same calls. The benefit of using that module is when you want to discover multiple services, or when you discovering on multiple servers automatically. It's pretty handy I would say.

RE: Concurrent services discovery

endnode — Thu, 11 May 2017 11:35:14 GMT

Sorry, I've missed this possibility. But is there any added value in using ble_db_discovery module if application on top of GATT Client layer wants to discover single Characteristic Value handle within specific Primary Service? Assuming using sd_ble_gattc_primary_services_discover and sd_ble_gattc_characteristics_discover functions directly is the competitive option...

RE: Concurrent services discovery

Hung Bui — Thu, 11 May 2017 11:24:46 GMT

Hi Andrzej,

Most of the requirements you listed are already implemented in the ble_app_multilink_central example. There is no issue to have concurrent service discovery. When a service discovery of a node is finished, you will get an event: BLE_DB_DISCOVERY_COMPLETE with the conn_handle attached to the node. Please have a look at db_disc_handler() in the example.

@endnode: I don't think we always do full service discovery. If you only look for one service UUID, we will only do "Find by Type Value Request" to ask the server the location of the exact service. This is when you call sd_ble_gattc_primary_services_discover() with a specific service UUID. This is variant 2 in this MSC.

RE: Concurrent services discovery

endnode — Thu, 11 May 2017 07:12:34 GMT

Well what ble_db_discovery module does for you? Do you need it? Because doing GATT Service Discovery isn't any magic, especially if you are looking for particular Service UUID (= one handle) which can be done by one GATT method. Similar for objects inside the Service (Characteristics, Descriptors), you typically need to exchange one GATT Command/Response pair to "discover" it. So if you have just bunch of handle variables for each GAP/GATT Client connection link (actually you have similar for GATT Server as well to be able to see which handle is used by client in particular Read/Write) then you can done the rest with few functions, not needing to use entire SDK module. Sure, if you are in hurry then you can rely on SDK, it should work in the end...

RE: Concurrent services discovery

Andrzej Kuros — Thu, 11 May 2017 06:23:33 GMT

"full DB module" - what do you mean? Is it about ble_db_discovery.c module supplied with nRF5 SDK 13 ? I don't want do enumerate all services just want to find those I can handle.

RE: Concurrent services discovery

endnode — Wed, 10 May 2017 11:33:36 GMT

I would personally avoid using full DB module because you would need to build GATT "stack" image of every server you are connected to (whatever GAP role is used, (G)ATT server/client should be "instance per connection" according to BT SIG spec - logically;) and normally you don't want to do that silly thing mobiles (or any "multi-app" rich-OS running thing today) do = general GATT Service Discovery procedure of enumerating all GATT handles regardless you are typically looking for particular Primary Service UUID etc. GATT Service Discovery procedure from Client side is surprisingly not so difficult thing, there are examples in SDK and on this forum... but if you build some generic device without clear understanding of APP/GATT layer at the compilation time then you probably need to stick with DB module (or invest in rewriting it to be smaller/faster if you care, thanks to knowing more about your specific use cases should help).