PVT

The PVT block is the last one in the GNSS-SDR flow graph. Hence, it acts as a signal sink, since the stream of data flowing along the receiver ends here.

The role of a PVT block is to compute navigation solutions and deliver information in adequate formats for further processing or data representation.

It follows a description of the available positioning algorithms and their parameters, the available output formats and the description of the configuration options for this block.

Positioning modes

The positioning problem is generally stated as

where is the measurement vector (that is, the observables obtained from the GNSS signals of a set of satellites), is the state vector to be estimated (at least, the position of the receiver’s antenna and the time), is the function that relates states with measurements, and models measurement noise. Depending on the models, assumptions, available measurements and the availability of a priori or externally-provided information, many positioning strategies and algorithms can be devised. It follows a description of the positioning modes available at the RTKLIB_PVT implementation, mostly extracted from the excellent RTKLIB manual.

Single Point Positioning

The default positiong mode is PVT.positioning_mode=Single. In this mode, the vector of unknown states is defined as:

where is the receiver’s antenna position in an earth-centered, earth-fixed (ECEF) coordinate system (in meters), is the speed of light and is the receiver clock bias (in seconds).

The measurement vector is defined as:

As described in the Observables block, for a signal from satellite in the i-th band, the pseudorange measurement can be expressed as:

In the current implementation, if the receiver obtains pseudorange measurements from the same satellite in different frequency bands, only measurements in the L1 band are used.

Hence, the equation that relates pseudorange measurements to the vector of unknown states can be written as:

The geometric range is defined as the physical distance between the satellite antenna phase center position and the receiver antenna phase center position in the inertial coordinates. For the expression in the ECEF coordinates, the earth rotation effect has to be incorporated. This is known as the Sagnac effect1, and it can be approximated by:

where is the Earth rotation angle velocity (in rad/s).

Earth rotation correction Geometric range and Earth rotation correction 2

Equation is clearly nonlinear due to the presence of the Euclidean norm operator . However, this term can be extended by using Taylor series around an initial parameter vector as , where is a partial derivatives matrix of with respect to at . Assuming that the initial parameters are adequately near the true values and the second and further terms of the Taylor series can be neglected, equation can be approximated by , and then we can obtain the following linear equation:

which can be solved by a standard iterative weighted least squares method.

Matrix can be written as:

and the weighted least squares estimator (LSE) of the unknown state vector is obtained as:

Navigation Solution for Single Point Positioning: Iterative weighted least squares estimator

For the initial parameter vector for the iterated weighted LSE, just all are used for the first epoch of the single point positioning. Once a solution obtained, the position is used for the next epoch initial receiver position. For the weight matrix , the RTKLIB_PVT implementation uses:

where:

  • is the satellite system error factor. This parameter is set to for GPS and Galileo.

  • is the code/carrier‐phase error ratio. This value is set by default to , and can be configured with the PVT.code_phase_error_ratio_l1 option.

  • is the carrier‐phase error factor and (in m). They are set by default to m, and can be configured with the PVT.carrier_phase_error_factor_a and PVT.carrier_phase_error_factor_b options, respectively.

  • is the elevation angle of satellite direction (in rad).

  • is the standard deviation of the broadcast clock error (in m).

  • is the standard deviation of ionosphere correction model error (in m). This parameter is set to m by default (PVT.iono_model=OFF) and m when the option PVT.iono_model=Broadcast is set in the configuration file.

  • is the standard deviation of troposphere correction model error (in m). This parameter is set to m by default (PVT.trop_model=OFF) and m when the option PVT.trop_model=Saastamoinen, PVT.trop_model=Estimate_ZTD or PVT.trop_model=Estimate_ZTD_Grad is set in the configuration file.

  • is the standard deviation of code bias error (in m). This parameter is set to m.

The estimated receiver clock bias is not explicitly output, but incorporated in the solution time‐tag. That means the solution time‐tag indicates not the receiver time‐tag but the true signal reception time measured in GPS Time.

Solution validation

The estimated receiver positions described in () might include invalid solutions due to unmodeled measurement errors. To test whether the solution is valid or not, and to reject the invalid solutions, the RTKLIB_PVT applies the following validation tests after obtaining the receiver’s position estimate:

1) Residuals Test

Defining the residuals vector with:

the residuals test is defined as:

where is the number of estimated parameters, is the number of measurements, is the chi‐square distribution of degree of freedom and with a significance level of (that is, ).

2) GDOP Test

The Geometric Dilution of Precision, defined as , must be better (that is, lower) than a certain threshold:

The threshold value is set by default to , and it can be configured via the option PVT.threshold_reject_GDOP in the configuration file.

If any of the validation fails, the solution is rejected as an outlier (that is, no solution is provided).

Receiver Autonomous Integrity Monitoring (RAIM)

