Subject: [IGLOSMAIL-736] IGS GLONASS tracking data
From: Stefan Schaer <[email-masked]>
To: igsmail <[email-masked]>, [email-masked]
Date: Thu, 08 May 2003 21:14:19 +0200

******************************************************************************
IGLOS Electronic Mail      08 May 12:14:22 PDT 2003   Message Number 736
******************************************************************************

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)