Clarification on GLUT week=0 handling in RINEX navigation writer

1

Hi all,

while working on a RINEX navigation aggregator based on Orekit 14.0‑SNAPSHOT, I noticed something with TIME SYSTEM CORR records for GLUT and I’m not sure if this is intended behaviour or just a small corner‑case artefact. I’d be grateful for your feedback.

Context

  • I parse RINEX 3.x navigation files with RinexNavigationParser.

  • I aggregate them and write a new RINEX navigation file using RinexNavigationWriter.

  • For sanity checks I compare my output against gfzrnx output for the same input files.

The difference appears in the TIME SYSTEM CORR header lines for GLUT.

Example:

     3.04           N: GNSS NAV DATA    M: MIXED            RINEX VERSION / TYPE
PRG-V1              Company             20251122 235942 UTC PGM / RUN BY / DATE
GLUT  0.0000000000D+00 0.000000000D+00      0    0          TIME SYSTEM CORR
    18    18  1929     7                                    LEAP SECONDS
                                                            END OF HEADER
E18 2024 03 21 08 20 00 4.597108927555e-04 4.318678747950e-11 0.000000000000e+00
     1.180000000000e+02-4.978125000000e+01 6.390980495705e-09-1.044630284062e+00
    -4.170462489128e-06 1.605720036896e-01 8.899718523026e-06 5.289336948395e+03
     3.756000000000e+05-8.381903171539e-07 2.297329000037e+00-2.555549144745e-06
     8.680081320685e-01 1.649687500000e+02 2.579802707961e+00-9.778978762289e-09
     1.013256491914e-09 2.580000000000e+02 2.306000000000e+03
     3.120000000000e+00 1.600000000000e+01-4.889443516731e-09 0.000000000000e+00
     3.763000000000e+05

This matches the RINEX 3.x / 4.x definition for GLONASS and time‑related fields T and W.

When I parse this file with Orekit and then write it back out via RinexNavigationWriter, the line becomes:

GLUT  0.0000000000e+00 0.000000000e+00      0 1024        0 TIME SYSTEM CORR

So the week number changes from 0 to 1024 on a round trip.

Numerically this still leads to the same correction (because a1 = 0), so from a timing perspective it’s harmless. However, from a RINEX/header perspective it feels somewhat unexpected that an input of 0 0 does not remain 0 0 when written back.

For comparison: in my tests, gfzrnx seems to treat a GLUT record as invalid or unusable and drops the GLUT line entirely in the merged/spliced output, regardless of the exact values of the other fields.

So my questions are:

  • Is the change of week number in TIME SYSTEM CORR GLUT (from 0 to a rolled value like 1024 when referenceDate == null) intentional, or is this more of a corner case?

  • Would it make sense to consider preserving the original T/W from the header for TIME SYSTEM CORR when no reference date is known, at least for types like GLUT/GLGP with a1 = 0 (i.e. constant corrections)?

If this is considered worth adjusting, I’d be happy to provide a small minimal example (RINEX nav file + Java snippet) and even draft a patch. If the current behaviour is intentional, I’d be glad to understand the reasoning so I can align my own aggregator accordingly.

Thanks a lot for your time and for Orekit!

h4x

2

This is most probably a bug.
There may even be two bugs and not only one because apart from the week number there is an additional 0 between the week number and the header label. This field corresponds to the satellite id, and it was blank in your input file so should most probably remain blank in the aggregated file.

Could you open a ticket on our issue tracker with the minimal example?

3

Thanks a lot for looking into this!

I’d be happy to open a ticket with a minimal example and even propose a fix. Unfortunately, my Forge account is still pending activation, so I can’t create an issue yet. I’ll do so as soon as that’s resolved.

Regarding the additional 0: I’m not fully convinced this is incorrect. My understanding is that the last integer field corresponds to the UTC ID, and 0 is a valid value meaning unknown. That said, after looking at the code, it’s not entirely clear whether this is intentional or just happens to work in this case.

h4x