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?