Instead of octets 12-13 of 128-bit UUID can we use octets 1-2

[Sivashankar]

Hi,

I've defined a base uuid 455449424C5545544845524DB87AD700 

For adding the service to the database CUS_SERVICE_UUID = 0x4942 which alters my 12th and 13 octets 

Instead I wan use 0xD700 to alter 1st and 2nd octets.

so I need UUID as follow

PS 455449424C5545544845524DB87AD700

PC-1  455449424C5545544845524DB87AD701 

PC-2  455449424C5545544845524DB87AD702

PC-3  455449424C5545544845524DB87AD703

PC-4  455449424C5545544845524DB87AD704

How can I do this....?

[Einar Thorsrud]

Hi,

Why do you want to change that? This is essentially the same question as in this old post. As the UUID format is standardized, doing it like you suggest means you will need a separate base for each UUID, where the base is incremented by one for each UUID. It will work, but it is a bit odd.

[Sivashankar]

Hi Einar,

Thanks for your response, Is there a way where i can define each PC UUID full 128bit and PS UUID as below. 

#define ETI_SVC_UUID { 0x00, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \
                                          0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                          0x42, 0x49, 0x54, 0x45 }
#define ETI_CHAR_SEN1_UUID { 0x01, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \

                                                        0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                                        0x42, 0x49, 0x54, 0x45 }
#define ETI_CHAR_COM_NOT_UUID { 0x05, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \
                                                                 0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                                                 0x42, 0x49, 0x54, 0x45 }
#define ETI_CHAR_SEN1_SET_UUID { 0x07, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \
                                                                 0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                                                 0x42, 0x49, 0x54, 0x45 }
#define ETI_CHAR_INS_SET_UUID { 0x09, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \
                                                             0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                                             0x42, 0x49, 0x54, 0x45 }
#define ETI_CHAR_TRM_SET_UUID { 0x0a, 0xD7, 0x7A, 0xB8, 0x4D, 0x52, \
                                                               0x45, 0x48, 0x54, 0x45, 0x55, 0x4C, \
                                                               0x42, 0x49, 0x54, 0x45 }

CS_SERVICE_UUID_128(ETI_SERVICE0, ETI_SVC_UUID),

/* To the BLE transfer */

/* Sensor 1 Reading in Service 1 */
CS_CHAR_UUID_128(ETI_SEN1_READING_CHAR0, // attidx_char
ETI_SEN1_READING_VAL0, // attidx_val
ETI_CHAR_SEN1_UUID, // uuid
PERM(RD, ENABLE) | PERM(NTF, ENABLE), // perm
sizeof(app_env_cs.to_air_buffer), // length
app_env_cs.to_air_buffer, // data
NULL),

[Einar Thorsrud]

No, that is not possible using the SoftDevice. You will need to add each base UUID with sd_ble_uuid_vs_add(), and then refer to each base when you use your UUID's (which will all have different base).

[Sivashankar]

Thanks again Einar, I want to use such UUID because our old products, It's having such PS and PC's  as below

UUID:  0x455449424C5545544845524DB87AD700   (in ASCII = ETIBLUETHERM¸z×)

Slot No.	Private Characteristic Name	Characteristic UUID	Property
1&2	Sensor 1 Reading	0x455449424C5545544845524DB87AD701	Read & Notify
3&4	Sensor 2 Reading*	0x455449424C5545544845524DB87AD703	Read & Notify
5&6	Command/ Notifications	0x455449424C5545544845524DB87AD705	Read/Write & Notify
7	Sensor 1 Settings	0x455449424C5545544845524DB87AD707	Read/Write
8	Sensor 2 Settings*	0x455449424C5545544845524DB87AD708	Read/Write
9	Instrument Settings	0x455449424C5545544845524DB87AD709	Read/Write
10	Trim Settings	0x455449424C5545544845524DB87AD70A	Read/Write

This is with BLE 4.1 and Now we are updating to BLE5.0 thus I also want to follow the same above protocol for all my Private Services and Private Characteristics. If I'm developing from scratch we can use new standards but here have have to follow this to support some custom developed native apps.   

I kindly request you to review this possibility. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-If I use 

// Add the Custom ble Service UUID
ble_uuid128_t base_uuid = CUS_SERVICE_UUID_BASE;
err_code = sd_ble_uuid_vs_add(&base_uuid, &p_cus->uuid_type);
if (err_code != NRF_SUCCESS)
{
return err_code;
}

ble_uuid.type = p_cus->uuid_type;
ble_uuid.uuid = CUS_SERVICE_UUID;

// Add the service to the database
err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &p_cus->service_handle);

for each UUID it will be abed as PS

But I want to add PC

/* Adding the service characteristics */

// Add the buttons characteristic.

uint8_t buttons_char_init_value [4] = {0};

memset(&add_char_params, 0, sizeof(add_char_params));
add_char_params.uuid = BUTTONS_STATES_CHAR_UUID;
add_char_params.uuid_type = p_cus->uuid_type;

add_char_params.init_len = 4;
add_char_params.max_len = 4;
add_char_params.p_init_value = buttons_char_init_value;

add_char_params.char_props.read = 1;
add_char_params.char_props.notify = 1;

add_char_params.read_access = SEC_OPEN;
add_char_params.cccd_write_access = SEC_OPEN;

err_code = characteristic_add(p_cus->service_handle,
&add_char_params,
&p_cus->buttons_states_char_handles);

[Einar Thorsrud]

Hi,

This is the same with Bluetooth 4.x and 5.x, and the SoftDevice API for this is mostly the same for a long time. What you want to do should be possible, but as it is not a normal approach it is not as elegant as you could hope. Essentially, you need to do as I wrote before, which is to add a base for each UUID, and a service UUID and a characteristic using that base. This is exactly what the code snippet you have included here does. Then you could duplicate this for all your different bases.

Do you know why the UUIDs are like this in the first place in the old product you are using? Could it be a misunderstanding somewhere? Could you check with nRF Connect for desktop and do a service discovery of the old product and copy--paste here just so we see to double-check?