Writing Your Own GPS Applications: Part I

What is it that GPS applications need to be good enough to use for in-car navigation? Also, how does the process of interpreting GPS data actually work? In this three-part series, I will cover both topics and give you the skills you need to write a commercial-grade GPS application.

“I am continually amazed by how little code is required to use atomic clocks in satellites 11,000 miles above my head.”

Introduction

What is it that GPS applications need to be good enough to use in a commercial environment, such as in-car navigation? Also, how does the process of interpreting GPS data actually work? In this three-part series, I will cover both topics and give you the skills you need to write a commercial-grade GPS application that works with a majority of GPS devices in the industry today.

One Powerful Sentence

This first part in the series will explore the task of interpreting raw GPS data. Fortunately, the task is simplified thanks to the National Marine Electronics Association which introduced a standard for the industry, now in use by a vast majority of GPS devices. To give developers a head start, I chose to use some Visual Studio .NET source code from my “GPS.NET Global Positioning SDK” component. (The code is stripped of features like multithreading and error handling for brevity.)

NMEA data is sent as comma-delimited “sentences” which contain information based on the first word of the sentence. There are over fifty kinds of sentences, yet an interpreter really only needs to handle a few to get the job done. The most common NMEA sentence of all is the “Recommended Minimum” sentence, which begins with “$GPRMC”. Here is an example:

The Core of An Interpreter

The first step in making an NMEA interpreter is writing a method which does two things: separating each sentence into its individual words and examining the first word to figure out what information is available to extract. Listing 1-1 shows the start of the interpreter class.

(Listing 1-1: The core of an NMEA interpreter is a function which divides NMEA sentences into individual words.)

The next step is to perform actual extraction of information, starting with latitude and longitude. Latitude and longitude are stored in the form “DDD°MM’SS.S”, where D represents hours (also called “degrees”), M represents minutes, and S represents seconds. Coordinates can be displayed in shorthand, such as “DD°MM.M’” or even “DD°”. The fourth word in the sentence, “3939.7”, shows the current latitude as hours and minutes (39°39.7’), except the numbers are squished together. The first two characters (39) represent hours and the remainder of the word (39.7) represents minutes. Longitude is structured the same way, except that the first three characters represent hours (105°06.6’). Words five and seven indicate the “hemisphere”, where “N” means “North”, “W” means “West” etc. The hemisphere is appended to the end of the numeric portion to make a complete measurement. I've found that NMEA interpreters are much easier to work with as they are event-driven. This is because data arrives in no particular order. An event-driven class gives the interpreter the most flexibility and responsiveness to an application. So, I'll design the interpreter to report information using events. The first event, PositionReceived, will be raised whenever the current latitude and longitude are received. Listing 1-2 expands the interpreter to report the current position.

(Listing 1-2: The interpreter can now report the current latitude and longitude.)

One thing to watch out for here is that some GPS devices will report blank values when no information is known. Therefore, it’s a good idea to test each word for a value before parsing. If you need to type the degree symbol (°), hold down the Alt key and type “0176” on the numeric keypad.

Taking Out the Garbage

A checksum is calculated as the XOR of bytes between (but not including) the dollar sign and asterisk. This checksum is then compared with the checksum from the sentence. If the checksums do not match, the sentence is typically discarded. This is okay to do because the GPS devices tend to repeat the same information every few seconds. With the ability to compare checksums, the interpreter is able to throw out any sentence with an invalid checksum. Listing 1-3 expands the interpreter to do this.

(Listing 1-3: The interpreter can now detect errors and parse only error-free NMEA data.)

Wireless Atomic Time

