Ephemeris time and clock corrections in RINEX navigation files

Question

RINEX (Receiver INdependent EXchange format) is a set of file formats to distribute satellite navigation systems data, including GNSS. One of these standards, navigation files, provide positional information about satellites.

The standard differs for different satellite navigation systems, but can be broadly classified into two types: those providing state vectors as orbital elements, and those providing state vectors as Cartesian coordinates (in an ECEF frame). As representatives of each class, RINEX navigation files for GPS are of the orbital-element type, while those for GLONASS are of the Cartesian coordinates type.

I am currently trying to use the state vectors provided in such RINEX navigation files as the starting point for propagation with a high-precision numerical propagator. However, in order to perform such operation, I believe it is key to know exactly to what time instant the provided state vectors refer.

Multiple time parameters are provided in RINEX navigation files, as described for example here, and in a more interactive manner here for GPS files and here for GLONASS files.

My question is, from the different time parameters provided, how can we obtain the time to which the state vectors correspond as accurately as possible?

I am leaving below a summary of what I have managed to work out so far, split into GPS and GLONASS sections.

GPS

The format is described in Tables A3 and A4 of the appendix of this document, with an example in Table A8 of the same appendix.

The first line of each message contains fields for the Epoch year, month, day, hour, minute and second. However, I am unsure about the following points regarding such Epoch fields:

• In what time system are they exactly?
• Such Epoch fields refer to the time of transmission of the message, or to the time to which the provided state vector corresponds?

The header contains a set of parameters labeled as Delta-UTC, which seemingly can be used to "compute time in UTC", named A0, A1, Reference Time and Week Number. The formula for conversion seems to be, according to section 5.4.1 of this document and section 8.2 of this document:

$$ T_{UTC} = T_{SV} - af_0 - af_1 * (T_{SV} - T_{OC}) - A0 - Δt_{LS} $$

Where $T_{UTC}$ is time in UTC, $T_{SV}$ is "space vehicle time" and $T_{OC}$ is "satellite time of clock".

Regarding this, I am unsure about the following:

• What exactly are $T_{SV}$ and $T_{OC}$ ?
• Are the $af_0$ and $af_1$ parameters the clock bias and clock drift included in the first line of each message?
• Could the formula be expanded to include a quadratic term, something like $af_2 * (T_{SV} - T_{OC})^2$ , where $af_2$ would be the clock drift rate, also included in the first line of each message?
• The A1, Reference Time and Week Number parameters provided in the header do not seem to be used for calculation of UTC time. What is the purpose then of these parameters?
• What is the $Δt_{LS}$ parameter, and how can it be calculated?
• Does the above formula include relativistic corrections, which I assume should be introduced to obtain UTC time from the time reported by the internal clocks of satellites?

The messages also include fields for "Time of Ephemeris" (first field of the 4th line of messages) and "Transmission Time" (first field of the 8th line of messages), both in units of "seconds of GPS week".

• How are these parameters related to the Epoch fields reported in the 1st line of each message?

Finally, the 3rd field of the 6th line of messages is "GPS week number". I am inclined to thinking that this value might potentially be combined with the "Time of Ephemeris" field to obtain the epoch time for the reported ephemeris.

• Is this interpretation correct?
• If so, the resulting pair of GPS week number and seconds of current GPS week would need to be converted to UTC time. Can anybody point me to a source describing how to correctly do so?
• If converted to UTC time, how would the resulting time be different from the Epoch reported in the 1st line of each message?

GLONASS

The format is described in Tables A10 and A11 of the appendix of this document, with an example in Table A12 of the same appendix.

The situation for GLONASS messages seems to be a bit different. The header (which is valid for all included messages in the file, which can and in fact usually seem to come from different satellites in the constellation) contains a set of parameters labeled as "CORR TO SYSTEM TIME". These are:

• Year of reference
• Month of reference
• Day of reference
• System time correction

These parameters are described to be used to perform a "correction to system time scale to correct GLONASS system time to UTC", applying the formula described in section 5.4.2 of this document and section 8.2 of this document

$$ T_{UTC} = T_{SV} + Tau_N - Gamma_N*(T_{SV}-T_b) + Tau_C $$

The $Tau_N$ and $Gamma_N$ parameters seem to be provided in the first line of each message, and my guess is they are again some form of clock bias and clock drift. However, the following are still unclear to me:

• What exactly are $T_{SV}$, $T_b$ and $Tau_C$?
• The previously mentioned parameters provided in the header do not seem to be used for time conversion. What is the purpose of these then?
• The first line of each message, similar to GPS messages, contains Epoch year, month, day, hour, minute and second. What exactly is this Epoch? Is it the time of transmission of the message, the time at which the provided state vector is valid, or something else?
• Would relativistic corrections also be required to correctly obtain an UTC time?

Edit: I thought it would be a nice idea to keep track here of the clarifications we find for the different questions.

• @PM2Ring notes that the $Δt_{LS}$ parameter required to calculate UTC time from GPS time is the number of leap seconds introduced until the time of transmission of the message. Conveniently this is given in the header of RINEX GPS navigation files

Edit 2: I have left as another answer the procedure that I believe to be correct after clarifications provided by @NgPh

Answer 1

What exactly are $T_{SV}$ and $T_{OC}$ ?

The first is any time (e.g. the time the message was transmitted) expressed in the time system maintained by a particular satellite (Space Vehicle). The second is the reference time for the clock correction, expressed in the same time system. The correction is needed so that any time announced by any satellite can be converted to a common GPS time system (also called GPST). Hence, Eq. 2 of the GPS reference spec (IS-GPS-200M, page 95 - that you mentioned in comments above) allows a receiver to correct the clock errors in a particular SV, from the navigation data broadcast by this SV, to get to the common time reference. These broadcast data are computed by the GPS Operation Center and regularly updated by it. This explanation from the GPS specification (IS-GPS-200M, Section 20.3.3.3.3.1) is clearer:

---

---

Could the formula be expanded to include a quadratic term, something like $af_2 * (T_{SV} - T_{OC})^2$ , where $af_2$ would be the clock drift rate, also included in the first line of each message?

It could, as the field exists in the specifications. It is possible that this quadratic term is rarely used. Its non-zero value would mean that the on-board clock is drifting in frequency as well. Probably, they would switch to the spare atomic clock (unless both clocks suffer this).

Would relativistic corrections also be required to correctly obtain an UTC time?

I think the relativistic correction is application-dependent. For the purpose of localization, I believe you do not need UTC, just to synchronize 4 measured deltas of time to the same common reference of time (GPST).

• Formula in the RINEX document

The formula in the RINEX document, Section 5.4.1 (reproduced down here) is a bit puzzling.

---

---

It looks like it's an incomplete formula, with omitted terms replaced by "..." (suspension points that you didn't reproduce in your question). The GPS specification, Section 20.3.3.5.2.4 is much clearer. It reads:

---

---

So, A0 and A1 have a similar role as af0 and af1. Together with the leap seconds, they serve the purpose of correcting the drift of GPST with respect to UTC, in a similar fashion as af0, af1 (and af2 possibly) serve the purpose of correcting the drift of $T_{SV}$ with respect to GPST.

Note that the reference time to compute the correction term for $T_{UTC}$ is $T_{OT}$ (and not the reference $T_{OC}$ for the correction term for $T_{SV}$)

I haven't read the GLONASS specifications but I think all GNSS clock corrections (Galileo, Beidou,...) follow the same approach, with only differences in notations of terms. A good exercise would be to read the same sections in their specifications (I am too lazy for that!).

Answer 2

Thanks to @NgPh's very insightful explanation, I think I could finally figure out how to correctly perform clock corrections to UTC for GPS and GLONASS RINEX navigation files. I have now completed my own implementation, and I thought it might be a good idea to leave a summary of the process as I believe it to be correct here. Note that the described processes here refer to how to correct the time of ephemeris (to put it in plain words, the time at which the provided state vector of the satellite is valid).

GPS

There is 2 steps involved here: conversion of individual GPS satellite time to system-wide GPST, and conversion of GPST to UTC.

