Where GNSS biases are coming from?
The GNSS code biases are time delays within the satellite and receiver caused by their hardware. This implies that the given time from the satellite clock is not equal to the signal emission time. The same is valid for the receivers. The given reception time adopted by the receiver is the time when the signal was demodulated and linked to the internal receiver clock. However, there is a time delay between the receiving time in the antenna and the time linking within the hardware. The principle may be illustrated as follows:
This delay is commonly known as bias and has to be taken into account when processing GNSS data for various applications, such as satellite and receiver clock estimation, carrier phase ambiguity resolution, and ionosphere analysis. These biases are in particular relevant, if the observations from different receivers (using different tracking technologies) and signals from different GNSS shall be processed together. This is illustrated in the following figure:
The figure illustrates how for instance biases for differences between GPS satellites become relevant when estimating clock corrections: receiver k is tracking the same signal from satellites i and j whereas the receiver l tracks the P2 signal from satellite i but from satellite j the C2 signal. The clock parameter for satellite j will refer to the hardware delay in the satellite for the P2 signal for station k and to the hardware delay of the C2 signal for station l. The resulting discrepancy must be handled by correcting for so-called differential code biases (DCB) P2-C2 at the satellite l that takes the difference in the hardware delay between the C2 and P2 signal in the satellite into account. For other scenarios and applications also P1-C1 and P1-P2 biases are relevant.
Analogue biases exist also for phase measurements. They are usually absorbed by the phase ambiguities, but they become important if the ambiguities shall be resolved to their integer values.
Monitoring of DCBs at CODE analysis center
In the frame of the processing activities for the IGS, CODE has established several ways to extract and monitor the DCBs. This is illustrated in the subsequent figure:
The DCBs are averaged over 30 days. The most recent values obtained from a sliding window process are available at AFTP/CODE. At the beginning of each month these files are copied as monthly DCB solution into the yearly subdirectories (labelled with two-digit year and two-digit month).
Updating the bias handling in the CODE analysis center
In comparison to a relative bias setup, using differential code biases (DCB), the pseudo-absolute code biases (OSB) is a step towards a flexible, expandable GNSS bias handling. The constraints, depending on the input data and processed data, can be evaluated after the full observation equations have been set up and can therefore be exactly determined prior to the normal equation inversion.
With this new approach it is in particular possible to combine the different sources of DCBs (which is illustrated above) into one system on normal equation level. All relevant differential biases can be extracted fully consistently by solving this normal equation after selecting a proper reference.
IGS Workshops on GNSS biases
The AIUB has hosted already two IGS workshops on GNSS biases:
