Understanding Advertisement of multiple 128 bit custom UUID

[SK]

Hi Everyone, 

I am using nRF52832 with SDK v14.2 and SD v5.0.0 on a custom chip. 

I want to advertise 2 custom UUID (DFU and NUS) and i wanted to know the correct way to do it. I understand that advertisement packet is 31 bytes and so is scan response packet. So, having one custom UUID on advertisement packet and the other on scan response packet makes sense since custom UUID is 16 bytes long. 

I did the same way and with nRF connect app i can see both services but when i sniffed for the packets being transmitted, i saw only one UUID there. 

I have attached the code here for a look. I have also attached sniffer trace for advertisement and scan response packet for your reference. Please advise why is it not advertising NUS UUID and still be able to detect by the nRF connect app when connected? 

.

 

ret_code_t advertising_init(void)
{
    ret_code_t u32ErrCode = NRF_SUCCESS;
    ble_uuid_t astAdvUuids[] =                                          /**< Universally unique service identifier. */
    {
      {BLE_DFU_UUID, DFU_SERVICE_UUID_TYPE},
      {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
    };
    ble_advertising_init_t stInit;

    memset(&stInit, 0, sizeof(stInit));

    stInit.advdata.name_type          = BLE_ADVDATA_FULL_NAME;
    stInit.advdata.include_appearance = false;
    stInit.advdata.flags              = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

    stInit.advdata.uuids_complete.uuid_cnt = 1;
    stInit.advdata.uuids_complete.p_uuids = &astAdvUuids[0];

    stInit.srdata.uuids_more_available.uuid_cnt = 1;
    stInit.srdata.uuids_more_available.p_uuids  = &astAdvUuids[1];

    stInit.config.ble_adv_fast_enabled  = true;
    stInit.config.ble_adv_fast_interval = APP_ADV_INTERVAL;
    stInit.config.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;

    stInit.evt_handler = on_adv_evt;

    u32ErrCode = ble_advertising_init(&m_advertising, &stInit);
    APP_ERROR_CHECK(u32ErrCode);

    ble_advertising_conn_cfg_tag_set(&m_advertising, APP_BLE_CONN_CFG_TAG);

    //nfc ble pair library init
    nrf_ble_pairing_init(&m_advertising);
    return u32ErrCode;
}

Thank you!

[Einar Thorsrud]

Hi,

SK said:

So type is uint8_t  whereas a 16 byte UUID is type ble_uuid128_t. Now inserting 16 bytes is not making sense and is giving me all sorts of warning messages. Do you want me to try pointing 16 bytes value to the 'type' field? 

No. The type field is uint8_t, and it is just an ID/index/offset (call it what you like). Think of it as a reference tho the UUID base you have added. To brake it down:

1. Add a UUID base with sd_ble_uuid_vs_add(). The second parameter to this function call is a pointer to a uint8_t, and this is an output. This means that the variable you pint to is populated with the number that is the UUID type (which is an index).
2. Whenever you need to use this base UUID, such as when populating an advertising packet, you should refer to the UUID type, and since this is a reference to the base UUID, the SoftDevice (BLE stack) will make sure that the correct base UUID is used.

SK said:

so i can very well take 0x03 (BLE_UUID_TYPE_VENDOR_BEGIN  + 1) as my next VS UUID, right?

Yes. The "proper" way would be to use the output, but this is orderly numbered so that the first call you make to sd_ble_uuid_vs_add() will give you a type 2, the second will give you type 3 and so on.

SK said:

But when i  try to run, it is giving me invalid param error.

From where do you get invalid param? You should call sd_ble_uuid_vs_add() before you reference the UUID type, could that be the problem?

[Einar Thorsrud]

That is a decision made by those who made the example. There is no need to advertise all service UUID's, and the fact that the peripheral example supports DFU is probably not the most important thing about it. So I would say it makes sense, at least if it were a real application. The central can anyway find out that it supports DFU by doing a service discovery after it has connected.

[SK]

Hi Einar, 

Einar Thorsrud said:

From where do you get invalid param? You should call sd_ble_uuid_vs_add() before you reference the UUID type, could that be the problem?

Right! This was the issue. Thanks a lot! 

Einar Thorsrud said:

so i can very well take 0x03 (BLE_UUID_TYPE_VENDOR_BEGIN  + 1) as my next VS UUID, right?

This works as well. I can see both UUID's now. One in ADV packet and other  in SCAN_RSP packet as expected.