Hello @FRami-5672​ ,

Thank you for the level of detail in this question and for asking it here in our community! It makes it much easier to give a precise answer. This is a genuinely interesting edge case in how the platform handles sparse telemetry. I do want to be transparent with you and let you know I am not a developer and used an AI tool to help me give you this response. If you have any issues with it or anything that doesn't make sense please let me know and I will pull in one of our developers more knowledgeable about this to help.

 a) Does MyGeotab use a hidden higher-resolution data store?

Almost certainly not and here is why: the GO device itself runs the Ramer-Douglas-Peucker (RDP) curve-reduction algorithm on-device before transmitting. It discards redundant intermediate points and only sends the inflection points of the signal. The high-resolution data never reaches the server in the first place. What the API returns via StatusData is the complete dataset the server received.

 The fact that reprocessing via the MyGeotab UI produces the same result is consistent with this: the calculation is deterministic and based on the same

 persisted StatusData records. It is not evidence of a hidden parallel store it is evidence that the UI and your pipeline are reading the same source of truth, but evaluating it differently.

 b) Is there a StatusData search parameter that returns hidden intermediate 

 values?

 No. There is no additional search parameter, result type, or endpoint that surfaces StatusData records beyond what a standard fromDate/toDate query returns for a given device and diagnostic. The GetFeed approach gives you the same records in streaming form. What you are getting is everything the server has.

 c) Does MyGeotab interpolate linearly, or count only explicit in-range points?

This is the most likely source of your discrepancy, and the honest answer is that Geotab does not publicly document the exact evaluation model. However, based on how the rule engine is described "continuously validates incoming data as it arrives" the most consistent interpretation is a step-function (hold-last-value) model, not linear interpolation:

 - When a StatusData point arrives and its value falls within the 1200–1400 RPM window, the rule condition becomes active.

 - That condition remains active until a new point arrives with a value outside the range.

 - Duration accumulates during the period the condition is considered active.

 This is meaningfully different from linear interpolation at the boundary transitions. Consider this example:

 ┌────────┬──────┬──────────────────────────┬──────────────────────────┐

 │ Time │ RPM │  Linear interp says  │  Step function says  │

 ├────────┼──────┼──────────────────────────┼──────────────────────────┤

 │ T=0  │ 800 │ Out of range       │ Out of range       │

 ├────────┼──────┼──────────────────────────┼──────────────────────────┤

 │ T=60s │ 1300 │ In range from ~T=22s   │ In range from T=60s   │

 ├────────┼──────┼──────────────────────────┼──────────────────────────┤

 │ T=120s │ 800 │ Out of range from ~T=98s │ Out of range from T=120s │

 └────────┴──────┴──────────────────────────┴──────────────────────────┘

 With linear interpolation you calculate ~38 seconds in range; with a step function you get 60 seconds. For sparse logging, these differences compound significantly.

To confirm which model MyGeotab uses: find a vehicle with a known RPM transition one StatusData point clearly below 1200, followed by one clearly above 1200, with a known gap and compare the exception duration the platform  reports against both models. This will tell you definitively.

 d) Are there other diagnostics or API calls to get a more complete engine speed series?

 DiagnosticEngineSpeedId is the correct and only diagnostic for engine speed. There is no alternative ID that returns a higher-frequency version of the same signal. The logging rate is adaptive (RDP-based), so sparse logging on a particular unit simply means the RPM signal was relatively stable during that period the device judged that fewer points were sufficient to represent the curve within its error tolerance.

One thing worth checking: confirm you are querying with DiagnosticEngineSpeedId (the standard OBD/J1939 engine speed) and not a device-type-specific variant. Some vehicles report a manufacturer-specific RPM diagnostic alongside the standard one. You can verify by querying all StatusData for the device across that time window without a diagnostic filter and checking what diagnostic IDs are present.

 Summary Recommendation

 The most productive next step is to switch your evaluation model from linear interpolation to a step function and re-run your comparison. If your results converge, that confirms the platform's behavior. If they still diverge, the remaining variable is boundary handling for large gaps specifically, whether the platform treats a gap as "unknown/inactive" (condition resets) or "last known value persists." Testing a unit with a long gap where the pre-gap and post-gap values are both inside the range would isolate that case.

 Please let us know if you have any other questions. We are here to help.

 Have a great day!

 Eishi FUN

 Sources:

 - GO Device Logging — Geotab Developers(https://developers.geotab.com/myGeotab/guides/goDeviceLogging/)

 - Rule Conditions — Geotab Support (https://support.geotab.com/help/mygeotab/groups-and-rules/rules/rule-conditions)

 - Data Feed Guide — Geotab Developers (https://developers.geotab.com/myGeotab/guides/dataFeed/index.html)

 - Top FAQs: Processing Fleet Management Rules — Geotab Blog (https://www.geotab.com/blog/top-faqs-processing-fleet-management-rules/)