[IGSMAIL-2279] RINEX Version 2.10

W. W.
Tue May 25 07:52:18 PDT 1999


IGS Electronic Mail      Tue May 25  7:52:18 PDT 1999      Message Number 2279
******************************************************************************

Author: W. Gurtner
Subject: RINEX Version 2.10: Request for Comments


                Proposed Changes of the RINEX Format
                         RINEX Version 2.10
                ************************************

                            May 25, 1999


                           Werner Gurtner
                       Astronomical Institute
                         University of Berne

                       (gurtner at aiub.unibe.ch)

During the last few years several proposals for changes in the RINEX format
have been brought to my attention. Please find below a collection of such
proposed changes.

In my opinion all these changes are so moderate that they do not justify the
introduction of a RINEX Version 3:

- Fractional version number:         Hopefully no problem,
                                     old programs read integer part

- Zero padding of year values:       No problem

- Field length of time of first obs: Hopefully no problem for old RINEX readers

- Non-integer sampling rate:         Wrong value for non-integer values
                                     larger than 1 second, should not be
                                     a significant problem

- Header records after event flags:  May give problems in rare special cases
                                     (kinematic files, event records)

- Additional obs types in obs files: Old readers might not accept them
                                     or issue warnings

- Receiver clock offset header line: Old readers might reject these files
                                     or issue warnings

- Default w.length fact header line: Hopefully no problem

- Inmarsat GPS payloads:             Old readers might reject these files
                                     or issue warnings

- Curve fit interval:                Hopefully no problem

- SV Health:                         Healthy satellites: No problem
                                     Unhealthy: Old: value=1, New: value > 32

- Additional obs types in met files: Old readers might not accept them
                                     or issue warnings


I propose therefore to introduce a version 2.10!
                                   ------------


May I ask you to review the proposals and send any comments to me till

                            July 1st, 1999
                            **************

A final draft will be compiled beginning of July if no serious objections
have been received (else a new iteration will be initiated).

I will then fix a release date as well as a date of activation. Any proposals
to this topic are welcome, too.

Thank you very much for your cooperation.

Best regards

Werner Gurtner


*******************************************************************************


Fractional Version Number (All RINEX file types)
*************************

Proposal:
--------

The RINEX version number in the first header line should be a non-integer value
for all rinex file types, as already introduced for the GLONASS navigation
message file.


 +--------------------+------------------------------------------+------------+
 |RINEX VERSION / TYPE| - Format version (2.10)                  | F9.2,11X,  |
 |                    | - File type ('O' for Observation Data)   |   A1,19X,  |
 |                    | - Satellite System: blank or 'G': GPS    |   A1,19X   |
 |                    |                     'R': GLONASS         |            |
 |                    |                     'T': NNSS Transit    |            |
 |                    |                     'M': Mixed           |            |
 +--------------------+------------------------------------------+------------+

Example:

     2.10           OBSERVATION DATA    M (MIXED)           RINEX VERSION / TYPE


Pad Two-digit Year Fields With a Zero (All files)
*************************************

Proposal by Lou Estey, UNAVCO:
--------

Pad all 2-digit year fields for the years 2000-2009 with a zero for easier
human readability.

Examples:

Obs:

 00  2  6 12 13 10.0000000  0 12G23G07G02G05G26G09G21R20R19R12R02R11

Nav:

 3 00  2  6 12 15  0.0 0.163525342941D-03 0.363797880709D-11 0.108000000000D+05

Met:

 00  2  6 12 15  0  987.1   10.6   89.5


Ambiguities in the Date of Met Data and GLONASS Nav Message Records
*******************************************************************

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.

A hundert-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 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.



Increase Field Length of TIME OF FIRST and LAST OBS (Observation files)
***************************************************

Proposal by Lou Estey, UNAVCO:
--------

