The standard way to measure how a car is being driven is to read it straight from the vehicle. Plug into the OBD-II port and you get speed, engine load, and fault codes from the car's own bus. It is accurate, and it is why almost every telematics and usage-based-insurance product starts there.
But OBD-II has a cost: hardware, installation, and physical access to the vehicle. The question I found more interesting was narrower — how much of that same signal can you recover from a phone in someone's pocket, using only GPS?
The constraint
GPS gives you four things: a position, a speed, a heading, and a timestamp. No throttle, no RPM, no direct braking signal. Everything about behavior — speeding, harsh braking, hard cornering — has to be inferred from how those four numbers move over time. That inference is the whole problem, and it is harder than it first looks.
Why the naive approach fails
The obvious version writes itself: if speed exceeds the limit, log a violation; if speed drops sharply between two samples, call it hard braking. Build that, run it against real driving data, and it falls apart immediately. Not because the logic is wrong, but because the input is noisy in ways that mimic exactly the events you are trying to detect.
Working through it, the difficulty separates into four distinct problems — and none of them is the one you expect going in.
1. GPS noise looks exactly like real events
GPS produces transient spikes: a single sample can report a sharp deceleration or a burst of speed that never happened. A naive detector reads each of these as a genuine event and logs it. The result is a system that constantly flags violations that didn't occur, which destroys user trust faster than almost anything else. The real work here isn't detecting events — it's separating true events from artefacts.
2. A single tolerance is wrong for every source
Speed-limit data doesn't come from one place. Some of it is well-verified; some is stale; some is estimated. Applying one fixed tolerance to all of it is wrong in both directions at once: too strict on the reliable data (false positives) and too loose on the weak data (missed cases). The tolerance has to depend on how much you trust the number you're comparing against — which means you first have to model that trust.
3. Signal loss is hard to distinguish from a real stop
When GPS drops — a tunnel, an underpass, an urban canyon — the data doesn't announce that it's now unreliable. A sudden reported stop might be a real hard stop, or it might be the signal cutting out. Treat the second as the first and every downstream calculation inherits the error. Detecting the difference is its own sub-problem, upstream of any behavior analysis.
4. Punishment-only scoring quietly fails
This one isn't a signal-processing problem — it's a design problem, and it's easy to miss. Most driving-analysis systems only ever subtract: every mistake costs points, and there's no path back up. That turns out to be self-defeating. A driver who sees only penalties disengages, and a system users disengage from measures nothing. Positive reinforcement isn't a nicety here; it's part of making the measurement work at all.
How it works
Each of the four problems has an answer, and fitting them together was the interesting part. Here's the shape of the solution — described at the level of the idea rather than the line of code.
Confirm before you trust: consecutive validation
The core move against GPS noise is refusing to act on any single reading. Instead of logging a violation the moment speed crosses the limit, the system waits for confirmation: a violation only counts if enough consecutive over-limit readings occur inside a short time window. A lone spike — the classic GPS artefact — never survives, because it doesn't repeat. A real, sustained overspeed does. Two parameters govern this: the length of the confirmation window, and the number of consecutive hits required within it. Tune them and you trade sensitivity against false positives directly.
Trust the number as much as its source: dynamic tolerance
Not every speed limit is equally trustworthy, so the comparison shouldn't treat them as if they were. Each limit carries a reliability level based on where it came from — verified, adjusted, or estimated — and the allowed tolerance scales with it. A well-verified limit is held to a tight margin; an estimated one gets a wider one, so a shaky data point doesn't manufacture a violation. The check itself is simple — limit times (one plus tolerance), compared to current speed — but making the tolerance a function of trust is what keeps it honest across messy real-world data.
Know when the signal is lying: the reliability filter
Before any of that runs, incoming GPS is screened in two passes. The first looks at the reported accuracy and discards readings too coarse to mean anything. The second watches for the tell-tale signature of signal loss — a sudden collapse in speed that a real vehicle couldn't physically produce — and, when it sees it, stops processing rather than feeding a phantom event downstream. A median-based smoothing step sits alongside, filtering the sharp jumps that survive the first cut. Only data that clears all of this reaches the behaviour logic.
When the map runs out: adaptive limit estimation
Sometimes there's simply no speed-limit data for a stretch of road. Rather than give up, the system infers a likely limit from how the vehicle is actually moving — averaging recent speed to guess road type, from residential street up to motorway, and estimating a limit band from that. Anything inferred this way is flagged as low-reliability, which automatically pulls in the wider tolerance from the step above. A guess is treated like a guess.
Reward, don't just punish: the scoring model
Finally, the score moves in both directions. Harsh events — speeding, hard braking, hard acceleration, hard cornering — cost points; sustained smooth driving earns a small bonus back. Crucially, the bonus only activates once a driver has dropped below a threshold, so it helps people climb back rather than inflating already-good scores, and a floor keeps the score from bottoming out entirely. The goal is a number a driver stays engaged with instead of abandoning — because a score people ignore measures nothing.
This method is the subject of a utility-model application (TR 2025/019546). The description here is deliberately at the conceptual level; the exact parameters and claim language live in the filing.