The Problem
Tracking a vehicle’s total distance traveled or total engine hours sounds simple — until you deal with the real world:
- Devices get swapped. A vehicle’s GPS tracker fails and is replaced. The new device starts counting from zero.
- Data gaps happen. A device loses power, goes offline, or misses reporting windows. When it comes back, there’s a jump in values.
- Counters reset unexpectedly. Firmware updates, device reboots, or hardware issues can cause a device’s internal counters to drop back to zero.
- Multiple data sources disagree. The GPS-calculated odometer says 102,450 km. The vehicle’s ECU says 104,203 km. Which one is “right”?
- Engine data is received from different source addresses. The data from the engine’s onboard computer / CAN network is received from multiple sources. Read this article for more information.
If you’re building fleet reports on top of raw device data, you have to handle all of these edge cases. Every device swap means manual corrections. Every data gap means broken reports. No worries, there’s a data-processing engine that handles this for you.
How Pegasus Structures Counter Data
Pegasus organizes absolute counter data (data that’s constantly supposed to increment) into three layers, each building on the one before it:
┌─────────────────────────────────────────────────┐
│ Layer 3: Vehicle Counters (vehicle_dev_dist) │ ← User-editable absolute value
│ "The odometer reads 104,203 km" │ Set it to "match the dashboard"
├─────────────────────────────────────────────────┤
│ Layer 2: Pegasus Counters (dev_dist) │ ← Normalized & protected
│ "Consistent, gap-free, swap-safe values" │ Pegasus manages automatically
├─────────────────────────────────────────────────┤
│ Layer 1: Raw Counters (vo, ce, cl) │ ← Straight from the device
│ "Whatever the hardware reported" │ No adjustments, no "protection", raw telemetry data
└─────────────────────────────────────────────────┘
Layer 1 — Raw Counters
These are the unmodified values reported by the device or vehicle’s onboard computer (ECU). They use fixed units (meters, seconds, liters) and are not adjusted to your user’s unit preferences when you query it.
When to use: Only when you need the original hardware-reported value for diagnostics or debugging.
Layer 2 — Pegasus Counters
Pegasus takes the raw values and applies automatic protections:
| Protection |
What it handles? |
| Gap filling |
If a device does not report the value, Pegasus fills in missing data with the previous value so your totals are always available. |
| Drop protection |
If a counter suddenly decreases (device reset, swap, etc.), Pegasus detects it and prevents your cumulative totals from going backward. |
| Swap continuity |
When a device is replaced on a vehicle, Pegasus ensures the new device’s counters continue from where the previous device left off — not from zero.
(Note that this level of protection is exclusive to Syrus and Antares devices, third party telematics devices only have the first two protections, thus if the new device being swapped in reports a similar odometer/counter value that’s slightly above the previous one then it would still consider it) |
These counters adjust to your unit preferences (km vs. miles, liters vs. gallons, etc.) and are the recommended default for reports and calculations.
When to use: For any report, dashboard, or integration that needs reliable cumulative values.
Layer 3 — Vehicle Counters
Vehicle counters inherit all of the protections from Layer 2, but add one critical feature: you can set their value.
This is how you align Pegasus with the real world. If a vehicle’s dashboard reads 104,203 km but the GPS-based counter shows 97,600 km, you set vehicle_dev_dist to 104203942 meters, and from that point on, the counter increases in unison with the Pegasus counter — but from your specified starting point.
When to use: When you need an absolute odometer or hourmeter that matches the physical vehicle (for compliance, resale records, maintenance scheduling, etc.). Note that the “GPS Odometer” will always tend to drift from the real dashboard values because it relies on the gps coordinates and satellite visibility, etc. Pegasus doesn’t fix that but at least the value you set manually will be closer to the real world value. It’s recommended to adjust these values once every few months so they maintain coherence.
Counter Reference by Type
Distance (Odometer)
| Field |
Layer |
Description |
Raw Unit |
vo |
Raw |
GPS-calculated odometer |
meters |
dev_dist |
Pegasus |
Normalized GPS odometer |
meters |
vehicle_dev_dist |
Vehicle |
User-editable GPS odometer |
meters |
ecu_distance |
Raw |
ECU-reported odometer |
meters |
ecu_dist |
Pegasus |
Normalized ECU odometer |
meters |
vehicle_ecu_dist |
Vehicle |
User-editable ECU odometer |
meters |
Engine-On Time (Hourmeter)
| Field |
Layer |
Description |
Raw Unit |
ce |
Raw |
GPS-calculated ignition time |
seconds |
dev_ign |
Pegasus |
Normalized GPS ignition time |
seconds |
vehicle_dev_ign |
Vehicle |
User-editable GPS ignition time |
seconds |
ecu_hours |
Raw |
ECU-reported engine hours |
hours |
ecu_eusage |
Pegasus |
Normalized ECU engine hours |
seconds |
vehicle_ecu_eusage |
Vehicle |
User-editable ECU engine hours |
seconds |
Idle Time
| Field |
Layer |
Description |
Raw Unit |
cl |
Raw |
GPS-calculated idle time |
seconds |
dev_idle |
Pegasus |
Normalized GPS idle time |
seconds |
vehicle_dev_idle |
Vehicle |
User-editable GPS idle time |
seconds |
ecu_hours_idle |
Raw |
ECU-reported idle time |
hours |
ecu_eidle |
Pegasus |
Normalized ECU idle time |
seconds |
vehicle_ecu_eidle |
Vehicle |
User-editable ECU idle time |
seconds |
Fuel Consumed
| Field |
Layer |
Description |
Raw Unit |
ecu_total_fuel |
Raw |
ECU-reported total fuel consumed |
deci-liters |
ecu_tfuel |
Pegasus |
Normalized total fuel consumed |
liters |
vehicle_ecu_tfuel |
Vehicle |
User-editable total fuel consumed |
liters |
Idle Fuel Consumed
| Field |
Layer |
Description |
Raw Unit |
ecu_idle_fuel |
Raw |
ECU-reported idle fuel consumed |
deci-liters |
ecu_ifuel |
Pegasus |
Normalized idle fuel consumed |
liters |
vehicle_ecu_ifuel |
Vehicle |
User-editable idle fuel consumed |
liters |
Unit preferences: Raw counters always return in their fixed unit. Pegasus and Vehicle counters adjust to your workspace’s configured unit preferences.
Which Layer Should I Use?
| Your goal |
Use this layer |
Example field |
| Debug raw device output |
Raw |
vo, ce, ecu_hours |
| Build reliable fleet reports (distance per day, idle %, etc.) |
Pegasus |
dev_dist, dev_ign, ecu_tfuel |
| Show an odometer/hourmeter that matches the physical vehicle |
Vehicle |
vehicle_dev_dist, vehicle_dev_ign |
What’s Next
This article covers how Pegasus structures and protects counter data. To learn how to query this data — including interval-based reports (daily, weekly, monthly breakdowns), derived metrics (average speed, fuel efficiency), and shared user counters — see the complete documentation:
Counters — Full Documentation