BLE Central - Discovering and reading custom 128-bit service UUID and different 128-bit characteristic

[PriyeshN]

Hi Nordic team,

My dev environment is as follows:

nrf52840 + s140 +SD6.0.0 + SDK15.0.0 + SES + nrf52840-DK

Here, nrf52840-DK is configured as BLE Central and my peripheral is a third party board with entirely different controller, architecture and stack.

My peripheral has a service with below UUID

Service UUID - fb349b5f-8000-0080-0010-000052fd0000

Characteristic UUID - e29819be-3b9f-24bc-3d45-2bf743ea48d8

So, they are completely different rather than differing just the 12-13 octet.

My concern is that after struggling a lot also, I'm not able to discover the service & characteristic on my central neither I'm able to read the value from characteristic. I went through the posts:

https://devzone.nordicsemi.com/f/nordic-q-a/44979/when-128bit-characteristic-uuid-is-different-form-128bit-service-uuid-how-to-discovery-it

https://devzone.nordicsemi.com/f/nordic-q-a/76515/how-to-read-value-if-service-128bit-uuid-is-completely-different-from-characteristics-128-bit-uuid

https://devzone.nordicsemi.com/f/nordic-q-a/36462/discovering-problem-for-different-128-bit-service-and-characteristic-uuid-as-a-central-device

are among the few posts. It seems likely that Nordic BLE stack does not support discovering and reading such UUID's, but I could not find this answer. Can someone from Nordic help me here, either stating that Nordic stack does not support this, or if we can do this, then how?

I have already added my service UUID and characteristic UUID to attribute table using sd_ble_uuid_vs_add() and also tried everything from multiple posts on similar topic.

Quick help on this is appreciated. 

Thanks

[Jared]

Hi,

Have you tried using two different UUID bases? I think that should work.

regards

Jared 

[PriyeshN]

Yes, I mean I do use two different UUID bases for getting them added to sd_ble_uuid_vs_add(). My init code looks something like this. Sorry for the dev style code, but that does means I have tried a lot  

ret_code_t ble_oes_init(ble_oes_t * p_ble_oes, const ble_oes_init_t * p_ble_oes_init)
{
    ret_code_t   err_code;
    ble_uuid_t ble_uuid;
    ble_uuid128_t base_uuid         = {BLE_ONITY_EVENT_SERVICE_COMPLETE_UUID_REV};//{BLE_ONITY_EVENT_SERVICE_COMPLETE_UUID}; BLE_ONITY_EVENT_SERVICE_COMPLETE_UUID_REV
    ble_uuid128_t char_base_uuid    = {BLE_OES_CHARACTERISTIC_UUID_REV};

    VERIFY_PARAM_NOT_NULL(p_ble_oes);
    VERIFY_PARAM_NOT_NULL(p_ble_oes_init);

    // Initialize service structure
    p_ble_oes->evt_handler                  = p_ble_oes_init->evt_handler;
    p_ble_oes->conn_handle                  = BLE_CONN_HANDLE_INVALID;
    p_ble_oes->handles.oes_handle           = BLE_GATT_HANDLE_INVALID;

    // Add custom Service UUID
    err_code =  sd_ble_uuid_vs_add(&base_uuid, &p_ble_oes->uuid_type);
    VERIFY_SUCCESS(err_code);
    
    // Add custom Service characteristic UUID
    err_code =  sd_ble_uuid_vs_add(&char_base_uuid, &p_ble_oes->char_uuid_type);
    VERIFY_SUCCESS(err_code);

    ble_uuid.type = p_ble_oes->uuid_type;
    ble_uuid.uuid = BLE_ONITY_EVENT_SERVICE_UUID;

    ble_oes_char_uuid.type = p_ble_oes->char_uuid_type;
    //ble_oes_char_uuid.uuid = 0xEA43;

    //return NRF_SUCCESS;
    APP_ERROR_CHECK(ble_db_discovery_evt_register(&ble_uuid));
    //APP_ERROR_CHECK(ble_db_discovery_evt_register(&ble_oes_char_uuid));
    return NRF_SUCCESS;
}

[PriyeshN]

