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.
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?
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:
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.
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].
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.
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.
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?