CC Blog Projects Research & Design Hub

Add GPS to Your Embedded System

Written by Stuart Ball

MCU-Based Design

We depend on GPS technology a lot these days, and technology advances have brought fairly powerful GPS functionally into our pockets. Today’s miniaturization of GPS receivers makes it practical to embed a GPS module into your system design. In this article, Stuart shows how to do this and take advantage of the GPS functionality.

  • How to embed a GPS module into your system design

  • How to understand how a GPS works

  • How to design the circuitry

  • How the NMEA protocol works

  • How to develop the software

  • How to interface the device with a PC

  • Texas Instruments TM4C1233D5 Arm MCU

  • STMicroelectronics LF33 3.3 V regulator

  • Lumex SO2004D, a 20-character × 4-line LCD

  • U-blox NEO-7 GPS receiver

  • TI Code Composer Studio

My first engineering job out of college was working on the early deployment of the Global Positioning System, or GPS. At that time, the full constellation of GPS satellites hadn’t been launched yet. GPS was then a military program, and the GPS receivers were large. Even though we were designing with the latest technology, it is ancient by today’s standards. Now I go hiking with a much better GPS receiver in my pocket.

In addition to pocket-sized GPS units, the miniaturization of GPS receivers allows you to purchase an inexpensive but capable GPS module that you can add to your designs. It’s not practical to build your own map-based navigation system. But GPS has applications in addition to helping you navigate your vacation.

GPS receivers provide time, latitude and longitude information—and there are applications where that can be useful even without street maps. Such applications include:

• Logging the movements of vehicles or shipping containers
• Monitoring the movement of unstable ground or other geologic features
• A radio-controlled boat or drone that returns home if the radio signal is lost
• A storage unit or other piece of equipment that uses a cell modem to dial “home” if it is moved more than, say, 100’ or outside some predetermined area
• A very accurate time source
• Steering or stabilizing drones
• Triggering a camera, cell modem or other device at a specific place
• Making a detailed topographical map of your property—or any property

Although smartphones have GPS, some of them depend on proximity to cell towers for navigation. When hiking in the mountains here in Colorado, there often isn’t any cell service. GPS doesn’t have that problem— although it does need to be able to find satellites. And since a GPS receiver doesn’t broadcast anything, you can be the only one who knows your location—if that’s important to you.


Conceptually, GPS is simple. A receiver needs four satellites to calculate its position. Each GPS satellite broadcasts its identification, health status, position and a very accurate time signal. The receiver compares the time broadcast by the satellite to the actual time when the signal was received. The difference is the travel time of the signal. Knowing how fast the signal travels, the receiver can calculate how far it is from the satellite, using the equation: Distance = Rate × Time. This tells the receiver that it is located somewhere on a sphere with the satellite at the center.


Advertise Here

By making the same calculation with a second satellite, the receiver knows it is somewhere on a circle that is the intersection of the two spheres. A third satellite provides two points, one of which is in space or in the center of the earth and can be discarded. So, using three satellites, the receiver can tell where it is in three dimensions.

So why do GPS receivers need four satellites to obtain a position fix? The reason is the measurement of the transmission time to plug into the “Rate × Time” equation. The rate in this case is almost the speed of light, so time is a very small number.

The GPS satellites use onboard atomic clocks to keep very accurate time. Without an atomic clock at the receiver, the precise time the satellite signal was received cannot be determined, and the travel time cannot be calculated. The fourth satellite provides an accurate reference time. Although only three satellites are need for positioning, the position calculation for those three satellites is time-based and requires atomic-clock time accuracy.

So, if GPS satellites only broadcast time, were do those street maps and hiking maps come from? They’re stored in your GPS receiver. The receiver translates the longitude and latitude calculated from the satellite signals to a position on a stored map. That’s why building your own in-car or hiking navigation system is impractical. You have to develop or license the maps, and interface them using your software. Generally, only commercial products that have enough production volume to recoup that expense are going to use maps.

Although the concept of measuring the difference between transmitted and received time is simple, the actual implementation is more complex. The GPS signals are sent as a series of pseudorandom bit streams, and the receiver must correlate to the incoming bitstream to decode the satellite signals. Early GPS receivers needed a separate hardware channel for each satellite tracked. Modern receivers can have many channels in a single IC, making satellite acquisition and tracking faster and more accurate because every visible satellite can be tracked simultaneously.