Time is the cornerstone of GPS technology because distances are measured at the speed of light. Each GPS satellite contains four atomic clocks which it uses to time its radio transmissions within a few nanoseconds. One fascinating feature is that with just a few lines of code, these atomic clocks can be used to synchronize a computer’s clock with millisecond accuracy. The second word of the $GPRMC sentence, “040302.663”, contains satellite-derived time in a compressed format. The first two characters represent hours, the next two represent minutes, the next two represent seconds, and everything after the decimal place is milliseconds. So, the time is 4:03:02.663 AM. However, satellites report time in universal time (GMT+0), so the time must be adjusted to the local time zone. Listing 1-4 adds support for satellite-derived time and uses the DateTime.ToLocalTime method to convert satellite time to the local time zone.

(Listing 1-4: This class can now use atomic clocks to synchronize your computer’s clock wirelessly.)

Direction & Speed Alerts

GPS devices analyze your position over time to calculate speed and bearing. The $GPRMC sentence at the beginning of this article also includes these readings. Speed is always reported in knots, and bearing is reported as an “azimuth”, a measurement around the horizon measured clockwise from 0° to 360° where 0° represents north, 90° means east, and so on. A little math is applied to convert knots into miles per hour. The power of GPS is again demonstrated with one line of code in listing 1-5 which figures out if a car is over the speed limit.