I'm not even able to discover service with UUID 0xFD52, so I haven't reached stage of discovering characteristic. My concern lies in discovering primary service itself. Attached is the RTT log post connection:

<info> app: Connecting to target DC:A6:32:A9:77:D5
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> app: Connected to a previously bonded device.
<info> app: Connected to target
<debug> ble_db_disc: Starting discovery of service with UUID 0xFD52 on connection handle 0x0.
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<info> app: Data length for connection 0x0 updated to 251.
<info> app: Connection secured: role: 2, conn_handle: 0x0, procedure: 0.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<info> app: GATT ATT MTU on connection 0x0 changed to 247.
<debug> ble_db_disc: Starting discovery of service with UUID 0xFD52 on connection handle 0x0.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 517 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
<info> app: GATT ATT MTU on connection 0x0 changed to 247.
<debug> ble_db_disc: Service UUID 0xFD52 not found.
<debug> ble_db_disc: Starting discovery of service with UUID 0xFD51 on connection handle 0x0.
<debug> ble_db_disc: Service UUID 0xFD51 not found.

[Jared]

Hi,

Our NUS central example shows how you can setup a client that can discover a proprietary ble service. Try comparing your client code with that one and see if there is any distinct differences. How is the initialization of the service discovery done on the client side?

regards

Jared 

[PriyeshN]

Yes, actually my code is based from NUS Central example code with a mix from HRS central code (for peer manager library usage). 

DB Discovery init is same as in NUS Central code. And in my custome service Init, as you can see in code, I'm registering the UUID's I need to look for.

Few questions:

1) My peripheral is running on BLE ver 4.2 whereas I'm using nRF52840 with SDk v15. Does this cause any known compatibility issues?

2) How should I provide the base UUID (128-bit) and the 16-bit UUID for Discovery? Should the base UUID (128-bit) be in reversed order as seen in nRFConnect app, or should it not be?

3) The 16-Bit UUID provided for discovery, should it be 12-13 Octet of the base UUID as seen in nRFConnect app or should it be 12-13 Octet of the reversed 128-bit base UUID?

Maybe, answers to above can solve my concern

Thanks

[Jared]

1. No, not that I know of. 
2. It all depends on the third-party device, it should be stated somewhere in the documentation how UUID is sent. Most BLE products send with little-endian, meaning the LSB first. If you compare the ble_app_uart and ble_app_uart_c examples you'll see that the service UUID that the GATT client is looking for and the one that the GATT Server is providing is in the same order. The UUID however is sent in the reverse order, which the GATT client assumes and therefore looks for the UUID in the reverse order.
3. It should be of the non-reversed. But the nRF will look for the reversed when it's actually trying to discover the service.

 

[PriyeshN]

Hmm ok,

Anyway, good news is that now I'm able to discover the services. In the interest of forum members and someone coming with same issue later, here's what I did change:

on nRFConnect - I'm seeing the service and characteristic UUID as below (as mentioned in my query as well)

Service UUID - fb349b5f-8000-0080-0010-000052fd0000

Characteristic UUID - e29819be-3b9f-24bc-3d45-2bf743ea48d8

So, when calling sd_ble_uuid_vs_add() I'm providing the

base UUID as - {0x00, 0x00, 0xfd, 0x52, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0x80, 0x5f, 0x9b, 0x34, 0xfb} 

but when registering for discovery using sd_ble_uuid_vs_add() I'm providing the 16-Bit UUID as 

UUID for discovery - 0x9B5F

The same goes true for Characteristic as well, although, for characteristic, we need not give the discovery event

For me, this was quiet tricky as I had to discover two custom service UUIDs

UUID1 - fb349b5f-8000-0080-0010-000052fd0000

UUID2 - fb349b5f-8000-0080-0010-000051fd0000

The differentiating factor here is 0xfd52 and 0xfd51, so, till now I was concentrating on them as unique differentiator for discovering, but it's not the way it is. The discovery UUID should be the 12-13 octet of the base UUID being added in attribute table.

So, anyone coming to this post with some similar issue, I recommend trying out by reversing base service UUIDs and trying both sets of reversed and non reversed UUID for discovery. 

For my third party device, I could not find the documentation regarding how UUID is being sent, so permutation combination helped me.

Thanks Jared