@Brittany Thompson yeah this is exactly the right question to be asking before you deploy, because getting the supervision timeout wrong at that range will absolutely wreck your power budget.
The short answer is: don't try to keep a traditional connected BLE link alive through 5-second sleep cycles at 8-12km. The supervision timeout math doesn't work in your favor — you'd need to set it long enough to survive the sleep interval plus any retry overhead from marginal RF conditions (and with tree cover in a semi-rural environment, you'll get multipath and attenuation events that eat into your link margin unpredictably). That means either a very long timeout that keeps the radio partially awake burning current, or constant reconnects when the link drops mid-cycle.
What actually works better for this use case is treating each wake cycle as a fresh advertisement/scan burst rather than trying to maintain a persistent connection. The MultiNav Pro+ can wake, advertise at high TX power, connect, push your sensor payload, and drop the link — all within a tight window. At 8-12km ground-to-ground with the module's receiver sensitivity, a clean connect-transfer-disconnect cycle is surprisingly fast once you tune the advertising interval down during the active window. You avoid the supervision timeout problem entirely because you're not asking BLE to hold state through a period where the radio is physically off.
If you really want persistent connection semantics, the other option is to set your connection interval to match your sleep cycle (so 5s connection interval, peripheral sleeps between events, radio only wakes for scheduled connection events) and set supervision timeout to something like 6-8x your connection interval as a starting point, then tune up from there based on how often you see link loss in your specific environment. But honestly for a sensor deployment at that range, the advertise-connect-transfer pattern is going to be more robust and you'll spend less time fighting the stack.
