Vendor Specific UUID Type/s

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_tSimilarly 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

Parents
  • > 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.

Reply
  • > 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.

Children
No Data
Related