Examining the Data

When you connect a GPS to another device (such as a PC or an iPAQ) or to a software application, it is quite probable that the communication protocol used by this connection will be based

on a standard known as NMEA. NMEA is crucial to this communication, and by understanding the format that NMEA takes and how the data is structured, you are in a position to directly examine the data stream. If you can read NMEA, you can troubleshoot GPS problems, directly examine the data retrieved, and also check for corrupted data.

In this chapter, we are going to take a close look at the NMEA protocol and the format in which the data is output by a GPS receiver. By the end of this chapter, you will be familiar with the following topics:

Communicating with other devices

Software applications that enable you to capture and store NMEA data

Troubleshooting

The more you know about and understand the data, the more you can do with it.

NMEA

NMEA is the protocol most used by GPS receivers to communicate with other devices — either for data transfer to and from the unit, or for communication with other devices. The fact that this standard is used for GPS betrays its marine roots.

NMEA stands for National Marine Electronics Association, which is the body that sets and defines the standard. The full name of the standard most commonly used by GPS receivers is NMEA 0183. This standard covers not only GPS receivers but a variety of other electronic devices.

Most computer programs that provide real-time position information are capable of understanding the NMEA format. Some can only understand the NMEA plaintext format, while others use a variety of different data formats.

NMEA data sent from a GPS contains full PVT (Position, Velocity, and Time) data calculated by the GPS unit.

chapter

in this chapter

˛Introduction to NMEA

˛NMEA sentence structure

˛A tour through common NMEA sentences

˛A different standard: SiRF

˛NMEA tools

˛Recording real and simulated NMEA data

˛Troubleshooting with NMEA

196 Part III — Data Hacking

NMEA Sentences

The concept behind NMEA is to send data one line at a time. Each line of data (called a sentence) is completely standalone — self-contained and independent from other sentences. There are two kinds of sentences:

Standard sentences for each device category

Proprietary sentences for use by the individual devices and manufacturers

All of the standard sentences have a two-letter prefix defining the device that uses that sentence type. For GPS receivers, the prefix is always GP — most sentences that a GPS receiver understands are prefixed by these two letters. They are followed by a three-letter sequence that defines what the sentence contains.

As I’ve already mentioned, the NMEA standard permits hardware manufacturers to define and use their own proprietary sentences for any purpose they see fit. The only prerequisite is that all proprietary sentences must begin with the letter P, and are followed with three letters that identify the manufacturer controlling that sentence. For example, Garmin sentences start with “PGRM,” while Magellan sentences begin with “PMGN.”

Proprietary sentences vary from receiver to receiver and over time and are not covered here. Proprietary sentences contain more, and more specific, information than NMEA does, which is considered the lowest common denominator.

NMEA Sentence Structure

Each NMEA sentence begins with a dollar sign ($) and ends with a carriage return/line feed sequence. Most sentences can be no longer than 80 characters. All the data is contained inside this single line, and data items are separated by commas. The data itself is in the form of ASCII text, and the data can, especially if it’s complex, be spread over many separate NMEA sentences, but it is normally fully contained in just one sentence.

The precision of different sentences varies depending on the data. For example, time information might be given in seconds correct to one decimal place, while positional information might be given to three or even four digits after the decimal place. NMEA uses commas to separate individual fields of data. If the field doesn’t contain data, it’s left blank, but a comma is still required.

To improve accuracy, there is a provision to include a checksum at the end of each sentence, which may or may not be checked by the unit that reads the data. The checksum field consists of an * and two hex digits representing the exclusive OR of all characters between, but not including, the $ and *. The checksum is used to validate the contents of the sentence.

A checksum is required on some sentences, and optional on others.

Chapter 9 — Examining the Data 197

A Closer Look at NMEA Sentences

No detailed study of GPS is complete without a study of the most commonly used protocol for communication between the GPS and other devices. Even if you have no intentions of writing applications that process or work with GPS data, and instead plan on using only readymade applications, a basic knowledge of NMEA is very handy when it comes to diagnosing GPS problems and understanding what goes on between the GPS and the device with which it is communicating.

Here is a list of the current NMEA sentences relating to GPS receivers along with a description of what they do:

String Type	Description
$GPAAM	Waypoint Arrival Alarm
$GPALM	GPS Almanac Data
$GPBEC	Bearing & Distance to Waypoint, Dead Reckoning
$GPBOD	Bearing, Origin to Destination
$GPBWC	Bearing & Distance to Waypoint, Great Circle
$GPFSI	Frequency Set Information
$GPGGA	*Global Positioning System Fix Data (Time, Position, Elevation)
$GPGLC	Geographic Position, Loran-C
$GPGLL	*Geographic Position, Latitude/Longitude
$GPGRS	GPS Range Residuals
$GPGSA	*GPS DoP (Dilution of Precision) and Active Satellites
$GPGSV	*GPS Satellites in View
$GPHDG	Heading, Deviation & Variation
$GPHDT	Heading, True
$GPHSC	Heading Steering Command
$GPMWV	Wind Speed and Angle
$GPRMC	*Recommended Minimum Specific GNSS GPS/TRANSIT Data
	(Time, Position, Velocity)
$GPROT	Rate of Turn
$GPRPM	Revolutions
$GPRTE	Routes

Continued

198 Part III — Data Hacking

String Type	Description
$GPSTN	Multiple Data ID
$GPTRF	Transit Fix Data
$GPVBW	Dual Ground/Water Speed
$GPVDR	Set and Drift
$GPVLW	Distance Traveled through the Water
$GPVPW	Speed, Measured Parallel to Wind
$GPVTG	*Track Made Good and Ground Speed ( Course over ground and ground speed )
$GPWCV	Waypoint Closure Velocity
$GPWNC	Distance, Waypoint to Waypoint
$GPWPL	Waypoint Location
$GPXTE	Cross-Track Error, Measured
$GPXTR	Cross-Track Error, Dead Reckoning
$GPZDA	UTC Date/Time and Local Time Zone Offset
$GPZFO	UTC & Time from Origin Waypoint
$GPZTG	UTC & Time to Destination Waypoint

NMEA consists of sentences; and for each of these sentences. the first word, called a data type, defines how the rest of the sentence is interpreted. Each data has its own unique interpretation, as defined by the NMEA standard.

For example, take the GGA sentence shown here:

$GPGGA,180432.00,4027.027912,N,08704.857070, W,2,07,1.0,212.15,M,- 33.81,M,4.2,0555*73

This NMEA sentence shows an example that provides fix data information.

Sentences vary in the information they contain. Some sentences will repeat some of the information already provided, while others provide new data. Devices attached to the GPS can look for the NMEA sentence they want and choose to ignore others.

Normally, there are very few ways to control which NMEA sentences are sent from a GPS and which aren’t. The usual state of affairs is that each GPS receiver simply transmits all of the data and lets the attached device pick and choose what to read and what to ignore. Some receivers can be set to send only certain types of sentences, but there is little benefit to doing this. There is no way for the receiving device to acknowledge receipt of the data or to request that the data be retransmitted because it was lost or garbled — if the receiving unit checks the checksum on a sentence and finds it is corrupted, the receiver must wait until the next time a similar NMEA sentence is transmitted.