MultiNav Pro+ BLE - link re-establishment time after a dropout at long range?

@Peter Adkins yeah that reconnection window is a known pain point at those ranges — the issue is mostly on the BLE advertising side. After a dropout, the peripheral goes back to advertising and the central has to catch those packets, but at 30-35km the link margin is tight enough that the first several advertising events can get missed entirely, so you're basically waiting for a lucky window where conditions are favorable enough to complete the handshake.

 

The main lever you have in firmware is advertising interval and the scan window/interval on the central side. If you haven't already, try dropping the advertising interval on the peripheral significantly — the tradeoff is power draw but if your node is powered you can afford to advertise more aggressively after a disconnect event. On the central side, widen the scan window so you're not missing advertising packets during the brief moments the link margin is there.

 

The GitHub repo has the STM32WB07 firmware source so you can dig into the connection parameter handling directly — worth looking at how the disconnect event triggers the re-advertising sequence and whether there's any backoff logic that's stretching your recovery time. If there's an exponential backoff on advertising after repeated failures, that alone could explain the variance you're seeing between 45 seconds and a few minutes.

 

What's your current advertising interval set to, and are you running any custom reconnection logic in the application layer or relying purely on the stack defaults?

Honestly 45 seconds to a few minutes at that range isn't shocking - the retry backoff tends to get pretty aggressive when RSSI has been marginal, basically the stack assumes the node is gone and slows its reconnect attempts way down. Worth digging into your connection interval and supervision timeout settings if you haven't already, tightening the supervision timeout in particular can help it declare the link dead faster and kick off a fresh scan/advertise cycle sooner rather than just sitting there waiting. Also curious if you're seeing the central or the peripheral side driving the reconnect, because that changes where you'd want to tune things.

Larry's point about supervision timeout is spot on - I'd also check whether your peripheral is advertising aggressively enough after it detects the drop, because at that range if it drops back to a slow adv interval (like 1-2 seconds) you can easily burn a minute just in the discovery phase before you even get to the connection attempt. What adv interval are you running post-disconnect?