Every telematics system shows a truck's position down to the second. Still, hardly any service reads it more often than every few minutes. That holds for automatic arrival notification from telematics too. That looks like half the job. It is not.
It is the answer to a simple question. How precise does a position need to be? Precise enough to know one thing: the truck is at the ramp. The answer has nothing to do with the technology. It has to do with the physics of a parked object. A moving truck goes stale with every minute since the last read. A parked truck does not go stale. It sits exactly where the last read placed it.
Take 30 km/h as a baseline. That is roughly how fast a truck moves on the last stretch before a ramp. Inside a town, or on a yard with a speed limit. That works out to 500 meters per minute. At a 15-minute read interval, the last known position can lag by up to 7.5 kilometers.
That is the position lag while driving. It is real. In that window a truck could have missed an exit. It could be stuck in traffic. It could already be at the gate, and the service would not know.
The trick is not to calculate this lag away. The trick is to ignore it once it stops mattering. A parked truck moves zero meters between two reads. 7.5 kilometers of lag while driving becomes zero meters of lag while parked.
A geofence around the ramp captures exactly that state. A guide to geofence radius puts 200 to 400 meters as typical for a yard. Wide enough to cover the yard and the loading bays, not just the office. Arrival then means: position inside the radius, speed near zero, two reads in a row. Not the moment a truck crosses a line. The state that two consecutive reads confirm.
This two-read debounce is not a safety margin. It is the actual trick. GPS jumps sometimes. One bad fix can place a truck inside the wrong building for a single read. One read inside the geofence does not prove arrival. Two in a row, with plausible speed in between, does.
The thinking error behind the demand for second-by-second reads has a name. It treats arrival like a photo. A moment you have to catch, or it is gone. With that picture in your head, you need high frequency. Otherwise you miss the shutter.
Arrival is not a photo, though. It is a state. It holds until the truck moves again. A four-stage state machine captures this cleanly: en route, inside geofence, parked, departed.
The first transition fires on the first read inside the radius. The second transition, from inside geofence to parked, fires on the second read at low speed. That second transition is the arrival notice. It goes to the ramp and the customer. The state falls back to departed once a read lands outside the radius.
Because it is a state, no single second matters. What matters is catching the state inside a reasonable window. At a 15-minute interval, that window is at most 15 minutes wide. For a heads-up to the ramp, that is enough. For a time-slot record in billing, that is enough too. For a second-accurate timestamp behind a contract penalty, it is not. In practice, almost no customer asks for that.
Buying more precision through faster reads sounds obvious. It runs into a wall first, though, one that sits in front of your own infrastructure: the source's own send frequency.
Daimler's Fleetboard service description lists a 3-minute interval for standard positioning. That applies without the Track & Trace add-on, on newer hardware. It used to be 30 minutes. Older onboard computers still record a position every 3 minutes. But they batch 10 positions into one packet. That packet reaches the portal only every 30 minutes. Only a booked Track & Trace service drops the interval to 30 seconds.
Polling faster than the source sends gets you nothing new. You get the same position again. Just more load, on your side and on the vendor's. The rFMS standard, the shared interface built by Daimler, Scania, Iveco, MAN and Volvo, caps the query rate on purpose. One request per minute, maximum. Webfleet sets a generic limit on its API: 10 requests per minute per account. These caps are not accidents. They are a statement from the vendors. More frequency buys nothing once the source stops sending faster.
In one of our own fleets, 77 vehicles, the read interval sits at 5 minutes. We add a 20-minute lookback window as a safety margin against a missed run (own workflow_runs data, 2026-09-14). In a different customer project, the source only delivered a new position every 10 minutes. The read interval there is 15 minutes, published in our case study on arrival notices without calling the driver. The gap between 5 and 15 minutes is not about ambition. It is the measured send frequency of each source, plus a safety margin. Nothing more.
A second oversimplification makes second-by-second reads look necessary. The assumption that every customer wants the exact time at the gate. That is rarely true. Some ramps only need to know when to hold a door open. That is the geofence-based arrival notice. Others want to know when the goods are actually available. That is a different notice. It only comes after unloading, and the telematics position alone cannot answer it.
Treating both notices the same builds a system with two flaws. Too imprecise for one question, too coarse for the other.
That distinction matters in billing too. German freight forwarding terms, the ADSp, allow up to two hours of free loading or unloading time for a 40-tonne truck. Demurrage only kicks in after that. Without a documented arrival time, that window cannot be proven. The state change inside the geofence, logged with a timestamp, is exactly that proof. Not a second-accurate value. A defensible record.
The 15-minute interval does not fail on the technology. It fails in three concrete situations, where the math above breaks down.
First: time slots shorter than the read interval. Slot systems in dock scheduling often run 15, 20 or 30 minutes long. If the read interval is 15 minutes and the slot is too, the arrival notice arrives too late. It comes after the slot has already closed. Here the interval has to sit below the slot length, not above it.
Second: short hauls under 5 kilometers. At 30 km/h, a truck covers 5 kilometers in 10 minutes. A 7.5-kilometer position lag then eats more than the final stretch. It eats the entire trip. For last-mile deliveries inside a city, you need a tighter interval. Or a different signal, such as a driver app with an active confirmation.
Third: ramps placed close together. Overlapping geofences leave too little resolution to assign the right ramp. That is not a case for a faster interval across the whole fleet. It is a case for an adaptive interval. Once a vehicle nears a dense ramp cluster, the service switches to a tighter interval there. The rest of the fleet keeps the standard pace.
The conclusion for a fleet or dispatch team is not "read as fast as possible." It is: check the actual send frequency of your own telematics. Define the two or three notices you actually need. For the edge cases, short time slots, short hauls, dense ramps, build in a tighter interval on purpose. Not across the whole fleet by default.
The rest of the fleet runs on the interval the source delivers anyway. That is almost always enough.
What interval does your telematics actually deliver? And what counts as arrival for you, the gate or the finished unload? Send me both. I will show you what the first notice would look like on our protocol. Request a process check, 30 minutes, no sales pitch.
