@Brittany Thompson yeah that variability is almost certainly your advertising interval on the peripheral side. When the link drops, the peripheral falls back to advertising and the central starts scanning, but if they're not in sync on timing — especially with the default advertising intervals which are pretty conservative — you can get these huge gaps where the scanner just misses the advertising window entirely. 30 seconds is pretty classic for that.
The fix that works best in this scenario is dropping your advertising interval way down on reconnect (something like 20-50ms) and keeping it there for maybe 10-15 seconds, then backing off if nothing connects. It burns more power but you're not in a steady connection state anyway, so it's a reasonable trade. On the central side, if you're not already running continuous scanning during the outage window, that's the other half of the problem — default scan windows often have duty cycles that make the timing mismatch even worse.
The STM32WB07 firmware repo is on GitHub (there's a link in the resources section) so you can get into the actual GAP parameters directly rather than fighting the stack defaults. Worth pulling the connection event timing logs too if you haven't — the variance in your reconnect times suggests it's probabilistic rather than a consistent timeout, which points squarely at advertising/scan window mismatch rather than something deeper in the stack.
