Guide · GPS tracking
Your rural GPS tracker is not live: it is store-and-forward.
You fit a long-range GPS tracker to the ute or a bit of gear, watch it on the map, and assume you are seeing where it is right now. On a rural LoRaWAN tracker you are often not: it is a store-and-forward device, and the dot you are looking at may be where it was hours ago. Here is why, from a real trip we decoded.
Last reviewed: 21 July 2026 · by Rural IoT
What store-and-forward actually means
A LoRaWAN tracker, the low-power long-range kind that runs for months on a small battery, only gets its fixes back to you when it is in range of a gateway: your base station at the house or shed, or a wider network of them.
Drive out of that range and the GPS does not stop working. The device keeps taking fixes and stores them on board. Then the moment it comes back into range of a gateway, it forwards the whole backlog, oldest first, until the buffer is empty. Store, then forward. That is the design, and it is the right design for a device that has to sip battery and cannot assume constant coverage.
The catch is that the map only updates when the forwarding happens. In between, the tracker is logging happily to itself and telling you nothing.
The real trip we decoded
On an actual trip, we drove well out of range of the home gateway and back. The fixes were not lost: they came in later, in a rush, once the tracker was home and could talk to the gateway again.
When we lined up each fix's capture time against when it actually arrived, the upload lag told the whole story:
Fixes taken near the end of the trip arrived roughly two hours after they were captured, not long after we got back in range.
Fixes taken deepest into the trip, the ones that had sat in the buffer longest, arrived nearly nine hours late.
That spread is the buffer draining oldest-first. The device had a queue of stored fixes and worked through it in order once it had a link. Nothing was missing; everything was just late, by an amount that depended on how long each fix had been waiting.
Why it happens, and why it is fine for logging
None of this is a fault. It is the trade-off that makes the tracker last.
No coverage out there means nowhere to send. With no gateway in range, forwarding immediately is physically impossible. Buffering is the only option.
Sending is the expensive part. Radio transmits are what drain a battery. A tracker that logs quietly and forwards in a batch when it can uses a fraction of the power of one trying to phone home every minute. That is how it runs for months.
So for logging where an asset went, whether the trailer left the property, what route the gear took, when it came back, store-and-forward is perfectly fine and barely touches the battery. You get the full track; you just get it retrospectively. It is the same low-power logic behind how LoRa sensor monitoring works.
Live vs logging, pick the right tool
The mistake is expecting live tracking from a device built for logging. If you genuinely need to know where something is right now, theft in progress, someone's safety, live dispatch, LoRaWAN store-and-forward is the wrong tool. You need actual network coverage at the asset.
| You need | Use | Because |
|---|---|---|
| Where it went (a log) | LoRaWAN tracker plus your gateway | Sips battery, months of runtime, coverage optional |
| Where it is right now (live) | Cellular (4G) tracker, or a wide gateway network | Constant coverage, so fixes arrive in near real time |
If your asset spends its time inside a wider gateway network, a community LoRaWAN network with lots of gateways, the buffering shrinks, because it is rarely out of range. That is the middle ground. But out on your own single home gateway, expect the lag. Tracking is just one job a single platform can do: see one platform, many uses.
Match the tool to the question: where is it now needs coverage; where did it go does not.
The short version
A rural LoRaWAN GPS tracker is not live. When it is out of range of a gateway it stores fixes on board and uploads them later, oldest-first, once it is back in range. On a real decoded trip that upload lag ran from about two hours to nearly nine as the buffer drained. For logging where an asset went, that is perfectly fine and sips battery. For genuinely live tracking you need network coverage: cellular, or a wide gateway network.
Educational overview based on our own decoded trip data; no device keys or identifiers here. Your results depend on your gateway coverage and tracker settings.
Need to know where your gear goes?
Tell us what you want to track and whether you need the log or the live position. We will match the tracker and the gateway to the job, no pressure, no jargon.
Get a quote