Is 32 bit service UUID supported?

[Roger Clark]

I'm trying to use a 32 bit service UUID, but it doesn't seem to be supported by SDK 10 or SDK 12

Looking in the HRS it has this code

BLE_UUID_HEART_RATE_SERVICE,         BLE_UUID_TYPE_BLE

which is passed to

ble_advertising_init

But BLE_UUID_TYPE_BLE is a 16 bit UUID and I can't see 32 bit defined in the list that ble_advertising_init uses

#define BLE_UUID_TYPE_UNKNOWN       0x00 /**< Invalid UUID type. */
#define BLE_UUID_TYPE_BLE           0x01 /**< Bluetooth SIG UUID (16-bit). */
#define BLE_UUID_TYPE_VENDOR_BEGIN  0x02 /**< Vendor UUID types start at this index (128-bit). */

I can see 32 bit listed in gap.h

#define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE         0x05 

Is it possible to use 32 bit service uuids and use ble_advertising_init or to use 32 bit UUID's do i need to do this some other way

Or is 32 bit not supported ?

[Petter Myhre]

Have you been assigned a 32 bit UUID by the Bluetooth SIG?

[Roger Clark]

I'm not sure how thats relevant.

I'm only writing some prototype / proof of concept code.

We have been using a 128 bit service UUID, as we want to uniquely detect just our product, and on iOS the only way to auto filter for this is to use a service UUID.

Using a 16 bit service ID is to short as companies seem to randomly use any 16 bit service ID's they pick at random.

128 UUID seems safe from collision, but takes up a lot of space in the advertising packet, and we need to send "manufacturer data" in the advertising packet, as the device constantly reports various aspects about its operation.

i.e with a 128 bit UUID, it leaves just 8 bytes for status reports, which is just about enough.

But using a 32 bit UUID would free up another 12 bytes, which would be beneficial for future expansion.

But as it stands we will need to use 128 bits for the proof of concept

[Petter Myhre]

16 bit and 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG, companies should not randomly use them.

If you have been assigned a 16 bit or 32 bit UUID you can use these in the advertising packet. You can of course use a 32 bit UUID in a prototype as well.

When used in GATT the 32 bit UUID can't be used, it shall be converted to a 128 bit UUID.

ble_advdata_set(), which encodes data in the advertising and scan response data format does not support 32 bit UUIDs. You can however modify it to support 32 bit UUIDs, or do the encoding manually yourself for your advertising packet.

[Roger Clark]

Thanks Petter

I know in theory that 16 and 32 bit UUIDs are allocated by Bluetooth SIG, but in practice I have seen many devices using random numbers for 16 bit service IDs on their products.

Anyway, from what you have written , it sounds like 128 bit Service UUIDs are not issued by Bluetooth SIG, so any random 128 bit UUID would be valid.

And we can live with only 8 bytes of Manufacturer data in the advertising.

If we need more data, it sounds like we'd need to create the advertising packet in our code, so I'll need to read the API docs to see how to pass a advertising packet to the API