The web site has quite a bit of information about the GPS system.


Figure 1 and Figure 2 show a GPS module connected to an Arm-based microcontroller and LCD display. The MCU circuit in Figure 1 is a Texas Instruments TM4C1233D5 Arm MCU that I wired onto a board with headers, so I can plug it into larger boards. This lets me build experimental circuits without having to wire the MCU part every time. The LCD and GPS receiver shown in Figure 2 are on a board with headers for the Arm module.

FIGURE 1 – TM4C1233 MCU for the GPS project. J4/J5 are headers mounted on the back of the board. This circuit board is plugged into a larger board with the GPS and LCD via J4/J5.
FIGURE 2 – Schematic of the LCD and GPS circuit. The TM4C MCU board plugs into the J1/J2 connectors on this board.

Figure 3 shows the boards assembled into a proof-of-concept model. If you look up the displayed longitude/latitude coordinates on Google, you will find that it is a parking lot in Longmont, CO. The sidebar in this article (scroll down to bottom of page) “Understanding NMEA Messages” explains how to convert the coordinates.

Figure 3 – Proof-of-concept board showing TM4C module, LCD and GPS module. Note the wire antenna in the SMA connector.

You might notice in Figure 3 that the antenna is a wire plugged into the external antenna connector. On the GPS module I received, the passive antenna was not working. There may be a way to switch between the passive and active antennae, but the board came with no documentation and the online seller had no technical knowledge at all. So, if you purchase a no-name module from somebody in China, well, buyer beware.


Advertise Here

Since the onboard passive antenna was not working, I put an 8” wire into the SMA connector for the external antenna. I wouldn’t go hiking using that antenna, but it was good enough to get a GPS fix. I did later connect an active GPS antenna and that worked as well.

The circuit operates from 5 V, with STMicroelectronics LF33 3.3 V regulators for the TM4C processor and the GPS module. The LCD display uses 5 V and U2 and U3 on the LCD/GPS board provide the 3.3 V to 5 V interface for the LCD. The LF33 regulator tabs are soldered to copper tape, which you can see in Figure 3. The MCU is a TI TM4C1233D5, which operates up to 80 MHz and is in a 64-pin QFP package. It has a USB interface—not used in this design—and multiple serial ports. Serial port 0 is reserved for downloading firmware to the MCU and for debug output, and serial port 3 is used for communication with the GPS.

The GPS module outputs a 1 PPS (pulse per second) signal on one of the pins. This is connected to the MCU but isn’t used in the software. The LCD is a Lumex SO2004D, a 20-character × 4-line display with a standard LCD parallel interface. The LCD is operated in 4-bit mode in this circuit. You will notice that there are two unconnected pins on the LCD connector for a backlight LED. The LCD I’m using has the pins but no backlight. The GPS is a small, self-contained GPS receiver with an antenna. It is based on the popular U-blox NEO-7 GPS receiver, mounted on a small PCB. The output of the receiver is an asynchronous serial signal that follows the NMEA (National Marine Electronics Association) protocol.


NMEA is an industry association that supports standardization of marine navigation interfaces—among other things. For the purposes of this article, we’re interested in the standard NMEA serial protocol that is transmitted by most GPS receiver modules.

The NMEA protocol was developed in the 1980’s and is intended to connect various navigation instruments. It uses asynchronous serial data, and all the characters are ASCII. Because most MCUs have at least one serial port, this is a perfect interface to use. The NMEA specification uses RS-232 or RS-422 voltage levels. GPS modules like the one used for this project follow the NMEA message protocols, but send and receive logic level signals, not RS-232/RS-422.

Each NMEA message consists of a “sentence” that starts with a $ and has fields separated by commas. The sentence ends with an ASCII carriage return/line feed pair. The first characters after the $ are the message type. The $GPGGA (GLGGA for the Russian GLONASS system) is a standard GPS message with latitude, longitude, UTC time and a few other things.

The standard NMEA interface baud rate is 4800 baud, although the unit I purchased has a default baud rate of 9600. The baud rate limits how quickly you will get position updates from the module. But updating once every second or so is not going to degrade the usefulness of the system much—unless you happen to be piloting an F-35 on full afterburner. In any event, the U-blox NEO-7 baud rate and update rate can be changed.


