GPS NMEA info

You may find some useful information here if you are trying to use the NMEA output of a GPS receiver. I am making an in car navigation system (just for fun really) using a GPS receiver. I had great difficulty in finding information about how to interface the GPS to a computer. Eventually by collecting bits of information here and there as well as by trial and error, I found out most of what I needed. Here I'm just collecting all those bits of information and putting them together.

The GPS I'm using is the GARMIN GPS II+. I have also used the GPS 12XL which in terms of the NMEA interface is 100% identical. All the sentences which do not start with PG are universal NMEA sentences. The ones which do start with PG apply only to specific Garmmin receivers.

This is by no means an authoritative description of the standard, however I think it contains most of what is needed to interface a Garmin GPS to a computer.

There are various information which I do not know (for example the GPRTE sentence). If you know this missing information, please inform me so I can update this page.

If you find any of the information on this page usueful, please email me so at least I will know I was not just wasting my time putting this together. Also if you need further information you may ask me, maybe I will know.

I have also done some investigation on the accuracy of the GPS and how it correlates to the EPE it gives. I have also made some subrouteines to read the GPS sentences and interpret them as well as convert them to UTM/UPS metric grid.

Garmin has put on their homepage very detailed specifications of their proprietary format. This allows up/downloading of routes/tracklogs/waypoints and some other facilities. It can also be used for receiving position and speed info instead of the standard NMEA interface, though its a bit more difficult to use.

I have written some Amiga software both for decoding the NMEA output as well as using the proprietary interface to up/download waypoints, tracklogs and routes. I think it should be quite possible to convert to Unix or even windoze format. If you arre interested, email me so I send you the sources - however I havent written any docs yet.

General information about the data format

Physical interface

The interface is compatible with normal RS232. Though not really adherent to the RS232 standard, the NMEA output of GPS equipment usually works perfectly with RS232.

The interface is three wire, using just the Ground, TxData and RxData lines. The speed is 4800 baud with 2 stop bits and no parity. No handshaking is used.

General message format

NMEA devices communicate in messages known as sentences. Each sentence is a sequence of plain ASCII characters starting with a dollar sign and ending in a CR/LF (ie character 13 and 10). The sentence is divided into a number of fields separated by commas.

The first field is a five character word. The first two characters indicate the equipment which is sending the message, and the next three give the type of message. In my case, with the Garmin GPS II+, the first two characters will always be GP or PG. GP is the prefix used for all standard GPS messages. PG is used for messages which are specific to the Garmin GPS. PG meaning Proprietary Garmin. A detailed description of the message types is given further on.

The fields following the first five character field contain the actual data that the GPS is issuing. This consists mainly of numbers which are formatted as normal ascii representations in decimal as well as some other ascii characters indicating for example the units of measure.

Finally, the sentence is terminated with an asterisk '*' followed by a two digit hexadecimal checksum.

Other info

To set up the communication, set the GPS Interface option to NMEA/NMEA. The GPS will send a group of messages every two seconds. This occurs automatically at regular two second intervals, so you do not need to send any message to the GPS from the computer. I think it is also possible to send commands to the GPS by the NMEA interface, but I have no idea what these commands are. (In case of GARMIN receivers, you can use a proprietary protocol which is described in great detail on their homepage)

Specific information on each sentence

Here is a description of each sentence the GPS II+ issues. Example data is included:

$GPRMC,160339,A,3551.860,N,01430.858,E,000.0,360.0,030898,001.4,E*7D
1. Time - GMT (UTC) time in format HHMMSS
2. Data validity - one character, A meaning data is valid, V meaning data is unreliable
3. Lattitude - The first two digits are in degrees. The following digits are minutes in decimal. For example 3551.860 means 35 degrees and 51.86 minutes
4. Lattitude sign - one character 'N' or 'S' for north or south
5. Longitude - The first three digits are in degrees. The following digits are minutes in decimal. For example 01430.858 means 14 degrees and 30.858 minutes
6. Longitude sign - one character 'E' or 'W' for east or west
7. Speed - in knots
8. Course - in degrees - I don't know if this refers to true or magnetic north.
9. Date - in format ddmmyy e.g. 030898 is 3rd August 1998
10. Magnetic variation - the difference in degrees between true and magnetic North (I think)
11. Direction of magnetic variation - one character E for east or W for west.
$GPRMBA,0.02,L,,060,3551.868,N,01430.840,E,000.0,295.7,,V*2B
1. Don't know anything about this sentence. Among other things, seems to contain position, but is different from that given in GPRMC
$GPGGA,160340,3551.860,N,01430.858,E,1,08,1.2,90.4,M,36.5,M,,*7B
1. Time - GMT (UTC) time in format HHMMSS
2. Lattitude - The first two digits are in degrees. The following digits are minutes in decimal. For example 3551.860 means 35 degrees and 51.86 minutes
3. Lattitude sign - one character 'N' or 'S' for north or south
4. Longitude - The first three digits are in degrees. The following digits are minutes in decimal. For example 01430.858 means 14 degrees and 30.858 minutes
5. Longitude sign - one character 'E' or 'W' for east or west
6. Quality - I think this refers to the quality of the received signal or something like that
7. Satellites tracked - The number of satellites being used to calculate the position
8. ?Don't know what this field is
9. Dilution of precision - refers to the (in)accuracy of the acquired position, though I don't know the exact meaning.
10. Units of DOP - the units used in the DOP field above. M is for metres
11. Altitude above sea level - beware that altitude given by any GPS is notoriously inaccurate. An error of over 200m is common. (Actually that was before selective availability was removed - the situation now is much better, but I havent investigated yet)
12. Units for Altitude - M is metres
13. I've no idea about the last field - I have always seen it blank
$GPGSA,A,3,04,13,14,16,18,19,22,24,,,,,1.9,1.2,1.5*3E
1. Validity - A for valid data (I think)
2. 2d or 3d navigation - basically 3d indicates that altitude is also available.
3. Don't know
4. 12 fields - list of satellites being used to aquire position
5. 3 fields - Dilution of precision - I don't know how to interpret these last three fields
$GPGSV,3,1,09,04,55,263,40,13,29,268,38,14,22,112,45,16,60,090,51*71 This sentence gives information on whch satellites are in view, their position and the quality of the signal received from them. Since the data for all twelve satellites would not fit into one line, upto three GPGSV sentences may be issued in each two second cycle. Each GPGSV sentence contains data for upto four satellites. The fields are as folows:
1. Number of GPGSV records
2. Sequence number of this GPGSV record
3. Number of visible satellites - this is not necessarily the number being tracked but rather those that are above the horizon.
4. Satellite identification number (0 to 31)
5. Elevation of satellite in degrees
6. Azimuth of satellite in degrees (0=North, 90=east, 180=southe,270=West)
7. Signal Quality - the quality of the received signal - 30 is the minimum usable signal quality, 60 is the best quality possible
8. next 12 fields same as above 4, 4 fields for each satellite
$PGRME,20.3,M,24.5,M,31.8,M*16
1. Horizontal (position) estimated error
2. Units for above - M=metres
3. Vertical (Altitude) estimated error
4. Units for above - M=metres
5. 3d estimated error
6. Units for above - M=metres
$GPGLL I don't have a clue about this one
$PGRMZ,296,f,3*16
1. Altitude
2. Units for altitude - f=feet
3. ??
$PGRMM,European 1979*78
1. Map Datum being used
$GPBOD,000.0,T,358.6,M,060,*79 Haven't got a clue about this one
$GPRTE Haven't got a clue about this one
$GPWPL Waypoint list. Gives the selected waypoint, or in the case of a route, cycles through each waypoint of the route. Each cycle gives the following fields:
1. Lattitude - The first two digits are in degrees. The following digits are minutes in decimal. For example 3551.860 means 35 degrees and 51.86 minutes
2. Lattitude sign - one character 'N' or 'S' for north or south
3. Longitude - The first three digits are in degrees. The following digits are minutes in decimal. For example 01430.858 means 14 degrees and 30.858 minutes
4. Longitude sign - one character 'E' or 'W' for east or west
5. Name of the waypoint
GPS accuracy
I have done some investigation about GPS accuracy and how it relates to the EPE value given by the receiver, and how dependable or otherwise the data is. The research is based on data collected over 3 weeks with an external GPS antenna fixed in a location with 100% view of the sky. If you would like any more details, copies of the recorded data, scatter plots or anything else related please email me.
Some of the findings are
- Vertical accuracy - This is dismal by any standards even with a 100% view of the sky. The RMS error is about 50 metres. Errors of +-150 metres are by no means rare. It is also common to get reading below sea level when you are in fact 75 metres above sea level.
- The longitude accuracy (15m RMS) is considerably better than the lattitude error (23m RMS). This is probably due to the distributon of the Navstar satellite orbits being less dense in the high lattitudes, whereas they are evenly distributed in longitude.
- The RMS horizontal error seems to be approximately equal to the total EPE (3d EPE) rather than the horizontal EPE. The longitude error is an almost constant 15 metres regardless of EPE, while lattitude error accounts for most of the position error and is roughly equal to the 3d EPE.
- It is possible to set up a poor man's differential GPS simply by simple post processing, using a fixed GPS as reference. It is often stated that this does not work for various complex reasons, however I have found that a considerable improvement of the normal GPS accuracy is in fact achievable by this method. I have observed RMS errors reduced by about 75%.
- The use of averaging to increase accuracy can give very accurate position readings if the interval is long enough. Averaging intervals of up to 2 minutes give no improvement whatsoever. An averaging interval of 3 days gives RMS errors as low as 1 metre both for horizontal as well as vertivcal errors.
- Speed accuracy is a fixed quantity of about 2km/H RMS and not a percentage. Thus the accuracy in km/H is independent of the actual speed. Consequently the % accuracy improves with speed.
Further information can be found at:
http://ourworld.compuserve.com/homepages/wingps/nmea.htm
http://vancouver-webpages.com/peter/

Page last updated on 27th May 1999

Note: This page was written when the USAF was still applying Selective Availability. The selective availability has since been removed and the accuracy of GPS in general has greatly improved. This page has not been comprehensively updated since then, therefore anything relating to accuracy issues is likely to be obsolete, especially the part regarding accuracy statistics. (30 Jun 2002)