Introduction

This article reviews the core principles underpinning the global navigation satellite system (GNSS). It references some of the key terminology, outlines the main potential sources of error, and describes how the application of RTK DGPS techniques can mitigate these errors to a large extent. See also Glossary of GNSS Terms and Abbrevations.

The term GPS or Global Positioning System is used generically but, as of 2023, there are four global satellite navigation constellations and two regional constellations:

1. GPS - USA
2. GLONASS - Russia
3. Galileo - Europe
4. Beidou - China
5. NavIC (aka IRNSS) - India (regional)
6. QZSS - Japan (regional)

There are, in addition, a number of 'augmentation systems' which use ground-based stations to augment the data provided by GNSS satellites.

In essence, GNSS is based on the principle of trilateration*, whereby a location in 3-dimensional space can be calculated by measuring the precise distances to at least 4 other non-coplanar points in space whose positions are known (the GNSS satellites). This is easier to visualise in 2-dimensions, where 3 points are necessary to establish a position.

To establish the receiver's position, GNSS needs to determine:

1. The location of each satellite
2. The distance to each satellite

* Trilateration measures distances; triangulation measures angles. The illustration above is somewhat simplified. In the context of GNSS, the principle is more properly referred to as 'multilateration' and is based on the convergence of cones rather than spheres.

Determining the Location of each Satellite

Most (but not all) GNSS satellites fly in medium Earth orbit (MEO) at an altitude of between 19,140 km and 23,222 km. Each satellite circles the Earth twice a day. The satellites in the GPS constellation, for example, are arranged into six equally spaced orbital planes surrounding the Earth, and every plane contains four "slots" occupied by baseline satellites. This 24-slot arrangement ensures users can view at least four satellites from virtually any point on the Earth's surface.

The means to determine the current position of each satellite in a given GNSS constellation are defined in a series of four datasets:

1. Ephemerides
2. Almanac
3. Clock and Satellite Health Factors
4. Atmospheric Factors

A. Ephemerides

The ephemerides describe, for each satellite in the constellation, various orbital parameters which allow the receiver to calculate the precise coordinates of the satellite at any moment. The parameters are based on the right ascension (RA) system of coordinates and the earth-centered, earth-fixed (ECEF), World Geodetic System 1984 (WGS84) datum. The receiver will typically convert the ECEF solution to latitude ψ, longitude λ and height h (LLH) or North East Down (NED) relative to an ellipsoidal Earth model. The height may then be further converted to height relative to the geoid, which is essentially mean sea level. The ephemerides include:

• the size or 'semi-major axis' of the orbit, α
• the shape or 'eccentricity' of the orbit, e
• the plane of the orbit, or 'longitude of the ascending node', Ω
• the inclination, i
• the argument of the perigee, ω
• the 'true anomaly' ν (or sometimes θ), which describes the angular position along the orbit
• the 'vernal point' ♈︎ represents the reference direction

The ephemerides are timestamped with the Issue of Data, Ephemeris (IODE).

B. Almanac

The almanac contains information which allows the receiver to locate the satellites in the constellation. It is essentially a simplified, coarser version of the ephemerides which is valid for a longer period of time. The age of the almanac data determines how quickly a satellite can locate the requisite number of visible satellites - the 'time to first fix' (TTFF). If the data is current or recent, the receiver can perform a hot or warm start and achieve a TTFF in less than 30 seconds. If the data has expired, the receiver must perform a cold start which may take 12.5 minutes or more, for reasons described below.

The almanac is bundled with the unique identification code or 'PRN' of each satellite (see PRN below)

C. Clock and Satellite Health Factors

This contains GPS week, age of data, satellite accuracy and health, satellite clock correction coefficients timestamped with the Issue of Data, Satellite (IODS), Issue of Data, Clock (IODC), etc.

D. Atmospheric Factors

This contains data which allows the receiver to model the effects of the ionosphere on the transmitted radio signal (see Ionospheric Delay below).

The NAV Message

These four datasets are transmitted by the satellite in a series of 'frames' known collectively as the NAV message. In the case of GPS, for example, the NAV message comprises 25 frames of 1,500 bits each, = 37,500 bits or approximately 4.6 kB. Other GNSS constellations use different frame structures, but the principle is the same.

The measurement interval for these messages is referred to as the GNSS epoch.

Since the accuracy of some aspects of the information included in the NAV message deteriorates with time (at a rate of roughly 4 cm/sec), it is updated on a periodic basis (every 2 hours for ephemerides, at least every 6 days for almanac) by a series of ground stations known collectively as the Control Segment.

Note that the NAV message transmission rate is only 50 bits/sec. A full set of 25 frames can therefore take up to 12.5 (37,500 / 50 / 60) minutes to transmit, or even longer if the signal is poor or intermittent. For this reason, several 'assisted GNSS' (A-GNSS) techniques have been developed to improve the time to first fix. In essence, these aim to transmit the necessary ephemerides and almanac data to the receiver via alternate faster communications channels e.g., mobile radio or internet.

Determining the Distance to each Satellite

Since it is impractical to measure celestial distance directly, GNSS deduces distance by multiplying the time it takes for a radio signal to travel from the satellite to the receiver - the 'time of flight' (tof) - by the speed of light (approximately 300,000 km/s):

Distance = speed * (time of arrival toa - time of transmission tot)

This calculated distance is known as the 'pseudorange' (R_P). In mathematical terms:

R_P = c ΔT

where c is the speed of light and ΔT represents the time of flight.

The time of transmission and time of arrival must be measured at the same point in the radio signal waveform - the 'phase centre'. To do this, GNSS needs accurate and synchronised time references at both ends of the transmission. The satellites themselves have extremely accurate atomic clocks, but for reasons of economy and practicality the receivers generally have simpler quartz-based clocks.

To determine the travel time (and hence pseudorange) as accurately as possible, GNSS employs a number of complementary techniques based on three key observables:

1. Pseudo-Random Noise (PRN) Code
2. Carrier Phase
3. Doppler Shift

1. 'Pseudo-Random Noise' (PRN) Code

The 'pseudo-random noise' code (aka ranging code) is basically a long, non-repeating (but not strictly random - hence 'pseudo') binary waveform. Each satellite is assigned a unique PRN code and these are known to the receiver. The satellite embeds this code into the transmitted signal. By shifting or 'slewing' a replica PRN waveform generated by the receiver until it correlates with the original PRN transmitted by the satellite, the travel time or ΔT can be deduced.

Two types of PRN or ranging code are in common use:

• C/A or Coarse/Acquisition (sometimes Civilian Access) code; a 1023-chip code transmitted at 1.023 Mchips/sec. Used for mainstream GNSS applications. “chip” is a term used in digital telecommunications to denote a single pulse of data. A "symbol" is comprised of one or more chips and the symbol rate per second is referred to as the baud rate.
• P or Precision (sometimes Protected) code, a much longer 6x10¹²-chip code transmitted at 10.23 Mchips/sec (10 times faster than the C/A code). It was traditionally reserved for military use. The code is encrypted to prevent spoofing, the encrypted version being referred to as P(Y).

2. Carrier Phase

Besides the PRN ranging codes, the carrier wave phase itself can also be used to obtain a measure of the apparent distance between satellite and receiver. These carrier phase measurements are much more precise than the code measurements (by up to two orders of magnitude), but they are ambiguous by an unknown integer number of wavelengths (λN) - the so-called 'integer ambiguity' problem. This ambiguity changes arbitrarily every time the receiver loses the lock on the signal, producing jumps or range discontinuities.

Ranging code and carrier phase measurements can be characterised thus:

• Ranging code measurements are noisy but unambiguous.
• Carrier phase measurements are precise but ambiguous.

3. Doppler Shift

