Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 14:21:11 GMT

Jan, that's it! Even though I removed all references to db_discovery_start, the callback handler was still receiving the events from the stack via ble_db_discovery_on_ble_evt. I guess this triggered the CHAR and DESC reads automatically in the background!

Thanks so much!

RE: Discovery of 128bit UUID services confusing

endnode — Thu, 15 Jun 2017 14:15:22 GMT

It looks like there is immediately after finding 2 primary services attempt to search for characteristics. Are you sure there is no other sd_gattc_xxx function call in your code or in some module you use? Eg. ble_db_discovery ?

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 12:53:52 GMT

...but when I do the request after the LAST BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP, then it is SUCCESS and I get the next SET of events

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 12:52:54 GMT

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

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 12:45:04 GMT

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?

RE: Discovery of 128bit UUID services confusing

endnode — Thu, 15 Jun 2017 10:51:59 GMT

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.

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 10:45:23 GMT

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?

RE: Discovery of 128bit UUID services confusing

endnode — Thu, 15 Jun 2017 10:34:32 GMT

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

RE: Discovery of 128bit UUID services confusing

endnode — Thu, 15 Jun 2017 10:30:16 GMT

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:

Discover Primary Services on range 0x0001 - 0xFFFF => you get response with at least one Pirm Service object and handle range.
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...

RE: Discovery of 128bit UUID services confusing

Tielman — Thu, 15 Jun 2017 10:12:02 GMT

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:

I'm getting the additional events
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

RE: Discovery of 128bit UUID services confusing

endnode — Wed, 14 Jun 2017 21:09:07 GMT

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

RE: Discovery of 128bit UUID services confusing

DavidC — Wed, 14 Jun 2017 13:56:24 GMT

The BLE_UUID_TYPE_BLE is working fine for me, maybe this is thus the sensor has a Primary Service Declaration: Custom Service.

RE: Discovery of 128bit UUID services confusing

Tielman — Wed, 14 Jun 2017 13:45:11 GMT

Hi David

Thanks for the answer. I am, however, already adding my 128bit UUIDs successfully. I can confirm this by doing a service discover and then seeing that the type is defined as a VENDER_SPECIFIC uuid.

I edited my original post at the some moment you replied, so you might have missed some more detail.

In summary, the first time a call service discovery, it responds with the ble services, characteristics and descriptors (not only services), followed by a service response with count = 0. Forcefully triggering another discovery after that works fine and does return the 128bit services, chars & descriptors, but this time it DOES NOT respond with the additional service event (with count = 0)

PS. I noticed you declared your .type for your service as BLE_UUID_TYPE_BLE...should this not be BLE_UUID_TYPE_VENDOR_BEGIN for a 128bit UUID?

RE: Discovery of 128bit UUID services confusing

DavidC — Wed, 14 Jun 2017 13:35:23 GMT

Hi Tielman,

I had the same problem, you need to add the SoftDevice the 128bit UUID and then ill reconize it as a 32 bit uuidd,in order to solve use this

uint32_t err_code;

err_code = sd_ble_uuid_vs_add(&quatServ128uuidd, &quatServ.type);

if (err_code != NRF_SUCCESS)
{
    NRF_LOG_INFO("Failed to add the vendor-specific Quaternions service.\n");
    return 4002;
}

// Find the Quaternios service. Calls back to on_service_discovery_response() via ble_evt_dispatch().
err_code = sd_ble_gattc_primary_services_discover(m_conn_handle[counter_conn-1],start_handle, NULL);

where my uuids run as follow:

 /**@Brief 32-bit UUID from the Quaternios service*/
 static ble_uuid_t quatServ =
 {
   .uuid = 0x0000, // this number are the bit 12 and 13 from my 128-bit uuid
    .type = BLE_UUID_TYPE_BLE
  };

 /**@Brief 128-bit UUID Quaternios service */
  ble_uuid128_t  quatServ128uuidd= {
	      {0xfb, 0x34, 0x9b, 0x5f, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 
           0x00, 0x00, 0x00}
  };

Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

Scan and connect to peripheral

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing

RE: Discovery of 128bit UUID services confusing