Parsing rinex observation file, TIME OF FIRST OBS

Orekit usage
1

Hi,

I started to use Orekit (13.0.3) to read the rinex files of my garmin GPS. I mostly follow the GNSS tutorial to parse the observation file.

final RinexObservation obs = new RinexObservationParser().parse(observationData);
int listNum=0;
for(List<ObservationDataSet> oList2 : obs.bundleByDates()) {
   System.out.println("[("+(listNum++)+") size: <"+oList2.size()+">]");
}

but all lists are of size zero and the loop never stops. When I use RinexObservation.getObservationDataSets(), there are observation data as expected.

Second problem is about time: The header of my observation file says:

 2025     6     4     5    31   27.0000000     GPS         TIME OF FIRST OBS

(this corresponds to the time of the recording) but

System.out.println("[first obs: <" + obs.getHeader().getTFirstObs()+ ">]");

says:

[first obs: <2025-06-03T17:38:53.586895150001510016Z>]

I tried to initialize the AbsoluteDate whith the GPS-TimeScale, but the result stays the same. Do I need to convert the first obs time somehow?

Thanks in advance.

Kind regards
Thomas

2

This is weird, could you provide an example file?

The dates differences also does not make sense, it is almost a 12 hours differences. Note that upon reading the dates, there is a tricky logic. There are two header elements involved: TIME OF FIRST OBS and RCV CLOCK OFFS APPL which tells if dates are expressed in receiver time scale (which should always be the case for a Rinex file obtained directly from a receiver and not post-processed). The estimated receiver clock offset in seconds to apply is in fact provided alongside the measurements themselves, at the start of the each block. This is an optional field and set to zero if missing. So the logic is to first read the header as is, without any offsets, and when the first/last observations are parsed later on, depending on RCV CLOCK OFFS APPL, the offset is applied or not, so the parsed header is fixed.

Does your receiver writes a huge receiver clock offset in the observations dates and how is RCV CLOCK OFFS APPL set?

3

Thank you for your response.

… could you provide an example file …

The observation file is: grmn155f29.25O (1.3 MB)

I can’t find a RCV CLOCK OFFS APPL header field in the observation file.

4 
> 2025 06 04 05 31 27.0000000  0 27      42735.413104850712

The receiver clock offset is indeed very large!

What seems strange to me is its logic seems to be reversed with respect to other files I have dealt with. Indeed, this logic is tricky even in the specification. RCV CLOCK OFFS APPL is used to specify (and I quote the Rinex specification, section 5.2.14):

In order to remove uncertainties about whether the data (epoch,
pseudorange, phase) have been corrected or not by the reported
clock offset, use the header record RCV CLOCK OFFS APPL.

The default value to use if not present is 0, which means no. So we interpret this as : the dates have been timestamped by the receiver, and not corrected to be brought back to system time (no RCV CLOCK OFFS APPL, hence default value, hence no), so upon reading we should correct them ourselves. This is why we subtract this value. In your case, we end up almost 12 hours before.

I am not really sure about what to do here. I think our interpretation of the RCV CLOCK OFFS APPL is correct, but as many Rinex file indeed have a 0.0000000 offset for each record, we may have done it incorrectly. Your 42735.413104850712 offset seems however weird, could you check the configuration of your receiver?

The empty lists problem is due to another header element: INTERVAL, which is also missing in your file. This record is optional, but we do use it to compute the tolerance on dates when bundling them together with bundleByDates(). So this is a bug in Orekit, we should take care of the missing INTERVAL. Could you open an issue on the forge for this?

I was able to parse your file adding these two lines manually in the header:

     1.000                                                  INTERVAL
     1                                                      RCV CLOCK OFFS APPL
5

I will do this next weekend.

Yes, I will.

Thank you very much, this will help me so far.

6

Ich checked my Garmin today, the displayed time seems to be “correct” (does not deviate by 42000 sec).

The only Time related setting I can make is the timezone. It is set to “automatic”. I made a few consecutive recordings and got following first lines:

> 2025 06 14 12 47  2.0000000  0 14       -15367.361931548061
> 2025 06 14 13 03  9.0000000  0 10        -2200.476683198121
> 2025 06 14 13 14 54.0000000  0 12        95133.142648794688
> 2025 06 14 13 25 14.0000000  0 15         7030.133229710358
> 2025 06 14 13 30  7.0000000  0 14       -80092.555675917072
> 2025 06 14 13 53 53.0000000  0 11      -203346.218155889888