CCCD and sd_ble_gatts_sys_attr_get

[Marcel Mulder]

I need to remember the CCCD's of some service, e.g. service changed. A CCCD is according to spec 2 bytes long. The method to do this is by using sd_ble_gatts_sys_attr_get. This function returns a binary blob which is not documented. The amount of data returned is, depending of how many characteristics you use, huge. Somewhere around 100 bytes. I don't want to store all this information for actually 1 bit, the indication config bit of service changed. Is there information available how this data is formatted? Or do I have to reverse engineer it?

Why is it implemented like this. Why not a function in the SD which can get or set the client characteristic configuration per handle? Or combine client and server characteristic configuration. This only has to return a 32 bits value.

Yes, I know there is BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS in SD v8 but going to SD v8 is not an option at the moment for my.

[Carles]

Hi there,

The reason we don't allow individually setting the CCCD values is that per the spec you need to remember all of them for a bonded device. You're still allowed to get them one by one though.

For the Service Changed user case as you already mentioned we have solved this in 8.0.0 by adding the new flags in the sys attr get and set functions.

Carles

[Marcel Mulder]

But this does not solve my problem. The only answer I get is use 8.0.0 but as I mentioned this is currently not an option. Leaves the unanswered questions:

1. Why is the data returned from sd_ble_gatts_sys_attr_get so huge?
2. As you mention I am still allowed to get them one by one. How?

Another remark: Per spec the CCCD's are persistent, I know, but why is then everybody using sd_ble_gatts_sys_attr_set(conn_handle, NULL, 0)? Including the Nordic examples? I worked with CSR also here is does not happen.

Marcel

[Carles]

1. Because you probably have a bunch of user CCCDs (i.e. characteristics that you have added that are either notifiable or indicatable or both), so those are all stored there along with the metadata that goes with them.
2. Use sd_ble_gatts_value_get() with the handle of the CCCD that interests you

I guess the examples you mention do not support bonding. CCCDs are only persistent if you are bonded with the device in question.

I will not comment about other implementations on the market, but we are open to suggestions to improve our own. I've created an internal ticket to consider allowing setting individual CCCDs by using sd_ble_gatts_value_set().

[Marcel Mulder]

Thank you! Off course the CCC is also only a value :)

As regarding to point 1. My point here is that I don't need all the metadata. Most (not all) of the meta data is readonly and set by the code itself. So this is information I already know. If you could only provide information which changes it will be a lot less. Writable Characteristics are (except value and description, you don't have to persist those):

• Client Characteristic Configuration bit field definition
• Server Characteristic Configuration declaration

That's 32 bits, or am I wrong?

Marcel

[Carles]

I understand what you mean. The system attributes API was designed to cover a few use cases and to future proof it when it was originally introduced, but as time goes by and use cases evolve we try to adapt our APIs to the current trends as to best fit the current batch of applications. You only really need to persist CCCDs according to spec, and that is all there is in the system attributes. The metadata is however necessary because between the time you call sys_attr_get() and sys_attr_set() the layout of the attribute table could have been modified (if you've for example reset the SD and populated the table with different attributes). Each CCCD is 16-bit, but we add a few other metadata fields that make the size of the sys attrs grow like you are now seeing. Allowing sd_ble_gatts_value_set() to set CCCD values would alleviate your problem considerably.