The software in the proof-of-concept model is written in C using the TI Code Composer Studio application. The primary code components are as follows:

Main code: The main code initializes the hardware and checks for incoming GPS data, and writes to the LCD when the LCD is ready to accept data. It also blinks the heartbeat LED once per second.

LCD code: The LCD code initializes and configures the 20-character x 4-line LCD, and has interface functions for the LCD. There is a buffer for outgoing data to the LCD, so the other processes don’t write directly to the LCD. Instead, they call a function to put data and command bytes into the buffer. The buffer is flushed to the LCD as the LCD is able to accept the data. The LCD code exposes functions to write the buffer, check available buffer space, and flush the buffer to the LCD.

The GPS code initializes the serial port for the GPS, and has a function that is called from main when a new GPS character is received. That function extracts the position, time, and speed information from the GGA and VTG sentences, and writes it to the LCD. The display is used as follows:

Line 1: Latitude and operation mode
Line 2: Longitude
Line 3: Altitude and speed
Line 4: UTC time

The software also has debug modes that display the first 20 characters of the GLL or GGA messages on the LCD, or send all the messages via UART0 to a host PC. UART0 of the MCU is connected to the PC for downloading and debugging, using the technique described in my article “Debugging Embedded Systems with Minimal Resources” (Circuit Cellar, July 2016). The current mode of operation is shown as the last character on line 1 of the LCD.


There are a number of things you can do to adapt these concepts to your specific design. For example, the GPS module I used is a prefabricated board, with the U-blox GPS unit already connected to an antenna, and a header for connection to the host MCU. This eliminates the need to lay out a PCB for the prototype or deal with the RF portion.

In your application you might want to use a different GPS receiver, such as the Maestro Wireless (now part of Lantronix) A2200, or you might want to put the U-blox module on your own PCB. The PCB module I used is simple, but using a different module or integrating the u-blox receiver into your own design allows you to take advantage of additional features in the receiver. Depending on which receiver you choose, these include power mode control to reduce power consumption, internal flash memory for data logging and different interfaces.


Advertise Here

The U-blox NEO-7 module includes serial, SPI, and I2C interfaces. Only the serial interface is brought out on the PCB I used. But using the NEO-7 (or another GPS module) on your own PCB would allow you to choose a different interface. You could connect an SD card socket to the MCU, so you can have an SD flash card as removable storage of a position log.

The Quality field in the GGA message reports the quality of the fix, with a character of “0” meaning no fix is available. You can use that to check the validity of the data, although the NEO-7 receiver sends empty fields for the position data if it doesn’t have a valid GPS fix. The software in this design detects a missing latitude field and displays “NO FIX” on the LCD, and ignores the rest of the fields except UTC. UTC is still displayed, because it is possible to get the time with just one satellite.

The GGA message reports altitude in meters. My software only displays the integer portion of altitude so there is room on line 3 for the speed information. The VTG message reports speed in knots or in kilometers-per-hour (KPH). Why knots? Because NMEA is a nautical organization. If you want miles-per-hour (MPH), you’ll have to convert.

All NMEA sentences have a checksum at the end. I didn’t use it but you can calculate it in your application to validate the message contents.

What about that 1 PPS signal from the receiver? How might you use that? Since the 1 PPS signal is synchronized to the GPS atomic clocks, it is extremely accurate. A laser ranging system could have GPS receivers at both ends and the transmitter could use the 1 PPS as a trigger for an output pulse; the receiver could use the 1 PPS signal from its own receiver to start a timer, measuring how long before the signal is received. The 1 PPS compensates for any clock variation between the two systems. The 1 PPS signal, and the GPS UTC in general, provide accurate timing that is independent of the accuracy and drift of the oscillator in your system. So, any system or group of systems that need to synchronize to a common, precise time reference can use these.


For many applications, you will want to know the distance between two GPS values. The position output of the module is latitude and longitude in degrees and decimal minutes. If you think of the north pole as the “top” of the earth, latitude lines run horizontally around the earth, parallel to the equator. Longitude lines run from north to south, converging at the poles.

