An architect's guide to GPS and GPS data formats

Understanding what GPS is and how it works is essential knowledge for today’s enterprise architects. Just as the universal clock organizes system timestamps for applications across the planet, so too does GPS for applications that need to determine a device’s location in time and space. If you’re an application architect engaged in creating mobile applications of any sort, from rideshare apps to those monitoring forklift activity in a warehouse, being able to work with GPS is a mission-critical skill.

The purpose of this article is to introduce the basics of GPS to those architects who are new to the technology. If you’re an architect who’s already working with geographic information systems (GIS), you’re probably already familiar with the information I'm going to present. Still, you might find the content interesting as a refresher.

The structure of this article is as follows. First, I’ll give you a brief introduction to what GPS is and where it came from. Then, I’m going to present a list of different data formats emitted by a GPS device. Also, I’ll discuss a gotcha (or potential problem) that you need to know about with regard to working with GPS data. Finally, I’m also going to provide a set of reference tables at the end of this piece that describe the details of each of the most popular GPS data sentence formats.

Along with explaining the ins and outs of GPS, as an added bonus, I’ve provided an example project on GitHub written in Node.js that demonstrates how to consume and report data from a GPS device connected to a Raspberry Pi

I have a lot of information to share, so let’s start with the basics of GPS.

The roots of GPS

The Global Positioning System (GPS) is a satellite-based radio navigation system started by the Department of Defense in 1973 and is operated today by the United States Space Force. GPS is available for free to anybody with a device that can receive transmissions from the many GPS satellites in medium earth orbit.

GPS is a popular system, but it’s not the only satellite-based geolocation technology available. There are also the Galileo navigation systems operated by the EU Agency for Space Programme as well as the GLONASS system operated by Russia. Other countries such as Japan, India, and China have satellite-based geolocation technologies in play, too.

Low cost, consumer grade GPS devices often have an accuracy of about five meters (~16 ft.), so it’s not really useful for determining the distance between objects in close proximity. Expensive industrial systems have an accuracy range measured in centimeters. But, if you want to know where on the planet you are in a general sense—for example, maritime navigation or monitoring the movement of buses around a city’s streets— a low cost, consumer grade GPS device is well suited to such a purpose.

GPS transmits data via radio waves captured by a GPS receiving device that decodes the satellite output into a machine-readable binary format. You install software on the computer to which the GPS device is attached that will decode the binary comma delimited text formats.

GPS data has its roots in military and defense activities such as ensuring missile accuracy. Eventually, as the military adopted other technologies, GPS was repurposed for civilian uses typically associated with surveying and map cartography.

In general, GPS data describes a device’s location in terms of longitude, latitude, altitude, and the time that the transmission was received. As you’ll read below, GPS data is transmitted in a variety of formats, but essentially the information reports where and when you are on the planet. Still, there are structural differences, which I’ll illustrate in detail later in this article

One of the amazing things about GPS is how inexpensive it is to get up and running with the technology. You can buy a GPS dongle that attaches to the USB port on your computer for less than $15 USD. The GPS listening device shown below in Figure 1 is the one I used for this article. It cost only $13.95 USD. Fifty years ago, a comparable device might have cost hundreds, maybe thousands of dollars. It’s something to think about.

As mentioned above, I’ve created a project on GitHub for this article that demonstrates how to get GPS up and running on a Linux computer, either laptop, desktop, or Raspberry Pi, using an inexpensive GPS dongle, such as the one shown above in Figure 1.

Understanding the GPS formats

As stated previously, location data is received by a listening GPS device from a GPS satellite as radio waves. The GPS listening device converts the binary stream into lines of text. Each line is comma-delimited according to a conventional format. In GPS parlance, a delimited line is called a sentence. Listing 1 below shows an example of the output sentences as captured by a GPS listening device attached to a computer. Notice that the output shows various GPS sentences, for example, $GPRMC, $GPVTG, $GPGGA, etc. These symbols indicate the GPS sentence format.

Listing 1: An example of GPS sentences being captured by a GPS listening device.

There are presently over 60 different formats for GPS sentences. However, today only a handful of them are in general use. The more common GPS sentence formats are:

• GPGGA: Global positioning system fix data (time, position, fix type data)
• GPGLL: Geographic position, latitude, longitude
• GPVTG: Course and speed information relative to the ground
• GPRMC: Time, date, position, course, and speed data
• GPGSA: GPS receiver operating mode, satellites used in the position solution, and DOP values.
• GPGSV: The number of GPS satellites in view, satellite ID numbers, elevation, azimuth, and SNR values.

The bonus section that follow at the end of this article describes the formats of the sentence formats listed above int Table 1. But, before you read the details of each GPS sentence format, there’s a gotcha you need to know about. It has to do with how longitude and latitude are described in the various GPS sentence formats.

Beware the gotcha

When it comes to GPS, there are a few formats for reporting latitude and longitude. The difference in the formats will affect how you process incoming data. The discrepancy among latitude/longitude formats has to do with history.

Originally back in the days of old, when mighty sailing ships circled the globe, a point on Earth was described in terms of degrees, minutes, and seconds. Thus, the location of the White House at 1600 Pennsylvania Ave, Washington DC is described as follows: latitude: 38° 52' 44.941" N (38 degrees, 52 minutes, 44.941 seconds, North) and longitude: 76° 58' 54.521" W (76 degrees, 58 minutes, 54.521 seconds, West).

Over time a decimal format emerged in which the location of the White House is described as latitude 38.879150390625 and longitude -76.9818115234375. When a location is North of the equator, it has a positive number for its location; South has a negative value. When a location is East of the prime meridian in Greenwich, England, it has a positive number. Locations West of the prime meridian have a negative number. The White House is in the Northern hemisphere, hence a positive latitude of 38.879150390625. But, it’s in the West, thus giving it a negative number for longitude, -76.9818115234375.

The difference between using the degrees, minutes, and seconds format and degree and the purely floating-point decimal version is a matter of translation. It’s not really a gotcha. The problem is there is another format for describing latitude and longitude that appears to be the floating point decimal format, but it's not! Take a look at the GPS sentence below. The latitude and longitude numbers are in bold.

$GPGGA,170243.00,3401.20701,N,11824.6820,W,1,06,2.14,70.9,M,-32.9,M,,*51

