This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE GATTC questions

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.

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

     

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

     

Children
Related