(Listing 1-5: This class can now tell you which direction you're going and help prevent a speeding ticket.)

Are We Fixed Yet?

The $GPRMC sentence includes a value which indicates whether or not a “fix” has been obtained. A fix is possible when the signal strength of at least three satellites is strong enough to be involved in calculating your location. If at least four satellites are involved, altitude also becomes known. The third word of the $GPRMC sentence is one of two letters: “A” for “active”, where a fix is obtained, or “V” for “invalid” where no fix is present. Listing 1-6 includes code to examine this character and report on fix status.

(Listing 1-6: The interpreter now knows when the device has obtained a fix.)

As you can see, a whole lot of information is packed into a single NMEA sentence. Now that the $GPRMC sentence has been fully interpreted, the interpreter can be expanded to support a second sentence: $GPGSV. This sentence describes the configuration of satellites overhead, in real-time.

Real-Time Satellite Tracking

Knowing the location of satellites is important when determining how precise readings are and how stable a GPS fix is. Since GPS precision will be covered in detail in Part 2 of this series, this section will focus on interpreting satellite location and signal strength. There are twenty-four operational satellites in orbit. Satellites are spaced in orbit so that at any time a minimum of six satellites will be in view to users anywhere in the world. Satellites are constantly in motion, which is good because it prevents the existence of “blind spots” in the world with little or no satellite visibility. Just like finding stars in the sky, satellite locations are described as the combination of an azimuth and an elevation. As mentioned above, azimuth measures a direction around the horizon. Elevation measures a degree value up from the horizon between 0° and 90°, where 0° represents the horizon and 90° represents “zenith”, directly overhead. So, if the device says a satellite’s azimuth is 45° and its elevation is 45°, the satellite is located halfway up from the horizon towards the northeast. In addition to location, devices report each satellite’s “Pseudo-Random Code” (or PRC) which is a number used to uniquely identify one satellite from another. Here’s an example of a $GPGSV sentence:

$GPGSV,3,1,10,24,82,023,40,05,62,285,32,01,62,123,00,17,59,229,28*70

Each sentence contains up to four blocks of satellite information, comprised of four words. For example, the first block is “24,82,023,40” and the second block is “05,62,285,32” and so on. The first word of each block gives the satellite’s PRC. The second word gives each satellite’s elevation, followed by azimuth and signal strength. If this satellite information were to be shown graphically, it would look like figure 1-1.

(Figure 1-1: Graphical representation of a $GPGSV sentence, where the center of the circle marks the current position and the edge of the circle marks the horizon.)

Perhaps, the most important number in this sentence is the “signal-to-noise ratio” (or SNR for short). This number indicates how strongly a satellite’s radio signal is being received. Remember, satellites transmit signals at the same strength, but things like trees and walls can obscure a signal beyond recognition. Typical SNR values are between zero and fifty, where fifty means an excellent signal. (SNR can be as high as ninety-nine, but I've never seen readings above fifty even in wide open sky.) In Figure 1-1, the green satellites indicate a strong signal, whereas the yellow satellite signifies a moderate signal (in Part 2, I will provide a way to classify signal strengths). Satellite #1’s signal is completely obscured. Listing 1-7 shows the interpreter after it is expanded to read satellite info.

(Listing 1-7: The interpreter is improved to interpret the location of GPS satellites currently in view.)

A World-Class Interpreter

International readers may have spotted a subtle problem early on that was not handled in the listings – numbers were being reported in the numeric format used in the United States! Countries like Belgium and Switzerland which use different formats for numbers, require adjustments to the interpreter in order to work at all. Fortunately, the .NET Framework includes built-in support for converting numbers between different cultures, so the changes to the interpreter required are straightforward. In the interpreter, the only fractional value is speed, so only one change is necessary. The NmeaCultureInfo variable represents the culture used for numbers within NMEA sentences. The Double.Parse method is then used with this variable to convert speed into the machine’s local culture. Listing 1-8 shows the completed interpreter, now ready for use internationally.

(Listing 1-8: The completed interpreter, suitable for use anywhere in the world.)

Final Thoughts

You should now have a good understanding that an NMEA interpreter is all about extracting words from sentences. You can harness the power of satellites to determine your location, synchronize your computer clock, find your direction, watch your speed, and point to a satellite in the sky on a cloudy day. This interpreter will also work with the .NET Compact Framework without any modifications. If sentences were also stored in a file, the interpreter can be used to play back an entire road trip. These are all great features, especially considering the small size of the class, but is this interpreter ready to drive your car and pilot an airplane? Not quite yet. There is one important topic remaining which is required to make GPS applications safe for the real world: precision. GPS devices are designed to report any information they find, even if the information is inaccurate. In fact, information about the current location can be off as much as half a football field, even when devices are equipped with the latest DGPS and WAAS correction technologies! Unfortunately, several developers are not aware of this problem. There are some third-party components out there which are not suitable for commercial applications that require enforcing a minimum level of precision. Keep this article handy, however, because in Part 2 of this series, I will explain precision enforcement in detail and take the interpreter even further to make it suitable for professional, high-precision applications!

Share

About the Author

Hi there! From 2004 to 2009 I ran a company called "GeoFrameworks," publishing two components called GPS.NET and GIS.NET which helped developers quickly write location-based services. Now, I've released the source code for GPS.NET to CodePlex for you to use as you see fit.

Comments and Discussions

Fantastic library! It is a real shame that GeoFramework is to be no more (long live GeoFramework!)

A few things I've noticed in the .NET 2.0 version (haven't had a chance to check out the 3.5 version to see if it is fixed there but some of them seem to right at the core of some of the components?!

In GPS.NET\interpreter.cs: Line 1266: having _VerticalDOP default to Invalid in Initialize was causing the kalman filter to throw an exception. This isn't really the cause of the problem but setting the default to maximum fixes it. My guess is the cause would be somewhere near where the kalman filter gets initialised (when it should have been, given that the data hasn't been populated)

Line 1617: Updating the IsFixed property in existing was never populating through to the _Satellites data structure (and this in turn was causing neither the satellite signal bar or satellite viewer to show any valid satellites). Fix would be to either make Satellite a class rather than a struct and operate on _Satellites directly or update the instance of the Satellite required. I did the latter. existing.IsFixed = isFixed; _Satellites[index] = existing;

In GPS.NET\controls\polargraphics.cs: Line 184: PointF(PolarCoordinate) appears to be recursive

In GPS.NET\controls\satelliteviewer.cs: Line 1257: for loops index modifier is incrementing 'index' and not 'iconIndex' resulting in problems displaying the satellites.

Thanks for the kind words and also for your detailed feedback! GPS.NET 2.0 and 3.0 are now available as open-source projects up on CodePlex. If you like, you are welcome to message me via CodePlex and I'll make you a developer on the project. You'll be able to make the edits you've suggested.