BLE GATTC questions

RE: BLE GATTC questions

natersoz — Fri, 15 Jan 2021 17:55:56 GMT

Yes, I would expect there to be an allocated 128-bit UUID during discovery. It would have to keep it around as well for the lifetime of the connection since it will have to match any associated updates to data with the UUID.

RE: BLE GATTC questions

Torsten Robitzki — Fri, 15 Jan 2021 16:15:35 GMT

Ah, ok. I'm currently with Version 16.x. The problem with the solution is, that it allocates resources (UUID slots) which one is not able to deallocate (`sd_ble_uuid_vs_remove´seems to be pretty useless).

RE: BLE GATTC questions

natersoz — Fri, 15 Jan 2021 16:00:34 GMT

I recall reading in a Nordic press release over the last year that they have fixed this issue.

Since I don't have to time play with the Nordic stuff these days, I did not dig into it.

But searching through the SDK, version 17.0.2 I found this:

Line 378 of file: nRF5_SDK_17.0.2_d674dde/components/softdevice/s132/headers/ble_gattc.h

/**@brief UUID discovery option.
*
* @details Used with @ref sd_ble_opt_set to enable and disable automatic insertion of discovered 128-bit UUIDs to the
*          Vendor Specific UUID table. Disabled by default.
*          - When disabled, if a procedure initiated by
*            @ref sd_ble_gattc_primary_services_discover,
*            @ref sd_ble_gattc_relationships_discover,
*            @ref sd_ble_gattc_characteristics_discover,
*            @ref sd_ble_gattc_descriptors_discover
*            finds a 128-bit UUID which was not added by @ref sd_ble_uuid_vs_add, @ref ble_uuid_t::type will be set
*            to @ref BLE_UUID_TYPE_UNKNOWN in the corresponding event.
*          - When enabled, all found 128-bit UUIDs will be automatically added. The application can use
*            @ref sd_ble_uuid_encode to retrieve the 128-bit UUID from @ref ble_uuid_t received in the corresponding
*            event. If the total number of Vendor Specific UUIDs exceeds the table capacity, @ref ble_uuid_t::type will
*            be set to @ref BLE_UUID_TYPE_UNKNOWN in the corresponding event.
*            See also @ref ble_common_cfg_vs_uuid_t, @ref sd_ble_uuid_vs_remove.
*
* @note @ref sd_ble_opt_get is not supported for this option.
*
* @retval ::NRF_SUCCESS Set successfully.
*
*/
typedef struct
{
uint8_t auto_add_vs_enable : 1;   /**< Set to 1 to enable (or 0 to disable) automatic insertion of discovered 128-bit UUIDs. */
} ble_gattc_opt_uuid_disc_t;

So my guess is that this can be done more efficiently than the solution that I referenced. Note what it says:

"The drawback of this solution is that there are exactly two more command-response GATT messages which makes Service Discovery longer by at least 4 connection intervals per unknown 128-bit UUID entries."

A small price to pay really. But here it looks like Nordic has solved the issue. I hope that this simple method works for you!

RE: BLE GATTC questions

Torsten Robitzki — Fri, 15 Jan 2021 09:35:52 GMT

Thanks! What a hassle ;-) I think this should also apply to characteristic discovery.

RE: BLE GATTC questions

natersoz — Fri, 15 Jan 2021 03:08:24 GMT

As a hobby project, which I have not had time for in the last year, I play with these Nordic boards.

Here is a link to the answer somewhere else in this Q/A forum:

https://devzone.nordicsemi.com/f/nordic-q-a/3656/s130-custom-uuid-service-discovery/13264#13264

Here is a link to my summary:
https://github.com/natersoz/nrf/blob/master/docs/nordic/NORDIC.md#nordic-softdevice-service-discovery

Nordic Softdevice Service Discovery

The softdevice does not provide a direct means for performing service discovery for 128-bit UUIDs. Based on the softdevice, the 128-bit UUIDs need to be defined ahead of time using sd_ble_uuid_vs_add().

There is a work-around which allows generic service discovery on the Nordic Softdevice:

If after calling sd_ble_gattc_primary_services_discover() response you resceive the response with the uuid type BLE_UUID_TYPE_UNKNOWN then you can get the full 128-bit UUID by issuing sd_ble_gattc_read() (raw GATTC READ command) on the very same handle.

The Response contains the full 128-bit Service UUID in the gattc_evt.params.read_rsp structure).

At this point call sd_ble_uuid_vs_add() call followed by repeated sd_ble_gattc_primary_services_discover() (on the same start handle) which will return the correct BLE_UUID_TYPE_VENDOR_BEGIN type and 16-bit short Service UUID in the response.

The drawback of this solution is that there are exactly two more command-response GATT messages which makes Service Discovery longer by at least 4 connection intervals per unknown 128-bit UUID entries.

