Difference between sd_ble_gatts_sys_attr_set() flags

[brianreinhold]

I am getting killed by the fact I cannot restore the CCCDs on a bonded reconnect and need to rely on the client doing it every connection - a violation of the standard.

I am using the ble_pc_driver.

So out of desperation I am asking what is the difference between doing the set operation with the following flag options?

sd_ble_gatts_sys_attr_set(m_adapter, p_ble_evt->evt.gap_evt.conn_handle, saveDataBuffer,
saveDataLength, BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS | BLE_GATTS_SYS_ATTR_FLAG_USR_SRVCS); 

sd_ble_gatts_sys_attr_set(m_adapter, p_ble_evt->evt.gap_evt.conn_handle, saveDataBuffer,
saveDataLength, BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS);

sd_ble_gatts_sys_attr_set(m_adapter, p_ble_evt->evt.gap_evt.conn_handle, saveDataBuffer,
saveDataLength, BLE_GATTS_SYS_ATTR_FLAG_USR_SRVCS);

sd_ble_gatts_sys_attr_set(m_adapter, p_ble_evt->evt.gap_evt.conn_handle, saveDataBuffer,
saveDataLength, 0);

The limited documentation on this method does not really explain what these different options will do.

The 'aveDataBuffer' has the results of the 'get' analog of this call obtained during the disconnect event of the previous connection. The contents of saveDataBuffer look valid.

SO far, no matter what I do, I cannot indicate/notify characteristics without having the client 'enable' the CCCDs every connection. 

Anybody know? 

Anybody ever get this to work?

[Einar Thorsrud]

Hi,

The SoftDevice does not store any information specifically for a bond or peer etc between connections, so this is the responsibility of the user. When using the nRF5 SDK this is handled by the peer manager library. We do not provide any similar library for the PC side (pc-ble-driver), so you have to implement this yourself.

[brianreinhold]

I do. I save the data on a disconnect indication and retrieve from a file before I start advertising. That along with pairing info.

Looks valid

[Einar Thorsrud]

Hi,

I see. Does the data include both user and sys attributes? If you want to do it generically (without knowing), you should modify the flags and try again, as you can see is done in the peer manager implementation in the do while loop in gscm_local_db_cache_apply() in <SDK>\components\ble\peer_manager\gatts_cache_manager.c.

[brianreinhold]

I have done all the obvious combinations and from the data I retrieve using the 'get' method during the disconnect (which I save to a file) the combination of both flags seems to be the 'most' correct. At least I see both the service-changed and measurement handles in the array of bytes. When I do just the system flag I only get the service-changed handle.

But in the end it doesn't matter. When I call the set method I use the same set of flags but it doesn't work. However, I have no way to know what the set method does with these flag settings (at least I can look at the result when I do the get). Should the set call be done with flags = 0 regardless of the flags used in the get? I think I have tried that too and it didn't work either.

[Einar Thorsrud]

Hi,

I see. Can you show the full code you use around sd_ble_gatts_sys_attr_set()? Do you check the return values?