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 ?

[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