This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to send the 128-bit base UUID

Hello,

I am developing on the nRF51 and soft device version 8.0.0.

I have created a new service that has a 128-bit UUID that is based on the base UUID: 00000000-0000-1000-8000-00805f9b34fb

I am trying to make the service discoverable with the full 128-bit service UUID, but it always just shows the 16-bit UUID.  Is there a way to show the whole UUID?  Here is my initialization code:

  const ble_uuid128_t service_uuid128 = {
    {
      0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
      0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
    }
  };

  BLE_UUID_BLE_ASSIGN(service_uuid, BLE_MY_GATT_SERVICE_UUID);

  err_code = sd_ble_uuid_vs_add(&service_uuid128, &(service_uuid.type));
  if (err_code != NRF_SUCCESS) {
      return err_code;
  }

  err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                      &service_uuid,
                                      &(p_my_service->service_handle));
  if (err_code != NRF_SUCCESS) {
    return err_code;
  }
 

Thanks

  • More clarification: When I connect to the device I just see BLE_MY_GAT_SERVICE_UUID instead of the whole 128-bit UUID.

  • Hi,

    Can you explain a bit more, where do you see only the short UUID?

    The context and nature of service_uuid is missing from the code excerpt, have you based it off of an example? What does the rest of the function look like?

    I recommend having a look at for instance the ble_app_uart example from the SDK, as that example uses 128 bit UUIDs.

    Regards,
    Terje

  • Sure,

    When I connect to my device using a BLE sniffer (e.g. BlueSee), I only see a 16-bit Service UUID (In this example the UUID is 0xDEAD):

    09:10:30.8920: connected in underlying BLE layer.
    09:10:30.8930: discovered services: (
        DEAD,
        "Device Information"
    )
    09:10:31.0390: discovered characteristics for service 180A: (
        "Manufacturer Name String",
        "Model Number String",
        "Serial Number String",
        "Hardware Revision String",
        "Firmware Revision String",
        "Software Revision String"
    )
    09:10:31.2480: discovered characteristics for service DEAD: (
        "0000FFF1-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF2-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF3-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF4-1212-0CAA-142F-C9B16EC683AB"
    )
    

    If I use a debugger to look at the resulting type id from sd_ble_uuid_vs_add(), it is 0x1 (BLE_UUID_TYPE_BLE)

    If I use a different UUID, for example, changing one bit in the 128-bit UUID (00000000-0000-1000-8000-00805f9b34fc) the sniffer sees this:

    09:10:30.8920: connected in underlying BLE layer.
    09:10:30.8930: discovered services: (
        "0000DEAD-0000-1000-8000-00805F9B34FC",
        DEAD,
        "Device Information"
    )
    09:10:31.0390: discovered characteristics for service 180A: (
        "Manufacturer Name String",
        "Model Number String",
        "Serial Number String",
        "Hardware Revision String",
        "Firmware Revision String",
        "Software Revision String"
    )
    09:10:31.2480: discovered characteristics for service 0000DEAD-0000-1000-8000-00805F9B34FC: (
        "0000FFF1-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF2-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF3-1212-0CAA-142F-C9B16EC683AB",
        "0000FFF4-1212-0CAA-142F-C9B16EC683AB"
    )
    

    Note that DEAD now has the 128-bit Service UUID.

    Is there some filtering done for base UUIDs?

  • Even more clarification: I am working with a service UUID that hasn't been registered.  However, the service provider created a 128-bit service UUID using the base UUID.  They essentially did this:  0000DEAD-0000-1000-8000-00805F9B34FB.  Is this legal?  If it is, how can I generate this 128-bit service UUID using the soft device SDK? 

  • Hi,

    Sorry for not spotting this at the first go. Of course. The way 16 bit UUIDs are implemented is that under the hood they are all 128 bit UUIDs, and for that they use a specially assigned Base UUID which cannot be used for other purposes. That Base UUID is 00000000-0000-1000-8000-00805F9B34FB.

    What it all means is:

    1) Do not use that base UUID. It is reserved for the 16 bit UUIDs defined by the Bluetooth SIG.

    2) Any tool (such as the sniffer that you are using) will see that this is the Base UUID for 16 bit UUIDs, and so they assume it is a 16 bit UUID, potentially one that it is not yet aware of.

    3) Use a different Base UUID for your projects. You can choose whatever Base UUID you would like, just not that one. Please note that choosing a random number is the best approach, for minimizing the chance of your Base UUID colliding with that of someone else.

    4) If, for some strange reason, you need to use the Base UUID for BT SIG defined 16 bit UUIDs, even though it is not for a BT SIG assigned 16 bit UUID, then firstly don't, and secondly what you have done seems to be doing exactly that (although you could have used BLE_UUID_TYPE_BLE directly as it is already there by default, and also in any case you should really do what I described in 3 instead.)

    Regards,
    Terje

Related