[IGSMAIL-6898] Re: [IGS-IC-757] GLONASS Navigation message failure impact on IGS
Jake Griffiths - NOAA Federal
jake.griffiths at noaa.gov
Mon Apr 14 04:47:04 PDT 2014
Dear Nacho,
Thank you for putting this together! I have not yet looked at the obs data
myself, but I agree that the IGS GLO (IGL, IGV) products were not impacted.
Thanks again!
jake
On 4/12/2014 9:22 AM, Nacho Romero wrote:
> Author: Nacho Romero, Infrastructure Committee Chairman
>
> Last April 1st, 2014 (d091) the GLONASS (GLO) constellation suffered an event as
> the uploaded navigation messages had an incorrect applicability times, this has
> been reported in the trade press as you are well aware
> (http://www.insidegnss.com/node/3979,
> http://gpsworld.com/glonass-gone-then-back/,
> http://gpsworld.com/altus-positioning-systems-pinpoints-cause-for-glonass-default/)
> the constellation continued emmitting navigation signals but the navigation
> message was incorrect, so some navigation users were affected if the incorrect
> navigation messages were not ignored, this lasted until well into April 2nd (d092).
>
> I have taken the IGS data from the Data Centers (DCs) in Rinex 2 and Rinex 3 to
> analyze what the impact of the GLO problems has been on the IGS; on the data
> holdings, on the GLO constellation coverage, and on the IGS products.
>
> This is a thorough but not complete or conclusive look into this issue, but
> after more than a week since the event I wanted to report to the IGS community
> about it with some hard facts. If interested please contact me and we can plan
> a more detailed study if needed.
>
> -- SUMMARY --
>
> The conclusion is that the IGS was not affected; we have good amounts of GLO
> data over the period in the DCs and good GLO products.
>
> We continue to have enough data coverage for GLO, and regular product generation
> were not at all affected. Either the receivers ignored the incorrect navigation
> messages or were unaffected due to internal RAIMS checks. Thus the IGS network
> is stable due to its heterogeneity, as we have always advocated. This diversity
> of equipment in the network continues to ensure that we have a resilient IGS.
>
> This does not mean we did not have problems ... GLO coverage did suffer slightly
> (0-12 % per satellite on day 092; April 2nd) as can be seen from the Analysis
> Center processing reports for the Finals of last week, but we have so many
> stations providing data that it did not affect the GLO product generation. From
> those same Analysis reports it is clear that the availability of GPS
> observations was not affected.
>
>
> -- ANALYSIS --
>
> In any case it is still of interest to understand the impact over certain
> stations since some show some small effect.
>
> I have projected below the expected tracking down to 3 deg elevation of GLO
> satellite data from each MGEX station (using MGEX to ensure many IGS Glonass
> tracking stations), and then compared to the actual observations contained in
> the downloaded data files. The figures below report the percent of the 24 hr
> GLO constellation orbits covered, so ... for the entire GLO constellation over
> 24 hr what should a station see in theory down to 3 deg, versus what it actually
> observes! Many stations can track down to 0 deg so they have more observations
> than theorized to 3 deg but that is not significant in this analysis.
>
>
> Almost all stations performed fine over the event (d091-092), for example:
>
> GLO coverage Observed||Theoretical
> 14091.MGEX/NetworkQC_R.txt:For R; kour : 34.03 % 33.94 %
> 14092.MGEX/NetworkQC_R.txt:For R; kour : 32.73 % 34.16 %
> 14093.MGEX/NetworkQC_R.txt:For R; kour : 34.94 % 35.20 %
> 14094.MGEX/NetworkQC_R.txt:For R; kour : 32.73 % 34.46 %
>
> 14090.MGEX/NetworkQC_R.txt:For R; ous2 : 35.89 % 35.29 %
> 14091.MGEX/NetworkQC_R.txt:For R; ous2 : 35.98 % 35.81 %
> 14092.MGEX/NetworkQC_R.txt:For R; ous2 : 36.07 % 36.02 %
> 14093.MGEX/NetworkQC_R.txt:For R; ous2 : 35.81 % 35.98 %
> 14094.MGEX/NetworkQC_R.txt:For R; ous2 : 36.15 % 35.85 %
>
> 14090.MGEX/NetworkQC_R.txt:For R; brst : 35.59 % 36.76 %
> 14091.MGEX/NetworkQC_R.txt:For R; brst : 36.24 % 37.07 %
> 14092.MGEX/NetworkQC_R.txt:For R; brst : 35.37 % 36.76 %
> 14093.MGEX/NetworkQC_R.txt:For R; brst : 35.63 % 36.98 %
> 14094.MGEX/NetworkQC_R.txt:For R; brst : 34.98 % 36.37 %
>
> 14090.MGEX/NetworkQC_R.txt:For R; usn5 : 32.25 % 34.24 %
> 14091.MGEX/NetworkQC_R.txt:For R; usn5 : 31.60 % 33.90 %
> 14092.MGEX/NetworkQC_R.txt:For R; usn5 : 31.12 % 34.20 %
> 14093.MGEX/NetworkQC_R.txt:For R; usn5 : 31.03 % 33.46 %
> 14094.MGEX/NetworkQC_R.txt:For R; usn5 : 31.25 % 33.59 %
>
>
> Some stations lost a few percent of GLO data on d091/092, but after those days
> they recovered fine, for example:
>
> GLO coverage Observed||Theoretical
> 14090.MGEX/NetworkQC_R.txt:For R; scrz : 31.29 % 33.07 %
> 14091.MGEX/NetworkQC_R.txt:For R; scrz : 28.65 % 32.55 %
> 14092.MGEX/NetworkQC_R.txt:For R; scrz : 28.26 % 33.07 %
> 14093.MGEX/NetworkQC_R.txt:For R; scrz : 31.77 % 33.25 %
> 14094.MGEX/NetworkQC_R.txt:For R; scrz : 30.34 % 32.99 %
>
> 14090.MGEX/NetworkQC_R.txt:For R; hofn : 39.37 % 38.37 %
> 14091.MGEX/NetworkQC_R.txt:For R; hofn : 36.20 % 38.85 %
> 14092.MGEX/NetworkQC_R.txt:For R; hofn : 33.03 % 38.41 %
> 14093.MGEX/NetworkQC_R.txt:For R; hofn : 38.85 % 38.28 %
> 14094.MGEX/NetworkQC_R.txt:For R; hofn : 37.93 % 38.11 %
>
> 14090.MGEX/NetworkQC_R.txt:For R; thtg : 31.34 % 32.77 %
> 14091.MGEX/NetworkQC_R.txt:For R; thtg : 28.47 % 32.73 %
> 14092.MGEX/NetworkQC_R.txt:For R; thtg : 29.08 % 33.59 %
> 14093.MGEX/NetworkQC_R.txt:For R; thtg : 32.25 % 33.38 %
> 14094.MGEX/NetworkQC_R.txt:For R; thtg : 30.56 % 33.20 %
>
>
> No effect in the GPS tracking of the MGEX stations is detected even when the GLO
> tracking is reduced a few percent over the 24 hr period, so this is a very minor
> effect on the days of the event of very limited consequence taking everything
> into consideration.
>
> some stations over the affected days submitted partial Rinex files (zim2, pado,
> etc) but its unclear if the partial files are due to the GLO problem or not, so
> I have not considered that issue, since in any case all the files a day after
> the event are fine again.
>
> Thanks.
>
> --
> Best regards,
> Nacho
> _______________________________________________________________
>
> Ignacio (Nacho) Romero
> Aerospace Engineer, PhD
> SAC @ ESA/ESOC/HSO-GN
> IGS Infrastructure Committee
> www.canaryadvancedsolutions.com
> _______________________________________________________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo,
> puede contener informacion clasificada por su emisor como confidencial
> en el marco de su Sistema de Gestion de Seguridad de la
> Informacion siendo para uso exclusivo del destinatario, quedando
> prohibida su divulgacion copia o distribucion a terceros sin la
> autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
> erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
> Gracias por su colaboracion.
> _______________________________________________________________
> This message including any attachments may contain confidential
> information, according to our Information Security Management System,
> and intended solely for a specific individual to whom they are addressed.
> Any unauthorised copy, disclosure or distribution of this message
> is strictly forbidden. If you have received this transmission in error,
> please notify the sender immediately and delete it.
>
>
>
> _______________________________________________
> IGS-IC mailing list
> IGS-IC at igscb.jpl.nasa.gov
> http://igscb.jpl.nasa.gov/mailman/listinfo/igs-ic
>
More information about the IGSMail
mailing list