Precise Point Positioning (PPP) HOWTO

This document assumes you are using gpsd versions 3.24 or git head. Using older versions will fail in strange ways.

This document is a guide getting high accuracy static positions from your GPS using Precise Point Positioning [PPP]. The rare few that have a GPS that output raw measurement data for L1 and L2 can achieve absolute accuracy of around 3 cm. The u-blox ZED-F9P and ZED-F9T can be better than 1 cm. The lucky owners of an L1 GPS that outputs raw measurements can get about 0.5 m. The majority will only be able to get somewhat better than 1.5 m using simple averaging.

Patience is required. For best results 6 to 24 hours of data is required. Post processing time may double that.

This document is not about getting high precision dynamic positions from your GPS. This is about after the fact Post Processed Positions (PPP). High precision real time dynamic positions requires Real Time Kinematic (RTK) which will not be discussed here. RTK users may still want to read this document. The RTK Best practice is to determine the position of the base using PPP before sending the RTK data from the base to its rovers.

To compute a location fix a GNSS receiver takes measurements (raw data) of the relative time of arrival of signals broadcast from the GNSS satellites. The receiver also knows the predicted orbit (ephemeris) of each satellite. The collection of ephemeris from all the satellites is known as the ephemerides. With these two sets of data, the CPU in the receiver can compute a fix in position in time and space using iterative techniques.

A major problem is that the predicted orbits are often off by one meter or more. Ground stations bounce lasers off the individual satellites as they pass overhead and use this new data to compute the actual orbits of the satellites. Using this new ephemeris data, when it becomes available, combined with the receiver’s raw data, better fixes can be computed. This is the basis of PPP.

There are other smaller error sources that PPP can reduce. The effects of ocean tides on the Earth’s crust, Clock drift of the satellite clocks. Troposphere and Ionosphere effects, and more.

The first take on the actual epherides may take 90 minutes to be published. The ephemerides may be further refined for up to three weeks.

There are two flavors of PPP: static, and kinematic. Kinematic PPP simply takes an existing time series of measurements and computes a new time series of fixes using the actual orbits, instead of the predicted orbits. Static PPP assumes all the raw measurements were taken at the same location over a long duration. Long is typically 15 minutes to 48 hours. All the computed fixes are then averaged to result in one precise location for the receiver’s antenna.

Now in 2020, most PPP services only use ephermides from GPS satellites, with more and more adding GLONASS. As time passes, more constellations will be used, leading to slightly increased accuracy.

The earth revolves around its axis every 24 hours, give or take a few milli seconds. GPS satellites revolve around the Earth’s axis about every 12 hours, give or take. PPP will provide best results if your data is 12, 24 or 36 hours. This allows some orbital errors to average out.

This document assumes that you have installed gpsd version 3.22 or later, basic knowledge of how to use gpsd. Before continuing you should know how to start and stop gpsd, and how to use cgps to see you current position and fix status.

This document also assumes that you have a GNSS receiver connected to a local GPSD demon and that cgps shows a stable 3D fix. This will allow Simple Averaging. You will also need Python and gnuplot installed. The Python and gnuplot do not need to be installed on the host that is connected to the GPS, they are merely needed for post processing.

For basic PPP (0.5 m) you will need a GPS that outputs L1 raw measurement data that gpsd understands. Currently that limits you to a Javad GPS that support the GREIS language, or a u-blox GPS that support the UBX-RXM-RAWX messages.

u-blox GPS known to support UBX-RXM-RAWX are: -M8T,-M8F, ZED-F9P and ZED-F9T.

For advanced PPP (3 cm) you will need a GPS that outputs L1 and L2 raw measurement data that gpsd understands. Currently that limits you to a Javad GPS that support the GREIS language or the u-blox 9 series.

Finally, patience is required.

The end goal of this process is to determine the latitude, longitude and altitude of your GPS antenna as precisely as possible. Additionally the Circular Error of Probability (CEP) will be determined.

CEP, also known as the CEP(50), is the radius of a circle, centered on the mean, whose boundary includes 50% of the GPS positions. You probably do not want to base any navigation or surveying on a 50% probability.

More interesting is the CEP(95) which includes 95% of the measurements.

Ever noticed how two "accurate" GPS placed side by side can give wildly different latitude, longitude, and especially altitude for the same spot?

All GNSS systems compute positions using ECEF (earth-centered, earth-fixed) coordinates. After an ECEF position is calculated, it is converted into latitude and longitude using various [DATUMS]. So many to choose from. You’ve probably heard of WGS84, NAD83, and maybe ITRF.

NAD83 is pinned to the North American tectonic plate. WGS84 is pinned to the Reference Meridian (near the Greenwich Meridian). NAD83 is the official datum in the USA and Canada, and is used by the FAA. WGS84 is the official datum of GPS and the US Department of Defense.

In 1987 the difference between NAD83 and WGS84 was not measurable. Since then the tectonic plates have moved. In 2018 the two datums can differ by more than 2 meters in the continental USA.

It is common when using NAD83 to also specify the year (epoch) of the measurements. This allows archival, and current, data to be used to similar accuracy.

It gets worse. Most PPP services support the International Terrestrial Reference Frame (ITRF). ITRF is pinned to a Celestial Reference Plane (CRF).

It gets worse. There is not one WGS84, but many: WGS 1984 (ORIG), WGS84(G730), WGS84(G873), WGS84(G1150), WKID: 4326, and more. There is not one ITRF but many: ITRF91/92, ITRF94/96, ITRF00, ITRF08 and more.

Original ITRF and WGS84 differ by less than 1 meter, which is huge for the purposes here. ITRF2014 and WGS84(G1762) differ by a few centimeters.

