Bernese GPS Software Version 5.0 - Bernese GNSS Software

14. Clock Estimation
Here the limitation results from the number of parameters to be estimated in the main normal
equation (e.g., phase ambiguity parameters limit the processing to about 40 stations per
day for the large memory model) and the size of the scratch file (e.g., a 2 Gigabyte scratch
file is generated for about 10 stations and a 30 seconds sampling for a daily solution).
A mixture of both algorithms for station and satellite clocks (e.g., EVERY EPOCH for “Pre-
Elimination” of “Receiver clock offsets” and NO resp. PRIOR TO NEQ SAVING for “GNSS clock
offsets” in panel “GPSEST 5.1: Setup of Parameters and Pre-Elimination 1”) is possible if necessary
for special applications.
When processing code observations only (original or smoothed code, see Section 6.2.4) for
the clock parameter estimation no ambiguity parameters need to be introduced and the
number of parameters in the main normal equation is reduced. In the extreme case all parameters
apart from the clock corrections (e.g., station coordinates, troposphere parameters,
orbits, ERPs, ...) are introduced from another program run (e.g., from a double-difference
solution). In this case all epochs are completely independent and the solution thus becomes
independent from the observation window used for the processing. In this case not only
the estimates but also their error values are identical for all computation strategies because
introducing of all non-epoch parameters as known into GPSEST is equivalent to the simplified
algorithm for computing the covariances based on the neglection of all non-epoch
parameters.
For precise estimation of the clock parameters the use of the phase observations is indispensable
(see Figure 14.1). They greatly improve the epoch-to-epoch accuracy of the solution
for the clock parameters. As stated in the introductory section the correlation between the
clock parameters and the phase ambiguities makes it necessary to analyze both observation
types together (unless the goal is precise frequency transfer only). Therefore it is important
that you select the corresponding “Phase observation files” and “Code observation files” in the
input panel “GPSEST 1.1: Input Files 1”.
It is important that both code and phase binary observation files contain the same receiver
clock corrections. The receiver clock corrections have to be stored by selecting BOTH in
option “Save clock estimates” in panel “CODSPP 2: Input Options” of the program CODSPP.
The program GPSEST uses the results from the receiver clock synchronization as a priori
values for the station clock estimation but it does not check the consistency of the values
in the two corresponding observation files.
Two input files need additional comments in the context of clock parameter estimation,
namely “GNSS clock corrections” and “Differential code biases” in panel “GPSEST 1.1: Input Files 1”.
It is recommended to introduce the GNSS clock corrections as a priori even if satellite clocks
are estimated. The satellite clock corrections may get values of up to 1 ms. If you introduce
no a priori information the estimates may become very big and the numerical reliability
of the parameter estimation may not be guaranteed anymore. The same is, of course, true
for the receiver clock corrections. The a priori values are stored in the observation files
when performing the receiver clock synchronization with program CODSPP. The capability
to introduce a priori receiver clock corrections is a new feature of the Version 5.0 of the
Bernese GPS Software.
As soon as you process data from receivers that do not provide P1 and P2 measurements
differential code biases need to be considered when estimating clock parameters. Specify the
P1 − C1 DCB corrections (provided at ftp://ftp.unibe.ch/aiub/CODE/yyyy/P1C1yymm.
Page 292 AIUB