@kristin hink great question, and honestly this is one of the more nuanced things to reason about with the STM32WB07 stack at range limits.
The short answer is yes, there's observable behavior before you actually drop — you don't have to wait for a supervision timeout to know things are degrading. The BLE LL will silently retry within a connection event (up to the retransmission limit), but what you can track is the RSSI trend and, more usefully, the connection event counter alongside missed event counts. On the WB07 stack you can hook into the `hci_le_read_rssi` call periodically, but the more telling signal is watching for `HCI_LE_CONNECTION_UPDATE_COMPLETE` events and tracking how often your central is having to stretch the supervision window — that's usually the first sign the link is getting marginal before you see actual packet loss at the application layer.
For your specific use case — moving node, fixed base, 30-40km transects — I'd strongly recommend building a lightweight link quality monitor that logs RSSI + connection event success rate on a rolling window, and sets a soft alert threshold well before you'd hit supervision timeout. The firmware repo has the connection event hooks exposed, so you can instrument that without touching the core stack logic. Check the GitHub at github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07 — the connection management examples are a reasonable starting point for where to inject that monitoring.
What's your current connection interval set to? At those distances with a moving node, the interval and supervision timeout tuning matters a lot for how gracefully the link degrades versus how aggressively it drops.
