5.4 Event Flag Records

The "number of satellites" also corresponds to the number of records of the
same epoch followed. Therefore it may be used to skip the appropriate
number of records if certain event flags are not to be evaluated in detail.


5.5 Receiver Clock Offset

A large number of users asked to optionally include a receiver-derived
clock offset into the RINEX format. In order to remove uncertainties if
the data (epoch, pseudorange, phase) have been previously corrected or not
by the reported clock offset, RINEX Version 2.10 requests a clarifying (new)
header record.

It would then be possible to reconstruct the original observations if
necessary.

As the output format for the receiver-derived clock offset is limited to
nanoseconds the offset should be rounded to the nearest nanosecond before it
is used to correct the observables in order to guarantee correct
reconstruction.


6. ADDITIONAL HINTS AND TIPS

6.1 Version 1 / Version 2

Programs developed to read RINEX Version 1 files have to verify the version
number. Version 2 files may look different (version number, END OF HEADER
record, receiver and antenna serial number alphanumeric) even if they do
not use any of the new features


6.2 Leading Blanks in CHARACTER fields

We propose that routines to read RINEX Version 2 files automatically delete
leading blanks in any CHARACTER input field. Routines creating RINEX
Version 2 files should also left-justify all variables in the CHARACTER
fields.


6.3 Variable-length Records

DOS, and other, files may have variable record lengths, so we recommend to
first read each observation record into a 80-character blank string and
decode the data afterwards. In variable length records, empty data fields
at the end of a record may be missing, especially in the case of the
optional receiver clock offset.


6.4 Blank Fields

In view of future modifications we recommend to carefully skip any fields
currently defined to be blank (Format fields nX), because they may be assigned
to new contents in future versions.


6.5 2-Digit Years

RINEX version 2 stores the years of data records with two digits only. The
header of observation files contains a TIME OF FIRST OBS record with the full
four-digit year, the GPS nav messages contain the GPS week numbers. From these
two data items the unambiguous year can easily be reconstructed.

A hundred-year ambiguity occurs in the met data and GLONASS and GEO nav
messages: Instead of introducing a new TIME OF FIRST OBS header line it is
safeto stipulate that any two-digit years in RINEX Version 1 and Version 2.xx
files are understood to represent

                80-99:  1980-1999
                00-79:  2000-2079

Full 4-digit year fields could then be defined by a future RINEX version 3.


6.6 Fit Interval

Bit 17 in word 10 of subframe 2 is a "fit interval" flag which indicates the
curve-fit interval used by the GPS Control Segment in determining the
ephemeris parameters, as follows (see ICD-GPS-200, 20.3.3.4.3.1):

                0 = 4 hours
                1 = greater than 4 hours.

Together with the IODC values and Table 20-XII the actual fit interval can be
determined. The second value in the last record of each message shall contain
the fit interval in hours determined using IODC, fit flag, and Table 20-XII,
according to the Interface Document ICD-GPS-200.


6.7 Satellite Health

The health of the signal components (bits 18 to 22 of word three in subframe
one) are now (Version 2.10) included into the health value reported in the
second field of the sixth nav mess records.

A program reading RINEX files could easily decide if bit 17 only or all bits
(17-22) have been written:                                                     |

RINEX Value:   0    Health OK
RINEX Value:   1    Health not OK (bits 18-22 not stored)
RINEX Value: >32    Health not OK (bits 18-22 stored)


6.8 Transmission Time of Message (Navigation message file)

The transmission time of message can be shortly before midnight
Saturday/Sunday, the TOE and TOC of the message already in the next week.
As the reported week in the RINEX nav message (BROADCAST ORBIT - 5 record)
goes with ToE (this is different from the GPS week in the original satellite
message!), the transmission time of message should be reduced by 604800
(i.e., will become negative) to also refer to the same week.


7. RINEX UNDER ANTISPOOFING (AS)

Some receivers generate code delay differences between the first and second
frequency using cross-correlation techniques when AS is on and may recover
the phase observations on L2 in full cycles. Using the C/A code delay on
L1 and the observed difference it is possible to generate a code delay
observation for the second frequency.

Other receivers recover P code observations by breaking down the Y code
into P and W code.