Notice that latitude is 3401.20701 while longitude is 11824.68206. This is not the floating-point decimal (##.######) format used in the White House example shown above. Rather, GPGGA, as well as other GPS sentence structures, use the dddmm.mmmm format for latitude and the dddmm.mmmm for longitude.

At first glance, you might think that the ddmm.mmmm and dddmm.mmmm formats represent a numeric value, but they do not. Rather these formats are a concatenation of numerals in which the position of each digit has a specific meaning.

In the ddmm.mmmm and dddmm.mmmm formats the dd and ddd digits indicate degrees. The mm.mmmm digits indicate the minute and fraction of a minute. Thus, the latitude expressed as 3401.21189 in ddmm.mmmn format, translates into 34.020196 in ##.##### format.

For those readers that like this sort of detail, Listing 2 below shows the conversion logic for the latitude 3401.21189 and longitude 11824.67797, from the ddmm.mmmm and dddmm.mmmm formats to standard decimal values.

^{Listing 2: Converting GPS latitude and longitude represented in ddmm.mmmm and dddmm.mmmm formats to standard decimal values.}

For those architects designing mobile systems, identifying the standard by which to represent and consume GPS data is an important determination, particularly when you’re passing data between systems and microservices. Developers writing programs that analyze GPGGA sentences or any of the other various GPS sentence formats will need to accommodate how latitude and longitude data are formatted. It can be a bit of a chore in terms of parsing.

The long and short of it is that you need to be aware of field formats when working with a specific GPS sentence.

Getting the sample code

As mentioned at the beginning of this article, I’m providing a sample application that demonstrates how to gather GPS information from a computer that has a GPS listening device attached. You can download the demonstration project that accompanies this article on GitHub.

The demonstration project, named simplegps, shows you how to attach a GPS device to a Linux computer or Raspberry Pi via a USB port and then use the daemon GPSD to capture GPS data from the connected device.

In addition, the readme file in the repository shows how to download and use the various GPSD client tools that are available for displaying data emitted by the GPSD daemon. Last, but not least, the repository has the source code for the simplegps API that’s written in Node.js. The API will report the current location of the GPS device attached to the Linux computer or Raspberry Pi. Also, the API can report how far away another GPS device is by providing the latitude and longitude of the distance device according to its GPGGA sentence structure. The animated GIF below in Figure 2 shows the simplegps code running in the VS Code integrated development environment (IDE).

Putting it all together

GPS is a powerful technology that has become commonplace for a variety of use cases, everything from rideshare applications to maritime navigation to geographic surveying. It has a long history and will be around for a long time to come. But, be advised that as the use of 5G technology grows, it may very well supplant a good deal of GPS activity.

5G relies on transmission stations that are placed in very close proximity to each other. The close proximity of transmission stations to client receivers makes it easy to track 5G-enabled devices with more detail than is presently reported by GPS satellites. Remember, GPS is only accurate to within five meters. 5G has the potential for a greater degree of accuracy.

Nonetheless, GPS isn’t going away any time soon. And, as mentioned early, advanced GPS equipment has a degree of geospatial accuracy that goes well beyond the limitations of low cost, consumer devices. Thus, the time you take to learn more about it now will serve you well for the foreseeable future.

GPS is a very cool technology, and it’s available at a price point that makes it accessible to just about anybody with an interest in taking advantage of its capabilities. Moreover, given that mobile technology is very much a part of today’s digital enterprise, GPS offers many opportunities to any Enterprise Architect designing applications for today’s digital infrastructure. These days, you literally can’t leave home without it.

Bonus Section: The details of the GPS sentence format

The sections that follow describe the details of the GPS sentences listed above in Table 1.

GPGGA

Global Positioning System Fix Data (Time, Position, Elevation)

GPGGA is a commonplace format specified by the National Marine Electronics Association (NMEA. In addition to GPS receivers, it’s also used by echo sounder, sonar, anemometer, gyrocompass, and autopilot devices.

Example:

$GPGGA,170241.00,3401.21189,N,11824.67797,W,1,06,2.14,71.6,M,-32.9,M,,*57

Field Description:

GPGLL

Geographic Position, Latitude/Longitude

GPGLL is also a commonplace sentence format. Whereas GPGGA contains altitude information, GPGLL does not. It’s best use is for ocean-going vessels.

Example:

$GPGLL, 3723.2475, N, 12158.3416, W, 161229.487, A, A*41

Field Description:

GPVTG

Track Made Good and Ground Speed (Course over ground and ground speed)

A key feature of GPVTG the format is that it provides course and speed information. GPVTG does not provide latitude, longitude, or altitude information.

Example:

$GPVTG, 309.62, T, ,M, 0.13, N, 0.2, K, A*23

Field Description:

GPRMC

Recommended Minimum Specific GNSS GPS/TRANSIT Data (time, position, velocity)

GPRMC is also a GPS sentence format similar to GPVTG. But, in addition to speed information, GPRMC provides latitude, longitude, and altitude information.

Example:

$GPRMC, 161229.487, A, 3723.2475, N, 12158.3416, W, 0.13, 309.62, 120598, , *10

Field Description:

GPGSA

GPS DoP (dilution of precision) and Active Satellites

GPGSA is a sentence format that provides information about the satellites reporting GPS positions in terms of pseudorandom noise sequence. You can think of the PRN as a code that uniquely identifies a particular satellite.

Example:

$GPGSA,M,3,17,02,30,04,05,10,09,06,31,12,,,1.2,0.8,0.9*35

Field Description:

GPGSV

GPS Satellites in View

GPGSV sentence format reports a number of satellites in view (SV) from a given geolocation. Each sentence can have information for up to four satellites, but any sentence can be part of a group of messages as reported by the message field, number of messages and then managed accordingly.

Example:

$GPGSV,3,1,11,18,87,050,48,22,56,250,49,21,55,122,49,03,40,284,47*78

Field Description:

References

• GPS NMEA sentence information
• gpsd - a GPS service daemon
• NMEA Sentence Decoding
• Wikipedia: 5G
• Wikipedia: GPS