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]

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.

[Tielman]

Hi Jan

THat is so weird. Here is my direct log from calling sd_ble_gattc_primary_services_discover()only once:

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

This then seems seriously wrong and does not match the message sequece charts.

Have you got the means to try and recreate this using softdevice s140?