BLE GATTC questions

[natersoz]

2 Questions, both short:

1. Documentation error in Softdevice 15.x and 14.x header files:

/** @note If any of the discovered services have 128-bit UUIDs which are not present in the table provided to ble_vs_uuids_assign, a UUID structure with
 *       type @ref BLE_UUID_TYPE_UNKNOWN will be received in the corresponding event. 
 */

ble_vs_uuids_assign() does not exist anywhere in the softdevice headers nor in any of the examples/components code.

Based on reading other related Q&A posts this function should be ble_vs_uuid_add(). Is that correct?

2. And now for some real disappointment on my end:

a. It appears that a generic Service Discovery Protocol cannot be written against the softdevice. The UUIDs need to be known ahead of time and if they are not defined then client UUIDs can never be discovered via SDP. True or False?

b. If 2.a. above is True then it appears that this deficiency is purely derived from the attempt at keeping an internal database within the softdevice of all VS (vendor specific 128-bit) UUIDs. And that was motivated by wanting to conserve RAM through the use of 16-bit UUIDs wherever possible. True or False?

This works fine if you are writing a GATT Server (which I would guess is 99% of the use cases out there).

But if you are writing a generic GATT Client, this not only a real disappointment but gratuitously unnecessary. I can see no reason why the GATTC service discovery calls

sd_ble_gattc_primary_services_discover()
sd_ble_gattc_relationships_discover()
sd_ble_gattc_characteristics_discover()
... etc ...

Should not return full 128-bit UUIDs even for registered Bluetooth SIG services and characteristics. These are stack variables and need not be stored by the client in their full 128-bit form. Let the choice be that of the developer writing the softdevice client code.

Correct me where I am wrong.

Thanks. I will go lie down in deep depression.

[natersoz]

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,

[natersoz]

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,

[Torsten Robitzki]

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

[natersoz]

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

[Torsten Robitzki]

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