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

128-bit UUID using sd_ble_uid_vs_add

I have a UUID in which bytes 12 and 13 are not 0. For example, I have something like this *addr = 87000d1f-1234-5678-9abc-123456789abc

When I use sd_ble_uuid_vs_add(&addr, uuid_type) and I examine the UUID advertised by using LightBlue I see the following:

87000000-1234-5678-9abc-123456789abc

In other words, bytes 12 and 13 now contain 0000 rather than 0d1f.

Is there a way that the advertised UUID is the original one that I intended, 87000d1f-1234-5678-9abc-123456789abc

Is there another method other than sd_ble_uuid_vs_add() that can give me the intended UUID?

Parents
  • FYI: We are trying to maintain backward compatibility of a GATT profile that we had previously defined while using a different chip set.

    In this definition, when adding a characteristic, we kept the original value of 0x0d1f for bytes 12,13. To define the first characteristic rather than modifying bytes 12,13, we modified bytes 11 and 10. So our first characteristic defined "0x0d1f" as bytes 13, 12 and "1001" as bytes 11,10. Our 2nd characteristic defined "0x0d1f" as bytes 13, 12 and bytes "1002" as bytes 11,10.

    A suggestion was made for me to do the following: " call sd_ble_uuid_vs_add() to add multiple vendor specific UUIDs, then save multiple types to use in the ble_uuid_t ". I did not know exactly what that meant. So here is what I attempted.

    This is what I did per the ble_nus.c example of the ble_app_uart ble_uuid128_t drs_base_uuid = DEVICE_REPORTING_SERVICE_UUID; /* I want to add a new characteristic with a UUID as per the following except that bytes 12,13 are0x01DF #define DEVICE_REPORTING_SERVICE_UUID {{ 0x88, 0XEC, 0X68, 0X70, 0X72, 0XEE, 0X04, 0X82, 0XF7, 0X40, 0X00, 0X10, 0X00, 0X00, 0X00, 0X75}} */ VERIFY_PARAM_NOT_NULL(p_drs); VERIFY_PARAM_NOT_NULL(p_drs_init);

    // Initialize the service structure.
    p_drs->conn_handle             = BLE_CONN_HANDLE_INVALID;
    p_drs->data_handler            = p_drs_init->data_handler;
    p_drs->is_notification_enabled = false;
    
        // Add a custom base UUID.
    err_code = sd_ble_uuid_vs_add(&drs_base_uuid, &p_drs->uuid_type);
    VERIFY_SUCCESS(err_code);
    
    ble_uuid.type = p_drs->uuid_type;
    ble_uuid.uuid = 0x0d1f;
    // Add the service.
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &ble_uuid,
                                        &p_drs->service_handle);
    VERIFY_SUCCESS(err_code);
    

    This worked well.

    Now I want to add a new characteristic with a UUID as per the following except that bytes 12,13 are 0x01DF and bytes 11,10 are 0x1001 /* #define DEVICE_STATUS_CHARACTERISTIC_UUID {{ 0x88, 0XEC, 0X68, 0X70, 0X72, 0XEE, 0X04, 0X82, 0XF7, 0X40, 0X01, 0X10, 0X00, 0X00, 0X00, 0X75}} */ Following the above, I added

    ble_uuid128_t drs_char_uuid = DEVICE_STATUS_CHARACTERISTIC_UUID;
    VERIFY_PARAM_NOT_NULL(p_drs);
    VERIFY_PARAM_NOT_NULL(p_drs_init);
    p_drs->conn_handle             = BLE_CONN_HANDLE_INVALID;
    

    p_drs->data_handler = p_drs_init->data_handler; p_drs->is_notification_enabled = false;

    err_code = sd_ble_uuid_vs_add(&drs_char_uuid, &p_drs->uuid_type);
    VERIFY_SUCCESS(err_code);
    
    ble_uuid.type = p_drs->uuid_type;
    ble_uuid.uuid = 0x0d1f;
    err_code = sd_ble_uuid_vs_add(&drs_char_uuid, &p_drs->uuid_type);
    VERIFY_SUCCESS(err_code);
    

    When I did this, the service was added properly. However the characteristic had bytes 11,10 as "1000" rather than "1001". This is the service UUID with bytes 13,12 as "0x0000".

    I would appreciate it if you would give me detailed recommendation.

    Thank You!

  • FormerMember
    0 FormerMember in reply to Esterina

    Hi Esterina,

    It should work to add "1001" to the service UUID. You can test in with the ble_app_uart example in the SDK: change BLE_UUID_NUS_SERVICE to "0x1001". If you then compile and run the application you will see that it advertises "1001".

Reply Children
No Data
Related