rinex211.txt

读取GPS的Rinex观测文件

  | Galileo Nav File                     .yyL       .yyL.Z  .yyL_Z  .yyT |     |
  | GEO Nav Files                        .yyH       .yyH.Z  .yyH_Z  .yyU |     |
  | GEO SBAS Broadcast Files (sep. doc.) .yyB       .yyB.Z  .yyB_Z  .yyA |     |
  | Met Data Files                       .yyM       .yyM.Z  .yyM_Z  .yyW |     |
  | Clock Files (see sep.doc.)           .yyC       .yyC.Z  .yyC_Z  .yyK |     |
  +----------------------------------------------------------------------+     |

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

  - ftp://terras.gsi.go.jp/software                                            |
  - IGSMails 1525,1686,1726,1763,1785,4967,4969,4975                           |


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
                                   E          : Galileo                        |

                            nn:    - PRN (GPS, Galileo), slot number (GLONASS) |
                                   - PRN-100 (GEO)

        Note: G is mandatory in mixed GPS/GLONASS/Galileo 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.


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 Versions

Programs developed to read RINEX files have to verify the version number.
Files of newer versions may look different even if they do not use any of
the newer 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
safe to 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.


6.9 Unknown / Undefined Observation Types and Header Records                   |
                                                                               |
It is a good practice for a program reading RINEX files to make sure that it   |
does not crash if it encounters unknown observation types or header records    |
by properly skipping them and optionally reporting them to the user.           |


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