how to discover 16bit uuid?

[roger.k]

Hi. i'm using nRF52832, SDK13.0.0. I'm developing Central, Peripheral both.

If peripheral just has 16bit UUID. It doesn't contain base UUID. Or if i don't know what peripheral's UUID is, how can I discover it?

My central source code has to know 128bit UUID as below.

{ ...... ble_uuid128_t lbs_base_uuid = {??????? --> how can I define????};

VERIFY_PARAM_NOT_NULL(p_ble_lbs_c);
VERIFY_PARAM_NOT_NULL(p_ble_lbs_c_init);
VERIFY_PARAM_NOT_NULL(p_ble_lbs_c_init->evt_handler);

p_ble_lbs_c->peer_lbs_db.button_cccd_handle = BLE_GATT_HANDLE_INVALID;
p_ble_lbs_c->peer_lbs_db.button_handle      = BLE_GATT_HANDLE_INVALID;
p_ble_lbs_c->peer_lbs_db.led_handle         = BLE_GATT_HANDLE_INVALID;
p_ble_lbs_c->conn_handle                    = BLE_CONN_HANDLE_INVALID;
p_ble_lbs_c->evt_handler                    = p_ble_lbs_c_init->evt_handler;

err_code = sd_ble_uuid_vs_add(&lbs_base_uuid, &p_ble_lbs_c->uuid_type);
if (err_code != NRF_SUCCESS)
{
    return err_code;
}
VERIFY_SUCCESS(err_code);

......

}

How can I discover UUID which i don't know or just 16bits?

I need your help.

[endnode]

That's incorrect. All UUIDs are in fact 128-bit long and that's why Nordic represents them always as pair of 128-bit base and 16-bit short UUID. In case that GATT Server presents just 16-bit short UUID that just means that 128-bit base is standard BT SIG base UUID as defined in the spec and hardcoded (as the only one base!) in Nordic BLE stack. So whenever you work with "just short 16-bit UUIDs" (aka standardized BT SIG UUIDs) in Nordic SD GATT API you should use BLE_UUID_TYPE_BLE as reference to 128-bit base index in virtual table of UUID bases (which are provisioned in SD).

UPDATE #1 (2017-11-17)

Why? Because it's in the code! Someone wrote it there. If not you then Nordic. Why? It doesn't matter, it's there! Do you like it? If yes then write your client accordingly! If not then do following little change on GATT Server side (according to code you posted earlier):

uint32_t ble_dfu_init(ble_dfu_t * p_dfu)
{
    ble_uuid_t service_uuid;
    uint32_t   err_code;

#ifndef NRF51
    if (p_dfu == NULL)
    {
        return NRF_ERROR_NULL;
    }
#endif

    m_conn_handle = BLE_CONN_HANDLE_INVALID;

    const ble_uuid128_t base_uuid128 =
    {
        {
            0x50, 0xEA, 0xDA, 0x30, 0x88, 0x83, 0xB8, 0x9F,
            0x60, 0x4F, 0x15, 0xF3,  0x00, 0x00, 0xC9, 0x8E
        }
    };
    err_code = sd_ble_uuid_vs_add(&base_uuid128, &p_dfu->uuid_type);
    VERIFY_SUCCESS(err_code);

    service_uuid.uuid = BLE_DFU_SERVICE_UUID;
    service_uuid.type = p_dfu->uuid_type;

    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &service_uuid,
                                        &(p_dfu->service_handle));
    VERIFY_SUCCESS(err_code);

    // ...

[roger.k]

Thank you very much for your reply. How about bootloader for DFU? As I discover it using PC program, It just has 0xfe59. It doesn't have base uuid. But 2 characteristcs have base UUID. What could be the problem? My bootloader's init code is below.

uint32_t ble_dfu_init(ble_dfu_t * p_dfu)
{
    ble_uuid_t service_uuid;
    uint32_t   err_code;

#ifndef NRF51
    if (p_dfu == NULL)
    {
        return NRF_ERROR_NULL;
    }
#endif

    m_conn_handle = BLE_CONN_HANDLE_INVALID;

    BLE_UUID_BLE_ASSIGN(service_uuid, BLE_DFU_SERVICE_UUID);

    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &service_uuid,
                                        &(p_dfu->service_handle));
    VERIFY_SUCCESS(err_code);

    const ble_uuid128_t base_uuid128 =
    {
        {
            0x50, 0xEA, 0xDA, 0x30, 0x88, 0x83, 0xB8, 0x9F,
            0x60, 0x4F, 0x15, 0xF3,  0x00, 0x00, 0xC9, 0x8E
        }
    };
    err_code = sd_ble_uuid_vs_add(&base_uuid128, &p_dfu->uuid_type);
    VERIFY_SUCCESS(err_code);

    err_code = dfu_pkt_char_add(p_dfu);
    VERIFY_SUCCESS(err_code);

    err_code = dfu_ctrl_pt_add(p_dfu);
    VERIFY_SUCCESS(err_code);

    m_flags |= DFU_BLE_FLAG_SERVICE_INITIALIZED;

    return NRF_SUCCESS;
}

I can't see 128bit UUID, just 16bit uuid(0xfe59).

I need your help more.

[endnode]

What do you mean it doesn't have base? It must, otherwise Nordic SD cannot work with it;) I don't know these cryptic functions in the code snippet and I won't learn them but what I clearly see is sd_ble_uuid_vs_add which is provisioning some base to be used later in composition with 16-bit short UUID.

Note that on GATT layer when you see it in the BLE sniffer log it really can look like there are 16-bit UUIDs and if you do discovery through Nordic SD API and you will discover some object (Service or Char) with proprietary UUID base then you might need second GATT command (e.g. read) to get the base even it might be already transmitted before to the SD. But overall the high-level statement stays: there are only 128-bit UUIDs, all other shortcuts mean they can and should be mapped on top of some 128-bit base.

[endnode]

Oh and if you are concerned about the code which comes in your snippet before sd_ble_uuid_vs_add then I see BLE_UUID_BLE_ASSIGN macro which I guess means that some short UUID will use standard BT SIG 128-bit base. Isn't it?

[roger.k]

Thank you very much for your help. As I've tested,

when it is on app mode, I can see 128bit UUID. Tha't why I'm sure that my PC tool shows me all raw data.

But when it is on bootloader mode, I can't see 128bit, just 16bit. Even I downloaded bootloader sample code, I can't see 128bit, just 16bit. Then I can see 128bit characteristics UUIDs for packet and control.

Can you see all 128bit UUID containing 0xFE59, when you discover example bootloader?