Skip to main content

An architect's guide to GPS and GPS data formats

As more applications incorporate geospatial capabilities and features, having a fundamental understanding of GPS is an important skill for today's enterprise architects.
Image
Small compass laying on a map for direction

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.

Image
an inexpensive gps device
Figure 1: Today, you can buy a GPS listening device, like the one shown above, for less than $15 USD.

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.

$GPRMC,044840.00,A,3401.21044,N,11824.67722,W,0.165,,010621,,,D*60

$GPVTG,,T,,M,0.165,N,0.306,K,D*21

$GPGGA,044840.00,3401.21044,N,11824.67722,W,2,07,1.34,29.5,M,-32.9,M,,0000*56

$GPGSA,A,3,21,32,46,27,08,22,10,,,,,,3.07,1.34,2.76*0F

$GPGSV,3,1,12,01,18,319,17,08,27,257,20,10,44,068,33,18,00,142,*73

$GPGSV,3,2,12,21,39,313,23,22,20,296,14,23,16,089,,27,22,221,32*7A

$GPGSV,3,3,12,31,28,168,20,32,70,025,31,46,49,199,30,51,49,161,*7E

$GPGLL,3401.21044,N,11824.67722,W,044840.00,A,D*7F

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.

Format

Value

Conversion logic

Result

ddmm.mmmm

3401.21189

34 + (01.21189 / 60)

34.020196

dddmm.mmmm

11824.67797

118 + (24.67797 / 60)

118.41129833

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).

Image
Code text editor running code that captures current GPS information of the device
Figure 2: The demonstration project, simplegps, processes GPS data received from an attached GPS listening device.

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:

Position

Field Name

Example Data

Description

0

Sentence Type Identifier

$GPGGA

GGA protocol header

1

Time

170241

17:02:41 UTC

2

Latitude

3401.21189

ddmm.mmmm format, converts to 34.020196 or 34d 1' 12.706" N

3

Latitude Hemisphere

N

N = North, S = South

4

Longitude

11824.67797

dddmm.mmmm format, converts to -118.41129833 or 118d 24' 48673" W

5

Longitude Hemisphere

W

W = West, E = East

6

- 0 = Invalid

- 1 = GPS fix

- 2 = DGPS fix

1

Data is from a GPS fix

7

Number of Satellites

06

6 Satellites are in view

8

Horizontal Dilution of Precision (HDOP)

2.14

Relative accuracy of horizontal position

9

Altitude

71.6

71.6 meters above mean sea level

10

Altitude Units

M

M = meters

11

Height of geoid above WGS84 ellipsoid

-32.9

-32.9 meters

12

Height of geoid above WGS84 ellipsoid Units

M

M = meters

13

Time since last DGPS update

blank

No last update

14

DGPS reference station id

blank

No station id

15

Checksum

*57

Used by program to check for transmission errors

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:

Position

Field Name

Example

Description

0

Message ID

$GPGLL

GLL protocol header

1

Latitude

3723.2475

ddmm.mmmm

2

N/S indicator

N

N =North or S = south

3

Longitude

12158.3416

dddmm.mmmm

4

E/W indicator

W

E =East or W = West

5

UTC time

161229.487

hhmmss.sss

6

Status

A

A = data valid or V = data not valid

7

Mode

A

A =Autonomous , D =DGPS, E =DR (This field is only present in NMEA version 3.0)

8

Checksum

*41

8

<CR><LF>

End of message termination

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:

Position

Field Name

Example

Description

0

Message ID

$GPVTG

VTG protocol header

1

Course

309.62

Degrees

2

Reference

T

True

3

Course

blank

Degrees

4

Reference

M

Magnetic

5

Speed

0.13

Knots, measured horizontal speed

6

Units

N

Knots

7

Speed

0.2

Km/Hr, measured horizontal speed

8

Units

K

Kilometers per hour

9

Mode

A

A = Autonomous, D = DGPS, E = DR

10

Checksum

*23

11

<CR><LF>

End of message termination

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:

Position

Field Name

Example

Description

0

Message ID

$GPRMC

RMC Protocol Header

1

UTC time

