-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The PPP implementation uses individual clock offsets for each constellation. However, update_stat() copies inters-system biases from the state vector rtk->x to the solution rtk->sol.dtr.
The satellite PCO and PCV corrections are applied in different places in the source code.
Satellite PCO corrections are no longer directly applied to the computed satellite position as a 3-dimensional vector in ECEF for positions from SP3 files. A per-frequency handling has been implemented.
Satellite PCV corrections are computed through two functions: the function ppp.c:satantpcv() computes the nadir angle and then calls rtkcmn.c:antmodel_s() to compute the interpolated PCV correction as a scalar value for each frequency.
Receiver PCO and PCV corrections are jointly computed in the function rtkcmn.c:antmodel(). The PCO is projected onto the LOS vector and the PCV is interpolated depending on the satellite elevation angle. Applying the PCV correction can optionally be turned off. This function also applies the eccentricity correction.
NOTE: this has been fixed in the dev branch!
The precise position returned by satpos() refers to the iono-free APC instead of COM for SP3. This comes with the advantage that the satellite antenna PCO is already applied at this stage. Only the correction for the PCV must then be applied for each frequency, which only depends on the Nadir angle. However, this will cause problems for consistent modeling of PCOs for un-combined multi-frequency PPP.
The satellite position for PPP is computed in ppp.c:pppos(). From there, the following functions are called:
ephemeris.c:satposs()
Computes position, clock offset, etc. for each satellite in the observation vector. Calls ephemeris.c:satpos() for each satellite.
ephemeris.c:satpos()
Computes position, clock offset, etc. for single satellite. Uses a switch opt to set teh computed positio to either CoM (opt=0) or APC (opt=1) depending on ephemeris type. Calls preceph.c:peph2pos() with opt=1 when the ephemeris type EPHOPT_PREC is selected.
preceph.c:peph2pos()
Computes the satellite position based on SP3. Here, the reference can be set either to CoM or APC using the opt switch. Calls the function preceph.c:satantoff() to compute the iono-free PCO.
There are inconsistencies between the pdf documentation and the source code comments and the implementation of the output to the *.stat file.
The output of the solution happens in rtkpos.c:rtkoutstat(). In case the positioning mode PMODE_PPP_KINEMA or higher is selected, the function ppp.c:pppoutstat() is used for the output instead.
-
PMODE_PPP_FIXED: the position is reset at each epoch to the pre-defined user position in the configuration fileant2-pos1(TBC!) with a small variance of 1.0e-8 m*m. -
PMODE_PPP_STATIC: a process noise with a variance defined instats-prnposin the configuration file is applied to the position state. The default value is 0.0 m*m/s, it cannot be changed in the GUI! -
PMODE_PPP_KINEMA: if receiver dynamics are not activated, a hard-coded process noise with a variance of 60 m*m/s is applied to the variance of the position states. This value is also used for the initial variance of the position state. If receiver dynamics are used, process noise with a variances defined instats-prnaccelhandstats-prnaccelvin the configuration file is applied to the acceleration state.
The following options (c.f. rtklib.h) can be defined at compilation time:
ENAGLO
ENAQZS
ENAGAL
ENACMP
ENAIRN
NFREQ
NEXOBS
IERS_MODEL
This is now uniformly defined in the CMakeLists.txt file in the root directory of RTKLIB, so the same settings are applied for GUI and CUI compilation.
After starting the processing postpos.c:execses() first checks if any of the files defined in the main GUI is a bias file. If no biases are found, a DCB file defined under Options->Files is read.
A fixed scaling factor of 3 is used for the observation standard deviation of the IF combination. This factor only applies to the GPS L1/L2 combination!
Review the selection of observations in rinex.c:decode_obsdata() with respect to code priorities!
A receiver bias is estimated when three or more frequencies are selected. These issues have been fixed in the dev branch:
- One bias parameter must be added for each frequency beyond the 2nd frequency.
- Biases must be estimated separately for each constellation.
The following issues still exist with this approach:
- Estimating these parameters only makes sense if the second frequency slot is populated with observations.
Review the processing of PCOs and PCVs in rtkcmn.c:readantex() and make sure, that the correct values are processed.
The data structure defines frequency numbers 1,2 and 5 for the three GPS frequencies L1, L2 and L5. For Galileo 1 and 5 are used for E1 and E5a, 2 is used for E5b, E6 is ignored. For the other GNSSs, frequencies which match the numbers 1,2 and 5 are stored, others are ignored. This may cause issue in particular for BeiDou.
| Number | 1 | 2 | 3 |
|---|---|---|---|
| GPS | L1 | L2 | L5 |
| Galileo | E1 | E5b | E5a |
| GLONASS | G1 | G2 | - |
| BeiDou | ?? | ?? | ?? |
| QZSS | L1 | L2 | L5 |
An ephemeris option QZSS LEX is defined in the GUIs, but does not seem to be included in the RTKLIB option set.
Carrier-phase biases are currently not supported. A data-structure for such biases is missing.
Not all OSBs in Bias-SINEX files seem to be supported. The OSBs are internally converted into DCBs by subtracting the values from a reference bias (with index 0) in preceph.c::readbiaf(). In the case of CODE MGEX files, the biases for the code reference signals C1W and C2W are set to zero. As a result, the stored biases are the negative values of the other biases.
TODO: check which values are actually stored in the data structures.
The code biases are applied in ppp.c:corr_meas(), where they are ADDED to the observations. Due to the above sign inversion, this seems to result in the correct sign.
TODO: check what happens in case of a third frequency.
Ideally, the OSBs should simply be used directly without any further modification. A flag could be used for indicating if absolute or relative biases have been read.
The estimated ionospheric delays are NOT slant delays but mapped to vertical delays for each satellite. The mapping function uses a hard-coded ionospheric scale height 350 km.