A delivery driver finishes her last drop of the day at 9:47 PM, parks in her driveway, and walks inside. Her phone, in her back pocket the whole time, has quietly produced a perfectly formatted IRS-compliant trip log: six segments between ten addresses, total of 87.3 miles, all timestamped, all stored in the cloud. She didn’t open an app, tap a button, or dictate a voice memo. The phone simply knew she was driving, knew she stopped, and knew when to start watching again
This kind of zero-effort mileage logging — now standard in the best driver apps — is the product of a quiet engineering achievement most people never notice. Understanding how automatic mileage tracking actually works reveals a surprisingly deep stack of sensor fusion, signal processing, and probabilistic inference operating inside every modern smartphone.
The Problem: Detecting a Car Trip Without Asking the User Anything
From a software engineer’s perspective, mileage tracking sounds trivial: log GPS coordinates continuously, compute distances, done. In practice, this naive approach fails immediately for three reasons. First, continuous GPS sampling drains a phone battery in four to six hours — unusable. Second, GPS alone can’t distinguish a car trip from a bus ride, a bike ride, or a walk down a street. Third, and most importantly, a user who has to manually start and stop tracking every trip forgets, and the app’s accuracy collapses.
The actual engineering problem is: detect the start of a vehicle trip with high probability, without consuming meaningful battery, and without user action — then switch on higher-precision tracking only for the duration of the trip. This is a classic signal detection problem, and the solution uses three layers of increasing power and accuracy.
Layer One: The Motion Coprocessor
Every iPhone since the 5S and every major Android flagship since 2013 ships with a dedicated low-power motion processor — a chip separate from the main CPU that handles accelerometer, gyroscope, and pedometer data at roughly 1/100th the power draw of the main processor. Apple’s implementation is called the M-series motion coprocessor (M17 in current iPhones); Android implements it via the Sensor Hub hardware and the Activity Recognition API.
This coprocessor runs continuously in the background. It doesn’t care about GPS; it only watches accelerometer patterns. A human walking produces a distinctive step cadence (roughly 1.5–2.5 Hz). A human running produces faster cadence with higher peak g-forces. A bicycle produces low-frequency vibration from road feedback without the vertical oscillation of footfalls. A car produces characteristic low-amplitude horizontal accelerations with longer-duration sustained motion and no step pattern at all. The coprocessor runs a classification model continuously — walking, running, cycling, driving, stationary — and can switch between these labels several times a minute.
This is the first filter. The phone’s operating system publishes the current activity classification to registered apps, so a mileage tracker can subscribe to “did the user just start driving?” without doing any of the detection work itself. The power cost of this subscription is essentially zero.
Layer Two: Triggered GPS Acquisition
When the motion coprocessor signals “driving started,” the tracking app wakes up and requests GPS updates. GPS itself is a satellite-based trilateration system with typical civilian accuracy of 3–5 meters in open sky (per GPS.gov), degrading to 10–20 meters in dense urban canyons. The first fix after a cold start takes 20–40 seconds; a warm start (recent ephemeris data cached) is under 2 seconds.
A well-designed tracker requests GPS only at the frequency needed to reconstruct the trip accurately. For a car moving at 40 mph, one fix every 5–10 seconds is sufficient to reconstruct the route with less than 1% error in total distance. More frequent sampling produces smoother paths but diminishing accuracy improvements and higher battery cost. Typical apps sample at 2–10-second intervals while driving.
| Sampling rate | Typical distance error | Battery impact (full day driving) |
| 1 Hz (every second) | <0.3% | 35–45% |
| 0.2 Hz (every 5 sec) | <0.8% | 12–18% |
| 0.1 Hz (every 10 sec) | <1.5% | 6–10% |
| 0.05 Hz (every 20 sec) | 3–5% | 3–5% |
The industry sweet spot is roughly 0.2 Hz — one fix every 5 seconds — which yields under 1% distance error with manageable battery cost. This is where most production mileage-tracking apps operate.
Layer Three: Sensor Fusion and Dead Reckoning
GPS alone has two failure modes that matter for mileage tracking: it loses signal in tunnels, parking garages, and dense urban cores, and it produces noisy position fixes that can randomly “jump” by 20–50 meters even with good signal. Good tracking apps combine raw GPS with data from other sensors to correct both.
The core technique is called Kalman filtering — a mathematical method that combines multiple noisy measurements into a single probabilistic best estimate of the true position. In a mileage tracker, the Kalman filter takes three inputs: GPS coordinates (primary), accelerometer-derived velocity (backup during signal loss), and map-matched road data (correction when the raw GPS drifts off a known road). The output is a smoothed trajectory that closely approximates the actual vehicle path even during brief signal outages.
Dead reckoning — estimating position from the last known fix plus velocity and heading — handles tunnels and garages. A car entering a 30-second tunnel loses GPS but the accelerometer, gyroscope, and compass still report movement. The phone estimates position during the blackout and picks up GPS again on exit. For short blackouts this is accurate to within a few meters; for longer ones (multiple minutes), error grows but is still better than losing the trip segment entirely.
This layered approach is a good example of the kind of engineering that distinguishes serious sensor-based products from amateur attempts — a theme explored in why machine learning projects fail. The gap between naive implementation and production-grade tracking is the difference between a toy project and a tool that survives a tax audit.
Classifying Business vs. Personal: The Probabilistic Problem
Detecting the trip is half the battle. Classifying it as business or personal is the harder half. The most advanced tracking apps combine several signals:
- Location heuristics. Trips starting or ending at known personal locations (home, gym, a favorite restaurant) are auto-classified as personal. Trips to known business locations (regular client addresses, airports during business travel windows) are auto-classified as business.
- Time-of-day patterns. Trips during standard business hours (9 AM–5 PM weekdays) have higher prior probability of being business; weekend trips have higher prior of being personal.
- Trip characteristics. Very short trips (<0.5 mile) are more likely to be personal errands. Trips that arrive and stay for less than 10 minutes are often drop-offs or deliveries.
- User-classified history. After a user manually classifies 50–100 trips, a simple machine learning model can predict classifications for new trips with 85–95% accuracy.
The combined probabilistic classification is presented to the user as a suggestion — “This looks like a business trip. Confirm?” — and the user’s response feeds back into the model. This kind of human-in-the-loop machine learning is a good match for small-sample problems like individual driver classification; full automation is the aspiration, but verified human labeling remains the legally defensive standard.
The Cloud Side: Audit-Safe Record Generation
Raw trip data — start location, end location, timestamps, route polyline, classification — is uploaded to a cloud backend for long-term storage and report generation. The IRS-compliant record format generated from this raw data contains:
- Date of the trip
- Starting location (city/address)
- Ending location (city/address)
- Business purpose (user-supplied or inferred)
- Total miles driven
- Optional: route polyline as backup evidence
At tax time, the app exports a year’s worth of trips as a PDF or CSV, formatted to match IRS Publication 463 guidance. The key defensive quality of this record is its timestamping — each trip has cryptographically verifiable metadata showing when it was created, proving the log is contemporaneous rather than reconstructed. This timestamp is the single biggest reason these apps survive audit where hand-kept spreadsheets often don’t.
What This Tells Us About the Next Decade of Sensor Apps
Mileage tracking is a microcosm of a broader trend: zero-UI applications that quietly produce structured, auditable records from ambient sensor data. The same pattern — motion-coprocessor triggering, selective high-power sensor activation, sensor fusion, probabilistic classification, defensive record generation — appears in continuous glucose monitoring, workplace safety wearables, fleet telematics, consumer fitness tracking, and increasingly in industrial IoT. The infrastructure to build these systems exists on every modern phone, and it’s getting more capable every year.
The startup ecosystem building on these foundations has been quietly productive — see the innovative tech startups for examples of companies turning sensor fusion into category-defining products. What a decade ago required custom hardware, bespoke firmware, and months of engineering work now runs on standard smartphone APIs and a couple of thousand lines of well-structured code.
For the delivery driver finishing her day at 9:47 PM, none of this matters in the moment. She didn’t notice that her phone did $61 of precisely-logged deductible driving. She just went inside for dinner. That’s the signature of a mature sensor-fusion system: it’s so quiet you forget it’s there, until one day you need the records and they’re exactly where you need them, formatted the way they need to be, with cryptographic timestamps the IRS can’t argue with. Engineering at its best is usually invisible. Mileage tracking is a very good example.
