Zeroing in on Locations with GPS
Looking to add accurate location mapping to an electronic system? In this series, Jeff introduces GPS technology, presents a circuit that accepts a standard string of serial data, and provides useful insights into topics such as receiver data processing and trilateration.
As a youngster traveling in the family automobile, I could almost feel the level of friction between my parents when it came to driving directions obtained from a paper map. We had about a dozen of these accordion folded wonders crammed in the glove compartment. My mom wasn’t much of a map reader, so we would be constantly pulling over so dad could get out, de-origami a map on to the front hood of the car to get his bearings. Fifty (or so) years later, I remember a friend having a TomTom (mobile GPS device) stuck to his dashboard. For years, I was jealous. It wasn’t until Bev and I bought a Prius in 2009 that we experienced the joy of in car navigation. If you’ve ever depended on your automobile’s navigation system to get you somewhere you’ve never been (to) before, you may recall being frustrated by an older set of internal maps, when your destination did not exist. Not only is an update to these systems expensive, but the updates are generally out of date before they can be installed.
The navigation app on my phone always downloads the latest maps, but it does require wireless access for its display abilities. Still, our phones are a veritable office on wheels. Or a playground, as we’ve seen lately with Pokémon Go the global sensation, which uses GPS and mapping to capture famous Pokémon characters. It’s no wonder globes are passé when you have access to Google Earth’s satellite mapping and Street View’s 360°.
When the Soviet spacecraft Sputnik was launched in 1957, the US began work on the Global Positioning System (GPS) for military and intelligence applications. It is a network of satellites that orbit the Earth and beam down signals to earth. These coordinated signals allow a GPS receiver to triangulate position. Let’s skim off the cream of this satellite system in order to understand its usefulness.
SATELLITES
In the early 1960s, the Navy used Transit, a group of five satellites, to give the Polaris submarine fleet precise positioning based on Doppler frequency shift. Later that decade, advanced satellites proved that highly accurate clocks could be used to create a passive ranging technique if they were synchronized with one another. High-performance crystal oscillator clocks were soon replaced by cesium 133-based atomic clocks. Cesium’s principal resonance is used to PLL a crystal oscillator to exactly 9,192,631,770 Hz.
Before we look at why this is important, let’s continue with the progress of the satellite system as it came to be known. By the late 1970s, the first of the “block I” satellites, Timation, developed by the Naval Research Laboratory, were being placed in orbit for military purposes. A total of 11 were in orbit by the mid-1980s. Their precise altitude is such that they orbit the earth once every 12 hours. Each satellite follows a different predetermined orbit, creating a net or block of coverage (see Figure 1). This strategy allows multiple satellites to be “seen” from any given point on the Earth’s surface at all times.
Today, GPS is used for dozens of navigation applications: route finding for drivers, map-making, earthquake research, climate studies, and an outdoor treasure-hunting game known as geocaching. (Source: Smithsonian Institution, 1988. Used by Permission.)
With a projected lifetime of only five years at the time, improvements in lifespan became a critical design element to the next generation of satellites. Navstar was designed to operate with a block of at least 24 satellites in orbit. Lockheed Martin began launching the Navstar satellites in the late 1980s. A total of 21 satellites are active at any one time; the other 3 satellites parked as spares. This block was finished in 1995, but today’s GPS network has around 30 active satellites in all with the last of the “block II” family placed in orbit in January 2016.
— ADVERTISMENT—
—Advertise Here—
The next generation of “block III” satellites has already rolled off the drawing boards. This new batch of eight will displace older satellites and will provide more powerful signals in addition to enhanced signal reliability, accuracy, integrity, and a 15-year design lifespan. The first of these GPS “block III” satellites have been launched.
SYNCHRONICITY
The Global Positioning System Operations Center (GPSOC) at that Schriever Air Force Base in Colorado provides for the GPS constellation 24/7. It monitors all satellites and communicates with each to provide a continuous and accurate information base. There are three kinds of time available from GPS: GPS time, UTC as estimated and produced by the United States Naval Observatory, and the independent times of each free-running GPS satellite’s atomic clock. Let’s review each one.
UTC refers to time referenced to the zero or Greenwich meridian. We derive local time using UTC with an offset of the number of time zones (hours) between our locality and Greenwich, England. The current version of UTC is based on International Atomic Time (TAI) and averaging data from some 200 atomic clocks in over 50 national laboratories initialized to UTC on January 1, 1970. This provides accurate ticks; however, since the Earth’s spin is slowing (taking ever so slightly more than 24 hours to complete one rotation) periodically, a leap second is added to the UTC to bring everything back in line. We calculate date and time based on this adjusted reference. However, since TAI is not affected by leap seconds (the artificial adjustment of UTC, due to the Earth’s actual rotation), it now leads UTC by 39 s since its inception!
GPS time was initialized to UTC on January 6, 1980. Note: GPS time and TAI are both linked to atomic clocks, so they remain in sync, but because initialization of the two were on different dates, TAI remains 19 s ahead of GPS time. The master control station (MCS) in Colorado provides command and control of the GPS constellation of satellites. They generate and upload navigation messages to ensure the health and accuracy of the system. The MCS receives navigation information from the monitor stations around the globe to compute the precise locations of the GPS satellites in space, and then uploads this data to the satellites. This includes the data needed to keep all satellite timebases synchronized. In the event of a satellite failure, the MCS can reposition satellites to maintain an optimal GPS constellation.
Without intervention, the constellation of satellites would begin to drift out of their respective orbits. This would lead to a false sense of position and a loss of synchronization. GPS receivers would calculate positional information based on the assumption of accurate information and the inaccuracies would produce unreliable results.
GPS TRANSMISSIONS
What began with a single transmission frequency has been upgraded, adding additional transmissions to increase accuracy, while remaining backward compatible with older satellites. Let’s take a look at the original microwave signal L1 at 1575.42 MHz. If you refer to Figure 2, you’ll see that the GPS signal has three parts, the carrier, which is modulated by a combination of the navigation message and the Coarse Acquisition (C/A) code.
Satellite transmissions are a combination of PRN codes and navigation data modulating a carrier derived from the atomic clock frequency. Each satellite uses a different PRN code to help distinguish itself from the other satellites.
Satellites are uniquely identified by a serial number called space vehicle number (SVN), a space vehicle identifier (SV ID), and pseudorandom noise number (PRN number). Each satellite uses a unique PRN code, which does not correlate well with any other satellite’s PRN code. This allows the PRN (or C/A) to remain uniquely identifiable to one particular satellite. Think of it this way: each satellite transmits speech in a different language. By tuning you ear for a specific language, you can understand the content from one satellite; otherwise, it’s all noise.
The navigation message is sent at a much lower rate requiring about 30 s and carries 1,500 bits of data. This includes the week number, precise “time-of-week,” and a health report for the satellite. This small amount of data is encoded with the C/A sequence that is different for each satellite. Since each GPS receiver knows the PRN codes for each satellite, it can not only distinguish between different satellites but also decode the navigation message. This message also includes orbital information particular to itself, which allows a receiver to calculate the time-of-flight from the position of the satellite. Almanac data contains information and status concerning all the satellites and helps a receiver determine which satellites are in service and the difference between UTC and GPS time. Remember the “leap seconds” issue?
RECEIVER DATA PROCESSING
For each satellite, a GPS receiver must first acquire the signal and then track it while it remains in sight. Acquisition is most difficult if no previous almanac information is present, as the receiver must search for all PRNs in its library. This may initially require several minutes. Once acquisition of a satellite has been made, the receiver continues to read successive PRN sequences and will encounter a sudden change in the phase of the PRN, the beginning of a navigation message. The navigation message or frame is divided into multiple subframes as seen in Table 1. The almanac has 25 pages of data and requires multiple subframes.
— ADVERTISMENT—
—Advertise Here—
Each GPS message or frame consists of multiple subframes, requiring 30 s for one complete frame. Almanac subframes contain a different page of data for each satellite and therefore requires multiple frames to complete (12.5 minutes).
GPS transmitted signals are so accurate—thanks to the accuracy of on-board atomic clocks and synchronization of all satellites from the GPSOC—that time-of-flight, and thus distance to the satellite, can be calculated to within a few billionths of a second. And this brings us to trilateration.
TRILATERATION
GPS trilateration is the process of determining relative and absolute location by measurement of distances, using the geometry of spheres. The sphere or bubble radius about a satellite is the measurement of distance calculated by the GPS receiver using time-of-flight of its transmitted signal. Using a single satellite, this distance indicates the receiver might be any point on the surface of that bubble. When the distances to two known satellites have been calculated, their bubbles intersect creating a circle. The receiver’s position is now narrowed down to all points on that circle. A third satellite’s bubble will intersect that circle at two points. One of those points will be the actual position of the GPS receiver. If we assume the receiver is on Earth, we could tell which of the two positions was in fact on Earth. The use of a fourth satellite can be used to verify which of the two is correct and also affirm the integrity of all the calculations.
You can see that the GPS receiver is a highly complex system comprising not only a high-gain receiver, but also a high-precision computational unit. Like many critical technologies, a standards agency is responsible for overseeing its use. Back in 1957, the National Marine Electronics Association (NMEA) was founded by a group of electronics dealers at the New York Boat Show who wished to strengthen relationships with electronic manufacturers. Their work has led to the NMEA 0183 Interface Standard, which defines electrical signal requirements, data transmission protocol and time, and specific sentence formats for serial communications (see Table 2).
The National Marine Electronics Association has developed a combined electrical and data specification for communication between marine electronic devices such as echo sounders, sonars, anemometers, gyrocompasses, autopilots, GPS receivers, and many other types of instruments. ASCII data is sent as sentences (collections) of different data. Here’s a list of some of the GPS messages and their associated data.
Each message sentence contains a specific data set and begins with “$” plus five letters, the first two of which indicate the source of the sentence. Every sentence contains only printable ASCII characters except for a trailing <CR><LF>. For instance, when a sentence begins with “$GPGLL,” the sentence has been written by a global positioning receiver and contains geographic position, latitude and longitude data—that is, $GPGLL,4916.45,N,12311.12,W,225444,A. Let’s look at the details. 4916.46,N means latitude 49° 16.45 min North. 12311.12,W represents longitude 123° 11.12 min West. 225444 is the fix taken at 22:54:44 UTC. And lastly, A means data is valid. Any sentence may include a checksum indicated by a “*xx” following the last data byte, where “xx” is the exclusive OR of all characters between, but not including, the “$” and “*”. Each manufacturer can choose what sentences it will send and how often. Many will stream data continuously without user intervention.
Some manufacturers accept similarly formed sentences as input. This may be used to customize how the chip behaves (i.e., data rate). For this project, we will be interested in the $GPGSS sentence, because it includes latitude, longitude, and altitude. While I bought a number of GPS modules from various sources (see Photo 1), I chose an Adafruit Industries Ultimate GPS. It can operate from a 3.3-to-5-V supply (5-V tolerant I/O) with an onboard antenna, yet it has an external antenna connector.
Using a four-wire interface, it mates up nicely to the RS-232 (TTL)-to-USB dongle I use in many projects. This will let us see the sentence output using a terminal program, RealTerm, on a PC. Note the output in Photo 2.
GPS modules
The multiple sentence formats are clearly displayed using RealTerm. Each sentence can be used for a specific purpose as they hold a unique data set.
LISTENING TO THE GPS RECEIVER
To make the GPS useful, I display the latitude, longitude, and altitude data being sent out by the GPS module. To do this, I used a circuit that I’d standardized on for many projects when user I/O is required (see Figure 3). The GPS data comes in through the J7 serial port at 9,600 bps. If you refer to Photo 2 and locate the $GPGGA sentence, you will see it contains 14 pieces of data. No data between commas indicates the GPS hasn’t collected sufficient data for that entry.
I used a standardized circuit for this project. User I/O and access to multiple buses exposes the microcontroller to a large number of potential external peripherals.
For this project, I defined the lengths of the data variables (see Listing 1) and the associated variables (see Listing 2). As a bare minimum, I need one ring buffer for the RX data. This enables the data to flow in unrestrained. The job of the main loop will be to watch for serial input and make a call to process it when available. At this point we are looking for the start of any sentence, the character ‘$’. A bad compare returns to the main loop. A match allows execution to remain in the processing routine and gathers the next characters. If the new sentence exactly matches our string of interest “$GPGGA,”, then we can begin gathering data, as we know the format. If at any time the received data does not match what’s expected, we exit processing to await new data.
Listing 1
I defined the lengths of each comma-delimited ASCII string item in the $GPGSS message. Comments show the format expected.
LengthTime equ d’6’ ; HHMMSS
LengthLatitude equ d’9’ ; xxxx.xxxx
LengthLatitudeLabel equ d’1’ ; x
LengthLongitude equ d’11’ ; xxxxx.xxxx
LengthLongitudeLabel equ d’1’ ; x
LengthQuality equ d’1’ ; x
LengthSatellites equ d’2’ ; xx
LengthHDOL equ d’3’ ; x.x
LengthAltitude equ d’5’ ; xxx.x
LengthAltitudeLabel equ d’1’ ; xListing 2
The available GPS variables are declared using the expected lengths defined earlier.
Time:LengthTime
Latitude:LengthLatitude
LatitudeLabel:LengthLatitudeLabel
Longitude:LengthLongitude
LongitudeLabel:LengthLongitudeLabel
Quality:LengthQuality
Satellites:LengthSatellites
HDOL:LengthHDOL
Altitude:LengthAltitude
AltitudeLabel:LengthAltitudeLabel
Each data value has its own format and ends with a comma (just like the sentence prefix we just located). Knowing this, we can use the comma as a delimiter for the data. Time is the first data value, and it is the UTC time as six ASCII characters of the format HHMMSS. Latitude is a positive number between 0 and 90°, as nine ASCII characters using the format DDMM.SSSS. It can be north or south of the equator. And instead of using the “-” sign for south of the equator, the third data value is an ASCII “N” or “S.” Longitude is a similar positive number between 0 and 180°, as 10 ASCII characters using the format DDDMM.SSSS. It can be east or west of the prime meridian. And instead of using the “-” sign for the west of prime, the fifth data value is an ASCII “E” or “W.”
The next value is quality, and it describes not only the validity, but also how the data is produced. Anything other than “0” is valid data by calculation, estimation, simulation, or another method as indicated via the byte value. Following the quality data value is the number of satellites used in the computation of position. From previously it was shown that a minimum of three satellites is necessary to trilaterate position. More satellites provide a higher degree of verification and not necessarily more accuracy.
Depending on the relative position of the satellites used, the accuracy of the computation may be affected. The highest accuracy can be attained when the distance measurement of each satellite can be used as a single component of the result. If you think of the receiver as a cube with three separate antennas pointing at three satellites directly over that cubes surface, then the distance to that satellite affects only one dimension of the position. With more satellites to choose from, the possibility of getting closer to perfection goes up. The dilution of position (DOP)—and Horizontal DOP (HDOP) and Vertical DOP (VDOP)—is an indication of how close the satellite positions come to perfection. The higher the number, less accurate the computation.
The next data in this sentence is the altitude, which is presented in distance above mean sea level. The data value is altitude in tenths. Following this data value is the unit of measurement, “M’” (meters in this case). The remaining data (and the checksum) was not used in this project. However, I’ll mention the next data because of its potential importance.
The World Geodetic System 1984 (WGS84) establishes a point (center of mass of the Earth) from which the surface ellipsoid is measured. All water is then distributed by gravity over this surface creating a new average surface we call mean sea level. The “mean” eliminates the tide and other factors that affect the instantaneous sea level. Even though we’ve seen a rise in sea level of approximately 20 cm over the past 30 years, altitude is still commonly referred to as distance relative to the mean sea level. The next data value in this sentence is the distance of mean sea level above the surface ellipsoid. This is presented, as the altitude, with a value and unit. This was used to determine the mean sea level.
DISPLAYING THE RESULTS
I use a 4 × 20 display to present the collected data in the following format.
Time (GMT) HH:MM:SS
Lat xxºxx’.xxxx x
Long xxxºxx’.xxxx x
Alt xxx.x x Sat xx
— ADVERTISMENT—
—Advertise Here—
A number of string constants are defined that label each piece of data. The data received is mostly in the ASCII format needed for the display, with a few exceptions. The time can be delineated using colons between the hours, minutes, and seconds for a more familiar read. I also can add the degree and minute symbols to the latitude and longitude values to make this more recognizable.
When the code runs, the immediately available time is presented quite quickly from a single satellite. Position data is garbage until the receiver can calculate position based on acquisition of multiple satellites. Note: This can be blanked based on the quality value. I’ve seen as many as 11 satellites indoors with just the existing antenna Photo 3.
After the GPS module has computed a fix based on the satellites it sees, the latitude, longitude, and altitude can be displayed. Note: Using UTC time, you can calculate your local time by subtracting the number of time zones between Greenwich, England and your location.
In Part 2 I’ll discuss what you can expect for accuracies. I’ll also explain how to go outside and use the setup for some cartography.
SOURCE
Ultimate GPS Module
Adafruit | www.adafruit.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2017 #318 – Get a PDF of the issue
Sponsor this Article
Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.
