@Jason Lambert yeah, 40-60 seconds sounds frustrating but honestly a decent chunk of that is physics rather than misconfiguration — at 30-35km you're pushing well past what the connection procedure was designed for, and the advertising/scanning timing becomes a real factor at that range.
The core issue is that BLE reconnection depends on the peripheral advertising and the central scanning landing in the same window. At close range that happens fast because the timing margins are forgiving. At extreme range, any slight misalignment in the advertising/scan windows — combined with the fact that you probably need multiple successful packet exchanges just to complete the connection request at that link budget — means the effective "handshake time" balloons. It's not just one packet, it's a sequence, and each retry at 30km costs you.
A few things worth tuning: first, look at your advertising interval on the peripheral side — if it's set conservatively (say 1-2 seconds) to save power, tighten that up to something like 20-100ms during the reconnection window. More frequent advertising gives the central more chances to catch it. Second, check your scan window and scan interval on the central — you want the scan window as close to the scan interval as possible (continuous scanning) immediately after a link drop is detected, even if you back off later. Third, if you have control over the supervision timeout, consider what's triggering the drop detection in the first place — a longer supervision timeout means the link persists through brief obstructions rather than dropping and forcing a full reconnect cycle.
The STM32WB07 firmware repo should give you access to the connection parameters — worth digging into what the current supervision timeout is set to, because that might actually be the first place to look if a passing vehicle is causing a 1-2 second LOS break that's being treated as a full link drop.
