Problems with Discovery all the services, including custum UUID

[DavidC]

Hello Community

I have read the following threads:

 devzone.nordicsemi.com/.../
 devzone.nordicsemi.com/.../

In order to know how to discover my services, including the 128 bit UUID base, but I can only find 3 of 5 of them. Also I am using the sd_ble_uuid_vs_add() and the error == NRF_SUCCESS

The Services that I should see are the followin: Device Information :180A Generic Access :1800 Generic Attribute :1801 Battery Service :180F Custom Service : [128 bit UUID] ble_uuid128_t quatServ128uuidd= { {0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} };

I just found 4 of them and the last one, I dont know which serivice is it. My code is the next one:

int16_t start_handle = 0x0001;
ble_uuid_t srvc_uuid =
{
	.type = BLE_UUID_TYPE_UNKNOWN,
	.uuid = 0x18A0 // Here should go my 16-Bit UUID but I dont know which uuid is. 
};
NRF_LOG_INFO("Discovering primary services.\n");

err_code = sd_ble_uuid_vs_add(&quatServ128uuidd, &srvc_uuid.type);

if (err_code != NRF_SUCCESS)
{
    NRF_LOG_INFO("Failed to add the vendor-specific Quaternions service.\n");
    return 4002;
}


// Find the Quaternios service. Calls back to on_service_discovery_response() via ble_evt_dispatch().
err_code = sd_ble_gattc_primary_services_discover(m_conn_handle, start_handle, NULL);

when I read the threads, I found they use a ble_uuid_t ,for the custom service, in order to find they custom service, but this one has a 16 bit-uuid base and I dont know which is the 16 uuid of my service only the 128 form. Also it says when the add the 128 uuid, the output of sd_ble_uuid_vs_add is in the variable .type, and this make me confuse.

Someone can explain me how to find my 16-uuid and find also what is the FB07 Service. When I do discovery char using that service, the start handle and end handle are the following : start handle: 0x805F, end handle: 0x0000 I cheked it out from my list of handle that I used on my peripheral device, and i dont find any handle like that.

I am using a SD 132, PCA10040

Regards,

David Caraveo

[endnode]

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