This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Concurrent services discovery

I am using S132 4.0.2 and SDK 13, and I have theese questions:

  1. I have an application where BLE node establishes multiple concurrent connections (several as central and several as peripheral). They will start db discovery on each other regardless of GAP role in connections. So peripheral will discover central services and central will concurrently discover peripheral services. Will it work? I it even a good idea?

  2. As my BLE node can be connected to many other peers db discovery can be started concurrently on each connection. I have separate ble_db_discovery_t per connection. Will it work?

  3. How can I be notified that service disvovery process is finished (I have several services to discover)? There is lack of event 'db discovery process finished'. I can always count events and compare it to number of ble_db_discovery_evt_register calls but is there a better way?

What else should I know, the tutorial devzone.nordicsemi.com/.../ is good but a bit outdated.

  • 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).

  • "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.

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

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

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

Related