@William Martin yeah that variability you're seeing is almost certainly the advertising interval on restart, not anything hardware-level with the module itself. When the peripheral wakes from deep sleep and starts advertising, if it's coming up with a conservative interval (say 1-2 seconds between packets) the central could miss several cycles before it catches one — and depending on the central's scan window/scan interval settings, that gap compounds. The 4-5 second worst case is pretty consistent with that math.
The thing worth checking first is whether you're starting advertising with a fast interval on wake-up and then stepping down, or just coming up at a single fixed interval. A common pattern is to advertise aggressively for the first 5-10 seconds (like 20-100ms interval) and then back off if nothing connects — that way you almost always get a sub-second reconnect without hammering power the whole time.
Also worth looking at your central's scan behavior. If it's doing duty-cycled scanning rather than continuous, there's a non-trivial window where it just isn't listening, and that's entirely on the central side regardless of what the peripheral does on wake.
If you're using the AI Firmware Builder in the Dev Hub, honestly just describe your sleep/wake cycle and the reconnect timing you're targeting — it'll generate the advertising state machine with the fast/slow interval handoff already baked in, which saves a lot of trial and error with the timing registers.
