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