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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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!