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]

Hi Jan

Thanks so much for the detailed response. You definitely shed some light on steps that I might have been doing, but not fully understood. Thanks for that.

I think that my original question does not quite relay my issue correctly (or maybe it does, but I just don't understand it yet). I don't (think) that I have an issue with the 128 bit uuid as such. I do already register my uuid using sd_ble_uuid_vs_add(). I will break up my issue with the following steps that I follow:

• ble_stack_init() => All good
• err_code = sd_ble_uuid_vs_add(&base_uuid, &uuid_sd_type ); // => SUCCESS

• Scan and connect to peripheral

• err_code = sd_ble_gattc_primary_services_discover(conn_handle, 0x0001, NULL); // => SUCCESS

Now this is where it gets confusing. According to the softdevice manual, I should only be getting BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event, yet, I am getting 3 different events:

• EVT RX: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP => svc_count = 2; - SVC Handles: 0x1-0x4 - type:1 - uuid:0x1801 - SVC Handles: 0x5-0xb - type:1 - uuid:0x1800
• EVT RX: BLE_GATTC_EVT_CHAR_DISC_RSP disc cnt=1: 0x2a05 - handle 0x3
• EVT RX: BLE_GATTC_EVT_CHAR_DISC_RSP disc cnt=0: 0x2a05 - handle 0x3
• EVT RX: BLE_GATTC_EVT_DESC_DISC_RSP disc cnt=1: 0x2902 - handle 0x4
• EVT RX: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP: Count 0x0

According to what I have read, after issuing the sd_ble_gattc_primary_services_discover() api call, I will receive BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event. If the count is more than 0, there are more services to read and I need to do another call. If count=0, then there are no more services to read. Simple enough, except that I receive all of the above events with a single API call, ending with another BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event, but with count=0.

This does not line up with the softdevice manual at all and I don't understand why:

1. I'm getting the additional events
2. why I get the second BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event saying there are no more services, yet there are more events (btw, I get the exact same response sequence when I start reading from a handle that is a 128bit service)

Please help

[endnode]

I guess your problem is with understanding of cnt (count) param: that's saying how many "objects" (Services/Characteristics/whatever you were looking for) were found. But if that's all or if there are more is said in start/end handle parameters. You need to go through each "object" and "reconstruct" handle space which is 1-65,535. You always issue that command on top of some range and until all objects reach the end you need to be issuing new commands with modified start parameter. Typical service discovery algorithm could look like this:

1. Discover Primary Services on range 0x0001 - 0xFFFF => you get response with at least one Pirm Service object and handle range.
2. Go through the response and verify that Primary Services are making "continuum". If so then simply go back to the point one but start handle is now last Prim Service end handle + 1. Continue until...

[endnode]

... you find what you were looking for or until you reach end of range 0xFFFF (there typically is end of continuous handle space occupied by Primary Services - BT SIG specification requires GATT handles to be continuous at the beginning of the range! - and afterwards when you try to discover services on range 0xXYZ - 0xFFFF you get error (not found) which means that there are no more.

For Characteristics and other objects it's the same algorithm but only in sub-range of handles which belong to one Primary Service.

Note that this time-consuming and little bit boring procedure must be done only if you are not sure which UUID you are looking for (e.g. if there might be more Services with such UUID and you want to see all) or if you want/need to map whole GATT Server "stack" (= all services). Otherwise you can use GATT method looking for particular UUID and it responds with handle range.

[Tielman]

Ah, I see, so the object count is probably throwing me off (even though it does not make sense why it would sometimes end with a zero object event and sometimes not). I will give this a try while only looking at the returned handle range to keep reading until I get the 0xFFFF.

When am I then supposed to issue the next services_discover command? If I issue it immediately after the BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event, then it fails with a BUSY because the GATT is still busy receiving the other GATT events (that it is not supposed to be giving me according to the softdevice manual). When is the right time to issue it?

[endnode]

This is interesting question, I've never encountered BUSY response when using sd_ble_gattc_primary_services_discover call invoking corresponding GATT method over RF interface. I always get BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP event (you need to wait for that of course), analyze the response data and issue another command with modified parameters to move forward. I believe this flow chart shows it nicely, there should be no problem or confusion when implementing it.