Discovery of 128bit UUID services confusing

[Tielman]

Hi

I am using sd_ble_gattc_primary_services_discover(conn_handle,0x0001,NULL) to discover primary services on a GATT server. After the first call to this function, I get 2 BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP, BLE_GATTC_EVT_CHAR_DISC_RSP and BLE_GATTC_EVT_DESC_DISC_RSP events:

1. BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP with service count = 2, with 2 Standard BLE services listed and all handles linked
2. BLE_GATTC_EVT_CHAR_DISC_RSP and BLE_GATTC_EVT_DESC_DISC_RSP events
3. BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP with service count = 0 (I guess this means discovery is complete)

I know there are more 128 bit services, but why am I receiving the 2nd event with service count = 0. This tells my code that there are no more services, right? If I do another call to sd_ble_gattc_primary_services_discover(conn_handle,0x000c,NULL), but with the start handle set to the handle of the first 128 bit uuid in the list, it correctly returns with the BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP response and some service info, but just the single event with its corresponding CHAR and DESC events...no second event with "service count = 0". So the first time I call it the response is different to the second time I call it.

So, why am I receiving the second event on the first api call, but not on any other there after?

I'm using the following

• IC: nRF52840
• Softdevice: S140 SDK: nRF5_SDK_13.0.0_04a0bfd
• Example as base: ble_app_hrs_c
• IDE: Eclipse + GCC

Thanks

[endnode]

Hi Tielman,

As David suggested Nordic Soft Device work on (G)ATT layer with UUIDs represented as 128-bit base + 16-bit "short" UUID. All base UUIDs are listed in "virtual" table inside SD and instead of values APP can only get base UUID "index" + short UUID whenever it uses GATT API. By default when SD is initialized after boot it knows only one base UUID = BT SIG default 128-bit UUID (that's quite logical). All other UUIDs will be referred as "UNKNOWN" base + short value. Now you have four options how to handle this:

• You don't care about base because you work only with UUIDs defined by BT SIG in their 16-bit space.
• You work with any proprietary UUIDs so you will scale ATT table size during SD init properly and you provision all 128-bit bases right after it before starting to work with GATT API (note that you need to keep some internal base UUID table or system in your APP because since then SD returns only indexes and it's up to the APP to link them to real UUIDs).
• You work with proprietary UUIDs but you cannot or don't want to provision all the bases during SD init. Then you can simply wait until you discover some handle with UUID referred by SD as "UNKNOWN" base, read the Characteristic's UUID handle "manually" and use response value (128-bit UUID) as base to provision SD for later use (so now it will get some specific index).
• Alternatively to previous point you can simply live with the fact that all proprietary UUIDs will be referred to "UNKNOWN" base and you need to verify full UUID by one (G)ATT Read method round-trip.

Btw. this thread has some source code examples (also with pretty old SD but I guess it still helps).

Cheers Jan

[Tielman]

This is the response when doing another service request immediately after receiving the first response:

• TESTER:DEBUG:SVC DISCOVERY TO CONN 0x0 from handle 0x1
• TESTER:DEBUG:SVC DISCOVERY START SUCCESS.
• TESTER:INFO:BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP: Count 0x2
• TESTER:INFO:=>Svc SVC Handles: 0x1-0x4 - type:1 - uuid:0x1801
• TESTER:INFO:=>Svc SVC Handles: 0x5-0xb - type:1 - uuid:0x1800
• TESTER:DEBUG:SVC DISCOVERY TO CONN 0x0 from handle 0xc
• TESTER:DEBUG:RESPONSE: Busy.
• TESTER:INFO:BLE_GATTC_EVT_CHAR_DISC_RSP disc 1: 0x2a05 - handle 0x3
• TESTER:INFO:BLE_GATTC_EVT_CHAR_DISC_RSP disc 0: 0x2a05 - handle 0x3
• TESTER:INFO:BLE_GATTC_EVT_DESC_DISC_RSP disc 1: 0x2902 - handle 0x4
• TESTER:INFO:BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP: Count 0x0