RE: Problems with Discovery all the services, including custum UUID

endnode — Mon, 22 May 2017 09:31:24 GMT

Hi David,

In fact there are only 16-byte (128-bit) UUIDs in BLE, there is just agreement that for "standard" (= listed at BT SIG) UUIDs the "base" is well-known (you can find it in BT SIG Core document) and so it can be shortened to 2 bytes (16 bits). Now Nordic stack (Soft Device) works the same way for all UUIDs on GATT layer: whatever is exchange over radio link it appears as 2-byte "short" UUID (3rd and 4th byte which means bytes 12 and 13 in zero-indexed array of bytes with little endian encoding) and reference to base UUID in the Soft Device (G)ATT table. By default there is of course only BT SIG base UUID listed, all the rest must be provisioned by application (= you). Now to the practical things, how to do actual Service Discovery:

You always want to know your target 16-byte UUIDs at compile time (or at FW boot before SD init). Then you can provision them into the stack and you will be always getting 16-bite (2-byte) UUID + reference to 16-byte base in GATT event callbacks so you can always do what you want.
If for whatever reason you don't know these then you need to use workaround explained by me in the first referenced question&answer: read the GATT handle of Service/Characteristic and you will get 16-bytes of full UUID a response. Then you can act immediately and optionally you can provision it to the SD so next time you will get proper short UUID + reference to known ("registered") base. Just remember that if you don't know how many such proprietary bases you meet during FW runtime then you cannot scale the table during SD init and so you should not provision everything to the SD through sd_ble_uuid_vs_add because you will run out of memory (= SD will return error result code).
The best way to see if you are doing proper Service Discovery sequence you should get BLE trace and look into the commands on ATT/GATT layer. If you go through all the handles you want then your logic is probably correct. If not then you can easily spot the bug. The UART debug print-out you paste here is not enough (if you don't want to look into RF traces then you need to print much more, e.g. what handle ranges and SD call you do and what is in event data upon callback from each step).

Cheers Jan