In the US, the latitude of Santa Monica, CA, on the west coast, is 34.0. This is about the same as Wilmington, NC, on the east coast, at 34.2. The distance between two degrees of latitude is about 69 miles, and each minute of latitude is about 1.1 miles. These are approximations and they vary a little because the earth isn’t exactly spherical. For mapping applications, you would want software that accounts for this. For calculations on the order of “how far did it move since my last reading,” the approximations may be good enough.

Longitude is a little more complex. The longitude lines come together at the north and south poles of the earth. Consequently, the distance between north-south longitude lines is greatest at the equator and smaller near the poles. At the equator, the distance between longitude lines is about 69 miles, the same as latitude. To measure distance between longitude lines, you would want to calculate or use a table to find the distance based on latitude.

You might want to calculate the distance between two latitude/longitude values. For example, you might have a waypoint where you parked your car and you want to know how far it is from where you are now. I always set a waypoint when I park my car while hiking.

There are two formulas—one based on the cosine law and the other called the haversine formula—that will let you calculate this distance between two GPS latitude/longitude points. You can find these on the Internet and implement one or the other for distance calculations. But be aware that you will need high-precision math. The earth’s mean radius is about 6371 km, so calculating small distances means taking sines and cosines of very small angles. You need several decimal places to make the calculations work.


If you just want to experiment with this kind of GPS module without building the entire MCU circuit, U-blox has a downloadable application called u-center that will let you view the GPS output on a PC with a serial port. Figure 4 shows a simple interposer board that connects the GPS to a Molex header. You can then use the level shifter from the aforementioned Circuit Cellar article to connect to a PC serial port. You will need a 3.3 V power supply for this.

FIGURE 4 – Schematic of a simple interposer board to connect the GPS module to an RS-232 converter module, which then connects to a PC serial port.

Although GPS is conceptually simple, actually designing a GPS receiver/processor is a complex project involving microwave RF, correlator design and software to find position. But inexpensive off-the-shelf GPS receiver modules can provide an easy way to add GPS to your designs. The receiver module does the hard work of receiving and processing the GPS satellite data, and provides you with a simple representation of position. That lets you focus on your application instead of the details of making a GPS receiver and makes design with GPS much simpler. 

NMEA messages are “sentences” that start with $ and end with a carriage return/linefeed pair. A typical GPS message with longitude, latitude, and time looks something like this:


Here’s what each message part means:

$GPGGA: Message type header; $GP is GPS, $GL is GLONASS, GGA is message type.
141202.00: Time, UTC.
3000.1234567,N: Latitude
06111.8901234,W: Longitude
1: Signal quality (0 = no fix)
10: Satellites in use
1.10: HDOP
123.456,M: Altitude (M is meters)
19.876,M: Geoidal separation (M is meters)
0.11: Correction age
0000: Base station
*20: Checksum

For the GPS module used in this project, if a fix cannot be obtained, the message looks like this:


Note that the quality field is 0 (no fix) and the latitude and longitude fields are empty

Other NMEA messages are also transmitted; for example, GLL has longitude, latitude and UTC. VTG has speed. The selection of messages transmitted by the GPS module is configurable, so you can limit what is sent if you only need some of the messages.

The NMEA latitude/longitude coordinates are in degrees and decimal minutes. There are 60 minutes in a degree. To convert the coordinates in Figure 3 to decimal values, you would use the latitude digits (40 degrees) and divide the remaining value by 60 (9.0782/60 = 0.1513). You would do the same with the longitude, with 105 degrees and 5.68112/60 = 0.09468. If you put 40.1513N 105.09468W into Google maps, you will see the result.

You will notice that the altitude shown on line 3 is 1,524 m, or 5,000 feet. Denver is known as the mile-high city, but there are a lot of places in Colorado that are about the same altitude.

National Marine Electronics Association

Maestro Wireless Solutions |
Lumex |
STMicroelectronics |
Texas Instruments |
U-blox |


Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.

Note: We’ve made the May 2020 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

+ posts

Stuart Ball is a registered professional engineer with a BSEE and an MBA. He has more than 30 years of experience in
electronics design. He is currently a principal engineer at Seagate Technologies.

Sponsor this Article

Supporting Companies

Upcoming Events

Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2021 KCK Media Corp.

Add GPS to Your Embedded System

by Stuart Ball time to read: 14 min