Bluetooth notification and indication state should be persistent

[ghost]

I know persisting data across USB DFU events is not possible today but I wanted to make a note of this issue for when the day arrives when we can.

Flags that enable or disable Bluetooth notifications and indications (i.e. the Client Characteristic Configuration Descriptor values) should be persisted. Right now they're not and this can cause confusion because smartphone clients persist the state at their end leading to a mismatch. e.g. Nordic nRF Master Control Panel could be telling you that indications are enabled for the UART TX characteristic but sending data from micro:bit will not work. Toggle the CCCD value from the smartphone UI and indications will now start working because micro:bit and smartphone states are now synced.

So.... on the glorious day when persisting data across USB DFU events is possible can we please persist CCCD data?

[jamesadevine]

CCCD data is already persisted in MicroBitStorage, coincidentally, @alexk2k12 's firmware persists the storage page used by MicroBitStorage.

P.S. already tested this using the new IF firmware, and it works 😄

(Bonds are maintained through flashes)

[ghost]

So how do you explain my experience just now. Are you sure this is working? It doesn't seem to be. Try it with the UART service as described. It's an easy test.

[jamesadevine]

You don't have the new interface firmware which persists data across flashes!

What experience with CCCD did you come across today?

[jamesadevine]

I definitely was not clear in my previous response, you need the new interface firmware to persist any data across flashes.

[ghost]

Aha. How do I get this marvel of modern technology?

What I saw today:

"e.g. Nordic nRF Master Control Panel could be telling you that indications are enabled for the UART TX characteristic but sending data from micro:bit will not work. Toggle the CCCD value from the smartphone UI and indications will now start working because micro:bit and smartphone states are now synced".

[jamesadevine]

@bluetooth-mdw Currently in beta! 😃

Interesting, I imagine if you conducted the same test on iOS this would be different, perhaps this is because iOS subscribes for CCCD's at bonding... Hmmmm...

Any thoughts @finneyj ?

[finneyj]

Hi @bluetooth-mdw @jamesadevine

Currently only CCCDs for system services and characteristics. Other characteristics aren't peristed at the moment. I think this is what @bluetooth-mdw is seeing, as he's inspecting the UART service.

The challenge we have with micro:bit is that the BLE service set can change at any time, and the Nordic stack is very static with how it allows CCCD data to be read/written. i.e. if the profile changed, any stored CCCD data will be nonsense.

To extend CCCD persistence to all services/characteristics, we'd need to create some sort of unique hash for a BLE profile, so we can invalidate cached data when necessary. We'd also need to ponder how to use MicroBitStorage to store the additional state, as the binary data from SoftDevice will be larger than a single entry... (about 8 bytes per characteristic).

on my soapbox again: hard state in protocols is bad. Bluetooth SIG should really think about whether this is a good idea. History tells us it isn't. :-)

@bluetooth-mdw - is maintaining all CCCD state a requirement in the spec, or just a "good thing" (tm)?

[ghost]

Yes, I see that would be tricky. Not to worry.

FYI the spec says "The Client Characteristic Configuration descriptor value shall be
persistent across connections for bonded devices. The Client Characteristic Configuration descriptor value shall be set to the default value at each connection with non-bonded devices."

I'm not sure this is protocol state per se... GATT is really about device state rather than protocol. But let's stay off those horrid soap box things :-)

I only logged this as a placeholder anyway. Worth noting even if only as a "known issue" so others bumping into what might appear weird behaviour will know what to do.

micro:bit. it's all good