rinex2.txt

这是国外关于卫星导航方面一书的源代码

                            December 7, 1999


         RINEX: The Receiver Independent Exchange Format Version 2.10
         ************************************************************

                            Werner Gurtner
                        Astronomical Institute
                          University of Berne

0. Revision History

0.1 Revision Summary

First Revision, April 1993
Clarification December 1993
Doppler Definition: January 1994
PR Clarification: October 1994
Wlfact Clarification: February 1995
Event Time Frame Clarification: May 1996
Minor errors in the examples A7/A8: May 1996
Naming convention for compressed met files; January 1997
Continuation line clarifications: April 1997
GLONASS Extensions: April 1997
Met sensor description and position records: April 1997
Wavelength factor clarifications: April 1997
Error in example A12: CORR TO SYSTEM TIME, April 1997
Redefinition of sv clock params in GLONASS Nav Mess Files: March 1998
Naming conventions for compressed RINEX obs files: March 1998
GPS week: No roll-over, continuous number: March 1998
Error in compressed DOS file naming convention: July 1998
Table A13 contained blank satellite identifiers: Sept 1998
Discrepancy between Tables A5 and A9 removed: Sept 1998
Phase data format overflow: Clarification: Oct 1998
Message frame time Table A11: Clarification: Oct 1998
RINEX Version 2.10 Modifications: July 1999
Typo in paragraph 0.4 (epoch flag >1): Nov 1999
Clarification regarding trailing blanks: Dec 1999
 

0.2 First Revision

The first documentation of the RINEX Version 2 Format was published by
W. Gurtner and G. Mader in the CSTG GPS Bulletin of September/October 1990.
The main reason for a revision is the new treatment of antispoofing data by
the RINEX format (see chapter 7). Chapter 4 gives a recommendation for data
compression procedures, especially useful when large amounts of data are
exchanged through computer networks. In Table A3 in the original paper the
definiton of the "PGM / RUN BY / DATE" navigation header record was
missing, although the example showed it. The redefinition of AODE/AODC to
IODE/IODC also asked for an update of the format description. For consistency
reasons we also defined a Version 2 format for the Meteorological Data files
(inclusion of a END OF HEADER record and an optional MARKER NUMBER record).

The slight modification (or rather the definition of a bit in the Loss of Lock
Indicator unused so far) to flag AS data is so small a change that we decided
to NOT increase the version number!


0.3 Later Revisions

* URA Clarification (10-Dec-93):

  The user range accuracy in the Navigation Message File did not contain
  a definition of the units: There existed two ways of interpretation:
  Either the 4 bit value from the original message or the converted value
  in meters according to GPS ICD-200. In order to simplify the interpretation
  for the user of the RINEX files I propose the bits to be converted into meters
  prior to RINEX file creation.

* GLONASS Extensions:

  In March 1997 a proposal for extensions to the current RINEX definitions based
  on experiences collected with GLONASS only and mixed GPS/GLONASS data files
  was circulated among several instrument manufacturers and software developers.
  The results of the call for comments have been worked into this document.
  A separate document (glonass.txt) summarizes just the necessary extensions.

* A blank satellite identifier is allowed in pure GPS files only

* Met sensor description and position records were added to facilitate the
  precise use of met values.

* Description and examples for wavelength factors and their temporary changes
  (bit 1 of LLI) clarified.

* The RINEX documentation distributed in spring 1997 contained definitions for
  the GLONASS satellite clock offset and drift with the intention to have them
  defined identically to the GPS values. Unfortunately the GLONASS Interface
  Document consulted had a sign error in one of the formulae.

  The values should be stored into the RINEX file as -TauN, +GammaN, -TauC.
  The original definition asked for -TauN, -GammaN, +TauC. See paragraph 8.2.

  To avoid problems with files created with the original definitions a real
  valued version number (2.01) has been introduced for GLONASS nav mess files.

* IGS decided to use the Hatanaka compression scheme for RINEX observation
  files. Below the corresponding RINEX file name conventions are included
  as recommendations. The DOS naming (extension .yyE) was wrongly set to
  .yyY in the March 1998 version of the document.

* GPS week: The GPS week number in all RINEX files is a continuous number
  not affected by the 1024 roll-over, it runs from 1023 over 1024 to 1025 etc.

* A descrepancy between the definition of the header line fields of met sensor
  description and position in Table A5 and the example in Table A9 was removed.
  The latter was correct.

* Clarification for phase data format overflows: Add or subtract a suitable
  number of cycles, set LLI flag.


0.4 Version 2.10 Modifications

The modifications leading to Version 2.10 include:

- Fractional version number
- Zero padding of 2-digit year values (years 2000-2009 --> 00-09)
- Field length of time of first obs (1/10 microsecond resolution)
- Non-integer sampling rate (INTERVAL header record)
- Header records now allowed after all epoch flags >1                          |
- Additional obs types in obs files: S1, S2 (raw signal strength values)
- Receiver clock offset header line to clarify applied corrections
- Default wavelength factor header line mandatory
- Inmarsat GPS payloads: New satellite system definition, new nav mess files
- Curve fit interval in GPS nav mess file
- Redefinition of SV health value in GPS nav mess file
- Additional obs types in met files (ZD, ZT)


0.5 Version 2.10 Revisions

* "Header records now allowed after all epoch flags >2" in paragraph 0.4
  should read ">1"

* The original intention of the RINEX format was to allow for variable record
  lengths of the ASCII files to minimize the file size. Empty fields or unknown
  values can either be represented by zeroes or blank space. Most RINEX
  converters removed trailing blank to further reduce the file size. The
  documentation was not clear enough to explicitely allow for this practice
  (paragraphs 2, 5.3, 9.1).


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: