32bit vendor specific uuid

[Kasper Leonhardt]

Hi

I am going to implement a BLE device according to a customers specifications.

The service UUID is defined as 00000001-0000-1000-8000-XXXXXXXXXXXX

The characteristics UUID are defined as 00010001-0000-1000-8000-XXXXXXXXXXXX 00010002-0000-1000-8000-XXXXXXXXXXXX

When implementing in nrf52 I have used 0000-0000-8000-XXXXXXXXXXXX as the base UUID, using the function sd_ble_uuid_vs_add to add it to softdevice's UUID table

But it seems that the softdevice/SDK only allows byte 12 and 13 to differ from the base UUID, but byte 14 also differs. And adding the service UUID with the sd_ble_gatts_service_add function does not work, as this function only allows to specify a 16 bit UUID. And adding the characteristics with the sd_ble_gatts_characteristic_add function is not easier.

Do I have a problem implementing this?

Can I device the service into two using two diferent base UUID's?

BR Kasper

[endnode]

I believe that Nordic stacks (Soft Device) only implement 128-bit (16-byte) and 16-bit (2-byte) UUIDs. Moreover they always build UUID as 128-bit base + 16-bit "short UUID". If you want to use 16-bit then base is BT SIG default UUID base. If you want to use full 128-bit custom UUID then you define your custom base + 16-bit values. There is 32-bit UUID defined in BT SIG (G)ATT specification but I had impression that for Low Energy implementations only 128-bit and 16-bit UUIDs are used. But I might be wrong (haven't studied all 3 thousand pages of BT SIG spec into such detail). In every case Nordic stack seems to support only full and short, not this variant.

[endnode]

And yes, you might "workaround" this limitation by simply provisioning more custom bases which will reflect your 32-bit UUID (which anyway must be mapped to some 128-bit base, always).

[Kasper Leonhardt]

Thanks for your answer. I have to give it a try with the multi-service workaround. Or make the customer change the protocol :-)