Skip to main content
Support Center
Help ArticlesAcademyCommunity
HomeCommunitySDK/APIOther/GeneralWhat are the trigger conditions and reporting frequency for LogRecord and EV diagnostics (SOC, charging state, etc.) in MyGeotab?

What are the trigger conditions and reporting frequency for LogRecord and EV diagnostics (SOC, charging state, etc.) in MyGeotab?

Solved
SDK/API
Other/General
D
D
DaichiMiura-2136
Original Poster

Hello,

We are developing a system that periodically retrieves vehicle data using the MyGeotab API (mainly

LogRecord

and

StatusData

).

To design our data collection and polling strategy properly, we would like to understand how frequently these data points are generated by GO devices and stored in the Geotab database.

Specifically, we would like to know the trigger conditions and typical update frequency/interval for the following data:

  • LogRecord.Latitude
  • LogRecord.Longitude
  • LogRecord.Speed
  • IsDeviceCommunicating
  • IsDriving
  • DiagnosticPositionValidId / DiagnosticPositionValidAtDeviceId
  • DiagnosticBatteryVoltageId
  • DiagnosticIgnitionId
  • DiagnosticRawOdometerId
  • DiagnosticStateOfChargeId (Code: 2118)
  • DiagnosticParkingBrakeId
  • DiagnosticElectricVehicleChargingStateId
  • DiagnosticOnBoardChargerAcInputVoltageId (Code: 3290)
  • aFGR6Q9guoUeiaAZI1fD6oQ (Code: 2659)
  • DiagnosticOutsideTemperatureId
  • aCiOQmMpe702NzD3cVCx4oA (Code: 3255)
  • az2JRiedliES6bw7pEe_UZg (Code: 3256)
  • anZTfpLFXgUq_iOB1Q-S9oA (Code: 3268)
  • aiC3laRAhVEOzOSvicbN9og (Code: 3254)

For example, we are trying to understand things like:

  • Are these diagnostics reported periodically (e.g., every few seconds/minutes), or only when the value changes?
  • Are they triggered by specific events (e.g., ignition change, distance traveled, charging state change, etc.)?
  • Are there documented intervals or thresholds for when GO devices send these values to the server?

If there is documentation that describes the recording logic or reporting frequency for these diagnostics, we would greatly appreciate being pointed to it.

Thank you in advance for your help.

1
Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

Top Answers

E
E
EishiFUN
Geotabber

Edited by EishiFUN

Hello @大地 三浦​ ,

 

Great question — understanding the recording logic is key to designing an efficient polling strategy. Here's a breakdown:

 

 LogRecord (Latitude, Longitude, Speed)

 

Geotab GO devices do not use fixed time-based or distance-based intervals for GPS logging. Instead, they use a curve-based logging algorithm that only records data points when they're meaningful — i.e., when the actual position or speed deviates significantly from a predicted path.

 

 The curve algorithm runs (flushes and saves) when:

 - The curve buffer becomes full (~every 100 seconds if driving straight at

 constant speed)

 - The actual GPS position diverges excessively from predicted (e.g., a turn)

 - The actual speed diverges excessively from predicted (e.g., hard

 braking/acceleration)

 - Another event triggers it (ignition change, exception, etc.)

 

 This means logging frequency is variable — you'll see more points during dynamic driving (turns, stops, acceleration) and fewer during constant highway cruising. Here are some references for that: https://github.com/Geotab/curve and https://www.geotab.com/blog/gps-logging-curve-algorithm/.

 

 StatusData Diagnostics — by type:

 

 Diagnostic: DiagnosticIgnitionId

 Recording Trigger: On state change (ignition on/off events)

 ────────────────────────────────────────

 Diagnostic: DiagnosticRawOdometerId

 Recording Trigger: At ignition ON, ignition OFF, and every ~2 km while driving

 ────────────────────────────────────────

 Diagnostic: DiagnosticBatteryVoltageId

 Recording Trigger: ~10 seconds of instantaneous voltage curve-logged at each

  ignition ON; averaged values saved on change of ≥250 mV

 ────────────────────────────────────────

 Diagnostic: DiagnosticParkingBrakeId

 Recording Trigger: On state change

 ────────────────────────────────────────

 Diagnostic: DiagnosticStateOfChargeId (2118)

 Recording Trigger: Every 1% change in value — both while driving and while

  charging

 ────────────────────────────────────────

 Diagnostic: DiagnosticElectricVehicleChargingStateId (3289)

 Recording Trigger: On state change (0=not charging, 1=AC, 2=DC) — reported in

  real-time

 ────────────────────────────────────────

 Diagnostic: DiagnosticOnBoardChargerAcInputVoltageId (3290)

 Recording Trigger: Curve-logged during charging sessions

 ────────────────────────────────────────

 Diagnostic: DiagnosticOutsideTemperatureId

 Recording Trigger: Curve-logged (recorded when value changes meaningfully)

 ────────────────────────────────────────

 Diagnostic: DiagnosticPositionValidId

 Recording Trigger: On state change (GPS fix acquired/lost)

 

 IsDeviceCommunicating / IsDriving

 

 These are derived/computed values in the API, not directly logged StatusData records. IsDriving is determined from ignition state and speed data. IsDeviceCommunicating reflects whether the server has received recent data from the device.

 

 Non-standard EV diagnostics (codes 2659, 3255, 3256, 3268, 3254)

 

 These fall under "Additional EV Diagnostic Signals" with non-standard support. Their recording behavior is generally curve-based (logged when the value changes meaningfully), but exact thresholds aren't publicly documented as they may vary by vehicle make/model and firmware version.

 

 General principle

 

 Most engine and EV diagnostics follow one of three patterns:

 1. State-change triggered — binary/enum values like ignition, charging state,

 parking brake (logged only when the value changes)

 2. Curve-based — continuous values like temperature, voltage, fuel level, RPM

 (logged when deviation from predicted exceeds a threshold)

 3. Event/interval triggered — specific diagnostics like odometer (every 2km)

 or engine hours (every 1 hour + ignition off)

 

 Polling strategy recommendation

 

 Since data is event/change-driven (not periodic), consider using https://developers.geotab.com/myGeotab/apiReference/methods/GetFeed instead of polling with Get calls. GetFeed gives you incremental data since your last token, which aligns perfectly with the variable recording rates.

 

 Key documentation:

 - https://geotab.github.io/sdk/software/guides/go-device-logging/

 - https://github.com/Geotab/curve

 - https://support.geotab.com/mygeotab/sdks/doc/ev-api-diagnostics

