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]

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?

[SK]

I have defined them like below:

#define DFU_SERVICE_UUID_TYPE           BLE_UUID_TYPE_VENDOR_BEGIN                  /**< UUID type for the Nordic DFU Service (vendor specific). */
#define BLE_DFU_UUID                    0xFE59                                      /**< The 16-bit UUID of the Secure DFU Service. */

[Einar Thorsrud]

I see. Have you added the vendor-specific base UUID with sd_ble_uuid_vs_add(), and was that used with the first call (if you made more calls to it)? If you add more, you should use the type populated in the second parameter int he call to sd_ble_uuid_vs_add(), so that you know it is correct, regardless of the order things happen in.

[SK]

I am calling sd_ble_uuid_vs_add() at two places, one where i am initializing the NUS service and the other for buttonless DFU service init. I do not understand the part where you say to use the type populated in the second parameter. Could you please give me an example on how to? 

Attaching both ble_nus and dfu_buttonless service init snippet here for your reference. 

uint32_t ble_nus_init(ble_nus_t * p_nus, ble_nus_init_t const * p_nus_init)
{
    uint32_t      err_code;
    ble_uuid_t    ble_uuid;
    ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_nus);
    VERIFY_PARAM_NOT_NULL(p_nus_init);

    // Initialize the service structure.
    p_nus->conn_handle             = BLE_CONN_HANDLE_INVALID;
    p_nus->data_handler            = p_nus_init->data_handler;
    p_nus->is_notification_enabled = false;

    /**@snippet [Adding proprietary Service to the SoftDevice] */
    // Add a custom base UUID.
    err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);
    VERIFY_SUCCESS(err_code);

    ble_uuid.type = p_nus->uuid_type;
    ble_uuid.uuid = BLE_UUID_NUS_SERVICE;

    // Add the service.
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &ble_uuid,
                                        &p_nus->service_handle);
    /**@snippet [Adding proprietary Service to the SoftDevice] */
    VERIFY_SUCCESS(err_code);

    // Add the RX Characteristic.
    err_code = rx_char_add(p_nus, p_nus_init);
    VERIFY_SUCCESS(err_code);

    // Add the TX Characteristic.
    err_code = tx_char_add(p_nus, p_nus_init);
    VERIFY_SUCCESS(err_code);

    return NRF_SUCCESS;
}

uint32_t ble_dfu_buttonless_init(const ble_dfu_buttonless_init_t * p_dfu_init)
{
    uint32_t        err_code;
    ble_uuid_t      service_uuid;
    ble_uuid128_t   nordic_base_uuid = BLE_NORDIC_VENDOR_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_dfu_init);

    // Initialize the service structure.
    m_dfu.conn_handle                  = BLE_CONN_HANDLE_INVALID;
    m_dfu.evt_handler                  = p_dfu_init->evt_handler;
    m_dfu.is_waiting_for_reset         = false;
    m_dfu.is_ctrlpt_indication_enabled = false;

    err_code = ble_dfu_buttonless_backend_init(&m_dfu);
    VERIFY_SUCCESS(err_code);
    
    BLE_UUID_BLE_ASSIGN(service_uuid, BLE_DFU_SERVICE_UUID);

    // Add the DFU service declaration.
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &service_uuid,
                                        &(m_dfu.service_handle));

    VERIFY_SUCCESS(err_code);

    // Add vendor specific base UUID to use with the Buttonless DFU characteristic.
    err_code = sd_ble_uuid_vs_add(&nordic_base_uuid, &m_dfu.uuid_type);
    VERIFY_SUCCESS(err_code);

    // Add the Buttonless DFU Characteristic (with bonds/without bonds).
    err_code = ble_dfu_buttonless_char_add(&m_dfu);
    VERIFY_SUCCESS(err_code);

    return NRF_SUCCESS;
}

[Einar Thorsrud]

Hi,

I was not clear enough, but the point is that the UUID type depends on the order you call sd_ble_uuid_vs_add(). Therefore, the second parameter is a pointer to the UUID type as an output, and this is the type you should choose. Therefore, the first call to sd_ble_uuid_vs_add() will give you ID 2 (BLE_UUID_TYPE_VENDOR_BEGIN) and the second call will give you ID 3.

This means that using a hardcoded value is problematic when adding more than one base UUID. You could always make sure to get it right, but then things will be messed up if you cange the order of which BLE service is initialized first. The alternative is to use the type provided when you call sd_ble_uuid_vs_add(). You can obtain that from m_nus (or whatever you named your NUS instance crated with BLE_NUS_DEF), like this: m_nus.uuid_type. But note that it will not be valid until after you have initialized the NUS service.

[SK]

In a case where ID 2 and ID 3 are the same, i.e, both DFU_SERVICE_UUID_TYPE and NUS_SERVICE_UUID_TYPE is BLE_UUID_TYPE_VENDOR_BEGIN, what should happen then? In my case, i am doing the above signalling that both type are vendor specific. Now, when initializing the services, buttonless dfu first and then NUS, i am calling sd_ble_uuid_vs_add() where within each function base UUID for respective services are being assigned (from the code attached above). I thought this should be the right way to have mulitple VS UUID in the application

[Einar Thorsrud]

The name "type" in the SoftDevice and SDK is a bit misleading and makes this more difficult to understand, but the point is that the UUID type is really just a UUID ID, which indicates which of the added base UUID's you should use.

SK said:

In a case where ID 2 and ID 3 are the same, i.e, both DFU_SERVICE_UUID_TYPE and NUS_SERVICE_UUID_TYPE is BLE_UUID_TYPE_VENDOR_BEGIN, what should happen then?

This shoult not happen, because it is incorrect. As you can read from the name of the define BLE_UUID_TYPE_VENDOR_BEGIN is the first (i.e. "begin") of the vendor types. Sinc you are using two different base UUID's, you need to add both. And then you get different types. The type is just an ID pointing to the base UUID, so since you are using separate base UUID's, they cannot possibly have the same UUID type.

SK said:

In my case, i am doing the above signalling that both type are vendor specific. Now, when initializing the services, buttonless dfu first and then NUS, i am calling sd_ble_uuid_vs_add() where within each function base UUID for respective services are being assigned (from the code attached above). I thought this should be the right way to have mulitple VS UUID in the application

Yes. But you need to provide the correct UUID for both services when you populate your advertising packet, and as explained earlier in this post, you are not. You are using the same UUID base (since you use the same type), even though you have added both bases.

[SK]

It's confusing :(

struct ble_uuid_t is defined as this: 

/** @brief  Bluetooth Low Energy UUID type, encapsulates both 16-bit and 128-bit UUIDs. */
typedef struct
{
  uint16_t    uuid; /**< 16-bit UUID value or octets 12-13 of 128-bit UUID. */
  uint8_t     type; /**< UUID type, see @ref BLE_UUID_TYPES. If type is @ref BLE_UUID_TYPE_UNKNOWN, the value of uuid is undefined. */
} ble_uuid_t;

Now, type when referred to BLE_UUID_TYPES tells me to add this below:

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? 

What i tried instead --> BLE_UUID_TYPE_VENDOR_BEGIN is 0x02. If my understanding is correct, VS types starts at this index, so i can very well take 0x03 (BLE_UUID_TYPE_VENDOR_BEGIN  + 1) as my next VS UUID, right? But when i  try to run, it is giving me invalid param error.