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,

Looking at your code I see that you put one UUID in the advertising data (stInit.advdata) and one in the scan response data (stInit.srdata). Most scanners will do active scanning, which means that they will also ask for and read the scan response data. Therefore you see it in nRF Connect. You can see it in the sniffer as well, but then you need to look at the scan response packet to see the second UUID.

Note that you can put both UUID's in the advertising packet instead, provided it can fit (depending on the length of the name, since you put the full name in the advertising packet).

[SK]

Hi Einar, 

I checked in the scan response packet as well (attached). I can only see one UUID being transmitted. (both having the same base UUID but different service ID- one being 0xFE59 and the other 0x0001)

[Einar Thorsrud]

Yes, that is correct. Looking at your code from the original question it is clear that you put one UUID in the advertisement packet (line 17-18 in your code snippet) and one in the scan response packet (line 20-21).

[SK]

Exactly! which is why it is confusing to see only one UUID being transmitted. Same UUID in Scan response and advertisement packet when sniffed. 

[Einar Thorsrud]

Hi,

I do not see any problems. The UUID is different in the advertising packet and scan response packet in your original question, and the numbers are correct (0xFE59 for DFU and 0x0001 for NUS). Please see the following two screenshots, which are your screenshots from the original question, but with my highlighting:

[SK]

Okay i was under the impression that if there are two different base UUID's, then i would be seeing those in the packets. It seems from the packets that it's taking only 1 base UUID and 2 different service ID's along with it which according to you is correct behavior? 

[Einar Thorsrud]

Hi,

Ah, you are right. I did not spot that. I cannot say why this is without seeing a bit more of your code, though. How have you defined BLE_DFU_UUID and DFU_SERVICE_UUID_TYPE?