Most of these observations may suffer from an increased noise level. In
order to enable the postprocessing programs to take special actions, such
AS-infected observations are flagged using bit number 2 of the Loss of Lock
Indicators (i.e. their current values are increased by 4).


8. GLONASS Extensions

8.1 RINEX Observation File

8.1.1 Time System Identifier

The original RINEX Version 2 needed one major supplement, the explicit
definition of the time system:

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.
In order to remove possible misunderstandings and ambiguities, the header
records "TIME OF FIRST OBS" and (if present) "TIME OF LAST OBS" in GLONASS and
GPS observation files _can_, in mixed GLONASS/GPS observation files _must_
contain a time system identifier defining the system that all time tags in the
file are referring to: "GPS" to identify GPS time, "GLO" to identify the
GLONASS UTC time system. Pure GPS files default to GPS and pure GLONASS files
default to GLO.

Format definitions see Table A1.

Hence, the two possible time tags differ by the current number of leap seconds.

In order to have the current number of leap seconds available we recommend
to include a LEAP SECOND line into the RINEX header.

If there are known non-integer biases between the "GPS receiver clock"
and "GLONASS receiver clock" in the same receiver, they should be applied.
In this case the respective code and phase observations have to be corrected,
too (c * bias if expressed in meters).

Unknown such biases will have to be solved for during the post processing

The small differences (modulo 1 second) between GLONASS system time, UTC(SU),
UTC(USNO) and GPS system time have to be dealt with during the post-processing
and not before the RINEX conversion. It may also be necessary to solve for
remaining differences during the post-processing.

8.1.2 Pseudorange Definition

The pseudorange (code) measurement is defined to be equivalent to the
difference of the time of reception (expressed in the time frame of the
receiver) and the time of transmission (expressed in the time frame of the
satellite) of a distinct satellite signal.

If a mixed-mode GPS/GLONASS receiver refers all pseudorange observations to
one receiver clock only,

- the raw GLONASS pseudoranges will show the current number of leap seconds
  between GPS time and GLONASS time if the receiver clock is running in the
  GPS time frame

- the raw GPS pseudoranges will show the negative number of leap seconds
  between GPS time and GLONASS time if the receiver clock is running in the
  GLONASS time frame

In order to avoid misunderstandings and to keep the code observations within
the format fields, the pseudoranges must be corrected in this case as follows:

  PR(GPS) := PR(GPS) + c * leap_seconds   if generated with a receiver clock
                                          running in the GLONASS time frame

  PR(GLO) := PR(GLO) - c * leap_seconds   if generated with a receiver clock
                                          running in the GPS time frame

to remove the contributions of the leap seconds from the pseudoranges.

"leap_seconds" is the actual number of leap seconds between GPS and GLONASS
(UTC) time, as broadcast in the GPS almanac and distributed in Circular T
of BIPM.

8.1.3 More Than 12 Satellites per Epoch

The format of the epoch / satellite line in the observation record part of
the RINEX Observation files has only been defined for up to 12 satellites
per epoch. We explicitly define now the format of the continuation lines,
see Table A2.


8.2 RINEX Navigation Files for GLONASS

As the GLONASS navigation message differs in contents from the GPS message
too much, a special GLONASS navigation message file format has been defined.

The header section and the first data record (epoch, satellite clock
information) is similar to the GPS navigation file. The following records
contain the satellite position, velocity and acceleration, the clock and
frequency biases as well as auxiliary information as health, satellite
frequency (channel), age of the information.

The corrections of the satellite time to UTC are as follows:

  GPS    : Tutc = Tsv - af0  -  af1  *(Tsv-Toc) - ... -  A0  - ... - leap_sec
  GLONASS: Tutc = Tsv + TauN - GammaN*(Tsv-Tb)        + TauC

***  In order to use the same sign conventions for the GLONASS corrections
     as in the GPS navigation files,  the broadcast GLONASS values are
     stored as:
                  -TauN, +GammaN, -TauC.

The time tags in the GLONASS navigation files are given in UTC (i.e. _not_
Moscow time or GPS time).

Filenaming convention: See above.


9.  RINEX Extensions for Geostationary Satellites (GPS Signal Payloads)