-https://developers.geotab.com/

 

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

 

Have a great day!

Eishi FUN

Best Answer

1 Reply

E
E
EishiFUN
Geotabber

Edited by EishiFUN

Hello @大地 三浦​ ,

 

Great question — understanding the recording logic is key to designing an efficient polling strategy. Here's a breakdown:

 

 LogRecord (Latitude, Longitude, Speed)

 

Geotab GO devices do not use fixed time-based or distance-based intervals for GPS logging. Instead, they use a curve-based logging algorithm that only records data points when they're meaningful — i.e., when the actual position or speed deviates significantly from a predicted path.

 

 The curve algorithm runs (flushes and saves) when:

 - The curve buffer becomes full (~every 100 seconds if driving straight at

 constant speed)

 - The actual GPS position diverges excessively from predicted (e.g., a turn)

 - The actual speed diverges excessively from predicted (e.g., hard

 braking/acceleration)

 - Another event triggers it (ignition change, exception, etc.)

 

 This means logging frequency is variable — you'll see more points during dynamic driving (turns, stops, acceleration) and fewer during constant highway cruising. Here are some references for that: https://github.com/Geotab/curve and https://www.geotab.com/blog/gps-logging-curve-algorithm/.

 

 StatusData Diagnostics — by type:

 

 Diagnostic: DiagnosticIgnitionId

 Recording Trigger: On state change (ignition on/off events)

 ────────────────────────────────────────

 Diagnostic: DiagnosticRawOdometerId

 Recording Trigger: At ignition ON, ignition OFF, and every ~2 km while driving

 ────────────────────────────────────────

 Diagnostic: DiagnosticBatteryVoltageId

 Recording Trigger: ~10 seconds of instantaneous voltage curve-logged at each

  ignition ON; averaged values saved on change of ≥250 mV

 ────────────────────────────────────────

 Diagnostic: DiagnosticParkingBrakeId

 Recording Trigger: On state change

 ────────────────────────────────────────

 Diagnostic: DiagnosticStateOfChargeId (2118)

 Recording Trigger: Every 1% change in value — both while driving and while

  charging

 ────────────────────────────────────────

 Diagnostic: DiagnosticElectricVehicleChargingStateId (3289)

 Recording Trigger: On state change (0=not charging, 1=AC, 2=DC) — reported in

  real-time

 ────────────────────────────────────────

 Diagnostic: DiagnosticOnBoardChargerAcInputVoltageId (3290)

 Recording Trigger: Curve-logged during charging sessions

 ────────────────────────────────────────

 Diagnostic: DiagnosticOutsideTemperatureId

 Recording Trigger: Curve-logged (recorded when value changes meaningfully)

 ────────────────────────────────────────

 Diagnostic: DiagnosticPositionValidId

 Recording Trigger: On state change (GPS fix acquired/lost)

 

 IsDeviceCommunicating / IsDriving

 

 These are derived/computed values in the API, not directly logged StatusData records. IsDriving is determined from ignition state and speed data. IsDeviceCommunicating reflects whether the server has received recent data from the device.

 

 Non-standard EV diagnostics (codes 2659, 3255, 3256, 3268, 3254)

 

 These fall under "Additional EV Diagnostic Signals" with non-standard support. Their recording behavior is generally curve-based (logged when the value changes meaningfully), but exact thresholds aren't publicly documented as they may vary by vehicle make/model and firmware version.

 

 General principle

 

 Most engine and EV diagnostics follow one of three patterns:

 1. State-change triggered — binary/enum values like ignition, charging state,

 parking brake (logged only when the value changes)

 2. Curve-based — continuous values like temperature, voltage, fuel level, RPM

 (logged when deviation from predicted exceeds a threshold)

 3. Event/interval triggered — specific diagnostics like odometer (every 2km)

 or engine hours (every 1 hour + ignition off)

 

 Polling strategy recommendation

 

 Since data is event/change-driven (not periodic), consider using https://developers.geotab.com/myGeotab/apiReference/methods/GetFeed instead of polling with Get calls. GetFeed gives you incremental data since your last token, which aligns perfectly with the variable recording rates.

 

 Key documentation:

 - https://geotab.github.io/sdk/software/guides/go-device-logging/

 - https://github.com/Geotab/curve

 - https://support.geotab.com/mygeotab/sdks/doc/ev-api-diagnostics

-https://developers.geotab.com/

 

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

 

Have a great day!

Eishi FUN

Best Answer
Still have questions?
Learn with AcademyBrowse documents