<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi<br>
</p>
<p>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!<br>
</p>
<p>we have had black lists and maintain them for years.<br>
</p>
<pre class="moz-signature" cols="72">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
<a class="moz-txt-link-abbreviated" href="http://www.navigation-office.esa.int">www.navigation-office.esa.int</a>
<a class="moz-txt-link-abbreviated" href="http://www.canaryspaceconsulting.co.uk">www.canaryspaceconsulting.co.uk</a>
_______________________________________________________________
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.</pre>
<div class="moz-cite-prefix">On 10/04/2019 13:22, Markus Bradke -
GFZ wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8f117117-c8b8-4555-9f64-6d53ca5bafb0@Spark">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<div name="messageBodySection" style="font-size: 14px;
font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Hi
Nacho,
<div><br>
</div>
<div>I agree, that the station operators should do their best to
provide valid data.</div>
<div>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.</div>
<div><br>
</div>
<div>I didn’t see the health flag issue. I only noticed that the
navigation files contain records from 1999.</div>
<div>In our processing chain these files got neglected because
the data does not match with the filename.</div>
<div><br>
</div>
<div>I would avoid maintaining black lists because you will
always be a step behind the provision of invalid data.</div>
<div>We fixed that BRDC issue in our routine by using all
records from all navigation files provided for a day. </div>
<div>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).</div>
<div><br>
</div>
<div>For tests, we could put that BRDC file on our FTP for you
to validate.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Markus </div>
</div>
<div name="messageSignatureSection"><br>
<div class="matchFont">
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">M.Eng.
Markus Bradke</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); min-height: 16px;
font-size: 14px;"><br style="font-size: 14px; font-family:
-apple-system, BlinkMacSystemFont, sans-serif;">
</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Section
1.1 Space Geodetic Techniques</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Phone:
+49 (0)331/288-1182</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Email:
<a href="mailto:markus.bradke@gfz-potsdam.de"
style="font-size: 14px; font-family: -apple-system,
BlinkMacSystemFont, sans-serif;" moz-do-not-send="true">markus.bradke@gfz-potsdam.de</a></p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;"><br
style="font-size: 14px; font-family: -apple-system,
BlinkMacSystemFont, sans-serif;">
</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Helmholtz
Centre Potsdam</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">GFZ
German Research Centre for Geosciences</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Foundation
under public law of the federal state of Brandenburg</p>
<p style="margin: 0px; font-stretch: normal; line-height:
normal; font-family: -apple-system, BlinkMacSystemFont,
sans-serif; color: rgb(51, 51, 51); font-size: 14px;">Telegrafenberg,
D-14473 Potsdam</p>
</div>
</div>
<div name="messageReplySection" style="font-size: 14px;
font-family: -apple-system, BlinkMacSystemFont, sans-serif;">On
10. Apr 2019, 13:58 +0200, Nacho Romero
<a class="moz-txt-link-rfc2396E" href="mailto:nacho@canaryspaceconsulting.co.uk"><nacho@canaryspaceconsulting.co.uk></a>, wrote:<br>
<blockquote type="cite" style="margin: 5px 5px; padding-left:
10px; border-left: thin solid #1abc9c;">
<p>Hi Markus,<br>
</p>
<p>I have advised via IGSSTATION email, what else do you
propose that we do?</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>167: nacho@mac03> more svtl100b.19n<br>
2.10 N: GPS NAV DATA RINEX VERSION / TYPE<br>
JPS2RIN V1.2.25 JAVAD GNSS 10-Apr-2019 01:59 PGM / RUN BY /
DATE<br>
.1118D-07 .1490D-07 -.5960D-07 -.5960D-07 ION ALPHA<br>
.8806D+05 .1638D+05 -.1966D+06 -.1311D+06 ION BETA<br>
-.372529029846D-08 -.621724893790D-14 503808 0 DELTA-UTC:
A0,A1,T,W<br>
18 LEAP SECONDS<br>
END OF HEADER<br>
...<br>
3 19 4 10 1 30 0.0 .188070960576D-03 .412114786741D-12
.000000000000D+00<br>
.114000000000D+03 .260156250000D+01 .480591447134D-08
.147100866651D+01<br>
.959262251854D-07 .197172485059D-02 .618025660515D-05
.515354026185D+04<br>
.264600000000D+06 -.344589352608D-07 -.106015271312D+01
.735744833946D-07<br>
.962385645534D+00 .259734375000D+03 .568300363374D+00
-.819474912879D-08<br>
.105540110455D-09 .100000000000D+01 .204800000000D+04
.000000000000D+00<br>
.115200000000D+04 .100000000000D+01 .232830643654D-08
.114000000000D+03<br>
.264600000000D+06<br>
</p>
<pre class="moz-signature" cols="72">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
<a class="moz-txt-link-abbreviated" href="http://www.navigation-office.esa.int" moz-do-not-send="true">www.navigation-office.esa.int</a>
<a class="moz-txt-link-abbreviated" href="http://www.canaryspaceconsulting.co.uk" moz-do-not-send="true">www.canaryspaceconsulting.co.uk</a>
_______________________________________________________________
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.</pre>
<div class="moz-cite-prefix">On 10/04/2019 12:13, Markus
Bradke wrote:<br>
</div>
<blockquote type="cite"
cite="mid:de61c4c8-6c5b-c6cf-7b51-b7e14f7fe378@gfz-potsdam.de"
style="margin: 5px 5px; padding-left: 10px; border-left:
thin solid #e67e22;"><tt>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.</tt></blockquote>
</blockquote>
</div>
</blockquote>
</body>
</html>