This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Support for GATT Caching (as described in BT 5.1)

There are several questions regarding this, most recent I could find from 6 months ago (https://devzone.nordicsemi.com/f/nordic-q-a/81686/is-there-support-for-gatt-caching-in-softdevice-s132_nrf52_7-2-0_softdevice-hex), where the answer was basically "Not supported".

Some other answers have expressed confusion why this is even necessary, or claimed that very few people have expressed the need for this feature. I thought I'd clarify both, and hopefully get an up-to-date answer regarding support for the feature.

The caching, as described in 5.1, differs from the earlier caching done using "Service Change Indication" by allowing caching while not bonded. This is important: When you have public devices that any user must be able to connect to (for example: package lockers), storing the bonding inforation is infeasible. It also increases the likelyhood, that a client's phone will see several different software revisions "in the field", so one can't "assume" a service structure, unless different service UUIDs are advertised (which is it's own can of worms).

This means that the client's phone can not 1. be sure the device hasn't been updated, and 2. use the cached data across the whole fleet of devices.

In practice, this means enabling the Service Changed indication, forcing all phones to always perform full service discovery. This can be several seconds of additional "latency" in establishing a connection.

"Faking" the new feature is also iffy: App developers don't have full control over what the phone BLE stack decides or doesn't decide to do when faced with a device that provides the "Database hash" attribute, but doesn't support the "Robust Caching" response (which AFAIK, is something we can't fake, as it's a Stack, not application functionality?). Robust Caching is mandatory, if both "Database Hash" and "Service Changed" are present. And Service Changed must be present, as otherwise clients have free rein to cache what they want and YOLO.

So: is there a way to support this mechanism on current Nordic BLE chips, using Nordic's precertified SoftDevices? Is it even a SoftDevice funtionality?

PS: "I ask, and I shall answer:" It seems nRF Connect SDK has the functionality: developer.nordicsemi.com/.../index.html


Parents Reply Children
No Data
Related