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.

[Hung Bui]

Hi Paul, 

Could you give more information about the application you are building ? I assume you plan to build something similar to our nRF Connect for desktop ? 

sd_ble_uuid_vs_remove() only supports to remove the last added Vendor Specific base UUID. So if you want to be sure that you will have the full table to store new UUID base you need to call until you receive NRF_ERROR_FORBIDDEN ( i haven't tried this but I assume it will return this error when the table is empty).

My idea is that before you connect to a new peripheral you can empty the table and will have a whole free table to add more UUID base. 
How many UUID bases do you expect from a peripheral ? As far as I know you can get up to 17 UUID bases in the table. 

Regarding your question about pc-ble-driver and sd_ble_uuid_vs_remove, it seems that it's not been implemented. But it should be possible to add the function and compile your own version of the connectivity firmware. 

[Paul Bradford]

It does not seem that the SDK implements either of these necessary pieces:

1. There is no serialization code for sd_ble_uuid_vs_remove in the SDK

2. The BLE_GATTC_OPT_UUID_DISC option to sd_ble_opt_set also has no serialization code in the SDK.

I am having a conversation with Mariano Goluboff (Field Application Engineer at Nordic) about this.

[Hung Bui]

Hi Paul, 

The serialization code was made as an example of using nRF52 as a connectivity chip, it may not cover all the APIs. From my point of view it's pretty straight forward to implement the missing functions. 

However, for your purpose, I'm not so sure if we do need to add the UUID base into the softdevice or not. The most important is to discovery the UUID and the handle of the characteristic in the peer device. As far as I know this can be done without adding the UUID base into the softdevice. 
We have some discussion on this a few years back. You can have a look here and here. 

[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.