1. THE PHILOSOPHY OF RINEX

The first proposal for the "Receiver Independent Exchange Format" RINEX has
been developed by the Astronomical Institute of the University of Berne for
the easy exchange of the GPS data to be collected during the large European
GPS campaign EUREF 89, which involved more than 60 GPS receivers of 4
different manufacturers. The governing aspect during the development was
the following fact:

Most geodetic processing software for GPS data use a well-defined set of
observables:

- the carrier-phase measurement at one or both carriers (actually being a
measurement on the beat frequency between the received carrier of the
satellite signal and a receiver-generated reference frequency).

- the pseudorange (code) measurement, 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.

- the observation time being the reading of the receiver clock at the
instant of validity of the carrier-phase and/or the code measurements.

Usually the software assumes that the observation time is valid for both
the phase AND the code measurements, AND for all satellites observed.

Consequently all these programs do not need most of the information that is
usually stored by the receivers:  They need phase, code, and time in the
above mentioned definitions, and some station-related information like
station name, antenna height, etc.


2. GENERAL FORMAT DESCRIPTION

Currently the format consists of six ASCII file types:

   1. Observation Data File
   2. Navigation Message File
   3. Meteorological Data File
   4. GLONASS Navigation Message File
   5. GEO Navigation Message File
   6. Satellite and Receiver Clock Date File

(The format definition of the clock files has been published in 1998
in a separate document by Jim Ray and Werner Gurtner, available at the IGS
Central Bureau Information System: ftp://igscb.jpl.nasa.gov/igscb/data/
format/rinex_clock.txt).

Each file type consists of a header section and a data section. The header
section contains global information for the entire file and is placed at
the beginning of the file. The header section contains header labels in
columns 61-80 for each line contained in the header section. These labels
are mandatory and must appear exactly as given in these descriptions and
examples.

The format has been optimized for mimimum space requirements independent
from the number of different observation types of a specific receiver by
indicating in the header the types of observations to be stored. In
computer systems allowing variable record lengths the observation records
may be kept as short as possible. Trailing blanks can be removed from the      |
records. The maximum record length is 80 bytes per record.                     |

Each Observation file and each Meteorological Data file basically contain
the data from one site and one session. RINEX Version 2 also allows to
include observation data from more than one site subsequently occupied by
a roving receiver in rapid static or kinematic applications. Although Version 2
allows to insert header records into the data field we do not recommend to
concatenate data of more than one receiver (or antenna) into the same file,
even if the data do not overlap in time.

If data from more than one receiver has to be exchanged it would not be
economical to include the identical satellite messages collected by the
different receivers several times. Therefore the Navigation Message File
from one receiver may be exchanged or a composite Navigation Message File
created containing non-redundant information from several receivers in
order to make the most complete file.

The format of the data records of the RINEX Version 1 Navigation Message
file is identical to the former NGS exchange format.

The actual format descriptions as well as examples are given in the Tables
at the end of the paper.


3. DEFINITION OF THE OBSERVABLES

GPS observables include three fundamental quantities that need to be defined:
Time, Phase, and Range.

TIME:

  The time of the measurement is the receiver time of the received signals.
  It is identical for the phase and range measurements and is identical for
  all satellites observed at that epoch. It is expressed in GPS time (not
  Universal Time).

PSEUDO-RANGE:

  The pseudo-range (PR) is the distance from the receiver antenna to the
  satellite antenna including receiver and satellite clock offsets (and
  other biases, such as atmospheric delays):

    PR  =  distance +
           c * (receiver clock offset - satellite clock offset +
                other biases)

  so that the pseudo-range reflects the actual behavior of the receiver
  and satellite clocks. The pseudo-range is stored in units of meters.

  See also clarifications for pseudoranges in mixed GPS/GLONASS files in
  chapter 8.1.

PHASE:

  The phase is the carrier-phase measured in whole cycles at both L1 and
  L2. The half-cycles measured by sqaring-type receivers must be converted
  to whole cycles and flagged by the wavelength factor in the header
  section.

  The phase changes in the same sense as the range (negative doppler). The
  phase observations between epochs must be connected by including the
  integer number of cycles. The phase observations will not contain any
  systematic drifts from intentional offsets of the reference oscillators.

