TL;DR · key takeaways
- Usable position and speed reports can help a platform estimate trip boundaries when ignition evidence is missing, on vehicles where movement-based trip detection is on.
- Trip data can keep movement-based boundaries distinct from reported ignition; route detail still depends on the GPS positions received.
- Invalid or duplicate reports can be identified and excluded; a location the tracker never sent cannot be reconstructed.
- A single vehicle-day can illustrate how different trip calculations work, but it cannot establish a fleet-wide result or prove a wiring fault.
- Our own data ingestion pipeline checks and interprets supported tracker reports; it cannot recreate missing GPS positions or diagnose a wiring fault by itself.
In this article
- Start with the record a fleet team needs
- What GPS hardware can tell the platform
- How reports enter Traxelio's platform
- How checks and enrichment prepare the data
- How ignition and movement inform trip history
- The data flow in one view
- How to read the three measures
- How the result reaches the mobile app
- What the system can and cannot recover
- Phones, tablets, and ELDs as a comparison
- A clearer record from the evidence available
Start with the record a fleet team needs
When ignition data is missing or inconsistent, sufficiently continuous valid GPS positions and speed reports can still support trip boundaries. That gives a fleet team trips and available route evidence to review instead of treating a missing ignition signal as proof that the vehicle did not move.
The practical question is which trips and route points the received data supports, and where the record remains incomplete. Movement-based boundaries are an inference under the platform's trip rules: they do not recover positions that were never reported or establish why ignition evidence is missing.
One anonymized vehicle-day makes the difference concrete. Its captured trip-summary payload showed 167 m, valid GPS points summed to 355.1 km, and the movement rules applied to the same positions produced six trips totalling 364.5 km. These are three different calculations, not a like-for-like accuracy comparison.
One anonymized vehicle-day, 14 October 2026 UTC.
What GPS hardware can tell the platform
A tracker can report time-stamped GNSS positions and, depending on the device, speed and other signals. A hardwired tracker may also read an ignition-switched input, often called ACC, when its model and installation support it. The tracker sends reports over its communications connection when power and network coverage allow.
These signals answer different questions. A position estimates where the tracker was at a particular time. An ignition reading reports an electrical input or device-derived state. One does not substitute for the other: a tracker can report positions while ignition is unavailable, and an ignition state by itself does not describe the route. For the wider path from tracker signals to a customer view, read the vehicle GPS geolocation guide, or start with our GPS tracking glossary.
How reports enter Traxelio's platform
Devices send reports in formats shaped by their hardware and configuration. We operate our own platform and data ingestion pipeline: supported reports enter that pipeline, their available fields are interpreted into structured records, and those records move through our processing toward the customer-facing trip history.
A decoded record can preserve the device identifier and available timestamps alongside validity, position, speed, course, accuracy, and device attributes. A quality reason, such as a duplicate-report marker, can show that a repeated report was excluded from the usable positions. The retained context supports later checks; it does not make every position usable.
Traxelio makes processed results available through its own customer interfaces and APIs, rather than a screen provided by the tracker manufacturer. The platform applies its trip rules before making the resulting history available.
This is not a raw-packet view presented as a finished trip. The platform has to make the reported observations usable for later checks and trip interpretation. If a device did not send a position or ignition value, ingestion cannot manufacture that original observation. That separation is useful when a fleet team needs to review what came from the tracker and what the platform inferred from it.
How checks and enrichment prepare the data
Before trip logic uses a position, quality checks help distinguish usable observations from invalid or repeated reports. The platform can also associate related device and event records and add derived context while retaining the basis for that context. For example, reported speed can inform a derived motion state; a supported ignition reading can be carried as device evidence.
In the sampled vehicle-day below, 4,529 position rows were present: 4,517 valid and 12 invalid, all marked as duplicate reports. The distance calculated from valid positions excludes those 12 invalid rows. This is one day's evidence, not a general invalid-data rate or a complete statement of every quality rule.
An invalid or duplicate position is different from an absent one. A rejected duplicate can retain a reason that explains why it was excluded from the usable route calculation. If no positions were reported for a period, there is no location path for the platform to check or enrich.
How ignition and movement inform trip history
Trip processing uses supported device signals and usable position evidence to estimate trip boundaries, summaries, and the route that can be shown. When ignition evidence is available and consistent, it can contribute to that interpretation. When ignition is missing or does not fit the observed movement, sustained valid speed and position evidence may still support trip boundaries if it meets the platform's rules.
The basis matters. A trip inferred from movement is different from one whose boundary is based on a reported ignition input. The platform can record that a trip was derived from movement. Missing ignition is also different from an explicit ignition-off reading: one is unavailable evidence; the other is a reported state.
This approach can make better use of positions the tracker did send. It does not mean every movement becomes a trip, or that movement alone establishes why an ignition signal was absent.
The data flow in one view
Device fields and processing rules vary; this flow shows how received data reaches trip history while distinguishing configured movement inference from reported ignition.
The diagram describes the processing concept, not a promise that every report contains every field. Missing GPS positions remain missing; the platform interprets the evidence it receives.
How to read the three measures
The stored trip summary, the sum between consecutive valid GPS positions, and the movement rules applied to the same positions answer different questions. The point sum measures the path between usable fixes. The movement rules group those fixes into trips and apply trip-distance rules. Comparing the outputs can help you ask where the difference comes from, but it does not tell you which calculation is correct without checking the source records and rules. The example covers one anonymized day only.
How the result reaches the mobile app
The mobile app presents prepared trip summaries and legs for a selected day. When a customer opens a driving leg, the app requests the route positions for that leg's time interval. This gives a fleet team a day-level record and the available map route without requiring them to inspect the original tracker messages.
The summary and route depend on the positions available for that day. A gap in the reports can leave part of the route incomplete, even when the surrounding trips can still be presented. See Trip History in Traxelio for the customer-facing capability.
What the system can and cannot recover
When a trip list and route appear to disagree, compare them for the same day and check which positions arrived during the period. If no usable positions arrived, there is no route evidence from which to infer movement. If positions are present but no trip boundary appears, the speed and position evidence may not have met the trip rules. Missing ignition and missing GPS therefore call for different interpretations.
Movement-based processing can help when ignition evidence is unavailable, but it cannot identify a wiring fault on its own. If an ACC connection may be physically faulty, an installer can inspect the device and connection. The platform can make a trip record more useful from available evidence, but it cannot recover a GPS route that was never reported.
If ignition alerts are missing in the platform, start with the “Alerts Not Working” section of the GPS tracker troubleshooting guide. A suspected physical ACC wiring fault still needs an installer to inspect the device and connection.
Phones, tablets, and ELDs as a comparison
On Android, location APIs can return the best available location from providers such as Wi-Fi and GPS; accuracy and update frequency depend on permissions and request settings. This is one example of how a phone or tablet can produce location observations, not a claim about every device or a Traxelio integration. For an electronic logging device (ELD) subject to U.S. FMCSA requirements, GPS location and engine-synchronized records serve distinct roles. The FMCSA's 2022 ELD functions FAQ describes when location is recorded and how engine synchronization captures engine power, vehicle motion, miles, and engine hours. GPS location cannot replace required ECM data.
Their sensors, reporting behavior, and operating constraints differ from a hardwired GPS tracker. The same broad data question still applies: what was actually reported, how reliable and continuous were those observations, and what can software reasonably infer from them?
This comparison explains a general tracking principle; it does not claim that Traxelio accepts every phone, tablet, or ELD as an ingestion source. In each case, a useful history depends on the data available and on making the evidence behind an inferred trip clear.
A clearer record from the evidence available
Ignition is one useful signal in a trip record, but it is not the only evidence a platform can interpret. With usable position and speed reports, movement may help fill a trip-history gap when ignition evidence is missing or inconsistent. Quality checks and processing provenance help the platform interpret the evidence; a clear mobile presentation helps customers understand the resulting record and its limits.
The useful question is whether your platform makes clear which observations came from the tracker, which were inferred, and where the record still has gaps.
The French version of this article follows the same explanation in French.