[IGSMAIL-4371]: IGS GLONASS tracking data
Stefan Schaer
stefan.schaer at aiub.unibe.ch
Thu May 8 12:14:19 PDT 2003
******************************************************************************
IGS Electronic Mail 08 May 12:14:22 PDT 2003 Message Number 4371
******************************************************************************
Author: Stefan Schaer
Dear IGS/IGLOS colleagues,
More or less one week ago, we started to consider IGS GLONASS tracking
data from GPS/GLONASS-combined receivers within the scope of the
- CODE rapid orbit determination process and the
- CODE rapid and final ionosphere analysis.
For all GPS/GLONASS analyses mentioned above, the most important aspect
is probably the fact that we perform one common GNSS data analysis in
each case, that is, we simultaneously solve for GPS- and GLONASS-
specific parameters. Consequently, we do not need additional processing
procedures.
The number of GNSS satellites currently considered is 39, namely 29 GPS
plus 10 GLONASS satellites. The active GLONASS satellites are R03, R05,
R07, R08, R17, R18, R21, R22, R23, R24, where R05 is a satellite of the
GLONASS-M modernization program.
The IGS GLONASS (IGLOS) tracking network forming the basis is shown at
http://igscb.jpl.nasa.gov/network/iglos.html
Except for KOU1 and STR2, all remote (or isolated) IGLOS stations seem
to regularly provide RINEX observation data. For a number of these
stations, data is available within 9 to 12 hours after observation. At
present, because of the increased IGLOS data latency, we use to execute
our rapid orbit analysis twice a day. This is a rather unpleasant
situation. But we hope that the IGLOS data availability can be improved
soon (see also second part of this mail).
It is worth mentioning that we already regularly send our rapid GNSS
orbit product to the IGS ACC for combination, where our GLONASS results
are filtered out. We thank Robert Weber for the implementation of
appropriate filters.
Our rapid orbit product, including precise orbit predictions, is made
available via the AIUB data archive at
http://www.aiub.unibe.ch/download/CODE/
ftp://ftp.unibe.ch/aiub/CODE/
CAUTION: The CODE GLONASS orbital information is still experimental
and therefore should be used only for test purposes!
Initially we modeled the GLONASS orbits with 1-day arcs (to be on the
safe side concerning the GPS orbits, so to speak). Meanwhile we
switched
over to a long-arc analysis as carried out for the GPS orbits.
No CODE GNSS SP3 files are sent to CDDIS. This is not true for the CODE
final IONEX submissions, which include now differential code bias (DCB)
values for the GLONASS satellite constellation and for GPS/GLONASS-
combined receivers, specifically with respect to their GLONASS system
component:
http://www.aiub.unibe.ch/download/CODE/P1P2.DCB
http://www.aiub.unibe.ch/download/CODE/P1P2_ALL.DCB
Finally, we may mention that the inclusion of GLONASS data in the CODE
final orbit analysis would now be actually a small step for us. Before
thinking about such a step, however, a few general issues must be
clarified first. One among these issues is whether GNSS SP3c orbit
files may be submitted (by an individual IGS analysis center) directly
to IGS (not IGLOS) data archives. To be precise, the latter issue does
not concern any IGS combined orbit product.
PROBLEMS CONCERNING IGLOS TRACKING DATA
---------------------------------------
We noticed several basic problems, which are primarily related to the
availability and the completeness of GLONASS (as well as GPS) tracking
data.
Problem 1: GPS/GLONASS-mixed RINEX observation files
----------------------------------------------------
Although we do not consider any extra IGLOS/IGEX data archives in our
data download procedures, we have access to nearly all IGLOS tracking
data. This is actually a very comfortable situation. There are,
however, some exceptions: LHAZ, REYZ, VS0G, WTZZ. We would like to
encourage the corresponding station managers to generally supply
"mixed" RINEX observation files.
Problem 2: IGLOS data latency
-----------------------------
In our first rapid orbit analysis automatically started at about 3 UT,
typically only DWH1, GOPE, UNB1, and ZIMJ are accessible in terms of
IGLOS data. GODZ, MTKA, THU2 data is not yet accessible at that time,
but does reach our data archive within the next 3 hours. Regularly
around 9 UT, another group of IGLOS stations, among them CONZ, DAVR,
DARR, HERT, MAT1, REYZ, OHI3, becomes available. As all these stations
must have an automated data delivery, we start from the assumption that
their data latency could be easily reduced. The same is probably also
valid for the stations IRKJ, KHAJ, KR0G, SUNM, data of which usually
becomes available within less than 24 hours after observation. Data of
LHAZ, MDVJ, NOVJ, YARR is unfortunately considerably delayed. It would
be desirable to shorten this delay at least to 2 days (making it
possible to consider the data as part of a final analysis).
Problem 3: Incomplete GPS/GLONASS tracking data
-----------------------------------------------
In order to verify the availability of tracking data to particular
PRNs, we wrote a simple Perl script that extracts corresponding charts
on the basis of RINEX observation (and navigation) files. Resulting
charts may be found at:
http://www.aiub.unibe.ch/download/igsdata/
There are three groups of files: gdata for GLONASS navigation data,
ndata for GPS navigation data, and odata for GPS/GLONASS observation
data. For odata, _gnss, _gps, and _glonass files are produced for
better reading. _day indicates files where the entries are sorted
according to the observation day, and _receiver indicates those files
where the charts are arranged in receiver-specific blocks. Note that
these charts are daily updated, considering all RINEX data (as
contained in our internal data base at CODE) over a sliding time
interval of 30 days. We copied a full set of such charts to
http://www.aiub.unibe.ch/download/igsdata/old/
for later referencing.
Let us point to the most striking data availability problems. When
browsing through
http://www.aiub.unibe.ch/download/igsdata/old/odata_gnss_receiver.txt
one may notice that SUNM and YARR have a serious problem concerning
GLONASS data recording. GODZ seems terrible concerning GPS. For
stations such as IRKJ, KHAJ, NOVJ, OS0G, SPT0, LHAZ, ZIMJ, one can
recognize that they suddenly stop to track particular GPS satellites
(like G27, or G30). Since exactly these PRNs were temporarily set
unhealthy (G27 on D112, G30 on D120), this misbehavior may be clearly
attributed to a Javad receiver problem. It is by the way interesting to
notice that the Blackjack receiver on board the SAC-C (SACC) LEO
satellite is affected by the same problem. Even that on board the CHAMP
(CHAM) satellite reveals a similar data availability problem.
At OS0G and SPT0, the GPS tracking problem seems to disappear. From
experience with ZIMJ, we know that a power cycle of the receiver can
solve the problem, at least until another PRN is set unhealthy. Anyway,
we have knowledge that one may expect quite soon some bug explanation
from the tracking expert of the Javad firmware team.
But single missing satellites is not just a Javad issue. Z18 receivers
show also tracking problems (e.g. R24):
http://www.aiub.unibe.ch/download/igsdata/old/odata_glonass_day.txt
It would probably be a good idea to come up with some "optimum" Javad
and Z18 receiver settings for continuous 30-second stations. Also,
although tracking problems might be different regardless of firmware,
one has to be aware of the fact that many Javad receivers are running
old or very old firmware.
We guess that the produced charts may also help to improve the
completeness of tracking data concerning GPS-only receivers. Two
examples: G27 is always missing in LHAS data, G31 in NRIL data.
Problem 4: "Unhealthy" GPS or GLONASS satellites
------------------------------------------------
A remarkable percentage of IGS/IGLOS receivers do not track, or report
data with respect to satellites that are marked unhealthy (by the
satellite system operator). For PRN G22, this is actually a permanent
condition. When looking at
http://www.aiub.unibe.ch/download/igsdata/old/odata_gps_receiver.txt
one may notice that a significant number of IGS/IGLOS receivers do not
record G22 observations. From our point of view, there is no plausible
reason why geodetic receivers should ignore tracking data to satellites
if they are marked unhealthy in their almanacs or ephemerides. For GPS,
this circumstance is not a real problem, since G22 or other satellites
temporarily marked unhealthy are still tracked by a relatively big
number of receivers. For GLONASS, however, where one has to rely on a
receiver network which is very sparse in some regions, that is an
unacceptable situation. The GLONASS orbit quality may be degraded for
particular satellites just because of a lack of IGLOS tracking data:
http://www.aiub.unibe.ch/download/igsdata/old/odata_glonass_day.txt
Whereas just R24 data seems to be rare on D125, the situation is really
alarming from D105 through D117 concerning R03 and R07, for example.
Because GNSS receivers now start to play a more and more supporting
role, it would be particularly important that they do record data
with respect to all active satellites (including "unhealthy"
satellites). Concerning Javad receivers, this is currently only the
case at DWH1 and OS0G. Z18 stations MAT1 and MTKA might know some
secret receiver setting which allowed (more or less successfully)
logging G22.
The charts
http://www.aiub.unibe.ch/download/igsdata/odata_glonass_day.txt
http://www.aiub.unibe.ch/download/igsdata/odata_gnss_day.txt
might help IGLOS station managers to check the GPS/GLONASS tracking
data availability of their stations. Additionally, the file
http://www.aiub.unibe.ch/download/CODE/P1P2.DCB
might be helpful as it summarizes the list of GNSS satellites that
were active during the last 30 days.
By the way, one may also find from time to time mysterious "dummy"
GLONASS satellites in observation and navigation files, like R04, R12,
or R31.
Problem 5: Concatenated IGLOS GLONASS navigation data
-----------------------------------------------------
To our knowledge, concatenated IGLOS GLONASS navigation files are
produced at CDDIS. The content of these files, which are named IGEX,
covers usually only a subset of active GLONASS satellites (compare,
e.g., with DWH1):
http://www.aiub.unibe.ch/download/igsdata/old/gdata_receiver.txt
Moreover, the latency of IGEX navigation files is several days.
Problem 6: Co-located IGS/IGLOS sites
-------------------------------------
GNSS data analysists principally interested in orbit, EOP,
troposphere, or ionosphere products will certainly no longer consider
GPS-only receivers from co-located IGS/IGLOS sites where a GNSS
receiver is operating. It is obvious that such a change can destroy
station coordinate time series, and that eventually maintenance of the
terrestrial reference frame (ITRF) is concerned. For latter reasons,
determination and monitoring of "inter-station" vectors would be
desirable (as part of densification projects).
Against this background, we think it would be important to formulate
IGS guidelines with regard to related issues.
For IGLOS receivers that are connected to the same antenna as the
IGS GPS-only receiver counterparts, alternation of the data source
should not be crucial. This is by the way the case for DAVR/DAV1,
OHI3/OHI2, THU2/THU3. At CODE, DAVR and OHI3 are already used for
datum definition, as DAV1 and OHI2 are officially addressed as IGS00
core stations.
That's all for the moment.
We are looking forward to an improving IGS GLONASS tracking data
availability and completeness. As soon as the IGLOS data allows us the
determination of not only some but all active GLONASS orbits with a
quality better than few decimeters, a notification will follow.
Many thanks to Doug Hogarth for his support and his helpful comments in
terms of GNSS tracking.
Best regards,
Stefan Schaer (on behalf of the CODE AC Team)
More information about the IGSMail
mailing list