Since the satellites are in constant motion relative to the receiver, the apparent frequency of the signal changes due to the phenomenon of Doppler shift. The Doppler shift provides the means to enhance a number of GNSS computations, but perhaps the most important application of Doppler data is the determination of the range rate between a receiver and a satellite. Range rate is a term used to mean the rate at which the range between a satellite and a receiver changes over a particular period of time. This can in turn be used to mitigate some of the sources of error in carrier phase measurement.

The Doppler shift is primarily determined by the relative velocity of the satellite's and receiver's antennas, plus a common offset that is proportional to the receiver's clock frequency error.

GNSS Signal

The original GPS design utilised two L band carrier wave frequencies, denoted L1 and L2:

• L1 1575.42 MHz - used for C/A and P(Y) codes
• L2 1227.60 MHz - used for P(Y) codes

Subsequent GNSS constellations use a range of frequencies in the L band:

Besides redundancy and increased resistance to jamming, a critical benefit of having two frequencies transmitted from one satellite is the ability to measure directly, and therefore remove, the ionospheric delay error for that satellite (see Ionospheric Delay below).

The C/A, P(Y) and NAV data are modulated onto the sinusoidal carrier wave using a technique known as binary phase-shift keying (BPSK), the same technique as used in Wi-Fi and Bluetooth signals.

The modulated signal is received and decoded by the receiver.

Sources of Errors

1. Dilution of Precision

Ideally, the satellites used for position calculation should be widely spaced to achieve the greatest measurement precision. The effect of geometry (the relative positions of the satellites and receiver) on the distance measurement is known as 'dilution of precision' (DOP).

DOP can be expressed as a number of separate measurements:

• HDOP - horizontal dilution of precision
• VDOP - vertical dilution of precision
• PDOP - position (3D) dilution of precision
• TDOP - time dilution of precision
• GDOP - geometric dilution of precision

DOP cannot be corrected as such but can be mitigated by having the best (broadest) possible view of the sky.

The remaining sources of error are sometimes collectively referred to as User Equivalent Range Errors (UERE):

2. Clock Offsets and Relativistic Adjustments

The clocks used in the satellite and receiver are not perfectly aligned and are themselves imperfect. Such discrepancies are important when a nanosecond represents approximately 30 cm.

In addition, the rate of advance of two identical clocks, placed one in the satellite and the other on the terrestrial surface, will differ due to the difference of the gravitational potential (general relativity) and to the relative speed between them (special relativity). This difference can be split into:

1. A constant component that only depends on the nominal value of the semi-major axis of the satellite orbit, which is adjusted by modifying (in factory) the clock oscillating frequency of the satellite.
2. A periodical component due to the orbit eccentricity, that must be applied by the receiver's software.

3. Orbital Errors

The orbits of the satellites are affected by many factors including variations in gravity, drag, and tidal forces from the sun, the moon, etc.

4. Tropospheric Delay

The troposphere is the lowest layer of the Earth's atmosphere, extending from the surface to an altitude of about 18 km and containing 99% of the atmosphere's water vapour.

The effect of the troposphere on the GNSS signal appears as an extra delay in the measurement of the signal traveling from the satellite to receiver due to slight variations in the speed of light through aqueous media. This delay depends on the temperature, pressure, humidity as well as the transmitter and receiver antennae location.

5. Ionospheric Delay

The ionosphere is the atmospheric layer that extends from an altitude of 48 km to more than 960 km. It contains a partially ionised medium, as a result of the X and UV rays of solar radiation and the incidence of charged particles.

The propagation speed of the GNSS electromagnetic signal in the ionosphere depends on its electron density, denoted Total Electronic Content or TEC. This is typically heightened during the day and lessened overnight.

As the ionosphere is a dispersive media, the GNSS signal's refraction depends on its frequency (as the squared inverse). This relationship to signal frequency allows us to remove up to 99.9% of its effect by using two carrier frequencies (e.g., L1 & L2). Single frequency receivers must apply an ionospheric prediction model to remove (as much as possible) this effect, which can reach up to several tens of meters.