The observables are not corrected for external effects like atmospheric
refraction, satellite clock offsets, etc.

If the receiver or the converter software adjusts the measurements using
the real-time-derived receiver clock offsets dT(r), the consistency of the
3 quantities phase / pseudo-range / epoch must be maintained, i.e. the
receiver clock correction should be applied to all 3 observables:

  Time(corr)  = Time(r)  -  dT(r)
  PR(corr)    =  PR(r)   -  dT(r)*c
  phase(corr) = phase(r) -  dT(r)*freq

DOPPLER:

The sign of the doppler shift as additional observable is defined as usual:
Positive for approaching satellites.


4. THE EXCHANGE OF RINEX FILES:

We recommend using the following naming convention for RINEX files:

        ssssdddf.yyt      ssss:    4-character station name designator
                           ddd:    day of the year of first record
                             f:    file sequence number within day
                                   0: file contains all the existing
                                      data of the current day
                            yy:    year
                             t:    file type:
                                   O: Observation file
                                   N: Navigation file
                                   M: Meteorological data file
                                   G: GLONASS Navigation file
                                   H: Geostationary GPS payload nav mess file

When data transmission times or storage volumes are critical we recommend
compressing the files prior to storage or transmission using the UNIX
"compress" und "uncompress" programs. Compatible routines are available on
VAX/VMS and PC/DOS systems, as well.

Proposed naming conventions for the compressed files:

File Types                      UNIX            VMS             DOS            |

Obs Files                       ssssdddf.yyO.Z  ssssdddf.yyO_Z  ssssdddf.yyY
Obs Files (Hatanaka compr)      ssssdddf.yyD.Z  ssssdddf.yyD_Z  ssssdddf.yyE
GPS Nav Files                   ssssdddf.yyN.Z  ssssdddf.yyN_Z  ssssdddf.yyX
GLONASS Nav File                ssssdddf.yyG.Z  ssssdddf.yyG_Z  ssssdddf.yyV
GEO Nav Files                   ssssdddf.yyH.Z  ssssdddf.yyH_Z  ssssdddf.yyU
Met Data Files                  ssssdddf.yyM.Z  ssssdddf.yyM_Z  ssssdddf.yyW
Clock Files (see sep.doc.)      ssssdddf.yyC.Z  ssssdddf.yyC_Z

References for the Hatanaka compression scheme: See e.g.

     ftp://igscb.jpl.nasa.gov/igscb/software/rnxcmp/docs/

     IGSMails 1525,1686,1726,1763,1785


5. RINEX VERSION 2 FEATURES


The following section contains features that have been introduced for RINEX
Version 2:


5.1 Satellite Numbers:

Version 2 has been prepared to contain GLONASS or other satellite systems'
observations. Therefore we have to be able to distinguish the satellites
of the different systems:  We precede the 2-digit satellite number with a
system identifier.

        snn                  s:    satellite system identifier
                                   G or blank : GPS
                                   R          : GLONASS
                                   S          : Geostationary signal payload
                                   T          : Transit

                            nn:    - PRN (GPS), slot number (GLONASS)
                                   - PRN-100 (GEO)
                                   - two-digit Transit satellite number

        Note: G is mandatory in mixed GPS/GLONASS files

                                   (blank default modified in April 1997)

5.2 Order of the Header Records:

As the record descriptors in columns 61-80 are mandatory, the programs
reading a RINEX Version 2 header are able to decode the header records with
formats according to the record descriptor, provided the records have been
first read into an internal buffer.

We therefore propose to allow free ordering of the header records, with the
following exceptions:

- The "RINEX VERSION / TYPE" record must be the first record in a file

- The default "WAVELENGTH FACT L1/2" record must precede all records defining
  wavelength factors for individual satellites

- The "# OF SATELLITES" record (if present) should be immediately followed
  by the corresponding number of "PRN / # OF OBS" records. (These records
  may be handy for documentary purposes. However, since they may only be
  created after having read the whole raw data file we define them to be
  optional.


5.3 Missing Items, Duration of the Validity of Values

Items that are not known at the file creation time can be set to zero or
blank or the respective record may be completely omitted. Consequently
items of missing header records will be set to zero or blank by the program
reading RINEX files. Trailing blanks may be truncated from the record.         |

Each value remains valid until changed by an additional header record.