Epoch ingestion error in GALILEO RINEX parsing

Orekit Python Wrapper usage
1

Good evening all,

I am fairly new to the use of Orekit and am unsure whether what I’m encountering is a general Orekit error or a Python wrapper error. I am currently attempting to use Orekit’s RinexNavigationParser to parse GALILEO navigation messages acquired from CDDIS before feeding them into some propagation algorithms. I was expecting a slight difference between the file itself and the extracted AbsoluteDate for time scale conversion. However, the AbsoluteDate’s extracted from each message are approximately 20 years into the future of each nav message’s epoch, e.g for ABPO00MDG_R_20213350000_01D_EN.rnx satellite ID E31, the epoch is 2021-11-30T23:30:00 at the first message but is ingested as 2041-07-16T23:29:42.000.

The code I am using to ingest the file and extract the appropriate GALILEO message is as copied below, inside a for loop not shown:

fp = os.path.join(sat_fp, file)
rnx_parser = navigation.RinexNavigationParser()
rnx_file = org.orekit.data.DataSource(fp)
parsed_rnx = rnx_parser.parse(rnx_file)
# Orekit raises an error if no data is found related to a given sat id
try:
    sat_data = parsed_rnx.getGalileoNavigationMessages(sat_id)
except orekit.JavaError:
    # Skip to next file if no data is found
    continue

The RINEX version in this case is 3.04, and I’ve tested 2022 and 2021 GALILEO data; both show the approx. 20-year jump. I’ve attached two example RNX files for reference from the CDDIS database.

ABPO00MDG_R_20213350000_01D_EN.rnx (950.9 KB)
ABPO00MDG_R_20223350000_01D_EN.rnx (968.5 KB)

I appreciate any insight you all may be able to offer, either if this is a Python wrapper error, an Orekit error, or if I am not performing the ingestion correctly.

I’m happy to provide any more information that may be missing from this initial post.

Thank you for your help!

2

EDIT : After much further investigation, I’ve determined that the dates extracted from the GALILEO navigation messages become accurate to their stated time if the week and second numbers are instead based on the GPS epoch instead of the GALILEO epoch. The Orekit source code appears to correctly use the stated GALILEO epoch of 1999-08-22T00:00:00 GST, resulting in the exact time difference appearing in my results. I tested a backwards time shift of 7168 days and now the extracted times match the expected times. I have contacted CDDIS about this discrepancy, but I leave it to the Orekit dev team as to whether they would like to release a patch or await a response from CDDIS.

3

It seems to be a bug in Orekit.
Looking at RinexNavigationParser.parseFifthBroadcastOrbit, we create a GNSSDate using SatelliteSystem.GALILEO. However, looking at section 8.1 in Rinex 3.04 format, we see:

In order to remove possible misunderstandings and ambiguities, the Galileo
week reported in the RINEX navigation message files is a continuous number
without roll-over, i.e., ...4095,4096,4097,... and it is aligned to the GPS
week.

We missed the “aligned to the GPS week part”…

Could you file a bug report in the forge?

2 Likes
4

I have created issue 1009 and already have a fix for it. It will be published in a patch release soon.

1 Like
5

Great news! Appreciate the incredibly fast turnaround. Thank you for pointing out that section in the RNX format, I missed it as well. I retracted my report from CDDIS.

6

Thanks for the kind words.

I did not check if the problem is the same for observation files, but I guess it is.
Could someone have a look at this?