In addition to the solution validation described above, RAIM (receiver autonomous integrity monitoring) FDE (fault detection and exclusion) function can be activated. If the chi-squared test described above fails and the option PVT.raim_fde is set to , the implementation retries the estimation by excluding one by one of the visible satellites. After all of retries, the estimated receiver position with the minimum normalized squared residuals is selected as the final solution. In such scheme, an invalid measurement, which might be due to satellite malfunction, receiver fault or large multipath, is excluded as an outlier. Note that this feature is not effective with two or more invalid measurements. It also needs two redundant visible satellites, that means at least 6 visible satellites are necessary to obtain the final solution.

Precise Point Positioning

When the PVT.positioning_mode option is set to PPP_Static or PPP_Kinematic in the configuration file, a Precise Point Positioning algorithm is used to solve the positioning problem. In this positioning mode, the state vector to be estimated is defined as:

where is ZTD (zenith total delay), and are the north and east components of tropospheric gradients (see the tropospheric model below) and is the ionosphere‐free linear combination of zero‐differenced carrier‐phase biases (in m), defined below in Equation ().

The Precise Point Positioning measurement model is based on the fact that, according to the phase and code ionospheric refraction, the first order ionospheric effects on code and carrier-phase measurements depend (99.9 %) on the inverse of squared signal frequency . Thence, dual-frequency receivers can eliminate their effect through a linear combination of pseudorange and phase-range measurements (where the definitions at Observables apply):

with and , where and are the frequencies (in Hz) of and measurements. Explicitly:

with

In the current implementation, satellites and receiver antennas offset and variation are not applied, so and . The correction terms for the Earth tide3 and the phase windup effect4 are deactivated by default, and can be activated through the PVT.earth_tide and PVT.phwindup options, respectively.

The measurement vector is then defined as:

where and .

In the current implementation, if the receiver obtains pseudorange measurements from the same satellite in different frequency bands, only measurements in the L1 band are used.

The equation that relates measurements and states is:

where:

This is again a nonlinear equation that could be solved with the iterative weighted least squares estimator as in the case of the Single Point Positing case. However, here we want to incorporate some a priori information, such as a basic dynamic model for the receiver, and some statistical knowledge about the status of the troposphere. The Extended Kalman Filter offers a suitable framework for that.

The partial derivatives matrix can be written as:

where is known as the single‐differencing matrix, with defined as above, and

is a matrix related to the tropospheric model (see below).

With all those definitions, the Precise Point Positioning solution is computed as follows:

Navigation Solution for Precise Point Positioning: Extended Kalman Filter

  • Time update (prediction):
  • Measurement update (estimation):

The transition matrix models the receiver movement:

  • If PVT.positioning_mode=PPP_Static:
  • If PVT.positioning_mode=PPP_Kinematic:

where is the time between GNSS measurements, in s.

The dynamics model noise covariance matrix is set to:

with:

  • , where is the coordinates rotation matrix from ECEF to local coordinates at the receiver antenna position (defined below), and , and are the standard deviations of east, north and up components of the receiver position model noises (in m).
    • If the positioning mode is set to PVT.positioning_mode=PPP_Static, these values are initialized to m in the first epoch and then set to in the following time updates.
    • If the positioning mode is set to PVT.positioning_mode=PPP_Kinematic, these values are set to m for all time updates.
  • , where , and are the standard deviations of east, north and up components of the receiver velocity model noises (in m/s/). In the current implementation, those parameters are set to .
  • is the standard deviation of the receiver clock offset (in m). This value is set to m.
  • is the noise covariance matrix of the troposphere terms. These values are set to , and are initialized to m/ in the first epoch and then set to in the following time updates. The default value of m/ can be configured with the PVT.sigma_trop option.
  • is the standard deviation of the ionosphere-free carrier-phase bias measurements, in m/. This value is initialized at the first epoch and after a cycle slip to m/, and then is set to a default value of m/ in the following time updates. This value and can be configured with the option PVT.sigma_bias.
  • is the rotation matrix of the ECEF coordinates to the local coordinates, where where and are the geodetic latitude and the longitude of the receiver position.

The measurement model noise covariance matrix is defined as:

where:

where is the standard deviation of L1 phase‐range measurement error (in m), and is the standard deviation of L1 pseudorange measurement error (in m). These quantities are estimated as:

  • , where:
    • and are the carrier phase error factors (configurable via PVT.carrier_phase_error_factor_a and PVT.carrier_phase_error_factor_b),
    • is the standard deviation of ionosphere correction model error (in m). This parameter is set to m by default (PVT.iono_model=OFF) and m when the option PVT.iono_model=Broadcast is set in the configuration file.
    • m is the standard deviation of the broadcast clock,
    • is the standard deviation of the troposphere correction model error (in m). This parameter is set to m when PVT.trop_model=OFF and m when PVT.trop_model=Saastamoinen, PVT.trop_model=Estimate_ZTD or PVT.trop_model=Estimate_ZTD_Grad.
  • , where:
    • (configurable via PVT.code_phase_error_ratio_l1),
    • m (configurable via PVT.carrier_phase_error_factor_a and PVT.carrier_phase_error_factor_b),
    • , and defined as above.
    • is the standard deviation of code bias error (in m). This parameter is set to m.

Outlier rejection

In each of the executions of the Extended Kalman Filter defined in ()-(), if the absolute value of a residual for a satellite is above a certain threshold, that observation is rejected as an outlier. The default threshold is set to m and can be configured via the option PVT.threshold_reject_innovation.

Ionosphere Model

The ionosphere is a region of Earth’s upper atmosphere, from about 60 km to 1,000 km altitude, surrounding the planet with a shell of electrons and electrically charged atoms and molecules. This part of the atmosphere is ionized by ultraviolet, X-ray and shorter wavelengths of solar radiation, and this affects GNSS signals’ propagation speed.

The propagation speed of the GNSS electromagnetic signals through the ionosphere depends on its electron density, which is typically driven by two main processes: during the day, sun radiation causes ionization of neutral atoms producing free electrons and ions. During the night, the recombination process prevails, where free electrons are recombined with ions to produce neutral particles, which leads to a reduction in the electron density.

The frequency dependence of the ionospheric effect (in m) is described by the following expression:

where STEC is the Slant Total Electron Content, which describes the number of free electrons present within one square meter between the receiver and satellite . It is often reported in multiples of the so-called TEC unit, defined as el/m. Ionospheric effects on the phase and code measurements have the opposite signs and have approximately the same amount. It causes a positive delay on code measurements (so it is included with a positive sign in the pseudorange measurement model) and a negative delay, or phase advance, in phase measurements (so it is included with a negative sign in the phase-range measurement model).

This dispersive nature (i.e., the ionospheric delay is proportional to the squared inverse of ) allows users to remove its effect up to more than 99.9% using two frequency measurements (as in the see ionosphere-free combination for dual frequency receivers shown in the Precise Point Positioning algorithm described above), but single frequency receivers have to apply an ionospheric prediction model to remove (as much as possible) this effect, that can reach up to several tens of meters.

Broadcast

For ionosphere correction for single frequency GNSS users, GPS navigation data include the following broadcast ionospheric parameters:

By using these ionospheric parameters, the L1 ionospheric delay (in m) can be derived the following procedure5. The model is often called as the Klobuchar model6.

This correction is activated when PVT.iono_model is set to Broadcast.

Troposphere Model

The troposphere is the lowest portion of Earth’s atmosphere, and contains 99% of the total mass of water vapor. The average depths of the troposphere are 20 km in the tropics, 17 km in the mid latitudes, and 7 km in the polar regions in winter. The chemical composition of the troposphere is essentially uniform, with the notable exception of water vapor, which can vary widely. The effect of the troposphere on the GNSS signals appears as an extra delay in the measurement of the signal traveling time from the satellite to the receiver. This delay depends on the temperature, pressure, humidity as well as the transmitter and receiver antennas location, and it is related to air refractivity, which in turn can be divided in hydrostatic, i.e., dry gases (mainly and ), and wet, i.e., water vapour, components:

  • Hydrostatic component delay: Its effect varies with local temperature and atmospheric pressure in quite a predictable manner, besides its variation is less that the 1% in a few hours. The error caused by this component is about meters in the zenith direction and meters for lower elevations ( approximately).

  • Wet component delay: It is caused by the water vapour and condensed water in form of clouds and, thence, it depends on weather conditions. The excess delay is small in this case, only some tens of centimetres, but this component varies faster than the hydrostatic component and in a quite randomly way, being very difficult to model.

The troposphere is a non dispersive media with respect to electromagnetic waves up to 15 GHz, so the tropospheric effects are not frequency dependent for the GNSS signals. Thence, the carrier phase and code measurements are affected by the same delay, and this effect can not be removed by combinations of dual frequency measurements.

Saastamoinen

The standard atmosphere can be expressed as:7

where is the total pressure (in hPa), is the absolute temperature (in K) of the air, is the geodetic height above MSL (mean sea level), is the partial pressure (in hPa) of water vapor and is the relative humidity. The tropospheric delay (in m) is expressed by the Saastamoinen model with , and derived from the standard atmosphere:

where is the zenith angle (rad) as , where is elevation angle of satellite direction (rad).

The standard atmosphere and the Saastamoinen model are applied in case that the processing option PVT.trop_model is set to Saastamoinen, where the geodetic height is approximated by the ellipsoidal height and the relative humidity is fixed to 70 %.

Estimate the tropospheric zenith total delay

If the processing option PVT.trop_model is set to Estimate_ZTD, a more precise troposphere model is applied with strict mapping functions as:

where is the tropospheric zenith total delay (m), is the tropospheric zenith hydro‐static delay (m), is the hydro‐static mapping function and is the wet mapping function. The tropospheric zenith hydro‐static delay is given by Saastamoinen model described above with the zenith angle and relative humidity . For the mapping function, the software employs the Niell mapping function8. The zenith total delay is estimated as a unknown parameter in the parameter estimation process.

Estimate the tropospheric zenith total delay and gradient

If the processing option trop_model is set to Estimate_ZTD_Grad, a more precise troposphere model is applied with strict mapping functions as9:

where is the azimuth angle of satellite direction (rad), and and are the east and north components of the tropospheric gradient, respectively. The zenith total delay and the gradient parameters and are estimated as unknown parameters in the parameter estimation process.

Output formats

Depending on the specific application or service that is exploiting the information provided by GNSS-SDR, different internal data will be required, and thus the receiver needs to provide such data in an adequate, standard formats:

  • For Geographic Information Systems, map representation and Earth browsers: KML and GeoJSON files are generated by default, upon the computation of the first position fix.
  • For sensor integration: NMEA-0183. A text file containing NMEA messages is stored with a default name of gnss_sdr_pvt.nmea, configurable via PVT.nmea_dump_filename. In addition, NMEA messages can be forwarded to a serial port by setting PVT.flag_nmea_tty_port=true. The default port is /dev/tty1, and can be configured via PVT.nmea_dump_devname.
  • For post-processing applications: RINEX 2.11 and 3.02. Version 3.02 is generated by default, and version 2.11 can be requested by setting PVT.rinex_version=2 in the configuration file.
  • For real-time, possibly networked processing: RTCM-104 messages, v3.2. A TCP/IP server of RTCM messages can be enabled by setting PVT.flag_rtcm_server=true in the configuration file, and will be active during the execution of the software receiver. By default, the server will operate on port 2101 (which is the recommended port for RTCM services according to the Internet Assigned Numbers Authority, IANA), and will identify the Reference Station with ID= . These values can be changed with PVT.rtcm_tcp_port and PVT.rtcm_station_id. The rate of the generated RTCM messages can be tuned with the options PVT.rtcm_MT1045_rate_ms (it defaults to ms), PVT.rtcm_MT1019_rate_ms (it defaults to ms), PVT.rtcm_MSM_rate_ms (it defaults to ms). The RTCM messages can also be forwarded to the serial port PVT.rtcm_dump_devname (it defaults to /dev/pts/1) by setting PVT.flag_rtcm_tty_port=true in the configuration file.

Important: In order to get well-formatted GeoJSON, KML and RINEX files, always terminate gnss-sdr execution by pressing key ‘q’ and then key ‘ENTER’. Those files will be automatically deleted if no position fix have been obtained during the execution of the software receiver.

Read more about standard output formats at our Interoperability page.

Implementation: RTKLIB_PVT

IMPORTANT: This implementation is only available from the next branch of GNSS-SDR source code, so it is not present in the current stable release.

This implementation makes use of the positioning libraries of RTKLIB, a well-known open source program package for standard and precise positioning. It accepts the following parameters:

Global Parameter Description Required
GNSS-SDR.SUPL_gps_ephemeris_xml Name of an XML file containing GPS ephemeris data. It defaults to ./gps_ephemeris.xml Optional
Parameter Description Required
implementation RTKLIB_PVT Mandatory
output_rate_ms Rate at which PVT solutions will be computed, in ms. It defaults to 500 ms. Optional
display_rate_ms Rate at which PVT solutions will be displayed in the terminal, in ms. It defaults to 500 ms. Optional
positioning_mode [Single, PPP_Static, PPP_Kinematic] Set positioning mode. Single: Single point positioning. PPP_Static: Precise Point Positioning with static mode. PPP_Kinematic: Precise Point Positioning for a moving receiver. It defaults to Single. Optional
num_bands [1: L1 Single frequency, 2: L1 and L2 Dual‐frequency, 3: L1, L2 and L5 Triple‐frequency] This option is automatically configured according to the Channels configuration. This option can be useful to force some configuration (e.g., single-band solution in a dual frequency receiver). Optional
elevation_mask Set the elevation mask angle, in degrees. It defaults to . Optional
dynamics_model [0: Off, 1: On] Set the dynamics model of the receiver. If set to and PVT.positioning_mode=PPP_Kinematic, the receiver position is predicted with the estimated velocity and acceleration. It defaults to (no dynamics model).   Optional
iono_model [OFF, Broadcast, Iono-Free-LC]. Set ionospheric correction options. OFF: Not apply ionospheric correction. Broadcast: Apply broadcast ionospheric model. Iono‐Free-LC: Ionosphere‐free linear combination with dual frequency (L1‐L2 for GPS or L1‐L5 for Galileo) measurements is used for ionospheric correction. It defaults to OFF (no ionospheric correction) Optional
trop_model [OFF, Saastamoinen, Estimate_ZTD, Estimate_ZTD_Grad]. Set whether tropospheric parameters (zenith total delay at rover and base‐station positions) are estimated or not. OFF: Not apply troposphere correction. Saastamoinen: Apply Saastamoinen model. Estimate_ZTD: Estimate ZTD (zenith total delay) parameters as EKF states. Estimate_ZTD_Grad: Estimate ZTD and horizontal gradient parameters as EKF states. If defaults to OFF (no troposphere correction). Optional
code_phase_error_ratio_l1 Code/phase error ratio for the L1 band. It defaults to . Optional
carrier_phase_error_factor_a Carier phase error factor . It defaults to m. Optional
carrier_phase_error_factor_b Carier phase error factor . It defaults to m. Optional
slip_threshold Set the cycle‐slip threshold (m) of geometry‐free LC carrier‐phase difference between epochs. It defaults to . Optional
threshold_reject_GDOP Set the reject threshold of GDOP. If the GDOP is over the value, the observable is excluded for the estimation process as an outlier. It defaults to . Optional
threshold_reject_innovation Set the reject threshold of innovation (pre‐fit residual) (m). If the innovation is over the value, the observable is excluded for the estimation process as an outlier. It defaults to m. Optional
number_filter_iter Set the number of iteration in the measurement update of the estimation filter. If the baseline length is very short like 1 m, the iteration may be effective to handle the nonlinearity of measurement equation. It defaults to 1. Optional
sigma_bias Set the process noise standard deviation of carrier‐phase bias , in cycles/. It defaults to cycles/. Optional
sigma_trop Set the process noise standard deviation of zenith tropospheric delay , in m/. It defaults to m/. Optional
raim_fde [0, 1]: Set whether RAIM (receiver autonomous integrity monitoring) FDE (fault detection and exclusion) feature is enabled or not. It defaults to (RAIM not enabled) Optional
reject_GPS_IIA [0, 1]: Set whether the GPS Block IIA satellites are excluded or not. Those satellites often degrade the PPP solutions due to unpredicted behavior of yaw‐attitude. It defaults to (no rejection). Optional
phwindup [0, 1]: Set whether the phase windup correction for PPP modes is applied or not. It defaults to (no phase windup correction). Optional
earth_tide [0, 1]: Set whether earth tides correction is applied or not. If set to , the solid earth tides correction is applied to the PPP solution, following the description in IERS Technical Note No. 323, Chapter 7. It defaults to (no Earth tide correction). Optional
rinex_version [2: version 2.11, 3: version 3.02] Version of the generated RINEX files. It defaults to 3. Optional
nmea_dump_filename Name of the file containing the generated NMEA sentences in ASCII format. It defaults to ./nmea_pvt.nmea. Optional
flag_nmea_tty_port [true, false]: If set to true, the NMEA sentences are also sent to a serial port device. It defaults to false. Optional
nmea_dump_devname If flag_nmea_tty_port is set to true, descriptor of the serial port device. It defaults to /dev/tty1. Optional
flag_rtcm_server [true, false]: If set to true, it runs up a TCP server that is serving RTCM messages to the connected clients during the execution of the software receiver. It defaults to false. Optional
rtcm_tcp_port If flag_rtcm_server is set to true, TCP port from which the RTCM messages will be served. It defaults to 2101. Optional
rtcm_station_id Station ID reported in the generated RTCM messages. It defaults to 1234. Optional
rtcm_MT1045_rate_ms Rate at which RTCM Message Type 1045 (Galileo Ephemeris data) will be generated, in ms. If set to 0, mutes this message. It defaults to 5000 ms. Optional
rtcm_MT1019_rate_ms Rate at which RTCM Message Type 1019 (GPS Ephemeris data) will be generated, in ms. If set to 0, mutes this message. It defaults to 5000 ms. Optional
rtcm_MSM_rate_ms Default rate at which RTCM Multiple Signal Messages will be generated. It defaults to 1000 ms. Optional
rtcm_MT1077_rate_ms Rate at which RTCM Multiple Signal Messages GPS MSM7 (MT1077 - Full GPS observations) will be generated, in ms. If set to 0, mutes this message. It defaults to rtcm_MSM_rate_ms. Optional
rtcm_MT1097_rate_ms Rate at which RTCM Multiple Signal Messages Galileo MSM7 (MT1097 - Full Galileo observations) will be generated, in ms. If set to 0, mutes this message. It defaults to rtcm_MSM_rate_ms. Optional
flag_rtcm_tty_port [true, false]: If set to true, the generated RTCM messages are also sent to a serial port device. It defaults to false. Optional
rtcm_dump_devname If flag_rtcm_tty_port is set to true, descriptor of the serial port device. . It defaults to /dev/pts/1. Optional
dump [true, false]: If set to true, it enables the PVT internal binary data file logging. It defaults to false. Optional
dump_filename If dump is set to true, name of the file in which internal data will be stored. It defaults to ./pvt.dat. Optional

Example:

;######### PVT CONFIG ############
PVT.implementation=RTKLIB_PVT
PVT.positioning_mode=PPP_Static
PVT.output_rate_ms=100
PVT.display_rate_ms=500
PVT.iono_model=Broadcast
PVT.trop_model=Saastamoinen
PVT.flag_rtcm_server=true
PVT.flag_rtcm_tty_port=false
PVT.rtcm_dump_devname=/dev/pts/1
PVT.rtcm_tcp_port=2101
PVT.rtcm_MT1045_rate_ms=5000
PVT.rtcm_MT1045_rate_ms=5000
PVT.rtcm_MT1097_rate_ms=1000
PVT.rtcm_MT1077_rate_ms=1000
PVT.rinex_version=2

Implementation: GPS_L1_CA_PVT

IMPORTANT: This implementation has been removed from the next branch of GNSS-SDR source code and will not be present in the next stable release. Please use instead the RTKLIB_PVT implementation described below.

This PVT implementation computes position fixes usign GPS L1 C/A signals and a basic, memoryless Least Squares solution. Those solutions are exported to KML and GeoJSON formats for their graphical representation.

In addition, observation and navigation RINEX files are also generated by default.

If configured, this block delivers NMEA messages in real-time through a serial port.

If configured, this block also generates RTCM messages in real-time, delivered through a TCP server.

This implementation accepts the following parameters:

Global Parameter Description Required
GNSS-SDR.SUPL_gps_ephemeris_xml Name of an XML file containing GPS ephemeris data. It defaults to ./gps_ephemeris.xml Optional
Parameter Description Required
implementation GPS_L1_CA_PVT Mandatory
flag_averaging Perfoms averaging over the internally generated results before outputting them. It defaults to false. Optional
averaging_depth If flag_averaging is set to true, size of the buffer performing a moving average. It defaults to 10. Optional
output_rate_ms Rate at which PVT solutions will be computed, in ms. The minimum is the integration time used in the tracking block. It defaults to 500 ms. Optional
display_rate_ms Rate at which PVT solutions will be displayed in the terminal, in ms. It defaults to 500 ms. Optional
nmea_dump_filename Name of the file containing the generated NMEA sentences in ASCII format. It defaults to ./nmea_pvt.nmea. Optional
flag_nmea_tty_port [true, false]: If set to true, the NMEA sentences are also sent to a serial port device. It defaults to false. Optional
nmea_dump_devname If flag_nmea_tty_port is set to true, descriptor of the serial port device. It defaults to /dev/tty1. Optional
flag_rtcm_server [true, false]: If set to true, it runs up a TCP server that is serving RTCM messages to the connected clients during the execution of the software receiver. It defaults to false. Optional
rtcm_tcp_port If flag_rtcm_server is set to true, TCP port from which the RTCM messages will be served. It defaults to 2101. Optional
rtcm_station_id Station ID reported in the generated RTCM messages. It defaults to 1234. Optional
rtcm_MT1019_rate_ms Rate at which RTCM Message Type 1019 (GPS Ephemeris data) will be generated, in ms. It defaults to 5000 ms. Optional
rtcm_MSM_rate_ms Rate at which RTCM Multiple Signal Messages GPS MSM7 (MT1077 - Full GPS observations) will be generated, in ms. It defaults to 1000 ms. Optional
flag_rtcm_tty_port [true, false]: If set to true, the generated RTCM messages are also sent to a serial port device. It defaults to false. Optional
rtcm_dump_devname If flag_rtcm_tty_port is set to true, descriptor of the serial port device. . It defaults to /dev/pts/1. Optional
dump [true, false]: If set to true, it enables the PVT internal binary data file logging. It defaults to false. Optional
dump_filename If dump is set to true, name of the file in which internal data will be stored. It defaults to ./pvt.dat. Optional

Example:

;######### PVT CONFIG ############
PVT.implementation=GPS_L1_CA_PVT
PVT.nmea_dump_filename=./gnss_sdr_pvt.nmea ; NMEA log path and filename
PVT.flag_nmea_tty_port=true ; Enable the NMEA log to a serial TTY port
PVT.nmea_dump_devname=/dev/pts/4 ; serial device descriptor for NMEA log

Implementation: Galileo_E1_PVT

IMPORTANT: This implementation has been removed from the next branch of GNSS-SDR source code and will not be present in the next stable release. Please use instead the RTKLIB_PVT implementation described below.

This PVT implementation computes position fixes usign Galileo E1B signals and a basic, memoryless Least Squares solution. Those solutions are exported to KML and GeoJSON formats for their graphical representation.

In addition, observation and navigation RINEX files are also generated by default.

If configured, this block delivers NMEA messages in real-time through a serial port.

If configured, this block also generates RTCM messages in real-time, delivered through a TCP server.

This implementation accepts the following parameters:

Parameter Description Required
implementation Galileo_E1_PVT Mandatory
flag_averaging Perfoms averaging over the internally generated results before outputting them. It defaults to false. Optional
averaging_depth If flag_averaging is set to true, size of the buffer performing a moving average. It defaults to 10. Optional
output_rate_ms Rate at which PVT solutions will be computed, in ms. It defaults to 500 ms. Optional
display_rate_ms Rate at which PVT solutions will be displayed in the terminal, in ms. It defaults to 500 ms. Optional
nmea_dump_filename Name of the file containing the generated NMEA sentences in ASCII format. It defaults to ./nmea_pvt.nmea. Optional
flag_nmea_tty_port [true, false]: If set to true, the NMEA sentences are also sent to a serial port device. It defaults to false. Optional
nmea_dump_devname If flag_nmea_tty_port is set to true, descriptor of the serial port device. It defaults to /dev/tty1. Optional
flag_rtcm_server [true, false]: If set to true, it runs up a TCP server that is serving RTCM messages to the connected clients during the execution of the software receiver. It defaults to false. Optional
rtcm_tcp_port If flag_rtcm_server is set to true, TCP port from which the RTCM messages will be served. It defaults to 2101. Optional
rtcm_station_id Station ID reported in the generated RTCM messages. It defaults to 1234. Optional
rtcm_MT1045_rate_ms Rate at which RTCM Message Type 1045 (Galileo Ephemeris data) will be generated, in ms. It defaults to 5000 ms. Optional
rtcm_MSM_rate_ms Rate at which RTCM Multiple Signal Messages Galileo MSM7 (MT1097 - Full Galileo observations) will be generated, in ms. It defaults to 1000 ms. Optional
flag_rtcm_tty_port [true, false]: If set to true, the generated RTCM messages are also sent to a serial port device. It defaults to false. Optional
rtcm_dump_devname If flag_rtcm_tty_port is set to true, descriptor of the serial port device. . It defaults to /dev/pts/1. Optional
dump [true, false]: If set to true, it enables the PVT internal binary data file logging. It defaults to false. Optional
dump_filename If dump is set to true, name of the file in which internal data will be stored. It defaults to ./pvt.dat. Optional

Example:

;######### PVT CONFIG ############
PVT.implementation=GALILEO_E1_PVT
PVT.averaging_depth=100
PVT.flag_averaging=false
PVT.output_rate_ms=100;
PVT.display_rate_ms=500;
PVT.nmea_dump_filename=./gnss_sdr_pvt.nmea;
PVT.flag_nmea_tty_port=true;
PVT.nmea_dump_devname=/dev/pts/4
PVT.flag_rtcm_server=true;
PVT.rtcm_tcp_port=2101
PVT.rtcm_MT1045_rate_ms=5000
PVT.rtcm_MSM_rate_ms=1000

Implementation: Hybrid_PVT

IMPORTANT: This implementation has been removed from the next branch of GNSS-SDR source code and will not be present in the next stable release. Please use instead the RTKLIB_PVT implementation described below.

This is a PVT implementation that computes position fixes using all the receiver’s available signals, and performs a basic, memoryless Least Squares solution. Those solutions are exported to KML and GeoJSON formats for their graphical representation. You always can use this implementation in your configuration file, since it accepts all kind of (single- or multi-band, single- or multi-constellation) receiver configurations.

If configured, this block delivers NMEA messages in real-time through a serial port.

If configured, this block also generates RTCM messages in real-time, delivered through a TCP server.

This implementation accepts the following parameters:

Global Parameter Description Required
GNSS-SDR.SUPL_gps_ephemeris_xml Name of an XML file containing GPS ephemeris data. It defaults to ./gps_ephemeris.xml Optional
Parameter Description Required
implementation Hybrid_PVT Mandatory
flag_averaging Perfoms averaging over the internally generated results before outputting them. It defaults to false. Optional
averaging_depth If flag_averaging is set to true, size of the buffer performing a moving average. It defaults to 10. Optional
output_rate_ms Rate at which PVT solutions will be computed, in ms. It defaults to 500 ms. Optional
display_rate_ms Rate at which PVT solutions will be displayed in the terminal, in ms. It defaults to 500 ms. Optional
nmea_dump_filename Name of the file containing the generated NMEA sentences in ASCII format. It defaults to ./nmea_pvt.nmea. Optional
flag_nmea_tty_port [true, false]: If set to true, the NMEA sentences are also sent to a serial port device. It defaults to false. Optional
nmea_dump_devname If flag_nmea_tty_port is set to true, descriptor of the serial port device. It defaults to /dev/tty1. Optional
flag_rtcm_server [true, false]: If set to true, it runs up a TCP server that is serving RTCM messages to the connected clients during the execution of the software receiver. It defaults to false. Optional
rtcm_tcp_port If flag_rtcm_server is set to true, TCP port from which the RTCM messages will be served. It defaults to 2101. Optional
rtcm_station_id Station ID reported in the generated RTCM messages. It defaults to 1234. Optional
rtcm_MT1045_rate_ms Rate at which RTCM Message Type 1045 (Galileo Ephemeris data) will be generated, in ms. If set to 0, mutes this message. It defaults to 5000 ms. Optional
rtcm_MT1019_rate_ms Rate at which RTCM Message Type 1019 (GPS Ephemeris data) will be generated, in ms. If set to 0, mutes this message. It defaults to 5000 ms. Optional
rtcm_MSM_rate_ms Default rate at which RTCM Multiple Signal Messages will be generated. It defaults to 1000 ms. Optional
rtcm_MT1077_rate_ms Rate at which RTCM Multiple Signal Messages GPS MSM7 (MT1077 - Full GPS observations) will be generated, in ms. If set to 0, mutes this message. It defaults to rtcm_MSM_rate_ms. Optional
rtcm_MT1097_rate_ms Rate at which RTCM Multiple Signal Messages Galileo MSM7 (MT1097 - Full Galileo observations) will be generated, in ms. If set to 0, mutes this message. It defaults to rtcm_MSM_rate_ms. Optional
flag_rtcm_tty_port [true, false]: If set to true, the generated RTCM messages are also sent to a serial port device. It defaults to false. Optional
rtcm_dump_devname If flag_rtcm_tty_port is set to true, descriptor of the serial port device. . It defaults to /dev/pts/1. Optional
dump [true, false]: If set to true, it enables the PVT internal binary data file logging. It defaults to false. Optional
dump_filename If dump is set to true, name of the file in which internal data will be stored. It defaults to ./pvt.dat. Optional

Example:

;######### PVT CONFIG ############
PVT.implementation=Hybrid_PVT
PVT.averaging_depth=10
PVT.flag_averaging=false
PVT.output_rate_ms=100;
PVT.display_rate_ms=500;
PVT.flag_rtcm_server=true
PVT.flag_rtcm_tty_port=false
PVT.rtcm_dump_devname=/dev/pts/1
PVT.rtcm_tcp_port=2101
PVT.rtcm_MT1045_rate_ms=5000
PVT.rtcm_MT1045_rate_ms=5000
PVT.rtcm_MT1097_rate_ms=1000
PVT.rtcm_MT1077_rate_ms=1000

References

  1. N. Ashby, The Sagnac Effect in the Global Positioning System, Chapter 1 in Relativity in Rotating Frames: Relativistic Physics in Rotating Reference Frames (Fundamental Theories of Physics), G. Rizzi , M.L. Ruggiero (Eds.), Kluwer Academic Publishers, Dordrecht, The Netherlands, 2004. 

  2. T. Takasu, RTKLIB ver. 2.4.2 Manual. April 29, 2013. 

  3. D. McCarthy, G. Petit (Eds.), IERS Conventions (2003), IERS Technical Note No. 32, International Earth Rotation and Reference Systems Service, Frankfurt (Germany), 2004.  2

  4. Kouba, P. Héroux, Precise Point Positioning Using IGS Orbit and Clock Products, GPS Solutions, Vol. 5, no. 2, 2001, pp. 12-28. 

  5. Global Positioning System Directorate Systems Engineering & Integration, Interface Specification IS-GPS-200H: Navstar GPS Space Segment/Navigation User Interfaces, Dec. 2015. 

  6. J. A. Klobuchar, Ionospheric time-delay algorithms for single-frequency GPS users. IEEE Transactions on Aerospace and Electronic Systems, Vol AES-23, no. 3, May 1987, pp. 325-331. 

  7. M. Bevis, S. Businger, S. Chiswell, T. A. Herring, R. A. Anthes, C. Rocken, R. H. Ware, GPS Meteorology: Mapping Zenith Delay onto Precipitable Water, American Meteorological Society, vol. 33, March 1994, pp. 379-386. 

  8. A. E. Niell, Global mapping functions for the atmosphere delay at radio wavelengths, Journal of Geophysical Research: Solid Earth, Volume 101, Issue B2 10, Feb. 1996, pp. 3227-3246. 

  9. D. S. MacMillan, Atmospheric gradients from very long baseline interferometry observation, in Geophysical Research Letters, Volume 22, Issue 9, May 1995, pp. 1041-1044. 

Updated:

Leave a Comment