Nothing in this page is "new", of course.
It is a (reasonably complete, I think) compilation of information related to GPS and Arduino handling of GPS receivers.
If you are "simply" looking for direct printing out of GPS stuff on your screen, this video may help you. If you are a bit more curious, the following lines may be of interest. If, at the other end, you are an advanced programmer or have worked in details related to GPS for a while, probably nothing here will be new for you.
The starting point was that (as usual!) I simply had some practical trouble with several aspects of the GPS-Arduino thing, and it took me a bit of time to find the answers (which, once found, proved to be quite obvious!). Later I expanded it to provide a bit of depth into the reasons of why things are like they are.
The page is organized in five blocks:
- how GPS work,
- the GPS module GY-GPS6MV2 (also NEO6MV2),
- what is NMEA (meaning NMEA standard 0183),
- Arduino sketches for GPS receivers,
- Handling the GPS data.
There are several satellite positioning systems, and overall they are known as GNSS, for Global Navigation Satellite System.
GPS is American (initially named Navstar GPS), GLONASS is managed by Russia, Galileo is being developed from Europe, and China has BeiDou, also in construction.
The GPS (Global Positioning System) currently includes some 30 satellites orbiting the Earth at some 20,000 km of altitude.
The satellites are travelling at fixed orbits (not geostationary). They keep track of their position and radiate it, together with the time when the signal is sent.
At any time and any position on Earth, at least 4 GPS satellites are visible.
The GPS receiver can calculate the distance to the emitting satellites in view. From the distance to at least four satellites the position of the receiver can be calculated.
Now with some more detail.
Position of the Satellites
The precise number of satellites varies depending on the source, from 24 to 32. The minimum is 24. Additional satellites allow for increased precision, while some may be temporarily down.
The satellites travel at high orbits, which apparently are quite predictable.
They are placed in six orbital planes, with at least 4 satellites on each. These orbits are equally inclined 55º from the Equator and are separated by 60º.
The satellites complete an Earth rotation twice per day, and due to the planet's rotation they repeat the same ground track once every day.
The theoretical position of all GPS satellites at any moment is stored in the "almanac" of a satellite. The almanac is, in general, valid for some 180 d as there are unforeseen actions on the satellite that may affect their position (errors in the initial placing location, gravitational forces from moon, solar pressure, loose atmospheric friction, etc).
There are verifications of the satellites from radar ground stations. The checks include position, altitude, speed and operation, and are performed twice a day.
The deviations from the foreseen position are collected in the "ephemeris" of the satellite, which are uploaded from the ground stations into each satellite once or twice a day. (However, a reference indicates that the ephemeris is valid for about 4 hours).
With the almanac and the ephemeris, the GPS receiver can determine the precise location of the emitting satellite.
The information on the almanac also allows the receiver to search for the satellites expected to be located within its field of view.
More information on almanacs and ephemeris: here, here and here.
The satellites emit messages in the radio-micro-wave spectrum.
Two basic frequencies are used by GPS satellites: L1 at 1575.42 MHz and L2 at 1227.60 MHz, although up to five bands are studied or used. The frequencies are related to the on-board atomic frequency standard (10.23 MHz), itself related to the message coded length (see below).
The messages sent by the satellites contain three types of information:
- identification of the satellite and date+time of signal (plus other information on the health of the satellite),
- ephemeris data for the emitting satellite,
- almanac data for all the satellites in the system.
The structure of the message sent by a satellite is as follows:
- 25 frames of 1,500 bits per frame,
- each frame is divided into 5 sub-frames, each of 300 bits.
- each sub-frame is made up of 10 words, each of 30 bits.
The content is:
- the first sub-frame of each frame encodes the week, the time within the week, and data about the satellite's health,
- second and third sub-frames are used for the satellite's ephemeris,
- fourth and fifth sub-frames contain the almanac of up to 32 satellites, spread over the 4th and 5th sub-frames of the 25 frames of the message.
The navigation messages are broadcast at 50 bits/s, so the full message takes 750 s, or 12.5 min. Sub-frame #1 is therefore transmitted each 30 s.
All satellites transmit in the same frequencies, using encoding systems that allow the receivers to identify the emitting satellite.
There are two codes for the L1 and L2 carriers:
- C/A (Coarse Acquisition), for L1. It is the most common GPS signal, but also the less accurate.
- P(Y) (Precise Code), available with both L1 and L2 frequencies. Encrypted and reserved for military use.
The original low-bit rate (50 bit/s) message is encoded in a PRN (pseudo random noise) code.
The C/A PRN code has clock rate of 1.023 MHz (chip rate) and a period of exactly 1 ms (1023 chips).
The P(Y) PRN code has a clock rate of 10.23 MHz (chip rate) and a period of exactly one week (so it is a very long binary code).
The 50 bit/s data stream thus coded is then phase modulated over L1 or L2.
At the GPS receiver, the satellite message needs to be demodulated and separated from the signals sent by the other satellites with the same wave frequency.
- GPS Interface Control Document here
- Wikipedia's GPS Signals, here
Time and Distance
The calculation of the distance satellite-receiver is done measuring the time required for the signal to travel.
The travel time of the radio signal is approx. 65-70 ms. A positioning accuracy of 15 m requires to accurately measure 50 nanoseconds.
This accuracy is provided by atomic clocks, four of which are mounted on each GPS satellite. They are also monitored and controlled from the ground stations.
GPS receivers do not include atomic clocks, but just (high end) quartz crystals which by their lower accuracy have an offset to the satellite clocks (synchronized among them).
The time of transmission (TOT) of an element of the signal (the "epoch") is included in the message from the satellite. The time of arrival (TOA) of the epoch can be determined by the receiver's clock.
The time of flight (TOF) of the signal can be calculated, with the uncertainty of the offset between the satellites and the receiver's clocks.
The offset, constant for a measure, is an additional unknown to be solved.
It is sometimes stated that three satellite signals are needed to locate a receiver on the surface of the earth, an the fourth signal is required to calculate its actual elevation.
This does not seem to make much sense to me: the second geometrical solution is in the outer space, so it should be easy to grasp (point E in the following 2D sketch, which is to-scale).
The fourth satellite is required to solve for the four unknowns: the three spatial coordinates of the receiver plus the time offset.
More than four satellites over-determine the system of equations and then a best fitting method is required.
2.- GPS module GY-GPS6MV2 (also NEO6MV2)
I bought this module some time ago, likely from Alibaba, maybe this one.
Here there is a rather detailed description of a GPS module which seems to be like mine, item by item- but unfortunately I can not guarantee.
My chip is a NEO-6M-0-001 (and this probably is why I have seen the module also labeled as GY-NEO6MV2). Funnily enough, the NEO-6M is not any more in the manufacturer's list of products. Anyhow, the datasheet is here. The receiver description, including the protocol specification is here.
3.3 vs 5 V
This latter datasheet (and some webpages) warn about burning the module by connecting it to the 5 V of Arduino: it should rather be connected to 3.3 V, or to an adequate resistor connected to the VCC but also, apparently, to the communication pins between the Arduino and the GPS module.
Fact is that, at least my module, has an on board voltage regulator (KB33 MIC 5205; ) and I have worked with no problem both with 3.3 and 5 V.
U-blox provides a software named u-center, which I find quite amazing. The company's page has a detailed User Guide, and a quick glimpse can be found here.
I have connected the module to the software in my PC through my USB to UART converter (chip CP2102).
(Please, just remind: RX is connected to TX, not to RX; otherwise it, of course, won't work.)
UART is not the only possible serial communication port. As indicated in the datasheet the receiver is "truly multi-port and multi-protocol [see below on this]". It has the following ports:
Although the baud rate defined by the standard NMEA protocol (see below) is 4800 b/s, and the Arduino sketches work at 9600 bauds (see below), the UART ports can be configured up to 115200 b/s.
The module has a small battery , which is, apparently, used for the secure storage of configuration data on a EEPROM .
The battery is rechargeable, but it may be faulty. Mine, for instance has dropped from 2.9 volts yesterday night to 0.9 V this morning. Upon re-connection it quickly grows again to 3.1 V, and one hour later, off the GPS, is at 2.5 V. (Maybe there is a small leakage somewhere in the UART converter and the USB extender cable).
This may create some difficulties: drain most of the current at the starting and delaying the actual operation of the GPS, and, perhaps, losing the information in the EEPROM.
See here, for instance, in Spanish.
The schematics above shows another LED, which I d not find in my module.
The GPS antenna  should be kept with the ceramic part upwards, looking to the skies!
(I have managed to break the shielded cable at the connector. Amazingly I have managed to recompose the connection, although the cable is approx. 1/20th of my fingers).
The data received from a GPS module like NEO 6 follows the standard 0183 from NMEA (National Marine Electronics Association), which supports "one-way serial data transmission from a single talker to one or more listeners".
The standard seems to be complex enough as it covers a wide range of equipment, but, on the other side, it follows a strictly defined coding with simple ASCII text.
NMEA 0183 is copyrighted, and not easy to find (but it can be bought at the association's webpage). Latest version is 4.10 (2012), and the previous version (3.01, dated 2002) can be found here.
Sentences for Communication
There are many sources of information on NMEA 0183 standard, but I have found this one particularly useful.
The key points, as far as I understand this issue, are:
- The communication from the GPS is done in sentences. One sentence is a line of data self-contained and independent from other sentences.
- There are standard sentences for each device category. There is also the possibility to define proprietary sentences for use by an individual company.
- The standard sentences have a two letter prefix that defines the device. For GPS receivers the prefix is GP. This prefix is followed by a three letter sequence that defines the sentence contents.
- Proprietary sentences begin with the letter P and are followed with 3 letters that identifies the manufacturer controlling that sentence: a Garmin sentence would start with PGRM.
- Each sentence begins with a '$' and ends with a carriage return/line feed sequence (<CR><LF>).
- Sentences can be no longer than 80 characters of visible text (plus the line terminators).
- The data is contained within this single line. Data items are separated by commas. If data for a field is not available, the field is omitted but the delimiting commas are still sent, with no space between them
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84 ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *
- $GPGGA (fix data): 16:55:12.00 (time UTC), 39º28.19043' N (lat), 0º23.07436' W (lon), 1 (data valid, GPS Quality Indicator), 05 (satellites in view), 1.61 (HDOP, horizontal dilution of precision), 107.0 m (altitude), 50.1 m (geoidal separation), 0 (age of differential GPS data), 0 (differential reference station ID), *4 (checksum).
- $GPGSA (GNSS receiver mode): A (automatic mode), 3 (3D), 29, 21 ,… (ID numbers of satellites in solution), 2.42 (PDOP, position dilution of precision), 1.61 (HDOP, horizontal dilution of precision), 1.80 (VDOP, vertical dilution of precision), *01 (checksum).
- $GPGSV (GNSS satellites in view): 4 (total number of GSV sentences), 1 (sentence number), 14 (total number of satellites in view), 04 (satellite ID number), 61 (elevation in º), 326 (azimuth in º), 0 (SNR, signal to noise ratio), 05, 06, … (data for up to 4 satellites in view per line), *77 (checksum).
- $GPGLL (geographic position latitude, longitude): 39º28.19043' N (lat), 0º23.07436' W (lon), 16:55:12.00 (time UTC), A (data valid), A (autonomous mode), *76 (checksum).
- $GPRMC (recommended minimum specific specific GNSS data): 16:55:13.00 (time UTC), A (data valid), 39º28.19045' N (lat), 0º23.07436' W (lon), 0.304 (speed over ground), 0 (course over ground), 230417 (date, ddmmyy), 0, 0 (magnetic variation), A (autonomous mode), *6E (checksum).
- $GPVTG (course over ground and ground speed): 0, T (course over ground, º true), 0, M (course over ground, º magnetic), 0.304, N (speed over ground, knots), 0.562, K (speed over ground, km/h), A (autonomous mode), *25 (checksum).
A side note on this: many of the sketches and libraries that I have seen use pins 3 and 4 for serial communication with the GPS module. However, not all Arduino boards allow those pins to be used for that purpose: check SoftwareSerial and avoid silly headaches on why the dammed GPS is not working with your Mega or Pro.
Some pages mention that Ublox modules may have timing issues with SoftwareSerial, and they recommend to use the hardware UARTS on the Arduino for communication with the GPS. I have not gone beyond this.
Of course SoftwareSerial avoids these problems.
GPS_bas_00 is quite simple, but is it possible to make it even simpler?
5.- Handling GPS Data