Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not ignore spare data in rinex nav (galileo) #74

Closed
Julie-TLS opened this issue Apr 16, 2021 · 2 comments
Closed

Do not ignore spare data in rinex nav (galileo) #74

Julie-TLS opened this issue Apr 16, 2021 · 2 comments

Comments

@Julie-TLS
Copy link

The function georinex.load do not ignore spare data when present in at the end of line BROADCAST ORBIT 5, in GALILEO navigation message file.
To be precise, according to rinex format description (version 3.03 and 3.04) a spare number may be present (on not) at the end of line BROADCAST ORBIT 5 for GALILEO (see appendix A8 of rinex version 3.04 format description for details).
If this spare number is not present in line BROADCAST ORBIT 5 (as in the example below), there is no problem with georinex.load
E11 2020 01 01 06 40 00 6.013473612256E-04 1.637943114474E-10 1.734723475977E-18
8.800000000000E+01 2.596875000000E+01 2.966909297967E-09 1.276502874234E+00
1.277774572372E-06 2.205414930359E-04 3.168359398842E-06 5.440606166840E+03
2.832000000000E+05 4.284083843231E-08-8.928647209081E-01 2.980232238770E-08
9.863573386337E-01 2.843750000000E+02-3.297164660828E-01-5.711666485264E-09
1.614352958566E-10 5.170000000000E+02 2.086000000000E+03
3.120000000000E+00 0.000000000000E+00-1.559965312481E-08-1.676380634308E-08
2.838650000000E+05

Unfortunately, if a number is present at the spare position (as in the example below), georinex.load use the spare value
as SISA and all following parameters are false (health=SISA ...).
E11 2020 01 01 07 30 00 0.601838983130D-03 0.163822733157D-09 0.173472347598D-17
0.930000000000D+02 0.234687500000D+02 0.293655089056D-08 0.164439719097D+01
0.116601586342D-05 0.220070476644D-03 0.350549817085D-05 0.544060818291D+04
0.286200000000D+06 0.186264514923D-07-0.892882065265D+00 0.726431608200D-07
0.986357735085D+00 0.276812500000D+03-0.325682311484D+00-0.570595196152D-08
0.192508018732D-09 0.516000000000D+03 0.208600000000D+04 0.000000000000D+00
0.312000000000D+01 0.000000000000D+00-0.155996531248D-07-0.167638063431D-07
0.287254000000D+06 0.000000000000D+00 0.000000000000D+00 0.000000000000D+00

The results of georinex.load should be identical independently from the presence of the spare number and there values.

A file revealing this problem is here provided.

BRDC00IGN_R_20200010000_01D_MN.zip

Do not hesitate to contact me for further information. Thanks in advance

@scivision
Copy link
Member

Thanks for your example, I will look at this

@JulieTls
Copy link

JulieTls commented May 4, 2021

Thank you !
Waiting for the new georinex version, I've implemented a temporary patch to circumvent this issue.
The following pre-processing fills missing parse data with 0 before georinex.load :
with open(rinex_filename, 'r') as f:
rinex_content = f.read()
regex = re.compile("(E.{79}\n.{80}\n.{80}\n.{80}\n.{80}\n.{61})\n")
rinex_content_new = re.sub(regex, r"\1 0\n", rinex_content, re.MULTILINE)
f = open(new_rinex_filename, "w")
f.write(rinex_content_new)
f.close()
georinex.load(new_rinex_filename)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants