Hey @FRami-5672
These are really thorough questions. Thank you for asking them here it's clear you've put a lot of care into your data pipeline. Let me address each part.
1. Does MyGeotab apply filtering or aggregation to raw diagnostic data before displaying it in the UI?
Yes, a few factors contribute to the minor discrepancies you're seeing:
Adaptive (curve-based) logging frequency
The GO device doesn't log GPS or RPM at a fixed interval. It uses a curve algorithm that increases logging frequency when there are meaningful changes in speed, heading, or RPM, and reduces it during steady-state driving (e.g.,constant highway speed). This means the underlying StatusData records are already non-uniform in time density before any resampling. When you resample to 1-minute intervals on your end, you're fitting a fixed grid to an irregular series, which can produce small shifts compared to how the UI charts the same curve.
UI chart rendering vs. raw API values
The MyGeotab UI renders data by plotting the actual logged StatusData points it does not down-sample or further aggregate them for chart display on normal zoom levels. However, the UI may hide certain classes of records that the API still exposes (e.g., adjustment-only entries when raw data has been partially purged). This is a documented behavior where API queries can surface records that don't appear in the UI.
Multi-source ECU normalization (J1939/HD vehicles)
On J1939 or heavy-duty vehicles, RPM may be broadcast by multiple ECUs. MyGeotab normalizes to a single selected source and presents that in the UI. If your API queries are pulling StatusData across multiple diagnostic IDs (e.g., DiagnosticEngineSpeedId vs. an OEM-specific RPM diagnostic), you may be capturing data the UI is not showing. It's worth confirming you're filtering to the exact diagnostic ID the UI uses for RPM.
Summary for your pipeline: Your approach of filtering trips and applying a physical range (50–4000 RPM) is well-reasoned. The small offsets you see are most likely a combination of the curve algorithm's non-uniform logging intervals and the fixed 1-minute resample grid. Rather than resampling to a fixed interval, you may get closer alignment by forward-filling or interpolating between the actual StatusData timestamps.
2. Speed spikes — GPS signal loss as a contributing factor
Yes, GPS signal loss is absolutely a known contributing factor to speed spikes, and your instinct is correct.
Here's the mechanism: the GO device uses GPS to track position and derive speed. When GPS signal is lost, the device has no valid position fix for a period of time. When the signal is restored, the firmware records a new position that may be significantly displaced from the last known position. If that displacement is divided by the elapsed time since the last valid fix, the implied speed can be unrealistically high — sometimes hundreds of km/h — even though the vehicle was moving normally.
A few other contributors:
- Firmware-level GPS buffering: Newer firmware versions buffer GPS logs on-device and upload them in batches. This can occasionally produce timing artifacts where several points arrive together with timestamps that compress travel distance into a short window.
- 2-wire ignition / RPM-based ignition detection: If the device is using RPM as an ignition proxy and the RPM signal times out mid-trip, the device may miss part of the trip, affecting position continuity.
- Cold start / satellite reacquisition: After going through a tunnel, parking garage, or area with heavy tree cover, reacquisition of the satellite constellation can take several seconds, during which position estimates may jump.
Practical handling: For your pipeline, filtering out data points where the implied speed exceeds a reasonable threshold (e.g., 200 km/h for standard fleet vehicles) is a sound rule of thumb. You can also cross-reference the LogRecord GPS valid flag — when isGpsValid is false, the speed value from that record should be treated with caution.
Hope that helps clarify things! If you have a specific vehicle or time window where the discrepancy is pronounced, the MyGeotab SDK Diagnostic reference can help you confirm exactly which diagnostic ID the UI is charting. Feel free to share more details if you'd like to dig deeper.
Have a good one!
Eishi FUN