search

geospace-code / georinex

Python RINEX 2 / 3 NAV / OBS / sp3 reader & batch convert to HDF5 with C-like speed
MIT License
216 stars 89 forks source link

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

Closed Julie-TLS closed 2 years ago

Julie-TLS commented 3 years ago

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 commented 3 years ago

Thanks for your example, I will look at this

JulieTls commented 3 years ago

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)