Tool/software:
According to the Bluetooth spec, the CCC needs to be reset on each new connection:
-
Client Characteristic Configuration (CCC):
The CCC is a descriptor (UUID: 0x2902) that controls whether notifications or indications for a given characteristic are enabled. It is specific to a connection between a central (e.g., smartphone or host device) and a peripheral (e.g., BLE sensor). -
BLE Connections Are Stateless:
In Bluetooth Low Energy (BLE), each connection is treated as independent. When a connection is lost or re-established, all state information related to that connection, including CCC configurations, is lost. -
Requirement to Re-enable Notifications:
After a connection is re-established, the central must again write to the CCC descriptor to enable notifications/indications. This ensures that notifications are only sent with the central’s explicit consent for the current connection session. -
Practical Implication:
- The peripheral must reset the CCC to its default value (usually “disabled”) on connection loss.
- Once the central reconnects, it must reconfigure the CCC if it wants to receive notifications or indications.
It seems that behavior has not been implemented as per spec. I'm using SimpleLink 7.40.0.77. When I establish a connection and enable notifications, then disconnect and re-connect, the notifications are still enabled. I had a look in the provided example code and it would seem it would need a call to GATTServApp_InitCharCfg for each CCC in each service for each new connection, but in your examples this will only ever be called once at startup. I am missing something?
