GATT Caching on Unicast Client

[Omri]

Hi,

I'm using the nRF5340 Audio application under NCS v2.5.0 as Unicast client.

I want to use the GATT Caching feature on my application.

How should I implement it? is it only by "CONFIG_BT_GATT_CACHING=y"?

I saw in the NCS v2.5.0 release notes the following known issue:

NCSDK-19865: GATT Robust Caching issues for bonded peers
  The Client Supported Features value written by a bonded peer may not be stored in the non-volatile memory.
  Change awareness of the bonded peer is lost on reboot.
  After reboot, each bonded peer is initially marked as change-unaware.

  **Workaround:** Disable the GATT Caching feature (:kconfig:option:`CONFIG_BT_GATT_CACHING`).

Do you recommend not to use the GATT Caching on NCS v2.5.0?

Regards,

Omri.

[dejans]

Hi Omri,

The issue with GATT Caching you are referring to is quite old. It was valid around the NCS v2.3.0 and it seems to have been fixed since then.
Please let me know if you see any issue with it when trying to use it in NCS v2.5.0.

Best regards,
Dejan

[Omri]

Thanks Dejan,

Should I only enable the GATT Caching by  "CONFIG_BT_GATT_CACHING=y"?

[dejans]

Hi Omri,

Enabling CONFIG_BT_GATT_CACHING should be enough, just ensure that all dependencies are satisfied.

Best regards,
Dejan

[Omri]

Hi Dejan,

I’d like to clarify my previous question. Our application, which plays a central role, needs to reduce connection time by using the GATT caching feature.

The goal is to store a local copy of the remote database structure and reuse it during subsequent connections.

Is there anything specific the application should do before or during the connection process, or is it enough to simply enable `CONFIG_BT_GATT_CACHING`?

Regards,

Omri.

[dejans]

Hi Omri,

Zephyr host does not do any actual caching. The application on the client side must store the handles themselves, handle reading database hash and receiving service changed indications.

Best regards,
Dejan