How to use sd_ble_uuid_vs_remove after setting the BLE_GATTC_OPT_UUID_DISC option

[Paul Bradford]

The product I'm developing uses the nRF52840 (vendor Fanstel) controlled using pc-ble-driver.

I will use the BLE_GATTC_OPT_UUID_DISC option to cause the vendor-specific UUID table to be populated without me ever calling sd_ble_uuid_vs_add.  It is populated when I use sd_ble_gattc_primary_services_discover and sd_ble_gattc_characteristics_discover to find services and characteristics. 

Part #1: is it true that since I don't call sd_ble_uuid_vs_add, the only cause for entries in the vendor-specific UUID table is calls to sd_ble_gattc_primary_services_discover and sd_ble_gattc_characteristics_discover?

----

Because the vendor-specific UUID table is getting populated every time I call those functions, I do need to delete entries in the table, otherwise it will get full, and no more UUIDs will be added. So I need to call sd_ble_uuid_vs_remove. 

The documentation for sd_ble_uuid_vs_remove says "Currently this function can only be called with a p_uuid_type set to BLE_UUID_TYPE_UNKNOWN or the last added UUID type." https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.3.0%2Fgroup___b_l_e___c_o_m_m_o_n___f_u_n_c_t_i_o_n_s.html&anchor=gaf9814a42465b2d51fba4aae3a05bdb95

Email with Nordic mentions a further restriction on this API, that "the last added VS base UUID will be removed". 

Since I apparently have no control over which element of the vendor-specific UUID table will be removed by sd_ble_uuid_vs_remove, it seems like my only option is to repeatedly call sd_ble_uuid_vs_remove until all elements are removed. I would do this after I had gathered results from each call to sd_ble_gattc_primary_services_discover or sd_ble_gattc_characteristics_discover.   Pseudo-code would look like this:

Service discovery:

    call sd_ble_gattc_primary_services_discover 

    ... Get all results including UUIDs ..

    Repeatedly call sd_ble_uuid_vs_remove

Characteristic discovery:

    call sd_ble_gattc_characteristics_discover

    ... Get all results including UUIDs ..

    Repeatedly call sd_ble_uuid_vs_remove

Part #2:   Should this approach work? Is there any other way I could use sd_ble_uuid_vs_remove to prevent the vendor-specific UUID table from filling up?

----

I'm currently using pc-ble-driver v4.1.1 from here: https://github.com/NordicSemiconductor/pc-ble-driver/tree/v4.1.1

But even the latest version at that site doesn't implement  sd_ble_uuid_vs_remove

Part #3: where is there a pc-ble-driver that implements sd_ble_uuid_vs_remove and BLE_GATTC_OPT_UUID_DISC?

Thanks,

Paul Bradford

Imprivata, Inc.

[Paul Bradford]

I'm not really sure what you mean by "adding the UUID base into the softdevice".   I need to use this BLE_GATTC_OPT_UUID_DISC feature so I can find the 128-bit UUID of services, and of characteristics - my app needs these 128-bit UUIDs.

[Hung Bui]

Hi Paul, 
Have you checked the link I provided? From there you can find how you can get the 128 bit UUID without the need of BLE_GATTC_OPT_UUID_DISC (you don't need to add base UUID to the softdevice). 

So what you need to do is to read the descriptor of the characteristic/service which contain the UUID of the characteristic/service. For example here is the att table, the UUID descriptor is at the top of the characteristic/service handle.  

How to do it was described in the answer by endnode in one of the case I sent you, here: 

[Paul Bradford]

I know that I can get the 128-bit UUID using sd_ble_gattc_read, but that's slow. That's why I'm using BLE_GATTC_OPT_UUID_DISC. I requested this performance improvement in this case:

https://devzone.nordicsemi.com/f/nordic-q-a/63208/need-better-performance-getting-128-bit-uuids-for-services-and-characteristics

The whole point of my current effort is to use BLE_GATTC_OPT_UUID_DISC instead of having to call sd_ble_gattc_read for each 128-bit UUID.  To effectively use BLE_GATTC_OPT_UUID_DISC, I need to also call sd_ble_uuid_vs_remove so that the vendor-specific UUID table doesn't fill up over time.

[Hung Bui]

Hi Paul, 
I see. It's slightly slower if you discover the 128 bit UUID manually but it allows you to discover unlimited number of service/characteristic. I don't see it as a blocking issue as the end user will most likely not notice the longer time it take to discover the services. 

If you want to use the BLE_GATTC_OPT_UUID_DISC, you would need to implement the api sd_ble_uuid_vs_remove () into the connectivity code. I haven't tried myself but I would assume it should be very similar to other APIs that in the code. 
Another option is to simply disable and enable the softdevice after each disconnection. The draw back is power consumption and a bit of delay time. 

[Paul Bradford]

I will try implementing sd_ble_uuid_vs_remove in the Connectivity code