It gets worse. Two expensive GPS often differ in altitude by over 60 feet. The Earth is not a perfect sphere. It is more pear shaped. GPS approximate this with an ellipsoid, usually some version WGS84. Then altitude is calculated as height above the ellipsoid (HAE).

Most people do not consider the altitude as the height above the ellipsoid, but as the height above Mean Sea Level. MSL is the same as pressure altitude (when corrected for temperature and barometric pressure), but different from HAE.

Mean Sea Level has had nothing to with the level of the sea, it relates to some stakes driven into the ground 100 hundred years ago that seemed at the time to be roughly mean sea level at that point.

Pressure altitude is not some sort of absolute geometric altitude, it is related to the gravity under the position being measured. So local gravity affects local MSL, but not local HAE. If the measured position is over a high density rock, like iron ore, then the gravity is higher, and the pressure is increased over the simple HAE. Conversely ocean water is less dense and has the opposite effect. This is very noticeable in the Hawaiian Islands.

Fun fact: gravity is at its maximum at 'sea level'.

Many different datums can be used to calculate height [VERTICAL]). These datums are based on different ellipsoids used to approximate sea level. The two used by CSRS-PPP are CGVD2013 and CGDV28(HT2_0). GCVD2013 is the standard datum in Canada since 2013. The standard in the USA is the North American Vertical Datum of 1988 (NAVD 88). Many GPS use the WGS84 Ellipsoid as the vertical datum. The WGS84 Ellipsoid is from the same organization as the WGS84 coordinate system, but not part of WGS84.

More refined datums, like the World Gravity Model, WGM2012, also take into account more gravitation effects.

Clearly there is no point knowing your precise position to a few cm if you are not certain of your datum and vertical datum (ellipsoid), with epoch. This will be important later as you are asked to input your choice of horizontal and vertical datums to your PPP service.

The first technique covered, Simple Averaging, works with any GPS that is supported by gpsd. For best results a minimum of 6 hours, and preferably 24 hours, of continuous observations are required.

gpsprof will be used to gather 24 hours of position data and then output a plot file. The plot file is fed into gnuplot to turn it into a png image file. The image will contain a scatter plot of all the positions reported by your GPS, as well as summary statistics. The statistics include the mean latitude, mean longitude, mean altitude and other computed values.

The procedure is simple:

There are many possible adjustments to the above procedure.

Maybe you want to collect just 10 minutes of data (20 epochs at 30 second interval) to verify that your tool-chain is working before doing a 24 hour run. Simple, just change gpsprof -n 2880 to gpsprof -n 20 and then proceed as above.

Maybe your gpsd host does not have Python installed. Just run gpsprof remotely. On the host you will need to run gpsd with the -g parameter so that it can be accessed over the network. Then run gpsprof on a remote host that supports Python this way: gpsprof -n 2880 -T pngcairo [hostname] > scatter.plot

Depending on your GPS, your GPS antenna, and your sky view, you may get a CEP(95) of around 1.5 m.

Plain GPS determine their position by measuring the distance to several GPS satellites and calculating a position solution. The main limitation is that the position of any GPS satellite is not known to better than a meter or two in real time.

PPP uses the raw GPS measurements from a worldwide network of precisely fixed ground receivers to precisely calculate the actual orbits of all the satellites. "Ultra Rapid" orbits take about 90 minutes to be available. "Rapid" orbits take a day. The most accurate orbits ("Final") take around 14 days to determine.

To use these orbits you need to collect the raw measurements from your GPS, then upload them to a service to compute a more precise fix. Receiver Independent Exchange Format (RINEX) files are the standard for sending your raw measurement data. gpsd uses RINEX Version 3 [RINEX3].

Most PPP services have many limitations making them unsuitable for our purposes. Some limitations include: open only to paid subscribers, require L1 and L2 raw data, and/or use proprietary data formats.

There is one online service that is free to all (requires registration), accepts L1 only raw data, and accepts RINEX 3 files: Natural Resources Canada (NRCAN). Their tool is at https://webapp.geod.nrcan.gc.ca/geod/tools-outils/ppp.php

Trimble has a free to all (requires registration) service that requires L1 and L2 observations in RINEX 3. Their tool is at: https://trimblertx.com/Home.aspx

Before you can collect raw data from you GPS, you must configure it to output raw data. This configuration will not be the default configuration that gpsd applies to your GPS by default.

The raw data can be quite large, so be sure your GPS serial port speed is set to 57,600, or higher.

Many of the configuration steps are order dependent. If in doubt, start over from the beginning. Be sure that gpsd is running and that cgps shows that you have a stable 3D fix.

Configuration complete. Collect 24 hours of samples at 30 second intervals, save the raw data as RINEX 3 format in the file today.obs. Collecting data at a rate faster than 30 second intervals may degrade your results. Trimble will average data to 10 second intervals if the data rate is faster than 10 seconds. Start the long process:

Now is a good time to go the NRCAN’s CSRS-PPP page and sign up for a free account. You need this account to be able to upload the RINEX 3 file today.obs to their free PPP service for processing. https://webapp.geod.nrcan.gc.ca/geod/tools-outils/ppp.php

Take a break. You now have 24 hours to contemplate the answer to the ultimate question of life, the universe, and everything.

More waiting. Before you can post process your data, the PPP service must be ready for it. Depending on the service it can take from 10 to 60 minutes before you can upload your new data. For best results you should wait 2 weeks.

The following two services are known to work with gpsrinex. CSRS-PPP will accept L1 only data, trimble RTX requires L1 and L2 data. Try both, with the same data set, if you can. That will show you that their sigma’s are "optimistic".