In order to have the same granularity of the seconds field in the TIME OF FIRST
OBS and TIME OF LAST OBS header record as the one in the OBS RECORDS we propose
to increase the field length for the seconds from F12.6,6X to F13.7,5X:

 +--------------------+------------------------------------------+------------+
 |TIME OF FIRST OBS   | - Time of first observation record       | 5I6,F13.7, |
 |                    |   (4-digit-year, month,day,hour,min,sec) |            |
 |                    | - Time system: GPS (=GPS time system)    |   5X,A3    |
 |                    |                GLO (=UTC time system)    |            |
 |                    |   Compulsory in mixed GPS/GLONASS files  |            |
 |                    |   Defaults: GPS for pure GPS files       |            |
 |                    |             GLO for pure GLONASS files   |            |
 +--------------------+------------------------------------------+------------+
*|TIME OF LAST OBS    | - Time of last  observation record       | 5I6,F13.7, |*
 |                    |   (4-digit-year, month,day,hour,min,sec) |            |
 |                    | - Time system: GPS (=GPS time system)    |   5X,A3    |
 |                    |                GLO (=UTC time system)    |            |
 |                    |   Compulsory in mixed GPS/GLONASS files  |            |
 |                    |   Defaults: GPS for pure GPS files       |            |
 |                    |             GLO for pure GLONASS files   |            |
 +--------------------+------------------------------------------+------------+

Example:

  1999     1     5    12    33   30.0490000     GPS         TIME OF FIRST OBS
  1999     1     5    22    25    0.0550000     GPS         TIME OF LAST OBS 


Non-Integer Sampling Rates  (Observation files)
**************************

Proposal:
--------

Introduction of a more general sampling interval, namely allowing for
fractional parts of seconds (e.g. 0.5 second sampling)

Problem brought to my attention by:

  Dr. David S. Coco
  Applied Research Laboratories
  University of Texas at Austin


Proposal:
--------

 +--------------------+------------------------------------------+------------+
*|INTERVAL            | Observation interval in seconds          | F10.3      |*
 |                    | (Old format for integer values only: I6) |            |
 +--------------------+------------------------------------------+------------+

Example:

     0.100                                                  INTERVAL

Such a record will still conform to RINEX version 1 and 2 for

- integer intervals
- fractional intervals smaller than one second (read as zero = undefined)

Non-integer intervals larger than one second would be read as INT(interval).



Header Records After Event Flags (Obs files)
********************************

Event flags 2 and 5 don't have header records assigned. That's why the
RINEX2 document requested the number of (header) records to follow to be zero.

Proposal:
--------

Remove this restriction so that COMMENT lines can directly follow such event
flags:

 +-------------+-------------------------------------------------+------------+
 | EPOCH/SAT   | - Epoch :                                       | 5I3,F11.7, |
 |     or      |     year (2 digits), month,day,hour,min,sec     |            |
 | EVENT FLAG  | - Epoch flag 0: OK                              |     I3,    |
 |             |              1: power failure between           |            |
 |             |                 previous and current epoch      |            |
 |             |             >1: Event flag                      |            |
 |             |                   ....                          |            |
 |             | If EVENT FLAG record (epoch flag > 1):          |            |
 |             |   - Event flag:                                 |            |
 |             |     2: start moving antenna                     |            |
 |             |                   ....                          |            |
 |             |     5: external event (epoch is significant,    |            |
 |             |        same time frame as observation time tags)|            |
 |             |                   ....                          |            |
 |             |   - "Number of satellites" contains number of   |            |
 |             |     special records to follow                   |            |
 +-------------+-------------------------------------------------+------------+

Example:

 99  1 24 13 13  1.2345678  5  2
     *** AN EVENT FLAG WITH SIGNIFICANT EPOCH ***           COMMENT
    *** DIRECTLY FOLLOWED BY TWO COMMENT LINES  ***         COMMENT



Default Wavelength factor header line (Obs files)
*************************************

Proposal by Lou Estey, UNAVCO:
--------

Make default wavelength factor RINEX header line a required line.

 +--------------------+------------------------------------------+------------+
 |WAVELENGTH FACT L1/2| - Wavelength factors for L1 and L2       |    2I6,    |
 |                    |   1:  Full cycle ambiguities             |            |
 |                    |   2:  Half cycle ambiguities (squaring)  |            |
 |                    |   0 (in L2): Single frequency instrument |            |
 |                    |                                          |            |
 |                    | - zero or blank                          |     I6     |
 |                    |                                          |            |
 |                    | The default wavelength factor line is    |            |
 |                    | required and must preceed satellite-     |            |
 |                    | specific lines.                          |            |
 |                    |                                          |            |
 +--------------------+------------------------------------------+------------+

