[IGS-DCWG-198] Re: exclude SVTL from merging navigation files

[Nacho Romero]

Hi Markus,

I have advised via IGSSTATION email, what else do you propose that we do?

several kinds of corruption may or may not affect the merging, in this 
case that I found this morning one station was causing GPS satellites to 
appear unhealthy. Is the GAL navigation issue also like this one?  I 
only found one station for the hours I checked this morning that had 
this GPS health flag problem as I only checked 19n files, but you are 
correct maybe there are more , please let me know ... we already manage 
an exclusion list for the navigation merging processes at different Data 
centers this is by no means the first or only time we have had issues 
with one (several) station corrupting the merging process.

The navigation messages from SVTL that have the incorrect health flag 
appear correct otherwise, do you have a way to detect and filter this 
message? ... because it appears correctly formed to our basic checks but 
we know is wrong! the sausage we make can only be as good as the meat we 
start with and demanding station produce good data is part of the 
agreement to join and international station network IMHO. The Data 
Centers can also improve their filters but we have to expect good 
practices on all sides ... clearly Javad may not have been aware of the 
extent of the roll-over issues in this case, but now it is station's 
responsibility to use the latest JPS2RIN as soon as possible since Javad 
have made a new version quickly available.

  167: nacho at mac03> more svtl100b.19n
      2.10           N:  GPS NAV DATA                        RINEX 
VERSION / TYPE
JPS2RIN V1.2.25     JAVAD GNSS          10-Apr-2019 01:59   PGM / RUN BY 
/ DATE
      .1118D-07   .1490D-07  -.5960D-07  -.5960D-07          ION ALPHA
      .8806D+05   .1638D+05  -.1966D+06  -.1311D+06          ION BETA
     -.372529029846D-08 -.621724893790D-14   503808        0 DELTA-UTC: 
A0,A1,T,W
     18                                                      LEAP SECONDS
                                                             END OF HEADER
...
  3 19  4 10  1 30  0.0  .188070960576D-03  .412114786741D-12 
.000000000000D+00
      .114000000000D+03  .260156250000D+01  .480591447134D-08 
.147100866651D+01
      .959262251854D-07  .197172485059D-02  .618025660515D-05 
.515354026185D+04
      .264600000000D+06 -.344589352608D-07 -.106015271312D+01 
.735744833946D-07
      .962385645534D+00  .259734375000D+03  .568300363374D+00 
-.819474912879D-08
      .105540110455D-09  .100000000000D+01  .204800000000D+04 
.000000000000D+00
      .115200000000D+04  .100000000000D+01  .232830643654D-08 
.114000000000D+03
      .264600000000D+06

Best regards,
Nacho
_______________________________________________________________

Ignacio (Nacho) Romero
Aerospace Engineer, PhD
CSC Ltd @ ESA/ESOC/OPS-GN
Satellite Navigation Engineer @ ESOC Navigation Support Office
IGS Infrastructure Committee Chair
www.navigation-office.esa.int
www.canaryspaceconsulting.co.uk
_______________________________________________________________
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.

On 10/04/2019 12:13, Markus Bradke wrote:
> 2. There are more stations in the network, that produce corrupt 
> navigation files for Galileo. This affects all Javad's with JPS2RIN 
> before version 2.0.168. So we should advice those operators to update 
> their JPS2RIN version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igs.org/pipermail/igs-dcwg/attachments/20190410/f0e0c42e/attachment.html>