On this panel, you can decide the handling of the ionospheric delay and the PPP model used during the processing. Furthermore, you can select a multitude of ionosphere models.
2-Frequency-LCs: The ionosphere-free linear combination is built with the first and second processed frequency. If three frequencies are processed, two 2-frequency-IF-LCs are built (first and second, first and third frequency).
3-Frequency-LC: A three-frequency ionosphere-free linear combination (3-frequency-IF-LC) is build.
Estimate with ... as constraint: The slant ionospheric delay is estimated on the first processed frequency. Furthermore, ionospheric pseudo-observations are used to constrain the estimation of the ionospheric delay.
Correct with …: The ionospheric delay is calculated from an ionosphere model. The code and phase observations are corrected. Please note that the ionosphere model's imperfections might degrade the estimated parameters' accuracy. However, this option might be useful for single-frequency or simulated data.
Estimate: The ionospheric delay on the first processed frequency is estimated. Please note that there is a rank deficiency between the ionospheric delay and the receiver code biases. If both are estimated, the estimated values are contaminated with each other.
Estimate, decoupled clock: The receiver clock is decoupled for code and phase observations using the so-called Decoupled Clock Model (DCM). The ionospheric delay on the first frequency is estimated and absorbs receiver biases. Please check this publication from Naciri and Bisnath (and others).
Off: No correction for the ionospheric delay is used. The raw observations are processed (no LC). This option is only recommended for simulated data.
IONEX File: The ionospheric delay is modeled using the VTEC values from an IONEX file.
Klobuchar model: The ionospheric delay is modeled using the Klobuchar model. The coefficients of this model are part of the GPS broadcast navigation message.
NeQuick model: The ionospheric delay is modelled using the NeQuick model and an external implementation (see the folder CODE/ATMOSPHERE/NeQuick_G and the function call_NeQuick_G.m for details). The NeQuick model coefficients are part of the Galileo broadcast navigation message. Please note that the current implementation is rather slow.
CODE Spherical Harmonics: The ionospheric delay is modeled using the model of CODE based on spherical harmonics.
VTEC from Correction Stream: Experimental. The ionospheric model of the correction stream is applied (spherical harmonics).
TOBS File: The ionospheric delay is taken from the file \DATA\IONO\MyTobsFile.TOBS. This format originates from a modified version of the ATom software, developed by Gregor Möller. Please make sure that your TOBS file contains data for the processed day and that the MARKER NAME of the RINEX header (usually 4 digits) agrees with the ‘#REC’ entry of the TOBS file. Then the temporally nearest STEC is used to model the ionospheric delay.
Source: Select the source of the Ionex File. The GIMs of various ACs can be selected. Furthermore, IGS RT GIM corresponds to the IGS experimental combined real-time GIM (http://chapman.upc.es/irtg/). Please note that the ionosphere models ‘Regiomontan’ and 'GIOMO' are calculated at TU Wien and are currently not publicly available.
Auto-Detection: Define the file name of the IONEX file using pseudo-code. Furthermore, you have to determine the folder of the IONEX Auto-Detection. Choose either the option ‘automatic folder’ (IONEX files are located in the corresponding /DATA/IONEX/yyyy/doy folder) or ‘manual folder’ (hardcode the folder path, all IONEX files are located in this folder). The latter option is useful for batch processing with multiple days.
manually: Choose an IONEX File manually.
Choose the type of the IONEX product (e.g., rapid, final). Note that the availability of these types depends on the selected AC.
Jump to Table of Content