Gaps, Dead Zones and Missing Data

The most consequential ambiguity in this field is a gap in the record. It has several ordinary causes and one suspicious one, and the system cannot distinguish them.

Why gaps happen

No satellite fix: underground car parks, covered yards, tall buildings, dense tree cover, inside large buildings.

No mobile coverage to transmit, so data queues and arrives later with an old timestamp.

Device powered down with the vehicle, on units that sleep with the ignition.

Battery saving on phone apps, which reduces fix frequency silently.

Operating system restrictions on background location, which tighten with every phone update.

Device fault, which is more common than people expect in vehicles that vibrate all day.

And deliberate disabling, which is one cause among seven.

The assumption that causes trouble

A gap read as evasion.

Employers have acted on gaps and found the explanation was a car park, which is an expensive way to learn.

Where a gap matters, investigate it as a question rather than as a finding: where was the vehicle meant to be, is that location known to be poor for signal, do other vehicles show gaps there?

Map your own dead zones. After a month you will know them, and a gap in a known dead zone stops being interesting.

Distinguishing the causes

A transmitted gap looks different from a fix gap. Data arriving late in a batch indicates coverage; no data at all indicates no fix or no device.

Ignition status, where the device reports it, separates parked from disabled.

Device health reporting — voltage, last heartbeat — distinguishes a fault from a disconnection.

Ask the vendor what the system can distinguish, because products differ substantially and most interfaces show a blank either way.

Disabling as a disciplinary matter

Some employers treat any gap as misconduct. This is where cases go badly, because the causes above are real.

If removal is permitted for personal use — which is the sensible arrangement — then gaps are expected and cannot also be evidence.

Write down which is which: if the plug-in device may be removed for private journeys, say so, and then a gap during working hours is a different question from a gap on a Sunday.

Where a genuine pattern exists, it is a conversation, and it will usually produce the explanation in the first minute.

What to build in

A known dead zone list, maintained.

Device health monitoring, so a fault is detected as a fault.

A tolerance in any report, because a system reporting ninety-eight percent coverage is working well and one demanding a hundred will generate constant false findings.

And a rule that gaps are questions, not conclusions, stated in the policy where everyone can see it.

Map your own

A month of observation that removes a whole category of false finding.

Note where gaps recur: the multi-storey, the depot with the metal roof, the rural valley, the customer with underground parking.

Keep the list and share it with whoever reviews reports.

A gap in a known dead zone stops being interesting, which is the point.

And a gap somewhere new becomes worth a question, which it should be.

Turn the principle into a test

For an example that can make this requirement testable, consult this operational use case. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, failures and permissions.

Independent reference

For an external point of reference, see Ofcom. The communications regulator is a relevant external source when considering coverage claims and connectivity limitations.