Testing mobile coverage before a call-out

PTT over IP runs on mobile data. That is the honest starting point for any search and rescue team weighing it up, and it means coverage is the one variable that decides whether it works for your ground, not a spec sheet or a vendor's marketing page. A car park with full signal tells you nothing about the valley two ridgelines over where your team actually searches.

Testing coverage properly, before a real call-out depends on it, is the difference between a tool that quietly works in the background and one that fails at the exact moment someone needs to report a position.

Why the car park test is not good enough

It is tempting to check coverage by opening the app in the car park before a training session and calling it done. Car parks tend to sit near roads, and roads tend to have better coverage than the terrain either side of them. A signal check at the meeting point tells you about the meeting point, not about the combe, the forestry block, or the far side of the hill where a search actually happens.

Coverage in the UK's search and rescue terrain varies more within a single search area than most people expect. A route with a clear signal along the ridge can drop to nothing in a steep-sided valley a few hundred metres away. The only way to know is to test the actual ground, on the actual routes your team is likely to search, not a proxy for them.

What to actually test

Walk or drive the routes your team most commonly searches, checking the app at intervals rather than only at the start and end. Note where position updates stop refreshing and where they pick back up. This matters more than a single "does it work here" check at one point, since coverage tends to be patchy rather than uniformly good or bad across a whole route.

Test at different times of day if your call-outs happen at varying hours. Mobile network load can shift coverage quality slightly between a quiet weekday afternoon and a busy Saturday evening, though the terrain itself remains the dominant factor.

Test with the same phones and carriers your volunteers actually use. Coverage varies between networks, and a test on one carrier's signal does not guarantee the same result for a volunteer on a different one.

Reading a stale position correctly

When a position stops updating, the map shows it as stale rather than removing the marker. That is a deliberate design choice: a stale marker is a prompt to call and check in, not proof that anything has gone wrong. Volunteers who have walked into a known dead zone on a familiar route should not need reassurance every time their marker greys out, and coordinators should know from testing which parts of a route are expected to go quiet.

This is exactly why the testing exercise matters. A coordinator who has already walked the route and knows where coverage drops will read a stale marker correctly. One who has never tested the ground may misread a normal coverage gap as an emergency, or worse, dismiss a genuine problem because "that bit's always patchy."

Where RF radio still wins

Nobody should treat PTT over IP as a full replacement for RF radio in terrain with no mobile coverage at all. If your search area includes genuine dead zones, radio remains the tool for that ground, and mixing both is normal rather than a sign the software has failed. Use PTT over IP where mobile data reasonably reaches, and keep radio for the parts of your search area it cannot cover. Most teams that test properly end up running both, deliberately, rather than picking one exclusively.

Building this into training, not just onboarding

Coverage testing is not a one-off task to tick off when a team first signs up. Network coverage changes over time as carriers upgrade infrastructure, and search areas sometimes shift as a team's operating area grows. Revisit the exercise periodically, ideally as part of a normal training session rather than a separate administrative task nobody prioritises.

Common questions

Does coverage testing require any special equipment? No. Walk or drive your usual routes with the phones your volunteers actually carry and watch how the app behaves. No additional hardware is needed for the test itself.

What should we do about known dead zones? Keep RF radio as the primary tool for that specific ground, and treat PTT over IP as the tool for the parts of your search area with reasonable mobile coverage.

How often should we retest coverage? Periodically, especially if your operating area changes or you notice coverage behaving differently than it used to. There is no fixed interval; use judgement based on how much your ground and network conditions actually shift.

Is a stale marker the same as an emergency? No. It means the GPS fix has not updated recently, often because someone is in a coverage gap or indoors. It is a prompt to call, not confirmation that something is wrong.

Run this test on your own ground before your next training session, and pair it with our guide to why consumer apps fail search and rescue call-outs if you are still deciding whether to move off a group chat. The free tier covers a coordinator and one volunteer for the test itself.