GPS tracking app: where transport telemetry breaks
GPS tracking apps break not at the stage of "showing a dot on the map," but at the junction of the mobile OS, the radio channel, and the receiver.
The dispatcher sees a smooth route, but in reality it's a stitch-up of rare lucky measurements: between them the vehicle was driving "in a straight line" through courtyards, while in fact it was standing under an overpass or turning around in a lot.
Gaps in coordinates in shadowed areas — dense urban development, tunnels, underground parking garages — produce breaks that no one can later reconstruct, because the raw data is already gone.
The second class of failures is telemetry loss at the network edge. The device enters a dead zone, the buffer overflows, and some packets are lost irretrievably.
If the app can't accumulate measurements locally and send them once the channel is restored, the dispatcher gets a hole in the track rather than a delay.
A separate story is background operation: aggressive battery saving on modern OSes puts the app to sleep, and the track cuts out exactly when the vehicle has gone out on a run.
Battery drain is the flip side: if the receiver is kept constantly active, the driver's phone dies within a shift, and the driver closes the app himself.
Clock desynchronization between the device and the server finishes the picture — points arrive with different timestamps, the order is restored incorrectly, and the mileage report diverges from reality.
The cost of each of these failures is not an "ugly map," but decisions made on incorrect data: downtime that went unnoticed, or overtime that was counted twice.
We break down how this is closed at the level of the app's architecture, rather than with interface cosmetics.
What sustainable fleet tracking delivers
A sustainable track is not "dots on a map" but the share of delivered points out of collected ones.
In urban development and on the highway, connectivity drops dozens of times per shift: a buffer on the device accumulates coordinates and sends them once the channel is restored, so a 3-5 minute gap does not turn into a hole in the route.
We design the application so that a network loss does not lose data but merely postpones its transmission.
The second measurable effect is recovery time after a gap. When the channel is back, the device does not wait for the next polling cycle but initiates the resend immediately; the queue is sent in batches so as not to clog the channel.
In practice, this shortens the "blind zone" window from minutes to seconds, and the dispatcher sees the vehicle where it is, not where it was.
The third is the eliminated class of failures.
We separately address the scenarios that produce a "choppy" track: aggressive system power saving that kills the background process; cell tower switching and transitions between networks; GPS loss in a tunnel and an underground parking garage.
Each scenario is a separate rule for the application's behavior, not a hope that it will "recover on its own."
Track stability directly affects what can be trusted: mileage calculation, fuel control, delivery confirmation. If the share of delivered points stays at a high level, fleet analytics ceases to be approximate.
We work on professional equipment and test the application's behavior in real conditions — in tunnels, on the highway, in dense urban development — so that the effect is confirmed by measurements, not promises.
Coordinate capture and server upload modes
The capture mode determines how often the application requests coordinates from the receiver, while the upload mode determines how often and in what batches they are sent to the server.
These are two independent settings, and their combination produces different battery consumption, different traffic volume, and different track detail.
A mistake in the choice does not show up immediately: the application works, but by the end of the shift the battery dies or "straight" segments appear in the report instead of the real route.
| Mode | When it fits | Limitations |
|---|---|---|
| Continuous stream | The dispatcher sees the vehicle in real time, second-level accuracy matters | Maximum battery and traffic consumption, sensitive to network outages |
| Event-based tracking | Monitoring deviations: zone exit, hard braking, idling | Between events the track is sparse; detailed analysis requires additional loading |
| Batch upload | Stable connectivity is not guaranteed, autonomy matters | Data arrives with a delay; the accumulated batch must be protected from loss |
| Hybrid mode | Mixed fleet: city, highway, areas without coverage | Harder to configure and test, requires switching logic |
In practice, the working option is a hybrid: while moving, coordinates are recorded frequently; when idle, the interval stretches; and the accumulated points are uploaded in batches once the network appears.
The buffer on the device survives an application restart, so the track is not broken even during a power loss.
We tie the choice of mode to the task: for route monitoring, event-based tracking is enough; for online dispatching, a continuous stream; for equipment far from coverage, batch upload. Let's discuss your scenario — we'll come back with an estimate and a plan.
How we implement a mobile IoT application
Work on GPS vehicle tracking begins not with code, but with an analysis of the fleet: what types of vehicles there are, what trackers are already installed, how drivers behave on the route.
Everything else depends on this — from the frequency of sending coordinates to the logic of alerts when deviating from the route.
How the process is structured
- Fleet and scenario audit. We record vehicle types, telematics unit models, areas with unstable connectivity, and dispatch requirements. The output is a list of scenarios: route monitoring, idle time, fuel drains, panic buttons.
- Data flow diagram. We determine what is computed on the device, what goes to the server, and where the history is stored. Here we also build in buffering: when the network is lost, points are not lost but catch up as a packet when the connection is restored.
- Configuring background operation. Tracking must survive when the app is minimized, in sleep mode, and after the phone is rebooted. We select the geolocation mode for the task: frequent points on the route, infrequent ones when parked.
- Field testing. We install the application on real vehicles and run it along working routes: city, highway, underground parking garages, areas without coverage. We compare the track against the reference tracker log.
- Load testing. We observe how the server side behaves when hundreds of vehicles transmit simultaneously, and what happens to the queue during peak bursts.
- Handover of the solution. We deliver the assembled application, access to builds, instructions for drivers and dispatchers, and the update policy.
Each stage ends with an artifact that can be verified: a coverage map, a track log, a battery consumption report.
This makes it possible not to carry problems over to the next step, but to close them on the spot — by the time of handover, the solution has already been tested on real routes, not only in a test environment.
Artifacts: configurations, schemas, regulations
A GPS tracking application does not live in code alone: after release, it is critical that the client's team can change sensor polling frequency, add geofences, and investigate incidents without us. That is why we close out every project with a package of artifacts, not just a build in the stores.
- Application configurations — parameter files per environment (dev/stage/prod): coordinate sending intervals, power-saving modes, buffering thresholds when the network is lost. Values are taken out of the code and can be changed without rebuilding.
- Data flow map — a diagram of the telemetry path: sensor → mobile device → queue → storage → dispatcher panel. With failure points and behavior when the connection drops.
- Access policies — a role matrix (dispatcher, logistics manager, fleet administrator), rules for issuing and revoking tokens, restrictions on exporting route history.
- Documentation — module descriptions, exchange formats, instructions for local launch and debugging tracking on a test vehicle.
- Update regulation — the procedure for releasing versions, rollout channels, conditions for rolling back to the previous build, and the criteria under which a release is stopped.
- Monitoring schema — which metrics are collected from the application and the server side, alert thresholds for coordinate delay and the share of lost packets.
- Decision log — why particular background operation and synchronization mechanics were chosen, so that as the product evolves we do not revisit what has already been done.
Such a set removes dependence on the contractor: the client's in-house engineer can see where to change parameters, how to read logs, and what to do in case of a failure.
Describe your fleet and scenarios — we will come back with an estimate and a plan for the composition of artifacts.
Case: tracking 400 vehicles on routes
The client is a logistics operator with a fleet of 400 vehicles on intercity routes.
Dispatchers worked in a web panel, and tracks arrived with gaps: in tunnels and on the way out of the city, coordinates were lost for 10-20 minutes, and at the boundaries of coverage zones the point "jumped" to a neighboring highway.
The dispatcher learned about a route deviation with a delay, when the vehicle had already deviated by several kilometers, and the investigation was conducted via phone calls rather than data.
What it was before
The client application on the driver's side sent coordinates in a single stream and without a local buffer: if the connection was lost, the points were simply not saved.
There was no deduplication on the server, so after the network was restored, a "fan" of old and new positions flew into the database, and the track on the map was broken.
The average dispatcher response time to a route deviation was about 12 minutes, and the share of routes with missing coordinates was 34%.
What was changed
The geodata collection layer was rewritten: the GPS tracking client writes points to local storage and sends them in batches when the network appears, while the server sorts by device time and discards duplicates.
Track smoothing was added — sharp coordinate jumps are not drawn as real movement. The dispatch center received threshold notifications: route deviation, idle longer than a specified period, loss of connection.
What the result was
The share of routes with missing coordinates dropped from 34% to 4% — gaps remained only where there is physically no connection, and the points arrive after it is restored.
Dispatcher response time decreased from 12 to 2 minutes: the notification arrives before the driver has time to go off course. The track became continuous along the entire route, and trip reviews are based on data rather than on the participants' memory.
The load was handled separately: 400 vehicles write points around the clock, and the application sustains this without an increase in battery consumption — drivers stopped turning off tracking during trips.
How does background tracking differ from event-based tracking?
Background tracking maintains a continuous stream of coordinates: the app receives a position on a schedule — every few seconds or tens of seconds — and accumulates points in a local buffer, from which they are sent to the server in batches. Track completeness here is maximal: every turn, stop, and deviation from the route is visible.
The price is constant resource consumption: the receiver and data transmission run throughout the entire shift, so the battery drains noticeably faster, and on weak coverage the buffer grows and requires careful uploading.
Event-based tracking is triggered by an event: crossing a geofence, start and stop of movement, sharp acceleration, a button press by the driver, deviation from a set corridor.
Between events, the app consumes almost no resources — it relies on system motion-detection mechanisms rather than continuous polling.
Track completeness is lower in this case: between two events, the line may be drawn using the last known position, and small details of the route are lost.
The choice is dictated by the scenario, not by a "best" approach. For controlling delivery routes, calculating mileage, and resolving disputed situations with a client, background tracking is needed — every point matters there.
For infrequent trips, monitoring arrival at a site, or confirming proof of delivery, event-based tracking is sufficient: it answers a specific question and spares the battery.
In practice, both modes are combined. The app runs background tracking while the vehicle is moving and switches to event-based when the transport is stationary: this preserves track completeness on the route and eliminates unnecessary consumption during stops.
We separately work through behavior when the network is lost — points accumulate locally and are sent once connectivity is restored, so that a gap does not turn into a hole in the track.
Common doubts about GPS vehicle tracking
Battery drain is the first question anyone who has held a tracker asks. The reason is not "bad GPS," but that the app polls the receiver and sends coordinates too often.
This is solved not by disabling features, but by modes: when parked — infrequent polling and batch transmission, while moving — the frequency increases, and when the signal is lost, the app switches to inertial dead reckoning based on the latest accelerometer data. As a result, a smartphone or tracker lasts a shift without recharging, rather than 3-4 hours.
Coordinate accuracy and tunnels are a related pair. In dense urban areas and under bridges, the satellite signal disappears for tens of seconds, and naive logic draws a "jump" on the map.
We filter such points by reliability, stitch the track together, and store the raw log separately from the display — the dispatcher sees a smooth line, not a zigzag.
Roaming and integration are about what happens outside the app. When crossing a border, the device switches carriers, and data transmission must not be lost: a queue on the device accumulates packets and sends them once connectivity is restored.
From there, the coordinates go to the customer's accounting system — via a software interface or file exchange, linked to waybills and with a clear update delay.
Questions worth resolving before the start:
Will the app drain the driver's phone battery heavily?
No, if the polling frequency is tied to the motion state rather than set as a constant. When parked, the device barely uses any charge; on a trip, consumption is predictable and fits within a work shift.
What happens to the track in a tunnel or an underground parking garage?
A section without signal is reconstructed from the latest reliable points and motion sensor data. The track remains continuous, and the raw log is stored separately — when reviewing a trip, you can see exactly where the signal was lost.
How will the data get into our accounting system?
Via a software interface or regular file exchange — tailored to the format your system already accepts. We will agree on the fields, update frequency, and behavior in case of a failure on the recipient's side.
Let's discuss your tracking task
To come back with an estimate and a plan, rather than generalities, we need to understand your tracking task down to the details.
Tell us what you already have: your fleet of vehicles and types of objects, who uses the app — dispatcher, driver, mechanic — and what decisions are made based on tracking data.
The architecture depends on this: how often to capture coordinates, how to store history, what to show in real time, and what to load on demand.
We will separately discuss the tracking scenarios that most often determine the scope of work:
- movement and stops: how we distinguish them, where we calculate mileage and engine hours;
- route control and deviations from a defined corridor;
- alerts and events: exiting a zone, prolonged stop, loss of signal;
- operation under unstable connectivity — accumulating points and uploading them once the network is available;
- access separation: the dispatcher sees the entire fleet, the driver sees only their own route;
- reports and exports for planning and resolving disputed situations.
For each item, we will clarify what is critical now and what can be deferred to later stages. This way the estimate turns out realistic, rather than "everything at once."
What we will return after the conversation: a map of scenarios with priorities, a proposal for the architecture of data collection and storage, a phased work plan, and a timeline estimate.
Describe the task in any convenient format — vehicle types, current systems, requirements for frequency and accuracy. We will get in touch, ask clarifying questions, and come back with an estimate and a plan.