Roll your own NMEA parser or use an open source GPS parser?

Question

I do a lot of location aware computing, often incorporating GPS. I have my own little simple NMEA parser that doesn't do anything special - just transforms the GPS specific sentences into usable numbers, flags, and so forth.

However, there is a lot of active development done on projects such as GPSD and Gypsy. If GPS were a simple matter, the projects would have finished long ago and simply gone into maintenance mode.

• What do they know/do that I don't know about, and therefore my code doesn't account for?

Chlorite

Answer 1

From an excellent article by the GPSD lead:

• NMEA standard doesn't provide a full TPV (time, position, velocity) tuple with error, geoid and magnetic variation, etc
• Since different values are in different sentences, and there's no defined order you can't easily know which velocity goes with which position report
• Some values are not given in full (ie, year is two digits on the more common and avilable sentences)
• No standardized way to determine vendor, model, firmware
• No standardized way to change settings (communications speed, sentences reported, samples per second, etc)
• Incompatible binary protocols for advanced usage and faster reporting
• Due to interesting race conditions for USB to serial bridges and bluetooth to serial bridges, changing the speed is a very tricky problem

-Adam

Chlorite

Answer 2

I have worked with NMEA, my experience is:

The NMEA format is not well designed. Professional applications, that have direct access to the GPS receiver, should avoid NMEA. They should consider the specific binary format of the GPS device.

In addition to the topics mentioned by Adam Davis above:

• Its not defined how to deal with invalid attributes: e.g. If the vehicle is standing still, especially, if it has not moved since starting the GPS receiver, the course/heading attribute is invalid; Most receivers will output an empty attribute ",,". But this is undefined.
• The time field: Some vendors use a fractional part after the second. Its not exactly specified(?) if that is allowed, or not; some devices do that, others not. (Further: the GGA sentence defines two digits after the second, the RMC sentence use integral seconds)
• The order of the RMC, GSV, etc. sentences are different from one receiver to the other. That leads to the problem to know when a position fix is complete. Either you check that a new time stamp arrived, then you know that the position is complete, but then you will loose one second, in terms of real time behavior. Or you know your receiver, and know which is the last sentence of a fix. Or you do some "artificial intelligence" to analyze the order in the first ten seconds, and then you know which is the last.

You can look in the SIRF and UBLOX protocol specification, and see what huge chapters they have, to describe how they interprete the NMEA protocol.

If somebody knows a really good NMEA parser / writer written in java or Objective-C, that is open source and not under the GPL license, please let me know.

Suzette