161229.487

hhmmss.sss

2

Status

A

A = data valid or V = data not valid

3

Latitude

3723.2475

ddmm.mmmm

4

N/S indicator

N

N = North or S = South

5

Longitude

12158.3416

dddmm.mmmm

6

E/W indicator

W

E = East or W = West

7

Speed over ground

0.13

Knots

8

Course over ground

309.62

Degrees

9

Date

120598

ddmmyy

10

Magnetic Variation

Degrees (E= East or W = West)

11

Mode

A

A = Autonomous, D = DGPS, E =DR

12

Checksum

*10

13

<CR><LF>

End of message termination

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:

Position

Field Name

Example

Description

0

Message ID

$GPGSA

GSA Protocol Header

1

Mode

M

M=Manual, forced to operate in 2D or 3D, A=Automatic, 3D/2D

2

Fix Quality

3

- 0 = Invalid

- 1 = GPS fix

- 2 = DGPS fix

3

PRN of Satellite Vehicle

17

Pseudo-random noise (PRN) sequence (a.k.a Gold code) of the satellite. You can think of the PRN as a code that uniquely identifies a particular satellite.

4

PRN of Satellite Vehicle

02

See description at row 3

5

PRN of Satellite Vehicle

30

See description at row 3

6

PRN of Satellite Vehicle

04

See description at row 3

7

PRN of Satellite Vehicle

05

See description at row 3

8

PRN of Satellite Vehicle

10

See description at row 3

9

PRN of Satellite Vehicle

09

See description at row 3

10

PRN of Satellite Vehicle

06

See description at row 3

11

PRN of Satellite Vehicle

31

See description at row 3

12

PRN of Satellite Vehicle

12

See description at row 3

13

PRN of Satellite Vehicle

blank

See description at row 3

14

PRN of Satellite Vehicle

blank

See description at row 3

15

Position Dilution of Precision (PDOP

1.2

The 3D Position Dilution of Precision (PDOP)

16

Horizontal Dilution of Precision (HDOP)

0.8

See Dilution of Precision on Wikipedia

17

Vertical Dilution of Precision (VDOP)

0.9*35

See Dilution of Precision on Wikipedia

<CR><LF>

End of message termination

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:

Position

Field Name

Example

Description

0

Message ID

$GPGSV

GSV Protocol Header

1

number message

3

Total number of messages (1-9)

2

Message number

1

Total number of messages of this type in this cycle

3

Number of satellites

11

Total number of satellites in view

4

Satellite #1 PRN Number

18

Pseudo-random noise (PRN) sequence (a.k.a Gold code) of the satellite.

GPS = 1 to 32

Galileo = 1 to 36

Beidou = 1 to 63

NAVIC = 1 to 14

QZSS = 1 to 10

SBAS = 33 to 64 (add 87 for PRN#s)

GLO = 65 to 96 1

5

Elevation

87

Elevation in degrees, 90 maximum

6

Azimuth

050

Azimuth, degrees from true north, 000 to 359

7

SNR

48

SNR, 00-99 dB (null when not tracking)

8

Satellite #2 PRN Number

22

Information about second SV, same as fields 4-7

9

Elevation

56

Information about second SV, same as fields 4-7

10

Azimuth

250

Information about second SV, same as fields 4-7

11

SNR

49

Information about second SV, same as fields 4-7

12

Satellite #3 PRN Number

21

Information about third SV, same as fields 4-7

13

Elevation

55

Information about third SV, same as fields 4-7

14

Azimuth

122

Information about third SV, same as fields 4-7

15

SNR

49

Information about third SV, same as fields 4-7

16

Satellite #4 PRN Number

03

Information about fourth SV, same as fields 4-7

17

Elevation

40

Information about fourth SV, same as fields 4-7

18

Azimuth

284

Information about fourth SV, same as fields 4-7

19

SNR

47

Information about fourth SV, same as fields 4-7

20

Checksum

*78

References

Topics:   Industries   Mobile architecture   APIs  
Author’s photo

Bob Reselman

Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.

OUR BEST CONTENT, DELIVERED TO YOUR INBOX

Privacy Statement