[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IGSMAIL-2320] Handling mixed receiver types
- Subject: [IGSMAIL-2320] Handling mixed receiver types
- From: Various (see below)
- Date: Thu, 24 Jun 1999 4:58:32 PDT
IGS Electronic Mail Thu Jun 24 4:58:32 PDT 1999 Message Number 2320
Author: Various (see below)
Subject: Handling mixed receiver types
Below is a draft position paper presented at the IGS AC Workshop on
10 June 1999. Even though the recommendations here have not yet been
officially endorsed by the IGS, it is being circulated now to alert
the IGS community to an emerging problem due to the mix of receiver
types in the network. Station operators, in particular, should be
aware of these complications when changing receiver types.
Author: Various *
Subject: Recommendations for handling non-Rogue data
Date: 18 June 1999
* Various individuals have contributed to the development of this
proposal, including J. Kouba, H. Dragert, J. Zumberge, R. Muellerschoen,
L. Estey, W. Gurtner, and K. de Jong, although they do not necessarily
endorse it. The text has primarily been written by J. Ray, H. Dragert,
and J. Kouba, who are responsible for the contents.
The transition of the IGS network from a core of Rogue/TurboRogue (TR)
receivers to newer codeless tracking architectures is natural and
beneficial. However, the new receivers provide pseudorange observables
which can be biased compared with TRs. This is of no significance for
data analysts who process only carrier phase observables. For analysts
who use the pseudorange observations, their estimates for satellite clocks
can depend on the receiver model and the RINEX translation process. To
avoid mixing data with different satellite biases, which will degrade
the IGS satellite clock products (and precise point positioning using
them), recommendations are offerred for RINEXing and analysis procedures
to maintain compatibility with the heritage TR tracking network until a
sufficient fraction of stations is upgraded. At a future date to be
decided, a uniform switch of the IGS to the new observables can be made.
Rogue/TurboRogue Observables (CC type)
The AOA Rogue and TurboRogue (TR) receivers produce the following 4
C1 = C/A code at L1 freq.
L1(C1) = C/A-based phase at L1 freq.
P2' = codeless pseudorange at L2 freq.
L2' = cross-correlated phase at L2 freq.
The P2' pseudorange-type observable and the L2' phase are actually
formed by a process which tracks the cross-correlated (P2-P1)
pseudorange and the (L2-L1) phase differences:
P2' = C1 + (P2-P1)
L2' = L1(C1) + (L2(P2)-L1(P1))
Analysis software then has available two pseudorange (C1, P2') and two
phase (L1(C1), L2') observables which can be linearly combined to form
an ionosphere-free pseudorange and phase observation for each receiver-
satellite observation epoch. We denote these as CC (for cross-correlated)
receiver and observable types.
Modern Codeless Observables (non-CC type)
Newer receiver models (e.g., Ashtech Z-XII, AOA Benchmark, AOA TurboRogues
upgraded with ACT, etc.) provide direct measurements of P1 and P2 without
the use of the Y-codes, with 6 (or more) observables available:
C1 = C/A code at L1 freq.
L1(C1) = C/A-based phase at L1 freq.
P1 = Y1-codeless pseudorange at L1 freq.
L1(P1) = Y1-codeless-based phase at L1 freq.
P2 = Y2-codeless pseudorange at L2 freq.
L2(P2) = Y2-codeless-based phase at L2 freq.
The first 2 observables (C1, L1(C1)) correspond to the same quantities
measured by the TurboRogues, but the others are not quite the same.
Because it would be confusing to report two different L1 phase values
(L1(C1), L1(P1)) in RINEX observation files, the one based on the higher
SNR C/A-code is usually preferred. It should be noted however that the
current default offload in Conan Binary, Conan ASCII, or RINEX format
from the AOA BenchMark receiver provides L1(P1) instead of L1(C1), and
does not provide C1.
We denote these as non-CC receiver and observable types.
Since phase is inherently ambiguous and according to specifications
(L1(C1)-L1(P1)) is a constant fraction of a carrier wavelength, the
distinction between L2' in TurboRogues and L2(P2) in these receivers is
not significant. However, the difference between the CC pseudorange
pair (C1, P2') and the non-CC pseudorange pair (P1, P2) can be
important for some applications, since the (C1-P1) pseudorange
difference varies between satellites and can reach up to 2 ns (0.6 m).
Biased Pseudoranges and Their Consequences
The (C1-P1) pseudoranges from non-CC receivers are not zero-mean, but
are biased up to ~ 2ns (see Appendix). The biases vary from satellite
to satellite but tend to be relatively stable in time. These effects
can be readily seen in data from modern receivers that output both L1
pseudorange observables. (Note that most CC type receivers also output
both L1 observables under non-AS conditions.) Using the non-CC (P1, P2)
pseudorange pair is not consistent and will be biased with respect to
the CC pair (C1, P2') by (C1-P1) at both frequencies. Hence, the
ionosphere-free pseudoranges will also be biased by (C1-P1), which will
go directly into clock estimates. Note that since the biases change
from satelite to satellite (unlike for phase observables) they will not
be eliminated by double differencing.
If CC and standard non-CC pseudorange data are mixed, then estimates
for the satellite clocks will be corrupted in a way that depends on the
mix of receiver types and their geometric distribution. Considering
that the IGS clock products have a precision at about 0.2 ns, this is
highly undesirable. Point positioning using non-CC data and IGS/AS
products that are based on CC-type data will also be correspondingly
On the other hand, data analyses which use only carrier phase observables,
and therefore have no sensitivity to the absolute values of the satellite
clocks, are not affected by these pseudorange biases. Pseudorange
ionospheric estimates, whether based on (P2'-C1) for CC receivers or on
(P2-P1) for non-CC receivers, are also unaffected.
Recommendations for Station Operators
For the time being, we strongly recommend RINEX translation procedures for
non-CC receivers that provide sufficient pseudorange observables in order to
allow CC-type pseudorange observables to be synthesized by the user. This
will permit consistency within the IGS network to be preserved until the
heritage core of TR receivers is largely replaced.
Specifically, station operators using modern non-CC receivers are asked to
ensure that the C1 observable, if available, is reported in their RINEX
files together with the P1 and P2 observables. This will allow RINEX
users to form the synthetic observable
P2' = C1 + (P2-P1)
UNAVCO has kindly provided modifications to their `teqc' toolkit to support
this need for certain receiver types; for further information please refer
to http://www.unavco.ucar.edu/software/teqc/. Options for using teqc for
particular non-CC receivers are given below.
AOA Benchmark & Upgraded TR
Data must be downloaded from the receiver in TurboBinary format. An
offload of data in Conan Binary format from the BenchMark receiver
will contain only the 4 observables P1, L1(P1), P2, L2(P2). The offload
in TurboBinary however provides all six non-CC observables described
above. (Note that the Turbo Binary files will be almost three times
larger in size than the commensurate Conan Binary files.) Then the
appropriate teqc option is
teqc -aoa tbY - O.obs L1L2C1P2P1S1S2
where S1 and S2 are recommended to provide full-precision SNR values
as additional observables; other suitable teqc options should also be
included, normally in a configuration file. The output RINEX files
should then contain the C1, P1, L1, P2, and L2 observables, as well
as the SNR values. For the "-aoa" options, teqc already adds the
appropriate comments to the RINEX header to indicate which observables
have been formed.
[actions needed for other receiver types ... still needs to be done]
The ASHTORIN translator provides all the necessary pseudorange data.
Of possible interest is the use of teqc to extract the L1(C1) phase
from either the Ashtech B-file (as also Werner Gurtner's ASRINEXO
translator does) or from an Ashtech MBEN/PBEN real-time data stream.
The teqc option to set is "+Ashtech_CA_L1". By default, teqc extracts
the L1(P1) phase as its RINEX "L1" value.
does not output C1 observable ...
Recommendations for IGS Central Bureau
Because the RINEX format contains no specific indicator of the precise
nature of the pseudorange observables reported (whether the CC-style P2'
or the non-CC P2 observables are used), data users must rely on the
"REC # / TYPE / VERS" RINEX header recorder together with knowledge of
the generic types of the various receivers available. This fact
underscores the vital importance of reliable RINEX headers, which the
IGS Central Bureau is asked to rigorously enforce.
In addition, it is necessary for the IGS Central Bureau, working with
receiver experts, to compile information characterizing all receiver
types as either CC or non-CC style. This information should be readily
available and specifically linked with the various "official" receiver
names used by the IGS.
A preliminary partial list of receiver types follows:
[needs work here to verify and complete!!!]
Cross-Correlation (CC) Style Receivers
ROGUE SNR-8* (when AS is on)
ROGUE SNR-12* (when AS is on)
Non-Cross-Correlation (non-CC) Style Receivers
AOA SNR-12 ACT
AOA BENCHMARK ACT
LEICA SR9500 (does not output C1 pseudorange)
LEICA CRS1000 (does not output C1 pseudorange)
Recommendations for Data Analysts
The IGS Analysis Center Coordinator should ensure that IGS products
are as consistent as possible with either CC or non-CC observables.
This information should be readily available to all IGS data and
For the time being, it is recommended that the IGS adopt CC-style
observables as a standard. Observables, biases, and analysis products
should be handled to ensure maximum consistency with this standard.
Specifically, those Analysis Centers which process pseudorange data
are strongly encouraged to: 1) Check their network mix and verify that
the data RINEX from non-CC receivers being used are consistent with the
recommendations above. 2) Use the (C1, P2') pseudorange pair, or the
equivalent, rather than the (P1, P2) pair in their analyses. The 2nd
recommendation can be accomplished in two possible ways:
a) Synthesize CC Style Observables
Use a utility to convert raw RINEX files to CC-style RINEX files by
synthesizing the P2' = C1 + (P2-P1) observable and using the C1
pseudorange rather than P1. Obviously, this is only possible if
the raw RINEX files hold all the necessary information.
A RINEX utility converter is available for ACs wishing to use this
option (ftp://maia.usno.navy.mil/pub/noncc2cc.f). When a RINEX
file is converted, the average (C1 - P1) bias values are printed
out by satellite PRN.
b) Apply Satellite-based Bias Correction
Alternatively, corrections for the satellite-based biases can be
applied based on empirical tabulations (such as have been compiled by
the JPL group; see Appendix). In this case, the (P1, P2) pseudorange
pair would be replaced by [P1 + f(i), P2 + f(i)], where f(i) is an
empirically-determined function that represents the average value of
(C1 - P1) as a function of GPS satellite PRNi. The Appendix describes
results from Ron Muellerschoen at JPL.
A disadvantage of the synthesis approach (a) is that additional noise is
introduced in forming the (C1, P2') pair that is not in the directly
observed (P1, P2) pair. If temporal variations in the f(i) biases are
small compared to the noise in the 30-s measurements of (C1 - P1), then
using f(i) would introduce less error (approach b). On the other hand,
if temporal variations in the f(i) biases are significant, then approach
a) yields smaller errors. Approach (b) could also be applied in reverse,
to convert CC-style observables to CC-type by subtracting f(i) from the
usual (C1, P2') pair; this would be useful when the IGS eventually
switches from a CC-based convention to non-CC.
As the IGS network continues to evolve these recommendations will be
reviewed and modified. In particular, the IGS Analysis Center
Coordinator may propose to end the CC-style standard and change to
non-CC observables when that seems appropriate.
Date: Wed, 14 Apr 1999 21:46:04 +0000
From: "Ronald J. Muellerschoen" <rjm @ cobra.jpl.nasa.gov>
Subject: Re: handling TR and non-TR data
<editted by J. Ray to add table headers>
I've been periodically computing global solutions for CA-P code bias since
Oct of 97 with a network of 14 to 15 Ashtech Z-12 receivers. The variation
over this period (in general) has been about 4-5 cm. The biggest
change was prn 7 when the bias changed from 20 cm sometime between 12/22/97
and 4/12/98. I hadn't looked at these biases until almost a year later
when I turned the process back on 3/18/99. The biggest change at this time
was 8 cm for prn13, 7 cm for prn31, 6 cm for prn29 and prn 18, 5 cm for prns
15, 30,17 while all others were less than 4 cm.
The below table are the results of hourly solutions of the CA-P code
bias for the last three weeks. Note in all this I am assuming that the CA-P
code bias at a particular station I have chosen is not changing. (To compute
the solution I fix the CA-P code bias at this station to a particular value. A
closer look at the values of CA-P code bias for the different prns all have
a similar signature, which would indicate that the CA-P code bias at my
reference station is not entirely stable.
Average (P1-C1) Biases over 3 weeks for 15 Ashtech Z-12 Receivers
(units are meters)
prn # average hi value low value spread var. of ave. numb.
------ ----------- --------- --------- --------- ------------- ------
prn 1 ave: -0.134 hi: -0.07 lw: -0.23 sp: 0.16 sigma: 0.030 n: 505
prn 2 ave: -0.378 hi: -0.31 lw: -0.45 sp: 0.14 sigma: 0.027 n: 505
prn 3 ave: -0.017 hi: 0.06 lw: -0.08 sp: 0.15 sigma: 0.029 n: 505
prn 4 ave: 0.358 hi: 0.43 lw: 0.29 sp: 0.14 sigma: 0.030 n: 505
prn 5 ave: -0.253 hi: -0.18 lw: -0.35 sp: 0.17 sigma: 0.030 n: 505
prn 6 ave: 0.099 hi: 0.17 lw: 0.03 sp: 0.14 sigma: 0.029 n: 505
prn 7 ave: -0.410 hi: -0.15 lw: -0.50 sp: 0.35 sigma: 0.060 n: 505
prn 8 ave: -0.324 hi: -0.23 lw: -0.40 sp: 0.16 sigma: 0.031 n: 505
prn 9 ave: 0.047 hi: 0.14 lw: -0.04 sp: 0.18 sigma: 0.035 n: 505
prn 10 ave: -0.588 hi: -0.52 lw: -0.65 sp: 0.13 sigma: 0.026 n: 505
prn 13 ave: 0.459 hi: 0.53 lw: 0.40 sp: 0.14 sigma: 0.029 n: 505
prn 14 ave: 0.057 hi: 0.14 lw: -0.03 sp: 0.17 sigma: 0.030 n: 505
prn 15 ave: -0.407 hi: -0.33 lw: -0.48 sp: 0.14 sigma: 0.028 n: 505
prn 16 ave: -0.290 hi: -0.22 lw: -0.36 sp: 0.14 sigma: 0.029 n: 505
prn 17 ave: -0.372 hi: -0.27 lw: -0.45 sp: 0.18 sigma: 0.037 n: 505
prn 18 ave: -0.038 hi: 0.03 lw: -0.12 sp: 0.15 sigma: 0.032 n: 505
prn 19 ave: 0.051 hi: 0.13 lw: -0.02 sp: 0.15 sigma: 0.032 n: 505
prn 21 ave: -0.171 hi: -0.10 lw: -0.24 sp: 0.14 sigma: 0.028 n: 505
prn 22 ave: -0.510 hi: -0.44 lw: -0.58 sp: 0.14 sigma: 0.029 n: 505
prn 23 ave: -0.206 hi: -0.14 lw: -0.27 sp: 0.13 sigma: 0.030 n: 505
prn 24 ave: 0.034 hi: 0.11 lw: -0.04 sp: 0.15 sigma: 0.029 n: 505
prn 25 ave: 0.176 hi: 0.28 lw: 0.09 sp: 0.19 sigma: 0.038 n: 505
prn 26 ave: 0.342 hi: 0.42 lw: 0.28 sp: 0.14 sigma: 0.027 n: 505
prn 27 ave: -0.067 hi: 0.02 lw: -0.16 sp: 0.17 sigma: 0.036 n: 505
prn 29 ave: 0.227 hi: 0.30 lw: 0.17 sp: 0.13 sigma: 0.029 n: 505
prn 30 ave: 0.470 hi: 0.53 lw: 0.40 sp: 0.14 sigma: 0.028 n: 505
prn 31 ave: -0.255 hi: -0.18 lw: -0.32 sp: 0.14 sigma: 0.029 n: 505
The "sp:" column (spread) is the hi value - low value, or the max variation of
the estimates over the 3 week time span. The "sigma:" column is the
variation of the estimates, n is the number of hourly solutions. Note
prn 7 is again anomalous with the largest variation.
My convention is, to convert P code data to CA code data, subtract the
above "ave:" value from range and phase. To convert back,
(CA to P code) add the above "ave:" value. The widelane observable of
course remains unchanged.
[Mailed From: Jim Ray (USNO 202-762-1444) <jimr @ maia.usno.navy.mil>]