Towards a Better GPS Protocol

NMEA timestamps usually (e.g in GPBWC, GPBWR, GPGBS, GPGGA, GPGLL, GPGXA, GPTRF, GPZTG) report time-of-day only. The exceptions (GPRMC, GPTRF, GPZDA) report only two digits of year and no century. Time precision is unspecified, usually to the second though some devices report a fractional decimal part to millisecond precision.

It is not possible to get a time/position/velocity report in a single sentence. Some sentences (GPRMC) report time and 2D position and velocity, some (GPGGA) report time and 3D position, some (GPVTG) report velocity only. As a result, the API for a protocol client is complicated by the necessity of maintaining separate age indications for 2D position, 3D position, and velocity,

NMEA sentences have at least three kinds of validity indicators — mode (GPGSA only), status (GPGLL, GPGGA), and the Active/Void field (GPRMC, GPGLL). And that’s before we get into the FAA extensions in late revisions of the protocol. Interpreting these status bits is a black art involving knowledge of undocumented and often vendor-specific quirks.

There is no standard way of indicating that part of a time/position/velocity report is invalid (e.g. because the device does not have a fix of the required quality). Many devices simply report 0 for invalid fields, which doesn’t sound bad unless you’re near the zero-zero point in the Bay of Benin — or at sea level. It is also not generally possible to distinguish between information a GPS is not yet reporting but will return on a good fix (such as altitude) from information it will never report (such as, on many units, local magnetic variation).

As least one messy bit in NMEA 0183 was an adaptation to machines with only small amounts of expensive RAM: the fact that satellite status may show up in a sequence of as many as three sentences to be processed serially. On modern machines, RAM buffers are cheap. It makes more sense to ship a single long sentence and decrease code complexity in the receiver by not requiring a stateful parser.

Position accuracy estimates are not easy to compute from NMEA reports. Reporting a measurement without giving its 95% confidence interval is bad practice.

For modern GPS devices, even the small piece of NMEA directly concerned with GPS capabilities is seriously over-complex. Whereas older GPS devices included elaborate facilities for waypoint tracking and navigational computation, newer ones are designed under the assumption that they are connected to a general-purpose computer that is more powerful and flexible at these things; thus, the GPS only needs to be a time/position/velocity oracle.

NMEA 0183 is in general very loosely specified and poorly documented. Its problems are compounded by the fact that it is a proprietary specification, jealously guarded by IP lawyers.

Keep the low-level syntax, because it’s not broken. It has all the advantages of textual protocols. Going to a more tightly-packed binary format might look attractive at first glance, but the gain in information would be marginal at best. Textual formats already use 7 out of 8 bits per byte and encode variable-length numeric fields more efficiently than binary; also they avoid endianness issues.

Add to the syntax standard ways of indicating that either (a) the GPS cannot now ship valid data for the field, or (b) the GPS will never ship data for this field.

Include a full timestamp, to millisecond precision or better, with every sentence. Every timestamp should be in the same standard form and should include a full date with century.

Report the uncertainty corresponding to a 95% confidence interval on a standard normal distribution for each measurement field.

Design the protocol around a single core sentence that reports time/position/velocity and the uncertainties in same.

Make it an objective of the design for an informal specification to fit on a single page.