Skip to content

Geofence Buffers and Dwell Time: Sizing a Boundary for Real GPS Error

By Saeed Baatiah · Published:

Short answer

Draw the geofence on the real boundary, then widen it by the positioning error you actually get at that site, not by the published two-metre figure, which excludes buildings and reflections. Then require the vehicle to remain inside for a set time before the arrival event fires. Both steps are needed.

Key takeaways

  • The US Government commitment is a signal-in-space user range error of 2.0 m or better at 95% probability, a satellite-side figure, not what a receiver achieves.
  • GPS.gov itself names the excluded factors: signal blockage by buildings, bridges and trees, multipath off walls, atmosphere and receiver quality.
  • Peer-reviewed measurements in deep urban canyons exceed 50 metres, and about 15 m 2D average remains even with 3D-mapping-aided correction.
  • A buffer alone still fires on a vehicle passing the gate, so pair it with dwell time, the vehicle must stay inside before the event counts.
  • Teltonika's AutoGeofence activation timeout defaults to 5 minutes, and the timeout pauses if a GNSS fix is achieved.

01What the published accuracy figure actually covers

Almost every discussion of geofence accuracy starts from the wrong number. The figure most often quoted comes from GPS.gov, and it is a signal-in-space user range error of 2.0 metres or better at 95% probability, with a measured value of 0.643 metres recorded on 20 April 2021. That is a commitment about the quality of the signal as it leaves the constellation, and it is genuinely excellent. It is also not a promise about where your truck appears on a map. GPS.gov states the exclusion itself, listing the local factors that determine achieved accuracy: signal blockage by buildings, bridges and trees, multipath reflection off buildings or walls, atmospheric conditions and receiver quality. A geofence buffer sized against the two-metre figure has therefore been sized against a number that explicitly does not include the site the fence is drawn on.

02What the error becomes near buildings

The gap between the two numbers is large enough to change every design decision. A peer-reviewed study in IEEE Sensors Journal measured positioning error in deep urban canyons at more than 50 metres, and found that roughly 15 metres of two-dimensional average error remained even with 3D-mapping-aided correction applied. The same work notes that receiver-side multipath mitigation has less capability against non-line-of-sight reception specifically, so several tens of metres of error can persist. Read that against a typical depot: a fence drawn tightly on a yard between two warehouse blocks, or a delivery point on a street with towers on both sides, sits in exactly the geometry the study describes. The practical conclusion is that the buffer is not a courtesy margin. It is the difference between a boundary that works and one that reports arrivals and departures no vehicle made.

03Why a buffer alone is not enough

Widening the fence solves one failure and creates another. A generous buffer stops a parked vehicle from drifting across the line, but it also means the fence now covers road the vehicle merely drives along. A truck passing the gate on its way somewhere else crosses the widened boundary, and an arrival event fires for a stop that never happened. Enlarge the buffer further and the problem gets worse rather than better, because the fence intercepts more traffic. This is the structural reason a geofence needs a second, independent condition. Space alone cannot separate arriving from passing, since both are the same sequence of positions; the thing that distinguishes them is how long the vehicle remains. Dwell time supplies exactly that, and it is why tuning a geofence by adjusting radius alone eventually stops improving anything.

04How dwell time is implemented on the device

Dwell logic already exists in tracker firmware, and it is worth using rather than rebuilding in a server. Teltonika's AutoGeofence carries an activation timeout with a default of 5 minutes and a range up to 65,535, and the documentation notes that the timeout pauses if a GNSS fix is achieved, so the delay is not simply a countdown but a state that responds to whether the device knows where it is. The same firmware offers a general On Hysteresis operand for input-driven alerts, which records only on crossing a high limit from below a low limit or the reverse, and duration gates such as a towing default of 1,000 milliseconds. All three mechanisms encode the same principle: a boundary crossing becomes an event only after it has demonstrated persistence, and persistence is cheaper to require at the device than to reconstruct later.

05Sizing the buffer for a specific site

Because the achieved error is a property of the location, the buffer should be too. Rather than applying one radius to every fence, measure. Park a vehicle at the point where you want the boundary, leave it stationary with the tracker reporting normally for a working day, and look at the spread of the recorded positions. That scatter is the site's own error, and it already includes the building geometry, the reflections and the receiver in use. Set the buffer to comfortably contain it. A open desert yard will need very little; a fence between two tall blocks may need tens of metres, consistent with the urban-canyon measurements. Recording the measured spread alongside each fence also gives you something to re-check when a site changes, a new building next door genuinely alters the number.

06Choosing the dwell value from the operation

The dwell threshold is not a technical parameter; it is a description of what a real visit looks like at that site. A bulk loading bay where the shortest genuine turnaround is twenty minutes can safely require several minutes inside the fence before an arrival is confirmed, and nothing legitimate will be missed. A parcel drop where the driver is gone in ninety seconds cannot use the same value, or every real delivery is discarded. So read the operation first and pick a dwell time comfortably shorter than the shortest genuine visit, then comfortably longer than the time a passing vehicle spends inside the buffer. Where those two windows overlap and no value separates them, the fence geometry is the problem, the boundary is intercepting a through route, and it needs redrawing rather than retiming.

