This document describes the design and implementation of a GPS tracker system. The system uses a GPS module to receive location data in NMEA format. A client program parses the NMEA strings and sends the latitude and longitude to a server program over TCP. The server displays the coordinates on an LCD screen connected via I2C. The system is designed to be portable by powering from a battery. Areas for future work include displaying additional GPS data and implementing checksum validation.

1. This paper is submitted as part of Final project in CSE598.
Abstract—GPS is a satellite based navigation system made
up of a network of 24 satellites placed into orbit. A GPS must
be locked on to at least 3 satellites at any given point in time
to get reliable data. This paper explains the design
philosophy and implementation details behind a GPS
tracker. The GPS tracker mentioned here displays data on a
LCD device with both LCD and GPS modules communicate
using sockets to ensure portability.
Index Terms— GPS, regex, LCD, client, server, NMEA,
GPRMC.
I. INTRODUCTION
PS tracking unit is a device, normally carried
by a moving vehicle or person, that uses the
Global Positioning system to determine and
track its precise location, and hence that of its carrier, at
intervals. The recorded location data can be stored within
the tracking unit, or it may be transmitted to a central
location data base. In this design, the co-ordinates(i.e.
latitude and longitude) are transmitted to an LCD module
over a client-server architecture.
G
GPS trackers usually fall into either Data logger or Data
pusher category. This design is a slight modification from
Data pusher such that the server does not store any GPS
data. Instead, the primary function of the server is to
display the incoming co-ordinates on the LCD display.
A. Abbreviations and Acronyms
GPS stands for Global positioning system. NMEA
correspond to National Marine Electronics Association,
LCD stands for Liquid Crystal Display, DMS is
abbreviation for degree, minute and seconds, regex
correspond to regular expressions. DC is Direct Current.
II. DESIGN OF THE TRACKER
A high level overview shows that the GPS tracker
consists of a client-server system where the Client
receives serial data from the GPS module and the server,
upon receiving the data displays it on the LCD display.
Socket communication has been used even though the entire
code base is on the same system is due to portability of the
code.
A. Read serial data
Adafruit ultimate GPS breakout supporting 66 channels
with 10 Hz is used in this project. This board draws in 5V
power supply and uses MTK3339 chipset.
Though the module has in-built data logging capability, the
data has been streamed to the server without any storage.
The module outputs the data in NMEA 01823 format at 9600
baud by default.
The GPS module is usually connected with USB module to
the Raspberry Pi. In this project, it is connected through the
serial port. To change this setting, /boot/cmdline.txt has been
modified to free the UART port(disabling the boot messages).
By default, UART port(/dev/ttyAMA0) is being used by the
kernel for logging, and it needs to be released. Along with
cmdline.txt file, /etc/inittab has been changed not to re-spawn
the serial port.
After the serial port is released, just doing a “cat” command
on UART module would spit out the GPS data. Initial design
involved just reading the file and piping the data to the client
module for parsing. In later design, wiringPiserial library is
Design and implementation of Global
positioning system Tracker
Vignesh Kannan, School of CIDSE, ASU.

2. used to read the serial data. Entire implementation has
been written using C.
a)Wiring configuration:
GPS module BCM pin
VIN +5v
GND -5v
TX RXD
RX TXD
b)GPS data format:
GPS receivers may be used to for many applications
like autopilots, fish-finders or along with other GPS
receivers and so, NMEA has different protocol format for
the messages being generated by the GPS module. The
most important NMEA sentences include the GGA which
provides the current Fix data, the RMC which provides the
minimum gps sentences information, and the GSA which
provides the Satellite status data.
GGA - essential fix data which provide 3D location and
accuracy data.
GSA - GPS DOP and active satellites. This sentence
provides details on the nature of the fix. It includes the
numbers of the satellites being used in the current solution
and the DOP. DOP (dilution of precision) is an indication of
the effect of satellite geometry on the accuracy of the fix.
RMC - NMEA has its own version of essential gps pvt
(position, velocity, time) data. It is called RMC, The
Recommended Minimum.
GSV - Satellites in View shows data about the satellites
that the unit might be able to find based on its viewing
mask and almanac data. It also shows current ability to
track this data.
VTG - Velocity made good. The GPS receiver may use the
LC prefix instead of GP if it is emulating Loran output.
Read serial data module reads data from UART port
at 9600 baud and print the data onto the stdout. WiringPi's
serialGetchar returns Ascii representation of a character.
Hence, read_serial_data module typecasts the data as
character and prints out the data.
B. Client
As the data from the serial module is sent out to stdout, client
code would read the data from stdout and parse the data
according to NMEA specifications. As mentioned above, at
this stage only the RMC statements are taken into
consideration. So, the before parsing the data, the GPS
sentence needs to be checked if it is in GPRMC format.
NMEA specifies GPRMC to have the format as below.
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,23
0394,003.1,W*6A
Where:
RMC Recommended Minimum sentence C
123519 Fix taken at 12:35:19 UTC
A Status A=active or V=Void.
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
022.4 Speed over the ground in knots
084.4 Track angle in degrees True
230394 Date - 23rd of March 1994
003.1,W Magnetic Variation
*6A The checksum data, always begins with *
Client implementation begins by matching the first word to
be “$GPRMC” and if a match is found, the sentence is sent to
parser.
The parser implementation would tokenize the given
sentence based on comma delimiter and uses regular
expressions to parse individual fields.
a) Time:
The second field in GPRMC statement gives information
about UTC time. Hence the POSIX regular expression used
is, “([0-9]{2})([0-90{2})([0-9]{2}).(.*)”. This would group date,
month and year appropriately and it is stored in a global data
structure.
b) Validity check:

3. The third field is checked to see whether the GPS
data is void or active. If found void, the statement is
skipped and the implementation proceeds with the next
statement.
Other than first 3 fields, any other field can have void
data. Hence the implementation checks whether the field
is void or contains useful data.
c) Latitude:
The fourth field contains data about the longitude.
This along with fifth field provides the longitude along
with hemisphere data. The regular expression for latitude
is “([0-9]{2})([0-9]{2}).(.*)” . This implementation displays
the data in degrees, minutes and seconds format rather
than the usual degree format. Hence, 33.4190815
correspond to 33°25'8.693” in DMS format.
d) Longitude:
The sixth and seventh field has data about longitude
and hemisphere data. The regular expression is “([0-9]{3})
([0-9]{2}).(.*)”. Even the longitude is mentioned in DMS
format. 111.920942099999 correspond to 111°55'15.391”.
e) Date:
The tenth field gives the date. This is parsed by “([0-9]
{2})([0-9]{2})([0-9]{2})”. All the data is stored in a global
data structure which gets passed to the server.
f)Speed:
The seventh field gives the speed of the object in
knots. This does not require any regular expression
matching.
g)Track angle:
The eighth field gives track angle and it does not require
regular expression matching. The track angle is the
direction that the vehicle is moving in.
h) Magnetic variation:
This is the angle on the horizontal plane between
magnetic north(the direction the north end of a compass
needle points, corresponding to the direction of the Earth's
magnetic field) and true north(the direction along a meridian
towards the geographic north pole). This varies depending on
the position on Earth's surface. This does not need regular
expression matching and it can be just copied to the data
structure.
The client module would continue with parsing the next
sentence after this. Once entire data structure is populated,
control is transferred to the client socket. It connects to server
socket prior to parsing the GPS data. Client is connected
through TCP socket at a known port number between server
and client (server listens to a hard coded port 25750).
The data is sent using standard Linux write command. Since
network communication can be expensive, only 2 character
strings corresponding to latitude and longitude are sent over
the socket. In further phases, using a button interrupt, any
data can be sent over to the server.
C. Server:
Server module listens to port 25750 and accepts at most
5 clients at a time. Server does not do any processing. It
receives the data from client and forwards it to LCD stub.
LCD stub receives the data from master and writes it to LCD
device.
This project uses HD44780U LCD module with standard
Hitachi controller. This is a 16*2 LCD working on 5v power
supply. This can display up to one 8-character line and ttwo
8-character lines.
The module connects through I2C bus. Below is the wiring
configuration
LCD module BCM pin
VCC +5v
GND -5v

