GLONASS Epoch vs GPS Epoch

Hello all,

I’ve been working with the GNSS and GLONASS Orekit code for a while now, but have a question about the implementation of GLONASS and its time scale. The RINEX parsing code for GLONASS appears to construct a GNSS date based on the GPS system:

public void parseFirstLine(final String line, final ParseInfo pi) {
                // PRN
                pi.glonassNav.setPRN(parseInt(line, 1, 2));

                // Toc
                final int glonassTocYear  = parseInt(line, 4, 4);
                final int glonassTocMonth = parseInt(line, 9, 2);
                final int glonassTocDay   = parseInt(line, 12, 2);
                final int glonassTocHours = parseInt(line, 15, 2);
                final int glonassTocMin   = parseInt(line, 18, 2);
                final int glonassTocSec   = parseInt(line, 21, 2);
                final AbsoluteDate date = new AbsoluteDate(glonassTocYear, glonassTocMonth, glonassTocDay, glonassTocHours,
                                                           glonassTocMin, glonassTocSec, pi.timeScales.getUTC());

                // Build a GPS date
                final GNSSDate gpsEpoch = new GNSSDate(date, SatelliteSystem.GPS, pi.timeScales);

                // Toc rounded by 15 min in UTC
                final double secInWeek = FastMath.floor((0.001 * gpsEpoch.getMilliInWeek() + 450.0) / 900.0) * 900.0;
                final AbsoluteDate rounded = new GNSSDate(gpsEpoch.getWeekNumber(),
                                                          SatelliteSystem.GPS, // in Rinex files, week number is aligned to GPS week!


However, in the RINEX documentation, it is stated in section 8.1 that

GLONASS is basically running on UTC (or, more precisely, GLONASS system time linked to
UTC(SU)), i.e. the time tags are given in UTC and not GPS time. It is not a continuous time, i.e.
it introduces the same leap seconds as UTC. The reported GLONASS time has the same hours as
UTC and not UTC+3 h as the original GLONASS System Time!

I am somewhat confused as to whether Orekit is referencing the correct epoch/timescale while parsing GLONASS navigation messages. Comparison to other software becomes almost exact if I introduce the GPS 18-second offset to Orekit data, though normally I am inclined to trust the results of Orekit over that of other software. I appreciate any insight you all may be able to offer.

Thank you!

Hi Jonathan,

I am not sure our handling has been thoroughly tested for Glonass. We already proved we missed some parts in the Rinex specification :frowning:
If you have external hints that points to an error in Orekit, I think the error is really in Orekit.
Could you provide a patch fixing this?

I can try, although I’m afraid my coding expertise and style is not the best. I’m relatively sure it would simply be a matter of setting the date and time to those in “date” instead of to “rounded”, but I do not know if we would also need to modify the epoch TOC.

created issue 1033 for fix

EDIT: my attempt at a patch is in this merge request; I removed all GPS references and set the toc and date directly to that from the nav message, which should already be in UTC

Hi @Jon_Hood

The issue is fixed in 11.3.2 version that has be released yesterday.

I cherry picked the commit of your fix. That’s why your merge request was closed manually instead of automatically.

Thank you!

1 Like