Reference Link: https://devzone.nordicsemi.com/f/nordic-q-a/3656/s130-custom-uuid-service-discovery/13264#13264
FYI: Here is my implementation for the solution described:
github.com/.../nordic_ble_gattc_discovery_observable.cc

RE: BLE GATTC questions

Torsten Robitzki — Wed, 13 Jan 2021 19:06:38 GMT

Hi,

I've stumbled over the same "issue". The same problem arrises, when discovering services. And in that context, I've learned that `sd_ble_gattc_attr_info_discover()` might be used to retrieve the 128 bit UUID of a service (https://devzone.nordicsemi.com/f/nordic-q-a/37916/how-can-i-get-the-primary-service-uuid/146211#146211). The documentation of `sd_ble_gattc_attr_info_discover()`is a little vague, as it does not define, which (and if) GATT procedure is used (and which handle would have to be provided in case of a characteristic, the Characteristic Declaration, the Characteristic Value?). In theory, it should be possible to get the UUID by ATT read the Characteristic Declaration attribute, but the SD provides not access to the ATT layer (but, of cause the mapping for reads between ATT and GATT is pretty trivial).

So, I also would be interested, if there is a way to discover 128 bit UUID characteristics without knowing the UUID ahead.

natersoz have you solved that problem?

Susheel Nuguru Do you have an answer?

best regards,

Torsten

RE: BLE GATTC questions

natersoz — Mon, 14 Jan 2019 15:13:04 GMT

Can I get an definitive answer to this question:

Do 128-but UUIDs always need to be defined up front before then can be discovered?

Thanks,

RE: BLE GATTC questions

natersoz — Fri, 11 Jan 2019 03:17:20 GMT

Hi again, I figured out what the problem was: I was not fully iterating through all the service discover responses. The first response contained the SIG UUIDs 1800, 1801, and 180f. I had to request more discovery packets to get to the rest of the services.

But I still would like an answer to the original question.

Thanks,

RE: BLE GATTC questions

natersoz — Thu, 10 Jan 2019 14:10:55 GMT

Yes - I will do that. It will take me a day to extract it as a minimal code chunk.

What about the question at the top: 2.a.? Do 128-bit UUIDs need to be known ahead of time?

RE: BLE GATTC questions

Susheel Nuguru — Thu, 10 Jan 2019 07:42:36 GMT

Hi Nathaniel, Sorry for the late reply

1) About the documentation, you seems to be right, thank you for the feedback, I will inform the doc writer to fix it.

2) Can you attach the code snippet(file) where you added the service to the gatt server. I will then try to see from the gatt client, why it is not able to discover it by doing a quick test run.

RE: BLE GATTC questions

natersoz — Mon, 07 Jan 2019 06:13:20 GMT

OK - changed the client so that uuid bytes [14:15] are zero. The service UUID is now:

0.009 info: sd_ble_uuid_vs_add(00000000-0001-494c-86c6-052628e7d83f): 0, uuid_type = 2

and is added to the client successfully. Server changed as well and is discoverable by other applications. However, still no discovery of that service.

RE: BLE GATTC questions

natersoz — Mon, 07 Jan 2019 05:12:16 GMT

You know what I just realized? I'm using all 32-bits of UUID bytes [12:15] and it looks like bytes [14:15] are dead as far as Nordic is concerned. I need to confine my custom UUIDs to not used bytes [14:15].

RE: BLE GATTC questions

natersoz — Mon, 07 Jan 2019 01:34:00 GMT

Well, from what I am attempting, calling sd_ble_vs_add() does not seem to allow the known 128-bit UUID to be discovered.

All of the GATT Services with 16-bit values are correctly discovered.

I'm calling sd_ble_gattc_services_discovery(0x0000, 0x0001, NULL); // the connection handle = 0

The response returns a count of 3, all of which are expected (my log output from parsing the service discovery response event):

     0.562 info: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP: count: 3
     0.562 info: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP[0x0001, 0x0009]: 00001800-0000-0010-0080-00805f9834fb
     0.563 info: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP[0x000a, 0x000a]: 00001801-0000-0010-0080-00805f9834fb
     0.564 info: BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP[0x000b, 0x0011]: 0000180f-0000-0010-0080-00805f9834fb

GAP service 0x1800, GATT service 0x1801, Battery Service 0x180F,

But no sign of my 128-bit service 00010000-bb9b-494c-86c6-052628e7d83f, which is found by this other tool and can be manipulated by its read/write/notifications. Screen shot below. Note the Primary Service UUID bytes are reversed by this tool. The GATT service is there. Just not found in my softdevice service discovery.

BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

Nordic Softdevice Service Discovery

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions

RE: BLE GATTC questions