Vendor Specific UUID Type/s

[doshunya]

Hello Support,

I was trying to get the information of services and characteristics from the peripheral after the connection is established.

With sd_ble_gattc_primary_services_discover(), we are able to retrieve the services and can get the detailed information from ble_gattc_evt_prim_srvc_disc_rsp_t. Similarly with sd_ble_gattc_characteristics_discover(), able to retrieve the characteristics details from  ble_gattc_evt_char_disc_rsp_t.

However, there is little ambiguity related to the TYPE field populated as a part of the responses. In case of Services it is ble_gattc_evt_prim_srvc_disc_rsp_t->ble_gattc_service_t->ble_uuid_t->type and  in case of Characteristics it is ble_gattc_evt_char_disc_rsp_t->ble_gattc_char_t->ble_uuid_t->type.

It seems these fields are not programmed in the GATT server and intern not conveyed by peripheral to central over the air by any message. We are seeing the values starting from 2 and just incrementing. We are aware that starting from index 2, these are valid types for vendor specific id's.

The question are

• Who is deciding these TYPE values and how?
• If Central's SoftDevice is populating it, will those be same every time when we try to retrieve the services and characteristics from the same peripheral connects/reconnects?
• Is there any way to use only particular TYPE common across all our vendor specific services and characteristics?
• Will those keep on incrementing if we add more peripherals or same for every peripheral identified by connection handle?

Best Regards

[Turbo J]

> Who is deciding these TYPE values and how?

Check softdevice specs/api, there is a call to add custom UUIDs to the softdevice memory. You will get new TYPE values when registering UUIDs - the only predefined one ist from the Bluetooth standard.

For your own devices you will need to register just one custom 128-bit UUID and then just change the 16 bits that correspond to the uuid part in ble_uuid_t when defining services and characteristics.

Not that this applies only to the old SDK thats no longer supported. Consider switching to the NRF connect SDK, which has a totally different handling of UUID values altogether.

[Einar Thorsrud]

Hi,

Who is deciding these TYPE values and how?

This is a number assigned when you configure the base UUID as allready desscribed.

If Central's SoftDevice is populating it, will those be same every time when we try to retrieve the services and characteristics from the same peripheral connects/reconnects?

Yes. If the order where you confiugre the base UUID by calling sd_ble_uuid_vs_add() is the same, the type will always be the same. Note that the type is an internal reference to a base UUID. The type itself is not visible outside (to the peer).

Is there any way to use only particular TYPE common across all our vendor specific services and characteristics?

If all your vendor specific services has the same base UUID, then yes, you can use the same type. In that case you only need one call to sd_ble_uuid_vs_add() to confiugre the base UUID and get the type, and then refer to that type for adding all the services that use that base UUID in case of a GATT server or discoverying UUIDs using it in case of a GATT client (as in your case).

Will those keep on incrementing if we add more peripherals or same for every peripheral identified by connection handle?

This way of refering to a base UUID is the same regardless.