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

Wed Apr 10 06:08:34 PDT 2019

Hi

just to clarify the obvious wrong date does not cause any issue in the 
merging , its the other messages as previously indicated , please open 
svtl100b.19n , those messages appear innocent but have completely the 
wrong health flag. DCs and users have implemented systems to identify 
obvious wrong or mal-formed messages but correctly formed message with 
wrong or false data inside are very tricky . In this case the navigation 
message epochs are at 30 minutes past the hour which is always a red 
flag but that is not incorrect on its own. I agree that majority voting 
is a good thing but when there is only one message at a certain epoch? 
(as in this case) believe me that we have gone through this many times 
in the past and in extreme cases such as this one exclusion is the only 
logical step when we know the data is corrupt!

we have had black lists and maintain them for years.

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 13:22, Markus Bradke - GFZ wrote:
> Hi Nacho,
>
> I agree, that the station operators should do their best to provide 
> valid data.
> But, as you see and from our own experience, this is not always 
> possible. Especially if the files come directly from a receiver to the 
> DCs.
>
> I didn’t see the health flag issue. I only noticed that the navigation 
> files contain records from 1999.
> In our processing chain these files got neglected because the data 
> does not match with the filename.
>
> I would avoid maintaining black lists because you will always be a 
> step behind the provision of invalid data.
> We fixed that BRDC issue in our routine by using all records from all 
> navigation files provided for a day.
> That way we can select the majority records for all satellites from 
> the whole network and exclude minority corrupt data (e.g. from one 
> station).
>
> For tests, we could put that BRDC file on our FTP for you to validate.
>
> Best regards,
> Markus
>
> M.Eng. Markus Bradke
>
>
> Section 1.1 Space Geodetic Techniques
>
> Phone: +49 (0)331/288-1182
>
> Email: markus.bradke at gfz-potsdam.de <mailto:markus.bradke at gfz-potsdam.de>
>
>
> Helmholtz Centre Potsdam
>
> GFZ German Research Centre for Geosciences
>
> Foundation under public law of the federal state of Brandenburg
>
> Telegrafenberg, D-14473 Potsdam
>
> On 10. Apr 2019, 13:58 +0200, Nacho Romero 
> <nacho at canaryspaceconsulting.co.uk>, wrote:
>>
>> 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/7f9e3cd4/attachment-0001.html>