@Shannon Vazquez yeah this is a classic STM32WB07 supervision timeout edge case — what you're describing with the peripheral "sitting there" instead of auto-advertising after a drop is almost certainly the central holding a stale connection handle rather than the peripheral misbehaving.
The way BLE connection supervision works, if the central doesn't formally detect the link loss before its supervision timeout fires, it can stay in a connected state internally while the peripheral has already moved on (or vice versa). At 30-35km you're probably right on the edge where the supervision timeout interval matters a lot — if your connection interval and supervision timeout multiplier are set conservatively, the central might not declare the link dead fast enough, so the peripheral never gets a clean disconnect event to trigger re-advertising.
Worth checking two things in the firmware: first, what your supervision timeout is set to relative to your connection interval, and second, whether your peripheral firmware has an explicit "on disconnect" handler that kicks off advertising immediately. The GitHub repo has the STM32WB07 firmware source so you can dig into exactly how the disconnect event is handled — if the advertising restart is conditional on receiving a proper HCI disconnect event and that event never arrives cleanly, that would explain the inconsistency you're seeing.
Quick field workaround while you sort it: bump your supervision timeout down so the central declares link loss faster, or add a watchdog on the peripheral side that monitors connection state and force-restarts advertising if it's been in a "connected but no packets" state for more than a few seconds.
