Cannot add multiple custom UUIDs?

[RMV]

I have reviewed most (if not all) posts on this forum that relate to multiple vendor specific UUIDs but still see issues on my platform.

I am using nRF52832 (with minor changes unrelated to Bluetooth) and Soft Device version 6.1.1

I have two custom 128-bit UUIDs that are very close to each other but differ only in bytes 12 and 13.
I want to use one set of values of bytes 12, 13 to advertise and the other pair to scan.

First question: Is this a viable / expected use case of multiple vendor specific 128-bit UUIDs

Second question: No matter what I do, two back to back calls to sd_ble_uuid_vs_add() always return the value '2' for the UUID type.
I was expecting to see the type be set to '2' for the first call and '3' for the next one but no such luck.

What is going on here -- or am I going about this the wrong way?

This has been bothering us for over a month now, so any feedback would be appreciated.

[Jørgen Holmefjord]

Hi,

This is explained in the Note in the API documentation for sd_ble_uuid_vs_add:

Bytes 12 and 13 of the provided UUID will not be used internally, since those are always replaced by the 16-bit uuid field in ble_uuid_t.
If a UUID is already present in the BLE stack's internal table, the corresponding index will be returned in p_uuid_type along with an NRF_SUCCESS error code.

Since bytes 12 and 13 are masked out, you are adding the same base UUID twice. If the base UUID already exists in the table, the corresponding index will be returned.

Best regards,
Jørgen

[RMV]

I have already read the note and do understand it.
I just wanted to confirm that my understanding was correct.

In this case, what is the best option to switch between broadcasting and scanning "with the same base UUID but different bytes 12 and 13"? Is that even allowed/possible with Nordic nRF52?

[Jørgen Holmefjord]

I'm not sure I understand your question. When advertising, you choose what to put into the advertising packet. For instance, in ble_app_uart, the UUID in the advertising packet is defined like this:

static ble_uuid_t m_adv_uuids[]          =                                          /**< Universally unique service identifier. */
{
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
};

BLE_UUID_NUS_SERVICE is defined as 0x0001, which corresponds to byte 12 and 13 in the advertised UUID. If you would like to advertise a different UUID, with the same base UUID but different byte 12 and 13, you would only change the BLE_UUID_NUS_SERVICE define.

Scanning does not use UUIDs, but you can use UUIDs to filter out devices that advertise the UUID of your service. This is done in a similar way.

[RMV]

Thanks.

Here is what I am trying to achieve. I want a device to use scan for a specific 128-bit UUID (where bytes 12 and 13 are fixed). When the device detects an incoming advertisement on that 128-bit UUID, I want my device to switch roles and "broadcast/advertise" with the same base UUID but a different combination of bytes 12 and 13.

Can that be done using the BLE_UUID_NUS_SERVICE kind of set up or something similar to it?
On the one hand I keep getting the impression that bytes 12 and 13 are only meant to play with attributes, services and characteristics -- and not really meant for switching roles between broadcaster and observer/scanner.

[Jørgen Holmefjord]

Yes, it is no problem to use similar to BLE_UUID_NUS_SERVICE to do this. In ble_app_uart_c, the same approach is used to scan for the NUS UUID:

/**@brief NUS UUID. */
static ble_uuid_t const m_nus_uuid =
{
    .uuid = BLE_UUID_NUS_SERVICE,
    .type = NUS_SERVICE_UUID_TYPE
};

err_code = nrf_ble_scan_filter_set(&m_scan, SCAN_UUID_FILTER, &m_nus_uuid);
APP_ERROR_CHECK(err_code);

You can change the .uuid and .type parameters as you like to scan for a different UUIDs, and you can create new ble_uuid_t variables to fill in the new advertising/broadcast packets.