A Bluetooth characteristic can be read, but its notifications stop after a reconnect. Which state and return values should a Silicon Labs application inspect before assuming that the radio link has failed?
Silicon Labs MCUs DISCUSSION
A GATT characteristic reads correctly but notifications stop: what should be logged?
3 replies
248 views
4 participants
Latest activity · 27 Sep 2026A GATT characteristic reads correctly but notifications stop: what should be logged?
Re: A GATT characteristic reads correctly but notifications stop: what should be logged?
#2Track the connection identity and the client's notification subscription for the relevant characteristic. A successful read does not prove that the client has enabled notifications. Reconnection and bonding behavior should be handled according to the stack's documented state and security model.
Re: A GATT characteristic reads correctly but notifications stop: what should be logged?
#3Check the send operation's status and any stack flow-control events. If production exceeds the available delivery rate, an application needs a bounded queue or an explicit latest-value policy. Repeatedly attempting sends without checking their outcome can conceal the original resource or state error.
Re: A GATT characteristic reads correctly but notifications stop: what should be logged?
#4Log sequence numbers at acquisition, send acceptance and reception. Test unsubscribe, disconnect and reconnect deliberately. Keep the GATT database version and client cache behavior in the investigation when the service layout has changed between firmware versions.