1. Retrieve $T_{OC}$, which as described in the IS-GPS-200M, Section 20.3.3.3.3.1, is the reference time for performing correction of individual GPS time to system-wide GPST. This is given by fields 2 to 7 (Epoch Year, Month, Day, Hour, Minute and Second) of the 1st line of each message (note: a single RINEX file contains a header and multiple messages), as described in table A4 here
2. Convert the retrieved $T_{OC}$ to GPS week and seconds of current GPS week, done by calculating to how many seconds since midnight between the 5th and 6th of January 1980 it corresponds. The resulting can be subjected to modulo 604800 to obtain seconds of current GPS week, and its integer division by 604800 will be the current GPS week (in continuous scale, i.e., not modulo 1024, which is anyway how GPS RINEX navigation files seem to distribute GPS weeks)
3. Retrieve the current GPS week and current seconds of GPS week for the time of ephemeris. These are stored, respectively, in field 3 of line 5 and field 1 of line 3 of each message. Note that the GPS week for time of ephemeris is in continuous scale, not modulo 1024.
4. Calculate the seconds of difference between time of ephemeris and $T_{OC}$. Note that, to account for potential GPS week crossovers, the seconds of difference should be brought to a range between -302400 and +302400.
5. Calculate a relativistic correction term. The formula can be found also at IS-GPS-200M, Section 20.3.3.3.3.1. Please note that the typography in the file that I was able to access can lead to confusion since it seems to show that the square root of the semi-major axis seems to be the exponent for eccentricity, while in reality it is just another multiplicative factor. Also, note that calculation of such relativistic term requires calculation of the eccentric anomaly. This can be done following the steps described in Table 20-IV of the IS-GPS-200M document.
6. Subtract from the individual satellite time the previously calculated seconds of difference between GPST and individual satellite time and the relativistic term.
7. Calculate a correction from GPST to UTC. This is another polynomial correction, with reference time $T_{OT}$ which is given in the header as a GPS week number/seconds of GPS week pair. The 0-order (bias) and 1st-order (drift) terms for the correction are also given in the header, referred to as A0 and A1 parameters, as described in table A3 of this document. We also need to subtract the leap seconds introduced since the 6th of January, 1980. These are also given in the header of the file.
8. Applying the above corrections, we obtain a corrected number of seconds of current GPS week, which can be added to the number of seconds calculated from the current GPS week to obtain the number of seconds since midnight of the 5th to the 6th of January, 1980. This can be then directly converted to a UTC date-time.

GLONASS

The situation seems easier for GLONASS files, although there is still a couple of things that I am not 100% sure. It should be noted to GLONASS time is bound to UTC time, and there will be only a small offset at any given time (usually in the range of a few hundreds nanoseconds, and in any case always below 1 ms as stated in page 15 of the GLONASS specifications). Additionally, RINEX GLONASS navigation files provide ephemerides directly in Cartesian coordinates in ECEF frame. I believe the correct procedure for obtaining the most accurate UTC time is:

1. Obtain the ephemeris time in GLONASS time of the individual GLONASS satellite. It should be noted that it seems that this is given by the time parameters in the 1st line of each message in the file for the case of RINEX GLONASS files. This is a key difference to GPS files, which provide in the corresponding fields $T_{OC}$, the reference time to perform correction from individual satellite GPS time to system-wide GPST. This is supported by the fact that table A11 in the description of RINEX formats states that such time parameters in the 1st line of each message are the "epoch of ephemerides". Compare this to table A4 of the same document, corresponding to GPS files, where the time parameters are described as "Epoch: Toc - Time of Clock".
2. Section 8.2 of the mentioned description of RINEX formats states that correction of time for GLONASS satellites should be calculated as: $T_{UTC} = T_{SV} + Tau_N - Gamma_N * (T_{SV} - T_b) + Tau_C$ . I understand $T_{SV}$ is the time of satellite vehicle that will be corrected to UTC, but I was confused as to what exactly $T_b$ is. There is no other mention of $T_b $ in the description of RINEX formats. However, checking in detail again GLONASS system specifications, it seems that $T_b$ defines the time instant for which the ephemeris parameters are valid. This is supported by the fact, for example, that table 4.6 of said document uses a notation for the position, velocity and acceleration of the satellite that defines them as functions of $T_b$. Therefore, I assume that $T_b$ in the formula found in the document describing RINEX formats is in fact the time of ephemeris. So, for the case of correcting the time of ephemeris, $T_{SV} = T_b$, and therefore the product with $Gamma_N$ is also 0, reducing the conversion to the application of a clock bias to system-wide GLONASS time (provided by $Tau_N$, which is given in the 8th field of the first line of each message), and then an offset to UTC time (provided by $Tau_C$, which is given in the header of each file, and it applies to all of the messages in the corresponding file).
3. There is one more time parameter in RINEX GLONASS navigation files, $t_k$, given in the 10th field of the 1st line of each message. It seems to be defined in page 22 of GLONASS system specifications , but I do not fully understand its meaning yet. I am unsure how/if it should be used to perform any clock corrections at all. It would be great if someone could clarify on this!
4. Also, there is no explicit relativistic correction for GLONASS times. This is because it is implicitly included in $Tau_N$ and $Gamma_N$, as described in page 18 here.