Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Retrieving base UUIDs from the SoftDevice

Is there a way to retrieve 128-bit base UUIDs from the SoftDevice, either the "built-in" Bluetooth SIG standard or a vendor-specific one registered via "sd_ble_uuid_vs_add"?

I thought "sd_ble_uuid_encode" would do it, but this function appears to be intended for other purposes.

Parents
  • Hi,

    The Bluetooth SIG assigned base UUID (for the 16 bit UUIDs) is a known constant.

    Vendor specific base UUIDs are added using sd_ble_uuid_vs_add(), and since this is called from the application you already know what base UUID you added. If, by any chance, you need to remember what base UUID you have used then you must keep the variable (or constant) used for passing the base UUID address to sd_ble_uuid_vs_add().

    You will get back from the SoftDevice the index in the base UUID table for your newly added base UUID, through the p_uuid_type parameter of sd_ble_uuid_vs_add(). This index is also known as the "UUID type".

    Once you have added the base UUID to the SoftDevice, you usually only need to care about the UUID type. Normally you will never need the full value of the base UUID again, as it is now handled entirely by the SoftDevice, and any reference to it is now done through the UUID type.

    For instance, in our UART/Serial Port Emulation over BLE example, using our proprietary Nordic UART Service (NUS), we use a vendor specific base UUID which is defined in 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. */

    The value itself is only used in ble_nus_init(), for adding the vendor specific UUID and setting up the service. After that point the base UUID itself is never needed again, since we now have the UUID type, which is all we need. The ble_uuid_t structure used for storing UUIDs has two fields; one for the 16 bit part of the UUID, and one for the UUID type.

    Regards,
    Terje

Reply
  • Hi,

    The Bluetooth SIG assigned base UUID (for the 16 bit UUIDs) is a known constant.

    Vendor specific base UUIDs are added using sd_ble_uuid_vs_add(), and since this is called from the application you already know what base UUID you added. If, by any chance, you need to remember what base UUID you have used then you must keep the variable (or constant) used for passing the base UUID address to sd_ble_uuid_vs_add().

    You will get back from the SoftDevice the index in the base UUID table for your newly added base UUID, through the p_uuid_type parameter of sd_ble_uuid_vs_add(). This index is also known as the "UUID type".

    Once you have added the base UUID to the SoftDevice, you usually only need to care about the UUID type. Normally you will never need the full value of the base UUID again, as it is now handled entirely by the SoftDevice, and any reference to it is now done through the UUID type.

    For instance, in our UART/Serial Port Emulation over BLE example, using our proprietary Nordic UART Service (NUS), we use a vendor specific base UUID which is defined in 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. */

    The value itself is only used in ble_nus_init(), for adding the vendor specific UUID and setting up the service. After that point the base UUID itself is never needed again, since we now have the UUID type, which is all we need. The ble_uuid_t structure used for storing UUIDs has two fields; one for the 16 bit part of the UUID, and one for the UUID type.

    Regards,
    Terje

Children
No Data
Related