4. SDA SDA
SCL SCL
LCD module is loaded at address 0x3f.
Configuration:
The configuration details are provided as below.
1. Wait for more than 40ms after Vcc raises to 2.7 v
2. Function set by sending (0011 0011) followed by
(0011 0010) to the module.
3. Set the data length, number of lines and font size
by setting the appropriate bits in the template below.
0 0 0 0 0 1 DL N F x x
4. Set display and control and blink.
The template is as below
0 0 0 0 0 0 0 1 D C B
5. Set the cursor move direction
0 0 0 0 0 0 0 0 1 I/D S
I/D stands for Increment/decrement the pointer as the
characters are getting displayed.
Once the configuration is set, the LCD is all set to display
the characters.
WiringPiI2cWrite has been used to write individual
characters to the display.
Since the LCD is working in 4-bit interface configuration,
there are 2 writes to send a byte to the display. This is
intended to reduce the number of pins being used. Also,
there is 50ms delay between writing these bytes on LCD.
4.Portability:
Since the main requirement of GPS tracker is to be
mobile, the whole GPS tracker setup along with Raspberry
Pi is connected to a 5V DC battery.
Results
Below is a output taken from Google which shows the GPS
location of the place.
Below image indicates the GPS location measured by the
module.
Below image shows the output of the GPS module. (1)
II. DISCUSSION AND CONCLUSION
After the project completion, a GPS tracking system has been
successfully designed and implemented. The system is
reliable and has successfully received GPS signals,
processed ad transmitted the data to the LCD. At the LCD,
the data has been displayed properly. The system can be
evaluated by its accuracy and delay.
A. System accuracy

5. The accuracy of the system depends on GPS accuracy
which depends on the weather and satellites coverage.
GPS re resolution is less than 3 meters according to the
data sheet[IV].
B. System delay
With regard to system delay, it is mostly affected by the
processing capabilities of the system. Ideally, there is no
delay and the system is capable of processing serial data
real-time from the GPS.
C. System Flexibility
The system is coded to be flexible and so it can be
adjusted to display any parameter from the global data
structure.
D. System simplicity.
The system relies on the power of regular expressions to
parse the incoming data.
III. FUTURE WORK
1. Currently the implementation sends only latitude
and longitude information from client to server.
The implementation can be modified so that a
button interrupt would iterate around the entire
data structure and display Date, Time, Magnetic
variation and speed.
2. Current implementation assumes that the GPS
hardware is ideal. Hence, only the third field
3. denoting “A or V” is checked to discard the
statement. However, GPRMC provides checksum
data to ensure correctness of the statement. A
checksum checker can be implemented in the
future.
4. Only the recommended minimum statements are
parsed. Further implementation can include parsing
other statements as well.
5. The entire parser could be rewritten using sed and
awk statements with a single regular expression
used to decode entire statement.
6. Finally, this tracker can be extended into a Geo-
fencing system to track the location of an user and
send text notifications when the user enters a
region.
REFERENCES
I. Hitachi HD44780U data sheet ADE-207-272(Z)'99.9
Rev0.0
II. GlobalTop Tech Inc PMTK command packet. Rev A.11
III. GlobalTop FGPMMOPA6B GPS Module data sheet
Revision A7
IV. GlobalTop MT3339 PC Tool Operation Manual

6. The accuracy of the system depends on GPS accuracy
which depends on the weather and satellites coverage.
GPS re resolution is less than 3 meters according to the
data sheet[IV].
B. System delay
With regard to system delay, it is mostly affected by the
processing capabilities of the system. Ideally, there is no
delay and the system is capable of processing serial data
real-time from the GPS.
C. System Flexibility
The system is coded to be flexible and so it can be
adjusted to display any parameter from the global data
structure.
D. System simplicity.
The system relies on the power of regular expressions to
parse the incoming data.
III. FUTURE WORK
1. Currently the implementation sends only latitude
and longitude information from client to server.
The implementation can be modified so that a
button interrupt would iterate around the entire
data structure and display Date, Time, Magnetic
variation and speed.
2. Current implementation assumes that the GPS
hardware is ideal. Hence, only the third field
3. denoting “A or V” is checked to discard the
statement. However, GPRMC provides checksum
data to ensure correctness of the statement. A
checksum checker can be implemented in the
future.
4. Only the recommended minimum statements are
parsed. Further implementation can include parsing
other statements as well.
5. The entire parser could be rewritten using sed and
awk statements with a single regular expression
used to decode entire statement.
6. Finally, this tracker can be extended into a Geo-
fencing system to track the location of an user and
send text notifications when the user enters a
region.
REFERENCES
I. Hitachi HD44780U data sheet ADE-207-272(Z)'99.9
Rev0.0
II. GlobalTop Tech Inc PMTK command packet. Rev A.11
III. GlobalTop FGPMMOPA6B GPS Module data sheet
Revision A7
IV. GlobalTop MT3339 PC Tool Operation Manual