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,

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.

[SK]

Another thing i noticed is that if we look into the buttonless DFU example, advertising packet only adds this service: 

static ble_uuid_t m_adv_uuids[] = {{BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE}};

Why is the addition of device information service included rather than adding 128 bit VS UUID for the ble dfu?