Optional satellite specific wavelength factor RINEX header lines may follow,
which should identify a state different from the default values:

 +--------------------+------------------------------------------+------------+
*|WAVELENGTH FACT L1/2| - Wavelength factors for L1 and L2       |    2I6,    |*
 |                    |   1:  Full cycle ambiguities             |            |
 |                    |   2:  Half cycle ambiguities (squaring)  |            |
 |                    |   0 (in L2): Single frequency instrument |            |
 |                    | - Number of satellites to follow in list |     I6,    |
 |                    |   for which these factors are valid.     |            |
 |                    | - List of PRNs (satellite numbers with   | 7(3X,A1,I2)|
 |                    |   system identifier)                     |            |
 |                    |                                          |            |
 |                    | Repeat record if necessary.              |            |
 |                    |                                          |            |
 +--------------------+------------------------------------------+------------+



Additional Observation Type: S1, S2 (Obs files)
***********************************

Several individuals came up with the request to increase the number of
significant digits for the signal strength. In the current RINEX definition
the signal strength is a number between 1 and 9 to get a coarse
receiver-independent indication about the actual signal strength. In order
to account for the request we propose to define two new observation types
S1 and S2 being the original signal strength or SNR values output by the
receiver for L1 and L2 tracking.

 +--------------------+------------------------------------------+------------+
 |                    | The following observation types are      |            |
 |                    | defined in RINEX Version 2:              |            |
 |                    |  ...                                     |            |
 |                    |  ...                                     |            |
 |                    |  ...                                     |            |
 |                    | S1, S2: Signal strengths or SNR values   |            |
 |                    | as given by the receiver for L1, L2      |            |
 |                    | observations stored in the RINEX file    |            |
 +--------------------+------------------------------------------+------------+


Application of Receiver Clock Offsets to the Data and Time Tag (Obs files)
**************************************************************

RINEX Version 2 defines a field in the epoch/satellite records for the
real-time determined clock offsets but asks that the observables code, phase
and time tag have to be corrected by these offsets.

This can (and did!) lead to some confusion. Some users would also like to
report these offsets without having to modify the original data.


Proposal:
--------

The new version of RINEX should allow for either way, i.e. define a header
field to indicate if the data has been corrected by the reported clock offset
or not. 

 +--------------------+------------------------------------------+------------+
*|RCV CLOCK OFFS APPL | Realtime-derived receiver clock offset   |     I6     |*
 |                    | applied to epoch/code/phase (1=yes, 0=no)|            |
 |                    | Default:  0=no                           |            |
 |                    | Record required if clock offsets are     |            |
 |                    | reported in the EPOCH/SAT records        |            |
 +--------------------+------------------------------------------+------------+

Example:

     1                                                      RCV CLOCK OFFS APPL


Curve Fit Interval (Navigation message file)
******************

Bit 17 in word 10 of subframe 2 is a "fit interval" flag which indicates the
curve-fit interval used by the CS 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.

Rick Mach from ARL (rmach at sgdmail1.arlut.utexas.edu) proposes to include the
fit interval into the navigation blocks of the RINEX navigation files.

Proposal:  
--------

  The second value in the last record of each message contains the fit 
  interval in hours determined using IODC, fit flag, and Table 20-XII,
  according to the Interface Document ICD-GPS-200.

 +--------------------+------------------------------------------+------------+
 | BROADCAST ORBIT - 7| - Msg transmit time   (sec of GPS week)  | 3X,4D19.12 |
 |                    |         (derived e.g. from Z-count       |            |
 |                    |          in Hand Over Word HOW)          |            |
 |                    | - Fit interval        (hours)            |            |
 |                    |         (see ICD-GPS-200, 20.3.4.4)      |            |
 |                    |   Zero if not known                      |            |
 |                    | - spare                                  |            |
 |                    | - spare                                  |            |
 +--------------------+------------------------------------------+------------+



