Speed from GPS Coordinates

Who it’s for

For fleet managers and asset-tracking teams who only get raw GPS coordinates from a tracker — “how fast is this vehicle actually moving right now?”, “is this asset still stationary, or did it just start rolling?”, “can I alarm on a vehicle exceeding a speed limit without a dedicated speed sensor?”

What it does

This SCRIPT calculated field derives speed from two rolling GPS coordinate streams, computing the great-circle distance between the latest fix and the newest earlier fix at least 10 seconds older, then dividing by the time between them:

The field only computes when the latest latitude and longitude readings share the same timestamp — meaning the tracker published both coordinates in the same message. When that holds, dashboards and alarms downstream receive speedKmh, a rounded time series value in km/h.

• Output: speedKmh in km/h, rounded to 2 decimal places, written as time series.
• Writes nothing if fewer than two readings are available yet on either stream, if the latest latitude and longitude readings don’t share a timestamp, or if the window holds no earlier matching pair at least 10 seconds older.

How to set up

1. Add the field to a device or, better, to a device or asset profile (e.g. “GPS Tracker”) — this applies the calculation to every entity of that type at once, including trackers added later.
2. Confirm the two arguments point at your GPS telemetry keys: lat → latitude, lon → longitude (both Time series rolling, 15-minute window).
3. Save. speedKmh starts appearing once the window holds a matching pair at least 10 seconds apart.

Requirement: your tracker must publish latitude and longitude together, in the same telemetry message. If the two values arrive in separate messages, the field will not compute a value for that reading — it waits for a real, time-matched pair rather than estimating from a stale coordinate.

Noise guard: the field only computes speed between the latest fix and a reference fix at least 10 seconds older (walking back through the rolling window to find one). This keeps ordinary GPS jitter — a few metres of drift on a stationary asset — from being divided by a near-zero time delta and reported as an unrealistic speed spike. A window of Max values samples spans (Max values − 1) × (seconds between fixes) — that’s the number to check against the 10-second guard, not Max values × (seconds between fixes). The shipped default of Max values 20 already covers trackers reporting about once per second (19 seconds of coverage). If your tracker reports faster than that, raise Max values on both lat and lon until (Max values − 1) × (seconds between fixes) is at least 10.

How to customize

• To point the inputs at your keys — change the Time series key on lat / lon if your tracker uses different telemetry key names (e.g. lat/lng).
• To rename the output — open the script and change the "speedKmh" key in the return object.
• To convert to mph — multiply speedKmh by 0.621371 before rounding.
• To widen or narrow the lookback window — adjust the Time window field on both lat and lon arguments (must match on both). A wider window tolerates slower-reporting trackers; a narrower one reacts faster to stops but is more sensitive to reporting gaps.
• To reduce noise further — average speed over more than the latest pair, by extending the script to iterate over more entries and apply a simple average.
• To adjust the jitter guard — change minIntervalSeconds in the script. Lower values react faster to genuine movement but let more jitter-driven speed through; higher values suppress jitter further at the cost of slower detection of real starts.