Observables

The role of an Observables block is to collect the synchronization data coming from all the processing Channels, and to compute from them the GNSS basic measurements: pseudorange and carrier phase.

The pseudorange measurement is defined as the difference of the time of reception (expressed in the time frame of the receiver) and the time of transmission (expressed in the time frame of the satellite) of a distinct satellite signal. It can be modeled as follows:

where:

  • is the pseudorange measurement.
  • is the true range.
  • is the speed of light.
  • is the satellite clock offset from GNSS time.
  • is the receiver clock offset from GNSS time.
  • is the tropospheric delay.
  • is the ionospheric delay.
  • models satellite orbital errors, since the orbits of the satellites are affected by many factors including the variations in gravity, drag and tidal forces from the sun, the moon etc.
  • models receiver’s instrumental delays.
  • models satellites’s instrumental delays.
  • models the effect of multipath on code delay estimation.
  • models the receiver’s thermal noise.

GNSS-SDR performs pseudorange generation based on setting a common reception time across all channels1. The result of this approach is not an absolute pseudorange, but a relative pseudorange with respect to the value (of pseudorange) allocated for a reference satellite. This is possible thanks to the time of week (TOW) information, that is the epoch conveyed by the navigation message, and the associated reception time , that is the epoch measured by the receiver’s time counter, both available for each satellite.

The first step performed by the common reception time algorithm is the selection of a reference satellite: it is the satellite with the most recent TOW (which is the nearest satellite), denoted as , whose associated is taken as the common reception time for all channels. An initial travel time ( ms is assigned to this satellite, but in general it is a value between and milliseconds according to the user altitude) that can be easily converted in meters considering the speed of light. Then, the pseudoranges for all other satellites are derived by adding the relative-arrival times. Each travel time can be computed as:

where is the difference between the reference TOW and the current TOW of the -th satellite; is the time elapsed between the reference and the actual receiver time, when the pseudorange must be computed for the specific satellite. This method is equivalent to taking a snapshot of all the channels’ counters at a given time, and thus it can produce pseudoranges at any time, without waiting for a particular bit front on each channel.

The block diagram of such approach is shown below:

Pseudorange computation Block diagram of the pseudorange computation using the common reception time approach in GNSS-SDR2

Note that, in the case of a multi-system receiver, all pseudorange observations must be referred to one receiver clock only.

The carrier phase measurement is actually a measurement on the beat frequency between the received carrier of the satellite signal and a receiver-generated reference frequency. It can be modeled as:

where:

  • is the carrier phase measurement.
  • is the speed of light.
  • is the satellite clock offset from GNSS time.
  • is the receiver clock offset from GNSS time.
  • is the tropospheric delay.
  • is the ionospheric delay.
  • models receiver’s carrier phase instrumental delays.
  • models satellites’s carrier phase instrumental delays.
  • is the carrier wavelength.
  • represents the integer ambiguity.
  • is the wind-up term due to the circular polarization of the electromagnetic signal.
  • models the effect of multipath on carrier phase estimation.
  • models the receiver’s thermal noise.

Notice that the ionospheric term has opposite sign for code and phase. This means that the ionosphere produces an advance of the carrier phase measurement equal to the delay on the code measurements.

As shown in a paper by Petovello and O’Driscoll3, the carrier phase measurement delivered by the receiver can be written as:

where:

  • is the signal reception time.
  • is the range from the satellite to the receiver at time .
  • is the radio frequency wavelegth.
  • is an initial phase offset of the locally-generated mixer signal.
  • is an initial satellite phase offset.
  • is the integer ambiguity, where:
    • is the integer component of the NCO phase.
    • is the integer component of the term .

In order to generate useable phase measurements, the receiver phase observations must maintain a contant integer number of cycles offset from the true carrier phase. That is, if the range increases by one cycle (i.e., one wavelength), the integer component of the NCO, denoted as , also increments by one cycle.

Implementation: GPS_L1_CA_Observables

This implementation computes observables by collecting the outputs of channels for GPS L1 C/A signals.

It accepts the following parameters:

Parameter Description Required
implementation GPS_L1_CA_Observables Mandatory
averaging_depth Number of observables used in a moving average filter. It defaults to $100$. Optional
dump [true, false]: If set to true, it enables the Observables 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 ./observables.dat Optional

Observables implementation: GPS_L1_CA_Observables.

Example:

    ;######### OBSERVABLES CONFIG ############
    Observables.implementation=GPS_L1_CA_Observables
    Observables.dump=true
    Observables.dump_filename=./my_observables.dat

Implementation: GPS_L2C_Observables

This implementation computes observables by collecting the outputs of channels for GPS L2C(M) signals.

It accepts the following parameters:

Parameter Description Required
implementation GPS_L2C_Observables Mandatory
averaging_depth Number of observables used in a moving average filter. It defaults to $100$. Optional
dump [true, false]: If set to true, it enables the Observables 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 ./observables.dat Optional

Observables implementation: GPS_L2C_Observables.

Example:

    ;######### OBSERVABLES CONFIG ############
    Observables.implementation=GPS_L2C_Observables
    Observables.dump=true
    Observables.dump_filename=./my_observables.dat

Implementation: Galileo_E1B_Observables

This implementation computes observables by collecting the outputs of channels for Galileo E1B signals.

It accepts the following parameters:

Parameter Description Required
implementation Galileo_E1B_Observables Mandatory
averaging_depth Number of observables used in a moving average filter. It defaults to $100$. Optional
dump [true, false]: If set to true, it enables the Observables 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 ./observables.dat Optional

Observables implementation: Galileo_E1B_Observables.

Example:

    ;######### OBSERVABLES CONFIG ############
    Observables.implementation=Galileo_E1B_Observables

Implementation: Galileo_E5A_Observables

This implementation computes observables by collecting the outputs of channels for Galileo E5a signals.

It accepts the following parameters:

Parameter Description Required
implementation Galileo_E5A_Observables Mandatory
averaging_depth Number of observables used in a moving average filter. It defaults to $100$. Optional
dump [true, false]: If set to true, it enables the Observables 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 ./observables.dat Optional

Observables implementation: Galileo_E5A_Observables.

Example:

    ;######### OBSERVABLES CONFIG ############
    Observables.implementation=Galileo_E5A_Observables

Implementation: Hybrid_Observables

This implementation computes observables by collecting the outputs of channels for all kind of allowed GNSS signals. 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.

It accepts the following parameters:

Parameter Description Required
implementation Hybrid_Observables Mandatory
averaging_depth Number of observables used in a moving average filter. It defaults to $100$. Optional
dump [true, false]: If set to true, it enables the Observables 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 ./observables.dat Optional

Observables implementation: Hybrid_Observables.

Example:

    ;######### OBSERVABLES CONFIG ############
    Observables.implementation=Hybrid_Observables

References

  1. M. Petovello, M. Rao, G. Falca, Code Tracking and Pseudoranges: How can pseudorange measurements be generated from code tracking?, Inside GNSS, vol. 7, no. 1, pp. 26–33, Jan./Feb. 2012. 

  2. J. Arribas, M. Branzanti, C. Fernández-Prades and P. Closas, Fastening GPS and Galileo Tight with a Software Receiver, in Proc. of the 27th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa, Florida, Sep. 2014, pp. 1383 - 1395. 

  3. M. Petovello, C. O’Driscoll, Carrier phase and its measurements for GNSS: What is the carrier phase measurement? How is it generated in GNSS receivers? Inside GNSS, vol. 5, no. 5, pp. 18–22, Jul./Aug. 2010. 

Updated:

Leave a Comment