SV Health (Navigation message file)
*********

Proposal:
--------

Include also the health of the signal components (bits 18 to 22 of  word three
in subframe one) and not just the summary bit of the nav data health (bit 17).

A program reading RINEX files could easily decide if bit 17 only or all bits
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)


Transmission Time of Message (Navigation message file)
****************************

Clarification:
-------------

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 nav message (BROADCAST ORBIT - 5 record) goes
with ToE, the transmission time of message should be reduced by 604800
(i.e., will become negative) to also refer to the same week.

 +--------------------+------------------------------------------+------------+
 | BROADCAST ORBIT - 7| - Transmission time of message        *) | 3X,4D19.12 |
 |                    |         (sec of GPS week, derived e.g.   |            |
 |                    |    from Z-count in Hand Over Word (HOW)  |            |
 |                    | - Fit interval        (hours)            |            |
 |                    |         (see ICD-GPS-200, 20.3.4.4)      |            |
 |                    |   Zero if not known                      |            |
 |                    | - spare                                  |            |
 |                    | - spare                                  |            |
 +--------------------+------------------------------------------+------------+

 *) Adjust the Transmission time of message by -604800 to refer to the reported
    week, if necessary



Additional Observation Types (Met data files)
****************************

Proposal:
--------

Define

  ZD : Dry component of zenith path delay
  ZT : Total zenith path delay

ZT could be used to distribute the zenith path delays estimated for permanently
operated GPS sites using their GPS observables.


RINEX Extensions for Geostationary Satellites (GPS Signal Payloads)
*******************************************************************

Problem brought to my attention by and discussed with

                       Jean-Marc Gaubert
                   Alcatel Space Industries
          26, avenue Champolion, 31037 Toulouse, France

               Jean-Marc.Gaubert at space.alcatel.fr


With the implementation of GNSS programs, GPS-like ranging measurements can be
performed on geostationary navigation payloads.

We propose here the necessary extensions to handle such data in RINEX files
for data exchange and postprocessing purposes.


RINEX Observation File
**********************

A new satellite system identifier has been defined for the geostationary
GPS signal payloads: "S"


 +--------------------+------------------------------------------+------------+
 |RINEX VERSION / TYPE| - Format version (2.10)                  |  F9.2,11X, |
 |                    | - File type ('O' for Observation Data)   |   A1,19X,  |
 |                    | - Satellite System: blank or 'G': GPS    |   A1,19X   |
 |                    |                     'R': GLONASS         |            |
 |                    |                     'S': Geostationary   |            |
 |                    |                          signal payload  |            |
 |                    |                     'T': NNSS Transit    |            |
 |                    |                     'M': Mixed           |            |
 +--------------------+------------------------------------------+------------+

The satellite identifier 'snn' in the observation files consists of the two
parts:

             's' : Satellite system identifier ("S")
            'nn' : Satellite number, being the designated PRN of the GEO
                   satellite minus 100,

                   e.g.: PRN = 120 --> 'snn' = "S20"

In mixed dual frequency GPS satellite / single frequency GEO payload
observation files the fields for the second frequency observations of GEO
satellites remain blank or are set to zero values.


RINEX Navigation Message Files for GEO Satellites
*************************************************

As the GEO broadcast orbit format differs from the GPS message a special GEO
navigation message file format has been defined which is nearly identical with
the GLONASS nav mess file format.

Proposed naming conventions:

     System   GEO Nav Files   Compressed GEO Nav Files

     UNIX     ssssdddf.yyH        ssssdddf.yyH.Z
     VMS      ssssdddf.yyH        ssssdddf.yyH_Z
     DOS      ssssdddf.yyH        ssssdddf.yyU


The header section contains informations about the generating program,
comments, and the difference between the GEO system time and UTC.

The first data record contains the epoch and satellite clock information,
the following records contain the satellite position, velocity and
acceleration and auxiliary information such as health, age of the data, etc.

The time tags in the GEO navigation files are given in the GPS time frame,
i.e. not UTC.

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

  GEO    : Tutc = Tsv - aGf0  -  aGf1 *(Tsv-Toe) -  W0  - leap_sec

