Why some head units report zero speed when the car is doing 60 km/h

At a desk, reading the speed in Android takes one line of code. On an aftermarket head unit, it is often the first thing to go wrong.

The cause lies in the NMEA sentences

A GPS module communicates with the operating system using NMEA sentences. Position comes in $GPGGA; speed and heading come in $GPRMC. Many low-cost modules only handle $GPGGA — enough to put a dot on a map, which is all most apps need.

To make matters worse, the GPS driver still marks the speed field as valid. location.hasSpeed() returns true and location.speed returns 0.0f. No exception is thrown and no error flag is set. An app that trusts this number ends up with a speedometer stuck at zero — on exactly the most common kind of device.

Why you cannot simply check for 'speed is zero'

A car waiting at a red light also reports zero. What is needed is a way to tell 'standing still' apart from 'faulty driver', and that is the distance between consecutive GPS fixes: a moving car produces fixes tens of metres apart, whatever the driver reports.

What the app does

SpeedEstimator runs two sources side by side:

• The driver source — location.speed, as reported.
• The derived source — the distance between two fixes divided by the time between them.

Normally the app uses the driver source, because it is smoother. But each time the derived source shows the car clearly moving while the driver still reports zero, the app counts one sample. After about eight such samples, it concludes the driver is faulty and switches to the derived source for the rest of the session.

Why eight rather than two? A single noisy fix can produce a false distance; eight in a row cannot.

What you see on screen

Once it has switched, the screen shows 'speed computed from GPS'. This is not an error message — it simply lets you know where the number comes from, so it is clear why the speed may lag slightly behind. On many head units, this is just how things normally work.