08.06.2013 Views

Bernese GPS Software Version 5.0 - Bernese GNSS Software

Bernese GPS Software Version 5.0 - Bernese GNSS Software

Bernese GPS Software Version 5.0 - Bernese GNSS Software

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

13.3 Determination of <strong>GNSS</strong> Code Biases<br />

13.3.1 P1–P2 Code Biases<br />

13.3 Determination of <strong>GNSS</strong> Code Biases<br />

Based on Table 13.1, one may draw the conclusion that the geometry-free (L4) linear combination<br />

is the most appropriate linear combination for accurate P1–P2 code bias retrieval.<br />

P1–P2 DCB values are computed while solving for ionosphere parameters (see also Chapter<br />

12). Remark: It should be clear that BC1−P2 (not BP1−P2) will result as receiver bias<br />

in case of C1/P2 receiver models.<br />

Note: Extraction of <strong>GPS</strong> τGD values is possible using RXNBV3. τGD values are exported as<br />

BP1−P2 values in form of a DCB file.<br />

13.3.2 P1–C1 Code Biases<br />

It is obvious that differences between pairs of simultaneous P1 and C1 code measurements—<br />

as provided by the first (P1/P2) receiver class—may be analyzed to retrieve inter-satellite<br />

P1–C1 code bias values, BP1−C1. As a matter of fact, this is the method commonly used by<br />

people doing P1-C1 bias retrieval (see, e.g., [Gao et al., 2001; Jefferson et al., 2001]). The<br />

necessity for accounting in addition to satellite also for receiver bias values may be easily<br />

understood in view of this straightforward method. Note that this method is not supported<br />

by the <strong>Bernese</strong> <strong>GPS</strong> <strong>Software</strong> <strong>Version</strong> <strong>5.0</strong> .<br />

At CODE, we use a fundamentally different, more sophisticated approach. Our method<br />

works on the basis of the ionosphere-free (L3) linear combination in the course of a global<br />

<strong>GNSS</strong> clock analysis. We solve for (satellite-specific) BP1−C1 parameters together with<br />

the epoch parameters responding to satellite and receiver clock offsets [Schaer, 2000]. The<br />

partial derivatives with respect to these satellite DCB parameters are exactly those factors<br />

as they may be gathered from from the L3 row of Table 13.1: 0, or undefined for P1/P2, −1<br />

for C1/X2, and −2.55 for C1/P2. Obviously, a “mixed” receiver network is indispensable<br />

for our method.<br />

The main advantage of our approach is that resulting P1–C1 DCB estimates directly reflect<br />

the code bias differences between the three receiver classes as seen by an analysis center in<br />

its clock estimation procedure. In other words, the bias values are estimated directly from<br />

the data sets for which they will be applied. We do not make use of C1 code measurements<br />

from P1/P2 receivers (providing C1/P1/P2).<br />

13.3.3 Verification of the Receiver Tracking Technology<br />

A special application of the P1–C1 bias parameter estimation is the possibility to verify<br />

which of the three receiver classes a particular receiver model may be attributed to. The<br />

principle is relatively simple: instead of solving for BP1−C1 parameters, these parameters<br />

are assumed to be known (see also Figure 13.4) and one common factor is set up as unknown<br />

parameter (called “P1–C1 DCB multiplier”) for each single receiver.<br />

Figure 13.5 shows an excerpt of a corresponding <strong>GPS</strong>EST output file. A factor close to 0<br />

indicates a P1/P2 receiver, a factor around 1 a C1/X2 receiver, and, with an expected factor<br />

of 2.55, identification of C1/P2 is utmost reliable [Schaer, 2002].<br />

<strong>Bernese</strong> <strong>GPS</strong> <strong>Software</strong> <strong>Version</strong> <strong>5.0</strong> Page 285

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!