W0 being the correction to transform the GEO system time to UTC. Toe, aGf0,
aGf1 see below.


 +----------------------------------------------------------------------------+
 |                                   TABLE A15                                |
 |     GEOSTATIONARY NAVIGATION MESSAGE FILE - HEADER SECTION DESCRIPTION     |
 +--------------------+------------------------------------------+------------+
 |    HEADER LABEL    |               DESCRIPTION                |   FORMAT   |
 |  (Columns 61-80)   |                                          |            |
 +--------------------+------------------------------------------+------------+
 |RINEX VERSION / TYPE| - Format version (2.10)                  | F9.2,11X,  |
 |                    | - File type ('H' = GEO nav mess data)    |   A1,39X   |
 +--------------------+------------------------------------------+------------+
 |PGM / RUN BY / DATE | - Name of program creating current file  |     A20,   |
 |                    | - Name of agency  creating current file  |     A20,   |
 |                    | - Date of file creation (dd-mmm-yy hh:mm)|     A20    |
 +--------------------+------------------------------------------+------------+
*|COMMENT             | Comment line(s)                          |     A60    |*
 +--------------------+------------------------------------------+------------+
*|CORR TO SYSTEM TIME | - Time of reference for system time corr |            |*
 |                    |   (year, month, day)                     |     3I6,   |
 |                    | - Correction to transform the GEO system | 3X,D19.12  |
 |                    |   time to UTC                        (W0)|            |
 +--------------------+------------------------------------------+------------+
*|LEAP SECONDS        | Number of leap seconds since 6-Jan-1980  |     I6     |*
 +--------------------+------------------------------------------+------------+
 |END OF HEADER       | Last record in the header section.       |    60X     |
 +--------------------+------------------------------------------+------------+

                        Records marked with * are optional


 +----------------------------------------------------------------------------+
 |                                  TABLE A16                                 |
 |      GEOSTATIONARY NAVIGATION MESSAGE FILE - DATA RECORD DESCRIPTION       |
 +--------------------+------------------------------------------+------------+
 |    OBS. RECORD     | DESCRIPTION                              |   FORMAT   |
 +--------------------+------------------------------------------+------------+
 |PRN / EPOCH / SV CLK| - Satellite number (PRN - 100)           |     I2,    |
 |                    | - Epoch of ephemerides (GPS)       (Toe) |            |
 |                    |          - year (2 digits)               |    5I3,    |
 |                    |          - month                         |            |
 |                    |          - day                           |            |
 |                    |          - hour                          |            |
 |                    |          - minute                        |            |
 |                    |          - second                        |    F5.1,   |
 |                    | - SV clock bias (sec)              (aGf0)|   D19.12,  |
 |                    | - SV relative frequency bias       (aGf1)|   D19.12,  |
 |                    | - message frame time (sec of day GPS)    |   D19.12   |
 +--------------------+------------------------------------------+------------+
 | BROADCAST ORBIT - 1| - Satellite position X      (km)         | 3X,4D19.12 |
 |                    | -           velocity X dot  (km/sec)     |            |
 |                    | -           X acceleration  (km/sec2)    |            |
 |                    | -           health (0=OK)                |            |
 +--------------------+------------------------------------------+------------+
 | BROADCAST ORBIT - 2| - Satellite position Y      (km)         | 3X,4D19.12 |
 |                    | -           velocity Y dot  (km/sec)     |            |
 |                    | -           Y acceleration  (km/sec2)    |            |
 |                    | - Accuracy code             (URA)        |            |
 +--------------------+------------------------------------------+------------+
 | BROADCAST ORBIT - 3| - Satellite position Z      (km)         | 3X,4D19.12 |
 |                    | -           velocity Z dot  (km/sec)     |            |
 |                    | -           Z acceleration  (km/sec2)    |            |
 |                    | - spare                                  |            |
 +--------------------+------------------------------------------+------------+

 References for the definition of the accuracy and health codes TBD.


[Mailed From: gurtner at ubeclu.unibe.ch (WERNER GURTNER)]



More information about the IGSMail mailing list