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

Checking my understanding of 128-bit UUIDs.

When registering a base UUID with the SoftDevice via "sd_ble_uuid_vs_add", a uint8_t is returned which (per the ble_app_pwr_profiling example) is intended to be the "type" field in a "ble_uuid_t" variable. The SDK documentation indicates (S132 SoftDevice -> API Reference -> BLE SoftDevice Common -> Events, type definitions, and API calls -> Functions -> sd_ble_uuid_vs_add) that this "type" is actually an index into a table of base UUIDs. Index #0 is "Invalid" or "UNKNOWN". Index #1 is "Bluetooth SIG UUID (16-bit)". Index #2 is the start of vendor-specific base UUIDs, "Vendor UUID types start at this index (128-bit)". I'm a bit confused by these comments. In reality, ALL the base UUIDs are 128-bits, and once installed, ALL the relevant API calls deal with 16-bit UUIDs that replace bytes 12 and 13 in the base UUID. Is that right?

So the SoftDevice would then have TWO UUID systems, one rooted at the Bluetooth standard base UUID which is "built in" the SoftDevice, and the second at the randomized vendor-specific base UUID installed via "sd_ble_uuid_vs_add". Thus, standard GATT services and custom GATT services can operate simultaneously, and the Bluetooth stack in the SoftDevice takes care of the advertising and the communication of service contents without further attention from the software developer. Therefore, once the service is initialized and the characteristics added, there is no need to keep track of the index in the ble_uuid_t variable returned from "sd_ble_uuid_vs_add".  Is that right?

  • Hi!

    From what I can see the statements in your post is correct.

    "In reality, ALL the base UUIDs are 128-bits, and once installed, ALL the relevant API calls deal with 16-bit UUIDs that
    replace bytes 12 and 13 in the base UUID. Is that right?"
    Yes, that is correct. The 16-bit Bluetooth SIG UUID's' uses a Base UUID provided by BT SIG. And that is, as you suggested in your question, already added in the softdevice.

    "Therefore, once the service is initialized and the characteristics added, there is no need to keep track of
    the index in the ble_uuid_t variable returned from "sd_ble_uuid_vs_add". Is that right?"
    That is correct. You need to declare which type you are adding to the service/characteristic, but after the services/characteristics is added, you no longer need to keep track of the variable.

    Let me know if you have any more questions.
    Cheers,
    Joakim.

Related