7. Multipath Effects

In radio communication, multipath is the propagation phenomenon that results in radio signals reaching the receiving antenna by two or more paths. Causes of multipath include atmospheric ducting, ionospheric reflection and refraction, and reflection from water bodies and terrestrial objects such as mountains and buildings. When the same signal is received over more than one path, it can create interference and phase shifting of the signal. Destructive interference causes fading; this may cause a radio signal to become too weak in certain areas to be received adequately. For this reason, this effect is also known as multipath interference or multipath distortion.

6. Receiver Noise

The receiver code noise is a white-noise-like error and can be smoothed electronically using a low pass filter. The carrier-to-noise ratio is referred to as the CNR or CNo.

This error affects both the ranging code and carrier phase measurements, but in different magnitude. The accuracy of pseudorange measurements is about 1% of the wavelength ("chip") or better. This implies a deviation of about 3 m for the C/A code and about 30 cm for the protected P(Y) code. However, when smoothing the code with the carrier phase, the deviation due to C/A code noise can be reduced to about 50 cm.

The carrier phase noise is at the level of few millimetres (about 1% of the carrier wavelength).

Code and carrier phase noise depends on the signal strength, which varies with the elevation angle.

8. Instrumentation delays - Code and Phase Bias

GNSS hardware code and phase biases occur because of imperfections and/or physical limitations in GNSS hardware. The biases are a result of small delays between events that ideally should be simultaneous in the transmission of the signal from a satellite or in the reception of the signal in a GNSS receiver. Moreover, hardware-induced biases differ between different signals, e.g., P1 and P2, and between different carrier waves, e.g., L1 and L2. Hardware-induced biases affect, for example, estimates of the precise Total Electron Content (TEC) in the ionosphere, which in turn will cause degradation in the accuracy of the positioning solution if not handled properly.

The Pseudorange Equation

The complete pseudorange calculation can be expressed as follows:

R_P = ρ + d_ρ + c(dt-dT) + d_ion + d_trop + ϵ_mp + ϵ _p

where:

• R_P = pseudorange measurement
• ρ (rho) = true range
• d_ρ = satellite orbital errors
• c = speed of light
• dt = satellite clock offset from GPS time
• dT = receiver clock offset from GPS time
• d_ion = ionospheric delay (re. TEC)
• d_trop = tropospheric delay
• ϵ_mp = multipath effects
• ϵ_p = receiver noise

Differential GPS and Real-time Kinematic Positioning

Overview

Conventional GNSS technology is capable of providing a navigation solution accurate to around 2.5 metres with clear line of sight, and perhaps 5-15 metres in urban, forested or mountainous areas. While generally acceptable for mainstream civilian use, such accuracy is inadequate for more demanding applications such as terrestrial and aerial surveying, etc. For these, centimetre-level accuracy is often required.

Positional accuracy can be dramatically improved via the use of differential GPS (DGPS) techniques. These are essentially based on calculating the difference between the position reported by a GNSS satellite receiver and the known position of a fixed terrestrial reference point (antenna reference point or ARP). Since atmospheric factors are often the most significant source of error, the fixed reference point should ideally be in relatively close proximity to the user's receiver, such that local atmospheric conditions are comparable (generally within a 30 km radius).

A number of DGPS systems and techniques are available:

• Satellite-based Augmentation Systems (SBAS). These support wide-area or regional augmentation of GNSS positioning through the use of additional satellite-broadcast messages. Using measurements from the ground stations, correction messages are created and sent to one or more satellites for broadcast to end users as differential signals. Examples include the Wide Area Augmentation System (WAAS), operated by the US Federal Aviation Administration, and the Quasi-Zenith Satellite System (QZSS), operated by Japan.
• Ground-based Augmentation Systems (GBAS). These provide DGPS corrections and integrity verification near an airport, providing precision approaches e.g. for runways that do not have Instrument Landing Systems.
• Real-time Kinematics (RTK), commonly used for GIS and surveying applications. This uses measurements of the phase of the signal's carrier wave rather than the information content of the signal and relies on a single reference station or interpolated virtual station to provide real-time corrections. It essentially endeavours to resolve the carrier wave range 'integer ambiguity' problem. The improvement possible using this technique is potentially very high. For instance, in the case of GPS, the L1 C/A code changes phase at 1.023 MHz (wavelength 293 m), but the L1 carrier itself is 1575.42 MHz (wavelength 19 cm), which changes phase over a thousand times more often. If one assumes a 1% error in phase lock, this corresponds to a ±1.9 mm error in pseudorange estimation. Two common implementations of RTK DGPS are the NTRIP protocol and the SPARTN protocol, described below.

  The detailed mathematics is beyond the scope of this article, but in essence RTK uses a technique known as carrier phase tracking, in which a series of differencing calculations based on least squares is performed:

  1. Single differencing - of the carrier wave phases measured from satellite 1 relative to that from satellite 2 at the same epoch. This approximately eliminates receiver clock errors.
  2. Double differencing - of the satellite difference observed by the fixed reference station relative to that observed by the receiver. This approximately eliminates satellite clock errors.
  3. Triple differencing - of double differencing performed at time t2 relative to that performed at time t1. This addresses the integer ambiguity problem and significantly reduces atmospheric and orbital errors.

  See Achieving cm Level Accuracy Via Real-time Kinematics for a practical illustration of the technique.

• Post-processing Kinematics (PPK). Similar in concept to RTK, but instead of applying DGPS corrections in real-time, PPK corrections are applied retrospectively to a captured raw GNSS datastream using specialised software. Some PPK software applications (e.g. RTKLIB) support a variety of correction algorithms in multiple passes and are capable of extremely high accuracy. The raw datastream is typically converted to an industry-standard Receiver Independent Exchange Format (RINEX) format before processing.

1. NTRIP

NTRIP (Networked Transport of RTCM via Internet Protocol) is a proprietary RTK DGPS protocol published by the Radio Technical Commission for Maritime Services (RTCM). NTRIP transmits correction data - typically in the form of binary RTCM messages - over the public internet using the standard Hypertext Transfer Protocol HTTP/1.1. The current version (as at January 2023) is 2.0, based on the RTCM 3.n message specification.

The NTRIP network comprises a series of fixed Continuously Operating Reference Stations or CORS (aka mountpoints), each of which transmits its own RTCM RTK data stream, typically at a rate of one message a second (1 Hz). An NTRIP server collates these data streams and provides a plain text list or sourcetable of the available mountpoints. Each sourcetable entry includes information on the name and coordinates of the station, which RTCM protocol is uses, which GNSS constellations it supports, which RTCM message types it transmits, and whether it requires the NTRIP client to report its current LLH position via an NMEA GGA message, e.g.:

['WEBBPARTNERS', 'Macclesfield', 'RTCM 3.2', '1005(5),1077(1),1087(1),1097(1),1127(1),1230(5)', '2', 'GPS+GLO+GAL+BDS', 'SNIP', 'GBR', '53.24', '-2.16', '1', '0', 'sNTRIP', 'none', 'B', 'N', '6820', '']

An NTRIP caster broadcasts the sourcetable and binary RTCM data over the public internet. NTRIP data may be unencrypted (HTTP) or encrypted (HTTPS). Some NTRIP casters are free, public domain services; others require authentication via userid and password.

An NTRIP client - which may be a software application (such as PyGPSClient), or integrated into firmware - parses the NTRIP data stream from the selected mountpoint and passes the RTCM messages to an RTK-capable GNSS receiver (e.g. u-blox ZED-F9P). The receiver's software then calculates the relevant adjustment to the reported navigation solution.

RTCM Message Types

The message types transmitted by an NTRIP RTCM3 mountpoint typically include:

• 1005 or 1006 - Reference station data, including ID, ECEF coordinates and (for 1006) antenna height.
• 1019, 1020, 1041-1046 - Ephemerides Data for each visible constellation.
• 107n, 108n, 109n, 110n, 111n, 112n and 113n - Multiple Signal Messages (MSM) representing GPS, GLONASS, Galileo, SBAS, QZSS, Beidou and NavIC respectively. These comprise:
  • A header containing GNSS epoch, IODS and clock data.
  • A repeating group of rough phase range, range rate and extended satellite information; one for each satellite nSAT.
  • A repeating group of precise phase range, range rate and CNR data; one for each signal (L1, L2, L5 etc.) nSIG per satellite (nSAT * nSIG = nCELL).
• 1230 - GLONASS Code Phase Bias data.

The pyrtcm Python library can be used to decode individual RTCM messages into their constituent datafields, e.g.:

<RTCM(1005, DF002=1005, DF003=2076, DF021=0, DF022=1, DF023=1, DF024=1, DF141=0, DF025=3822566.3113, DF142=1, DF001_1=0, DF026=-144427.5123, DF364=0, DF027=5086857.1208)>

where DF002 is the message type, DF003 represents the station ID (ARP) and DF025, DF026 and DF027 represent the station ECEF X,Y,Z coordinates - in this case equivalent to an LLH of 53.24, -2.16, 214.98 m.

2. SPARTN

SPARTN (Secure Position Augmentation for Real Time Navigation)) is an RTK DGPS protocol published by u-blox. SPARTN correction data is typically transmitted from either a geostationary L-Band satellite (Inmarsat), or an MQTT server or NTRIP caster over the public internet. The current version (as at February 2023) is 2.0.2.

While the protocol itself is in the public domain, reception of SPARTN correction data from either an NTRIP, MQTT (IP) or L-Band source normally requires a paid subscription to a proprietary SPARTN location service e.g. u-blox Thingstream PointPerfect. The data is encrypted and the access credentials and decryption keys are uploaded to the SPARTN client and GNSS receiver, either manually or via a published MQTT topic.

For SPARTN-compatible u-blox receivers, SPARTN correction data from an IP source is uploaded to the GNSS receiver via binary SPARTN messages. Data from an L-Band source is typically uploaded to the GNSS receiver embedded in a UBX RXM-PMP message. The SPARTN decryption keys are uploaded via a UBX RXM-SPARTNKEY message. The GNSS receiver can be configured to acknowledge the receipt of SPARTN data via a UBX RXM-COR message, which contains details of the current RTK correction status.

SPARTN MQTT Topics and Message Types

The following topics (message classes) are typically transmitted by a SPARTN MQTT server:

• /pp/ip/region (IP or Spartn) - raw SPARTN correction messages for the selected region.
• /pp/ubx/mga (MGA or AssistNow) - ephemera data (UBX MGA-EPH-* messages) for each GNSS constellation.
• /pp/ubx/0236/ip (SPARTNKEY or Key) - SPARTN decryption keys (UBX RXM-SPARTNKEY message).

The following SPARTN message types are provided:

• SPARTN-1X-OCB Orbit, Clock, Bias for each constellation.
• SPARTN-1X-HPAC High-precision atmosphere correction for each constellation.
• SPARTN-1X-GAD Geographic Area Definition.
• SPARTN-1X-BPAC Basic-precision atmosphere correction.
• SPARTN-1X-EAS Encryption and Authentication Support.

The pyspartn Python library can be used to parse individual SPARTN messages e.g.:

<SPARTN(SPARTN-1X-HPAC-GPS, msgType=1, nData=619, eaf=1, crcType=2, frameCrc=12, msgSubtype=0, timeTagtype=1, gnssTimeTag=419070990, solutionId=5, ..., SF061a_09_07=8257, SF061b_09_07=8259, SF055_09_08=2, SF056_09_08=1, SF060_09_08=8487, SF061a_09_08=7995, SF061b_09_08=8287)>