Advertise multiple vendor UUIDs

[tajo]

Hello!

I hope this question has not been asked before - at least I can't find it. I do have an application with two vender specific services (128bit UUID's) and I want to advertise both of them.

First: I know how to advertise two standard services (16bit UUIDs):

ble_uuid_t m_adv_uuids[] = 
{
    {BLE_UUID_SERVICE_ONE, BLE_UUID_TYPE_BLE},
    {BLE_UUID_SERVICE_TWO, BLE_UUID_TYPE_BLE}
};

Second: I know how to advertise one vendor Service (128bit UUID):

ble_uuid_t m_adv_uuids[] = 
{
    {BLE_UUID_SERVICE_ONE, BLE_UUID_TYPE_VENDOR_BEGIN}
};

But when I want to add a sencond vendor UUID to "Second", I end up in errors. Mixing BLE and VENDOR_BEGIN is possible, but than I only have one 128bit UUID and the others are 16bit.

PS: Adding UUIDs is done the folowing way:

ble_advdata_t srdata;
memset(&srdata, 0, sizeof(srdata));

srdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
srdata.uuids_complete.p_uuids = m_adv_uuids;

Thanks, Johann

[Roger Clark]

What software are you using to receive the advertisements, is it some existing software e.g. an iOS app or something you are writing yourself

If its just a normal iBeacon scanner, then the iBeacon protocol just allows for one UUID and this is all the App will look for

It sounds like what you really want to do is alternate between sending 2 different vendor UUID's or perhaps send one the send the other, but I'm not sure you can send both at once and still have a valid iBeacon data packet

[tajo]

I am using the nRF Connect v1.0 with a second nRF52 dev board.

Since there where some examples which propagated more than one UUID (e.g. ble_app_bps in nRF5 SDK 11.0.0), I thought I could do so for vendor specific UUIDs.

[Ole Bauck]

You can send UUIDs both in advertisement packet and in scan response packet. Scan response packet is initialized the same way as the advertisement packet (same struct -> ble_advdata_t). The ble_app_uart example in the SDK sends the UUIDs in the scan response packet to save power (less bytes sent if few scan responses is received), so you can see how it is done there.

To be correct you also should populate the uuids_more_available field in ble_advdata_t and not uuids_complete field as there are more UUIDs available.

Also take a look at this great tutorial on advertising.

[tajo]

Hello and thanks to your response.

I might have a little trouble understanding the meaning of "complete" and "more available". I thought that there would be a complete list of UUIDs which get propagated via the ble_advdata_uuid_list_t.

But now I think this would be impossible due to the packet size of 31 bytes and an (vendor specific) UUID size of 16byte. I wouldn't event be able to send two of them.

My only question now is: where can I find a documentation about the meaning of "more available", "complete" and "solicited" (not in the tutorial you mentioned).

Thanks a lot!

[Ole Bauck]

“More available” is the same as “incomplete” and should be used if there are more UUIDs in the attribute table of that type (16 bit or 128 bit). “Complete” means that the UUIDs in the advertisement packet are all the ones of that particular type (16 bit or 128 bit) found in the attribute table.

“Solicited” is used if the server is on the scanner side. Then the advertiser wishes to connect to a device with the service(s) defined by the uuid(s) in the advertisement packet. So you don’t have to think about this term.

It is difficult to find clear documentation on this. It is briefly touched in “Supplement to Bluetooth Core Specification” Part A section 1.1.