Rapid Static Positioning Using GPS and GLONASS
S. C. SCHAER 1, E. BROCKMANN 1, M. MEINDL 2, G. BEUTLER
Abstract
For rapid static positioning, the combined analysis of
all observed GNSS becomes more and more important
in view of the steadily increasing number of active
satellites (early in 2009 exceeding 50 GPS+GLONASS
satellites). Successful ambiguity fixing for all involved
GNSS is the key for this application. First results of an
implementation of a “GNSS-capable” LAMBDA
ambiguity resolution scheme into a project version of
the Bernese Software are presented.
1
Implementation of a “GNSS-capable”
LAMBDA ambiguity resolution scheme
The initiation of GLONASS ambiguity resolution on
an operational basis as part of the regional GNSS data
analysis procedures as accomplished at swisstopo’s
Permanent Network Analysis Center (PNAC) was an
important step towards the best possible use of GNSS
observation data [Schaer et al. 2007]. In particular for
(additionally generated) GLONASS-only solutions,
GLONASS-extended ambiguity fixing results in a clear
quality improvement. The evaluated GNSS ambiguity
resolution strategies of the Bernese Software are,
2
however, only applicable to static positioning with
observation time spans of, let us say, longer than one
hour.
For so-called rapid static positioning, with typical
observation time spans of maximally a few minutes,
the Bernese Software Version 5.0 offers the “general
search” strategy for GPS ambiguity resolution [Dach et
al. 2007], a generalization of the Fast Ambiguity
Resolution Approach (FARA) developed by Frei
[1991]. The corresponding software realization does
not allow it to keep all involved GNSS ambiguity
parameters on the single-difference (SD) level,
however, a basic requirement we believe to be of
greatest importance for the success of correct
GLONASS ambiguity resolution strategies [Schaer et
al. 2007]. Therefore, we decided to develop a “GNSScapable” ambiguity resolution scheme using another,
well established integer ambiguity resolution method,
namely the LAMBDA (Least-squares AMBiguity
Decorrelation Adjustment) method as developed by
Teunissen [1995] and de Jonge and Tiberius [1996].
Figure 1 illustrates the three LAMBDA ambiguity
resolution schemes we implemented for test purposes.
Figure 1: Illustration of the implemented “GPS/GLONASS-capable” LAMBDA ambiguity resolution schemes for an
assumed observation scenario involving 4 GPS (G) and 2 GLONASS (R) satellites: separate LAMBDA resolution steps
1
Swiss Federal Office of Topography swisstopo, Geodesy Division, Seftigenstrasse 264, CH-3084 Wabern, Switzerland,
Phone: ++41 31 963 21 11, Fax: ++41 31 963 24 59, E-mail: stefan.schaer@swisstopo.ch, Web site: www.swisstopo.ch
2
Astronomical Institute of the University of Berne (AIUB), Sidlerstrasse 5, CH-3012 Bern, Switzerland
for GPS and subsequently GLONASS (top, called “GPS/GLONASS”); common LAMBDA resolution step with (middle,
called “mixed-GNSS”) and without (bottom, called “separate-GNSS”) intersystem double-difference ambiguity fixing.
A dual-frequency observation scenario is assumed with
4 GPS and 2 GLONASS satellites. For this particular
observation scenario a total of 12 single-difference
ambiguity parameters have to be dealt with. The
following two principles are common to all illustrated
ambiguity resolution schemes:
–
–
A set (or subset) of single-difference ambiguity
parameters is examined by the LAMBDA method
(on the basis of the real-valued estimates and their
complete variance-covariance information coming
from an initially computed ambiguity-float leastsquares parameter adjustment). Each examined set
is identified by a solid bar in Figure 1.
Properly selected differences of LAMBDAproposed SD integers are fixed (finally resulting in
an integer ambiguity fixing on the doubledifference level). These differences are identified
by horizontal squared brackets in Figure 1.
Obviously, we apply the LAMBDA method to SD
information, not to double-difference (DD) information
as it is traditionally done (and this is correct in the
GPS-only case). Ambiguity fixing, however, is
furthermore done on the level of double differences.
The implementation scheme in Figure 1 (top) includes
two separate LAMBDA ambiguity resolution steps:
one applied to the GPS-related ambiguity parameters
and one to the GLONASS-related ambiguity
parameters. An extra inversion of the remaining, thus
“GPS-ambiguity-fixed” normal equation matrix is
performed to achieve an improvement of the formal
errors of the internally built GLONASS DD ambiguity
estimates. Consequently, GPS may be seen as the
master observation system for the first implementation
scheme. We denote it in the following with
“GPS/GLONASS.”
The two other implementation schemes include just
one common LAMBDA ambiguity resolution step for
both GNSS observation systems, where all appearing
SD ambiguity parameters are examined at one time by
the LAMBDA method. The decisive point is that the
second implementation scheme in Figure 1 (middle)
does explicitly include integer fixing of intersystem
ambiguity parameters (between GPS and GLONASS),
whereas the third scheme (shown at the bottom of
Figure 1) does not include this feature. Following this
basic difference, we simply use “mixed-GNSS” and
“separate-GNSS” to label the second and the third
implementation scheme.
Let us now explain why we treat all involved GNSS
ambiguity parameters on the SD, not on the DD level:
For GLONASS ambiguity resolution, different
frequencies and consequently different carrier
wavelengths between pairs of satellites are crucial. The
bias introduced in the difference of two SD ambiguities
is proportional to the initialization bias of the involved
Page 2
SD ambiguities and, moreover, proportional to the
frequency difference between the pairs of satellites
considered. According to [Habrich 1999], GLONASS
SD ambiguity parameters have to be initialized with an
uncertainty of better than 285 cycles to keep the singledifference bias term below 0.1 cycles (more precisely
for a frequency channel difference i–j of 1). This basic
requirement is illustrated by Figure 2.
We conclude that manipulation of GNSS (particularly
GLONASS) ambiguity parameters on the DD level is
dangerous, if not forbidden (due to the initialization
uncertainty). It should be mentioned that we impose an
a priori constraint (of nominally 200 meters) on each
SD ambiguity parameter in order to avoid singularities
(to be expected for the ambiguity-float solution). After
successful GLONASS ambiguity fixing, all remaining
GNSS SD ambiguity parameters finally become
regular (actually determined) in the reduced normal
equation matrix. They directly reflect the occurring,
initially hidden SD ambiguity initialization bias values
with a comparably small formal uncertainty (typically a
fraction of a cycle). Note that these bias values depend
on the receiver clock synchronization and therefore are
de facto a function of the GNSS pseudorange biases.
In this context, it is worth to specify the total number
of remaining GNSS SD ambiguity parameters to be
expected for the computation of the ambiguity-fixed
solution: namely four for the “GPS/GLONASS,” two
for the “mixed-GNSS,” and again four for the
“separate-GNSS” ambiguity resolution scheme, or
generally speaking, the initial number of SD ambiguity
parameters minus the total number of fixed integers (in
agreement with the illustration in Figure 1). To be
more precise, two SD ambiguity parameters (one
parameter per frequency) finally absorb potentially
significant, non-negligible biases concerning SD
ambiguity initialization (see Figure 2) and the two
Figure 2: Illustration of the single-difference (SD)
ambiguity bias term, as introduced in [Habrich 1999],
to be proportional to the single-difference ambiguity
initialization bias (and proportional to the GLONASS
frequency channel difference i–j).
For implementation into a project version of the
Bernese Software Version 5.0, we used specifically the
“LAMBDA4” Fortran-coded module (implying “direct
computation of ZT”) as provided by the Delft
University of Technology [de Jonge and Tiberius
1996]. Nevertheless, it should be possible to adapt the
main principles and results discussed in this paper to
any ambiguity resolution method suited for rapid static
positioning. This includes also the “general search”
method as previously addressed.
2
Test data set and processing options
The baseline we considered for testing is shown in
Figure 3, including details of the AGNES GNSS
receiver network of Switzerland—which was enhanced
from GPS to GNSS mid of 2007 [Ineichen et al. 2007].
It connects the Trimble NetR5 receivers (each
associated with a Trimble Zephyr GNSS Geodetic II
antenna) at ZIM2 (Zimmerwald) and HUTT (Huttwil).
With a length of approximately 41 km, the selected
baseline is relatively long for a “rapid-static” baseline.
By this intended circumstance, additional requirements
in terms of adequate modeling of the anticipated
ionosphere delays are created (described below).
information produced by CODE was used in
conjunction with stochastic ionosphere parameters
(SIPs) set up for each epoch and each GNSS satellite
involved, imposing elevation-dependent a priori
constraints of nominally 1 cm SD delay on L1 phase at
zenith. No troposphere zenith path delay (ZPD)
parameters were estimated because of the short
observation sessions. We just relied on a standard
troposphere model.
3
Discussion of the results
3.1 Baseline vector repeatability
Figure 4 shows a particular time series of the ZIM2HUTT baseline vector computed on the basis of fiveminute
GPS/GLONASS
observation
periods
consecutively selected over the specified 24-hour
period (September 27, 2008). The results shown in
Figure 4 (and in the next two figures) are generally
referred to an elevation mask angle of 15º. They may
be accepted as evidence that the first introduced
“GPS/GLONASS” LAMBDA ambiguity resolution
scheme, adopted in this case, is working properly.
We used the corresponding daily RINEX observation
files for September 27, 2008 (containing data sampled
at intervals of 30 seconds). An automated processing
procedure was set up using the Bernese Processing
Engine (BPE) and the ambiguity-fixed baseline vector
was computed for
–
288 consecutive observation periods, covering five
minutes (eleven epochs) each,
–
elevation mask angles of 3º, 5º, 10º, 15º, etc.
–
the three introduced GNSS LAMBDA resolution
schemes (using GPS and GLONASS)—plus a
LAMBDA-based reference solution using GPS
observation data only.
Figure 3: Detail of the AGNES GNSS receiver network.
The indicated baseline connecting the Trimble NetR5
receivers at ZIM2 (Zimmerwald) and HUTT (Huttwil)
was considered for validation of the GNSS-capable
LAMBDA ambiguity resolution implementation.
The GPS-only reference solutions were also computed
in complete accordance with our GNSS LAMBDA
implementation (basically relying on a SD-level
ambiguity parameter treatment).
We used the consistent orbit information of the final
orbit product of the GNSS analysis product line
generated of the Center for Orbit Determination in
Europe (CODE) for the International GNSS Service
(IGS) [Dach et al. 2009]. Furthermore, we adopted an
elevation-dependent observation weighting to the phase
data. The weighting function is a reciprocal sine
function, 1/sin(e)2, and assumed to be identical for the
two frequencies and the two GNSS systems. For
ionosphere modeling, global ionosphere map (GIM)
Page 3
In Figure 4 (bottom) we included the difference of a
ZIM2-HUTT ZPD reference signal (as extracted from
swisstopo’s regular AGNES daily processing results
and moreover multiplied by a factor of 3). The high
correlation between the Up component residual signal
and the ZPD reference signal shows the effect of the
neglected differential troposphere variations in the
rapid static positioning. Nevertheless, we emphasize
again that the estimation of ZPD troposphere
parameters for rapid static positioning (and accordingly
for very short observation sessions) would be
inappropriate, if not counterproductive.
The ZIM2-HUTT baseline vector repeatabilities were
computed for the GPS-only case and for different
GPS/GLONASS-combined cases, performing the
“GPS/GLONASS” and the “mixed-GNSS” LAMBDA
implementation. They are evaluated statistically in
Figure 5. The standard deviation values turned out to
be minimal for the “GPS/GLONASS” case,
consistently for all three components. Compared to the
GPS-only case, the improvement may reach values up
to 15%. The latter value is, by the way, relatively
consistent to the value reported by Ineichen et al.
[2008], where the quality of GPS-only and GNSS
kinematic positioning results was compared.
GPS/GLONASS analysis, respectively. These values
must be considered as rather hypothetical in view of
the circumstance that accurately known ZPD
troposphere estimates are in practice hardly available
(in particular for rapid static positioning). The general
results of Figure 5, however, remain unchanged by
these “troposphere-reduced” values.
Figure 6 shows the total number of observed GNSS
satellites as a function of time using an elevation mask
angle of 15º (generally used in this subsection). The
number of available GPS satellites varies between 5
and 10, that of GLONASS between 1 and 6. The total
number of observed GNSS satellites did never fall
below 8 and reached occasionally 14. Note that these
numbers are valid for September 27, 2008, a day for
which a total of 32 GPS plus 14 GLONASS active
satellites is made available in CODE’s GNSS orbit
product line. It should also be noted that the tracking
data of one particular GLONASS satellite (R09) is
commonly considered as unsuitable and therefore
excluded from POD at CODE.
16
14
12
Standard deviation (mm)
Figure 4: ZIM2-HUTT baseline vector repeatability on
the basis of GPS/GLONASS observation data collected
on September 27, 2008, computed for 288 consecutive
five-minute observation spans (using elevation mask
angle of 15º). The bottom subfigure showing the Up
component includes the difference of the ZIM2-HUTT
ZPD reference signal (multiplied by a factor of 3).
10
8
6
4
2
0
The assessment of the performance for the two
“GNSS” special cases, “mixed-GNSS” and “separateGNSS,” is interesting. Whereas the “separate-GNSS”
case did not reveal any difference with respect to the
“GPS/GLONASS” case (this case is therefore not
explicitly shown in Figure 5), we observed a
significantly degraded quality of the “mixed-GNSS”
case, which, for the East component, turned out to be
even worse than that of the GPS-only case. This
degradation in quality is a clear indication that
intersystem DD ambiguity parameters are definitely
not of an integer nature. We conclude that no attempt
should be made to resolve GPS–GLONASS DD
ambiguities to integers [Schaer et al. 2007].
In the context of GPS–GLONASS phase biases, it is a
must to specify that we generally assume that the
variability of these biases has to be on a level
comparable to the phase measurement noise. Schaer et
al. [2007] give examples (considering an old GNSS
receiver model) where this essential assumption is
occasionally not met.
For the sake of completeness, we give the reduction for
the standard deviation of the Up component when daily
processed ZPD troposphere estimates (as indicated at
the bottom of Figure 4) were taken into account. We
obtained 8.9 mm for the GPS-only and 7.8 mm for the
Page 4
North
East
Up
GPS-only
6.1
4.5
14.1
GPS/GLONASS
5.2
4.3
12.8
Mixed-GNSS
5.9
4.8
13.3
Figure 5: Statistics of ZIM2-HUTT baseline vector
repeatability results, for September 27, 2008 (elevation
mask angle: 15º). GPS-only, “GPS/GLONASS,” and
“mixed-GNSS” (with intersystem DD ambiguity fixing)
results are compared.
Figure 6: Number of GNSS satellites as observed on
the ZIM2-HUTT baseline during consecutive fiveminute observation spans, for September 27, 2008
(elevation mask angle: 15º). Dashed lines indicate the
daily mean numbers for each GNSS system.
3.2
Availability analysis based on maximum
elevation mask angle
The elevation mask angle was mentioned in Section 2
as an important processing option. It is used here to
simulate a gradually increasing restricted satellite
visibility. We checked the gathered analysis parameters
for each GNSS LAMBDA evaluation (at intervals of
5º) in order to find the maximum elevation mask angle,
where a particular GNSS LAMBDA evaluation was
just able to provide a correct and adequately accurate
baseline vector determination. The following analysis
parameters were consulted to check whether a
particular solution is acceptable or not: the root-meansquare (rms) error of unit weight of the final leastsquares parameter adjustment, the absolute deviation
(from a long-term average) and the formal accuracy for
each of the three components.
Figure 7 shows the accumulated maximum elevation
mask angle values as a function of time for two cases:
GPS-only and GPS/GLONASS LAMBDA ambiguity
resolution. The circles plotted, indicating the
enhancement from GPS-only to GPS/GLONASS, are
evidence of the advantage of the “GPS/GLONASS”
LAMBDA application. It is really remarkable that the
GPS/GLONASS case is in no case inferior to the GPSonly case (the resulting enhancement is always
positive). In the GPS/GLONASS application, we were
able to produce adequate baseline vectors several times
using an elevation mask angle of up to 55º. The daily
mean values for the assessed maximum elevation mask
angle (sufficient to get a successful GNSS LAMBDA
solution) were found to be 32.8º (GPS-only) and 37.7º
(GPS/GLONASS). This corresponds, statistically
speaking, to an average availability improvement of
around 5º (at that time the GNSS constellation,
consisting of simply 32+14=46 satellites, was far from
being complete). Note that the addressed daily mean
values are indicated with dashed lines in Figure 7.
Figure 7: Maximum elevation mask angle with
successful GPS-only and “GPS/GLONASS” LAMBDA
ambiguity resolution, respectively, as determined for
the ZIM2-HUTT baseline, for September 27, 2008.
Dashed lines indicate daily mean values.
The total number of observed GPS (not GPS+
GLONASS) satellites above the maximum elevation
mask angle (see Figure 7) is shown in Figure 8,
underlying again the clear advantage of the
GPS/GLONASS-combined application. In the GPSonly case, the minimally accepted number of satellites
is sporadically at the level of 4 (conforming to the
theoretical minimum number), in the majority of cases
at 5, and, on the average, at a level of about 5.4 GPS
satellites. In contrast to the GPS-only case, the
GPS/GLONASS application is able to provide
adequate GNSS LAMBDA solutions on the basis of,
sometimes only 3 GPS satellites, relatively often 4,
and, on the average, about 4.6 GPS satellites. Although
the GLONASS constellation was accessible through a
comparably small number of active satellites at that
time, we may draw the conclusion that making use of
the GLONASS observation system in a consistent way
is strongly advisable to significantly improve the
solution availability and reliability for rapid static
positioning.
The latter statement, however, can only be justified, if
the required GPS/GLONASS ambiguity resolution
process is performed in a proper form. If, e.g., GPS–
GLONASS intersystem ambiguity parameters are
included in the ambiguity resolution process, the
situation may be judged differently. The lack of the
“mixed-GNSS” LAMBDA method is obvious in
Figure 9, where the enhancement concerning maximum
elevation mask angle is compared for the two
previously introduced “GNSS” cases with respect to
the reference values of the “GPS/GLONASS”
LAMBDA ambiguity resolution (shown in Figure 7).
As opposed to the “separate-GNSS” case, where the
resulting availability values are practically identical to
the “GPS/GLONASS” reference values, the “mixedGNSS” case turned out to be unacceptable.
Page 5
unjustified, arbitrary integer resolution of intersystem
phase biases. It should be emphasized that all these
schemes may be easily adapted to schemes coping with
dual-frequency, or single-frequency ambiguity
parameters from multiple GNSS systems (involving
three or more GNSS systems). Concerning our
implementation, the following aspect is essential:
generally all GNSS ambiguity parameters are kept on
the level of single (not double) differences. Ambiguity
fixing, however, is rigorously done on the level of
double differences.
Figure 8: Number of observed GPS satellites above the
maximum elevation mask angle, as determined for the
ZIM2-HUTT baseline, for September 27, 2008. Dashed
lines indicate the daily mean numbers.
Figure 9: Enhancement concerning maximum elevation
mask angle for the “separate-GNSS” case (top) and
the “mixed-GNSS” case (bottom) compared to the
reference values of the “GPS/GLONASS” LAMBDA
ambiguity resolution (shown in Figure 7).
4
Summary and conclusions
We developed three different ambiguity resolution
schemes for adequately handling the GPS and
GLONASS ambiguity parameters in the “rapid static
positioning” mode (where a few minutes or less of data
are supposed). We used the well established LAMBDA
method for managing the ultimate task of ambiguity
resolution to integers. We denoted these LAMBDAbased ambiguity resolution schemes—as illustrated in
Figure 1—with: “GPS/GLONASS” (without), “mixedGNSS” (with), and “separate-GNSS” (again without
intersystem integer fixing). The scheme of “mixedGNSS” was added in anticipation of problems due to
Page 6
All our GNSS ambiguity resolution schemes were
implemented into a project version of the Bernese
Software (using the LAMBDA4 Fortran module).
Thereafter, a dedicated test procedure was set up for
validation on the basis of a RINEX daily data set, in
particular for September 27, 2008, and the baseline
connecting ZIM2 (Zimmerwald) and HUTT (Huttwil),
both occupied by a Trimble NetR5 receiver of the
AGNES GNSS receiver network of Switzerland. With
a length of approximately 41 km, the baseline is
relatively long, a circumstance asking for careful
modeling of the anticipated ionosphere delays (realized
by the additional estimation of tightly constrained
parameters absorbing these ionosphere delays).
We computed a set of ambiguity-fixed baseline vectors
by scanning (a) the time domain (at intervals of 5
minutes, (b) a varying elevation mask angle (at
intervals of 5º), and ultimately (c) four different
application cases: “GPS/GLONASS,” “mixed-GNSS,”
“separate-GNSS,” and in addition a consistently
handled GPS-only case, conforming to a LAMBDAbased reference solution without GLONASS
contribution. The dimension (a) was used to test the
operational reliability of each GNSS-capable
LAMBDA ambiguity resolution scheme, (b) to assess
the availability (the varying elevation mask angle was
used to simulate a gradually more and more restricted
satellite visibility), and finally the dimension (c) was
dedicated to assess the general performance of the
slightly differing GNSS ambiguity resolution schemes.
The repeatabilities obtained with the various time
series of baseline determinations clearly indicate that
the implemented GNSS-capable ambiguity resolution
scheme (relying on the LAMBDA method) may be
applied in the GPS-only as well as in the
“GPS/GLONASS” case. Furthermore, the performance
of the “GPS/GLONASS” application turned out to be
significantly better in terms of both baseline vector
accuracy and solution availability (compared to the
GPS-only case). The repeatability (standard deviation)
values specific to “GPS/GLONASS” could be reduced
by up to about 15%, a reduction rate that is consistent
to those reported by Ineichen et al. [2008] and Dach et
al. [2009] for ambiguity-fixed single-epoch solutions.
The improvement of the solution availability,
expressed by an increment in the elevation mask angle,
was assessed to be about 5º. This value, however, is
just a daily average (valid for a comparably poor ratio
of 32/14 GPS/GLONASS satellites). In extreme cases,
we were able to generate suitable “GPS/GLONASS”
LAMBDA solutions using elevation mask angles of up
to 55º. The solution availability is mainly a function of
the number of available (and actually observed) GNSS
satellites. The application “GPS/GLONASS” is in no
case inferior to that of GPS-only (the resulting
enhancement is always positive or equal to zero). This
is more than remarkable.
number of satellites), but crucial in case of a
severely restricted satellite visibility (with a total
number of observed satellites close to the
mathematically allowed minimum).
–
In the context of the previous item, the following
qualitative characteristic is essential—as long as
intersystem GPS–GLONASS double-difference
observation equations are built: such (obviously
existing) intersystem phase biases must be
constant roughly on the level of the phase
observation noise (over the observation period).
–
The auxiliary “separate-GNSS” LAMBDA scheme
generated nearly identical results to those of our
primary “GPS/GLONASS” scheme (both without
intersystem integer fixing).
–
Our development is transferable without restriction
to a more general “multi-GNSS” ambiguity
resolution scheme (consistently applicable to three
or more GNSS).
Let us finally highlight the basic findings of our dualGNSS (GPS/GLONASS) and single-GNSS (GPS)
LAMBDA-based ambiguity resolution experiments:
–
–
–
–
The performance of the dedicated application of
GPS and GLONASS (following our primary
“GPS/GLONASS” LAMBDA implementation
scheme) turned out to be significantly better in
terms of both baseline vector accuracy and
solution availability (compared to the consistently
executed application of GPS only). The use of
observation data of the GLONASS system is
extremely helpful, in particular under difficult
observation conditions (with restricted satellite
visibility). The performance improvements are
expected to become even more pronounced with
the expected decreasing ratio of GPS to
GLONASS satellites (thanks to the continuously
growing GLONASS constellation, but also due to
the potential drop in the number of healthy GPS
satellites caused by the delay in the Block IIF
program).
Handling of the GNSS ambiguity parameters on
the single-difference, not double-difference level is
considered to be of greatest importance for a
proper treatment of the GLONASS singledifference bias term, which is directly caused by
slightly different carrier frequencies for each
GLONASS satellite—and which is definitively
crucial when finally forming (double) differences
from GLONASS single-difference ambiguities
(see, e.g., [Habrich 1999], or [Schaer et al. 2007]).
This technicality is transferable to any other GNSS
ambiguity resolution strategy and therefore
generally adopted in the Bernese Software.
We successfully processed GNSS observation data
from diverse “receiver-mixed” baselines. These
(randomly accomplished) applications confirm that
our GNSS-capable ambiguity resolution scheme is
self-calibrating and, moreover, able to cope with
very significant GLONASS-relevant ambiguity
initialization bias values (of a few of hundreds of
cycles to be reckoned with in the case of a pair of
mixed receiver models). The same is true for
random tests with considerably shorter observation
time spans (with 30 seconds, or two epochs).
Intersystem GPS–GLONASS double-difference
phase biases should not be fixed to integers. The
assumption of the integer nature of these biases is
obviously not valid. The impact of ignoring this
fact is rather marginal in case of a good
observation scenario (with a relatively large
Strict resolution of all involved ambiguity parameters
to integers is not appropriate for rapid static positioning
using multiple GNSS (two or more GNSS). This,
however, is an assumption for the LAMBDA method.
Two of the three developed LAMBDA-based
ambiguity resolution schemes (namely “GPS/
GLONASS” and “separate-GNSS”) may actually be
regarded as a technically feasible bypass (avoiding
integer fixing of intersystem ambiguity parameters).
The use of (adequately downweighted) observations
from low elevation angles (as we recommend it) is
another strong argument for leaving the general rule of
fixing all involved ambiguity parameters. Our results
suggest that each ambiguity resolution method should
be extended to comply with the formulated
requirement. The “general search” ambiguity resolution
method (traditionally used in the ernese GPS
Software) might be easily extended in this direction.
References
Dach R., U. Hugentobler, P. Fridez, M. Meindl (Eds.)
(2007): Bernese GPS Software Version 5.0.
Documentation,
Astronomical
Institute,
University of Bern, January 2007.
Dach R., E. Brockmann, S. Schaer, G. Beutler, M.
Meindl, L. Prange, H. Bock, A. Jäggi, L. Ostini
(2009). GNSS Processing at CODE: Status
Report. Journal of Geodesy, 83, 353–365.
Frei E. (1991): Rapid Differential Positioning with the
Global Positioning System (GPS). Geodätischgeophysikalische Arbeiten in der Schweiz,
Volume 44.
Habrich H. (1999): Geodetic Applications of the
Global Navigation Satellite System (GLONASS)
and
of
GLONASS/GPS.
Ph.D.
thesis,
Astronomical Institute, University of Berne.
Ineichen D., E. Brockmann, S. Schaer (2007):
Enhancing the Swiss Permanent GPS Network
Page 7
(AGNES) for GLONASS. In: Torres, J.A. and H.
Hornik (Eds): Subcommision for the European
Reference Frame (EUREF), London, 2007.
Ineichen D., E. Brockmann, S. Schaer (2008):
Processing Combined GPS/GLONASS Data at
swisstopo’s Local Analysis Center. In: Torres,
J.A. and H. Hornik (Eds): Subcommision for the
European Reference Frame (EUREF), Brussels,
2008.
Jonge de P.J. and C.C.J.M. Tiberius (1996): The
LAMBDA method for integer ambiguity
estimation: implementation aspects. Publications
of the Delft Geodetic Computing Centre, LGR
Series, No. 12, August 1996.
Schaer S.C., E. Brockmann, D. Ineichen (2007):
Inclusion of GLONASS for EPN Analysis at
CODE/swisstopo. In: Torres, J.A. and H. Hornik
(Eds): Subcommision for the European Reference
Frame (EUREF), London, 2007.
Teunissen P.J.G. (1995): The least-squares ambiguity
decorrelation adjustment: a method for fast GPS
integer ambiguity estimation. Journal of Geodesy,
70, 65–82.
Page 8