Hello Nordic Engineers!
Thank you in advance for your time and advice.
===== Overview =====
I'm developing (sort of) a Bluetooth mouse using the nRF Desktop Application as a jumping-off point. I've run into an undesirable program state and I'm not sure how to go about handling / preventing it.
It's possible to enter a state where the central (e.g. your computer) has forgotten the device (dev kit), yet the device is using directed advertising towards that computer. That directed advertising makes the device invisible to anyone (else) searching for it, including the central that just forgot it (biggest issue).
The only way out of this state that we've found is to manually run a peer erase, which is acceptable, but not overtly obvious (especially to an end user).
Ultimately, I'd like to have a "Bluetooth No Connection Indicator" that is distinct from "Bluetooth Advertising" -- with this, I can inform the user via LED that the device is looking for a specific connection that it hasn't found yet. That indicator will prompt the user to either run a Peer Erase Operation, connect to the dedicated device (in the case where the bonded central is just "off"), or switch to an unoccupied peer identity with our peer swap button (in the case that the user wants to add a second supported central).
===== Environment =====
Here are my environment details:
nRF52840DK (development environment)
which will transition to Xiao BLE Sense for (production environment)
Using Nordic's SDK v2.5.0 (installed via nRF Connect Desktop App)
(Though I'm willing to switch to 2.6.Latest if there is a fix there)
Running in VS Code, Win 11 Host Machine, MINGW Bash environment
===== Questions =====
Preamble to question:
Connecting to our device from a central causes the device store some bond data. When the central disconnects from that device, the information persists, which is desirable. However, once the device resets (e.g. Device Power Management / User switches "Off"), that information still persists, but is no longer available to the user (my) application (that I can find). The device doesn't automatically reconnect (which makes sense since the central dropped it), but also doesn't show as available on either the (former) central or other scanning devices.
In summary: the problem state occurs when the central disconnects, then the peripheral resets, which causes the device to become invisible until a peer erase. I'd like to indicate that the device is in this state, despite device resets.
Question:
How can I access that information from my application modules?
I would be happy for a way to query:
1. The current bt_conn object, so I can check it's connection status and use its security (level) information to judge if that connection is "occupied" by a bond
2. The ble_adv data, so I can determine if the advertising is directed
3. The generic "ble settings / bond settings" persistent information -- to determine which identities are "occupied"
Where I'm stuck:
When my device boots, I get quite a lot of events about the startup of the device. Notably, though, I do not see an event whose structure contains info on (1), (2), or (3) above that might let me infer the current saved-information state.
Those only occur once I actually run a connect operation, which isn't possible if the device is already directed advertising to a computer that ignores it.
Thanks again for any advice you can give!
============
Wishing you all a happy weekend,
- Finn