07A checklist before you draw the next fence

The whole method fits in five steps. First, draw the boundary on the real feature, the gate, the yard edge, the bay, rather than on a rounded circle that is convenient on the map. Second, measure the stationary scatter at that point over a working day and take that as the site error. Third, set the buffer to contain the scatter, not to match the published two-metre commitment, which excludes the local factors. Fourth, set a dwell time between the shortest genuine visit and the longest transit through the buffer, using the device timeout where the firmware provides one. Fifth, review the fences that produce the most events after a month, a fence generating far more arrivals than the site sees visits is telling you which of the two settings is still wrong.

Which failure each setting fixes, and which it cannot
Failure seenCauseBuffer helps?Dwell time helps?
Parked vehicle exits and re-enters all nightPosition scatter across the lineYes, the main fixPartly
Arrival reported for a vehicle that drove pastFence intercepts a through routeNo, makes it worseYes
Arrival missed at a very short stopDwell set longer than the visitNoYes, lower it
Events cluster near tall buildings onlyMultipath and blocked signalYes, per siteYes
Stop reported during a signal lossNo fix, treated as no movementNoAccelerometer fallback
Both false arrivals and missed ones at one siteFence geometry, not timingNoNo, redraw it

Figures and sources

  • The US Government GPS accuracy commitment, and what kind of figure it is: signal-in-space user range error ≤ 2.0 m at 95% probability (0.643 m measured 2021-04-20) (Source: GPS.gov, GPS Accuracy, as of 2026-08-31)
  • Local factors GPS.gov names as determining achieved accuracy, excluded from the 2 m figure: signal blockage by buildings, bridges and trees; multipath off buildings or walls; atmosphere; receiver quality (Source: GPS.gov, GPS Accuracy, as of 2026-08-31)
  • Measured GNSS positioning error in deep urban canyons, peer-reviewed: more than 50 metres; ~15 m 2D average even with 3D-mapping-aided correction (Source: Ng, Zhang & Hsu, IEEE Sensors Journal 21(16):18307–18317 (2021), as of 2026-08-31)
  • Limit of receiver-side multipath mitigation against non-line-of-sight reception: less capability against NLOS; several tens of metres of error can remain (Source: Ng, Zhang & Hsu, IEEE Sensors Journal 21(16) (2021), as of 2026-08-31)
  • AutoGeofence activation timeout, and its documented role during a GNSS fix loss: default 5 minutes, range 0–65,535; timeout pauses if GNSS fix is achieved (Source: Teltonika Telematics Wiki, FMB920 Auto Geofence settings, as of 2026-08-31)
  • True dual-threshold hysteresis operand available on any I/O-driven alert: operand "On Hysteresis": record only on crossing the high limit from below the low limit, or vice versa (Source: Teltonika Telematics Wiki, FMB920 I/O settings, as of 2026-08-31)
  • Minimum-event-duration gate showing how a persistence requirement is expressed on the device: towing Duration default 1,000 ms (range 1–5,000) (Source: Teltonika Telematics Wiki, FMC003 Accelerometer Features settings, as of 2026-08-31)
  • Teltonika fallback preventing a GPS dropout from reading as a stop inside a fence: when there is no GPS fix, movement is determined from accelerometer data (Source: Teltonika Telematics Wiki, FMC920 Accelerometer Features settings, as of 2026-08-31)
  • Teltonika FMC003 GNSS accuracy in our catalogue, the receiver-side figure for a cabin install: < 2.5 m CEP; GPS, GLONASS, GALILEO, BeiDou (Source: ENTEK.AI product catalogue, as of 2026-08-31)

Questions

Is GPS accurate to two metres or not?

The 2.0 m figure at 95% is a signal-in-space commitment about the constellation, and GPS.gov itself lists what it excludes, buildings, bridges, trees, multipath off walls, atmosphere and receiver quality. What a tracker achieves at a specific yard is a different, larger number, and it is the one your buffer has to accommodate.

How big should the buffer be?

Measure rather than guess. Park a vehicle at the boundary point for a working day with the tracker reporting normally, and look at the spread of positions, that scatter is the site's own error, buildings and receiver included. An open desert yard needs very little; a fence between tall blocks may need tens of metres.

Why not just make the geofence very large?

Because a larger fence covers more road, so more vehicles that are merely passing cross the boundary and generate arrival events for visits that never happened. Enlarging past a point makes the alert worse, not better. That is exactly the failure dwell time exists to solve.

What dwell time should I set?

Comfortably shorter than the shortest genuine visit at that site, and comfortably longer than the time a passing vehicle spends inside the buffer. Teltonika's AutoGeofence timeout defaults to 5 minutes as a reference point. If no value separates the two windows, the fence is intercepting a through route and needs redrawing.

Sources

Related insights