Blog ·
How mileage apps decide a drive has started: Bluetooth, beacons and motion
The three ways an app knows you are driving, how each one fails, and the honest limits of relying on the car's Bluetooth.
An automatic mileage app has one hard problem: knowing when you are driving, and in which car, without you telling it. Everything else is arithmetic. There are three common answers to that problem, and each one fails in a different way. If you are choosing an app, or wondering why yours logged your bus ride, this is the part worth understanding.
Approach one: motion and speed
The simplest approach watches the phone’s sensors. iOS reports a motion activity type (stationary, walking, running, cycling, automotive) from the accelerometer and gyroscope, and a location fix gives speed. When the activity says automotive, or the speed passes a threshold, the app assumes a drive has begun. When the phone is still for a few minutes, the drive ends.
This works in any car, including a rental, because it does not need to know anything about the vehicle. That is its strength and its weakness.
How it fails. Motion cannot tell your car from anyone else’s. A bus, a train, a taxi, the passenger seat of a colleague’s car, all look like driving. A fast bike descent can cross a speed threshold. Stop-and-go traffic, a drive-through, or a long red light can look like the end of a trip, so one drive becomes three. And the activity classifier takes time to decide, so the first few hundred metres of a trip are often missed or guessed.
Apps built on this approach push the cleanup onto you: you delete the transit rides, merge the split trips and assign a vehicle after the fact.
Approach two: a paid beacon
Some apps sell a small Bluetooth Low Energy beacon that you leave in the car. The phone listens for the beacon’s advertisement; when it appears, you are in that car, and when it disappears, you have left. Driversnote and TripLog both sell one.
This solves the identity problem. The beacon is in your car and nowhere else, so a bus ride is silent.
How it fails. The beacon costs money, runs on a coin cell that eventually dies, and can be forgotten in a glovebox during a vehicle change. BLE range is generous, so a phone walking past the parked car, or sitting in a house with the car in the driveway, can register as “in the car” until the app’s motion check catches up. And the start of the drive still depends on the phone noticing the beacon quickly, which iOS does not guarantee when the app is in the background.
Approach three: the car’s own Bluetooth
Most cars built in the last fifteen years have hands-free Bluetooth, and most drivers pair their phone with it. When the phone is connected to the car’s audio system, the car is identifying itself, for free, with no extra hardware.
An app can use that as the identity check. iOS does not hand apps a “Bluetooth connected” event, but it does let an app ask which audio inputs are currently available, and a connected car shows up in that list by name. Combine that with a cheap wake-up (iOS will relaunch an app on significant location changes, roughly every few hundred metres) and a motion check (was there automotive motion in the last few minutes?), and the app has a three-part test: the phone moved, the car is connected, the motion looks like driving. Only when all three agree does it start recording with full GPS.
How it fails. Three honest limits.
Some cars do not pair, or pair in a way the phone does not expose as an audio route. Older vehicles without hands-free, some fleet vehicles, and some cars that connect over Bluetooth Low Energy only (a phone-as-key setup, for instance) will not appear in the audio input list. For those, the app needs a fallback: a BLE scan for the car’s own advertisement, or a plain motion-only mode with a “not my drive” button on every trip.
A passenger whose phone is paired to the car will be logged as driving. If two people in a household pair with the same car, each phone thinks it is the driver.
And force quitting the app stops everything. iOS does not wake an app the user has swiped away from the app switcher, for location events or anything else. Every background-detection app on iOS shares this limit. The apps that handle it well notice on next launch that they were force quit and say so; the ones that handle it badly let you discover it at month end.
What “split trips at stops” means in practice
Every approach has to decide when a drive ends. End too eagerly and a coffee stop splits one client visit into two trips, with a gap in between. End too lazily and the trip home absorbs the walk from the parking lot.
The usual answer is a pair of timers. With a car identity signal (Bluetooth or beacon), the app can end quickly once the car disconnects and the phone has been still for a minute or so, because disconnection is a strong signal you got out. Without that signal, it has to wait longer, typically several minutes of stillness, and a long red light becomes a risk.
A reasonable design also discards very short trips, since a 300-metre reposition in a parking lot is noise rather than a business kilometre.
Choosing
If you drive one or two cars that pair, the car’s own Bluetooth is the cheapest reliable identity signal, with motion as a confirmation. If your car does not pair, a beacon or a motion-only mode with easy correction is the fallback, and you should expect to do some cleanup. In either case, check how the app handles force quit, passengers, and the end-of-trip timer, because those are where the logs go wrong.
Odie uses the car’s hands-free Bluetooth name as the identity check, confirms with motion before recording, offers an optional BLE scan for cars whose hands-free name is not visible, and has a motion-only mode with a “Not my drive” option for cars that do not pair. Trips under 500 metres are dropped, a stop under five minutes does not split a trip, and the app tells you if it was force quit.
Sources
Written by the Odie team. Not tax advice; your accountant knows your situation.