Advertising Bluetooth LE 128-bit vendor specific UUID

[Jarmo]

I am wondering what is the logic and magic behind using sdk API's to advertise vendor specific 128-bit service UUIDs. In the "Nordic UART Service" example (nus, SDK12.2.0) there is:

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

But the BLE_UUID_NUS_SERVICE is not the 128-bit UUID but just 16-bit:

#define BLE_UUID_NUS_SERVICE 0x0001                      /**< The UUID of the Nordic UART Service. */

Digging the other source code files the true 128-bit UID can be found from ble_nus.c:

#define NUS_BASE_UUID                  {{0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E}} /**< Used vendor specific UUID. */

So, ble_advertising_init() gets only the 16-bit "UUID" but is still able to build advertising data with the true 128-bit UUID. This is very strange. I tried to examine internal implementations and it looks like the 128-bit UUID is send to the Soft Device before calling ble_advertising_init. Is it so, could somebody please explain the underlying logic? What if I have several vendor specific 128-bit UUIDs, how do the advertising data build functions know which one must be set into the advertising data, if only 16-bit "UUID" is given?

[Petter Myhre]

It is a bit hard to see the logic.

The base UUID is added to the SoftDevice inside ble_nus_init():

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

The returned type is referenced when telling the advertising module which UUID to advertise.

[Petter Myhre]

Maybe you can remove the "hidden" dependency by adding the base UUID in main, and then give the type as an argument to ble_nus_init()?