Bernese GPS Software Version 5.0 - Bernese GNSS Software

14.2 Precise Clock Estimation
To illustrate the benefit from using phase observations for time transfer the final solution of
the clock determination example (see Section 20.4.4) is repeated four times using only original
code observations (dotted line in Figure 14.1), using only smoothed code observations
(dashed line in same figure), using only phase observations (long-dashed line), and using
smoothed code and phase observations together (solid line). From all four solutions the
clock differences between the station clock parameters for PTBB and BRUS are extracted
and their Allan variance is displayed in Figure 14.1. The improvement in the noise of the
clock differences achieved by adding the phase observations is obvious.
14.2 Precise Clock Estimation
The clock estimation using combined GPS/GLONASS receiver data does not work in Version
5.0 of the Bernese GPS Software. There is an offset between the GPS and GLONASS
time frames which may reach several hundreds of nanoseconds. This case is not yet handled
by the software. Furthermore a GLONASS only solution assumes that there are no
biases between the code measurements received from satellites with different frequencies,
an assumption that is actually not true (see [Dach et al., 2006a]).
14.2.1 Epoch-Wise Clock Estimation in GPSEST
Clock corrections have to be estimated with zero-difference data. In GPSEST the clock
parameters may be handled in two different ways:
• All clock parameters are estimated together with other parameters (e.g., station coordinates,
troposphere parameters) in the main normal equation.
• The clock parameters are setup resp. pre-eliminated epoch by epoch. After solving the
main normal equation (containing all non-epoch parameters) the resulting parameters
are introduced and kept fixed when the epoch-parameters are estimated epoch by
epoch in a back-substitution step. We refer to Section 7.5.3 for more details on the
handling of epoch parameters.
The estimated clock corrections are identical in both cases. To obtain the correct covariance
information for the resulting epoch parameters the back-substitution algorithm requires
significantly more computing resources. Therefore, a simplified computation giving
too optimistic formal accuracies is recommended for normal (see Section 7.5.6).
The first strategy is preferable if only a small number of epoch parameters is requested (e.g.,
PPP with a sampling of 5 minutes for one day). The overhead generated by the epoch-wise
pre-elimination and the backsubstitution can be avoided in this case. The limitation is the
number of parameters to be estimated in one normal equation system: With 8 stations
observing on average 12 satellites 20 parameters have to be estimated per epoch. Applying
a 5 minutes sampling rate, i.e., 288 epochs per day, this yields 5760 clock parameters to be
estimated (in the large memory model the corresponding arrays are limited by default to
MAXPAR= 4000 in program GPSEST).
For the second strategy the number of parameters in the main normal equation is dramatically
reduced and much more clock parameters may be estimated in one run of GPSEST.
Bernese GPS Software Version 5.0 Page 291