📄 rinex2.txt
字号:
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
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)
With the implementation of GNSS programs, GPS-like ranging measurements can be
performed on geostationary navigation payloads.
RINEX Version 2.10 defines the necessary extensions to handle such data in
RINEX files for data exchange and postprocessing purposes.
9.1 RINEX Observation Files for GEO Satellites
A new satellite system identifier has been defined for the geostationary
GPS signal payloads: "S", to be used in the RINEX VERSION / TYPE header line
and in the satellite identifier 'snn', nn being the GEO PRN number 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, are set to zero values or (if last in the record) |
can be truncated. |
9.2 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.
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 in the format definition tables.
* References for the definition of the accuracy and health codes still have *
* to be defined. *
* Help is needed here by colleagues working with such GEO data! *
10. REFERENCES
Evans, A. (1989): "Summary of the Workshop on GPS Exchange Formats."
Proceedings of the Fifth International Geodetic Symposium on Satellite
Systems, pp. 917ff, Las Cruces.
Gurtner, W., G. Mader, D. Arthur (1989): "A Common Exchange Format for
GPS Data." CSTG GPS Bulletin Vol.2 No.3, May/June 1989, National Geodetic
Survey, Rockville.
Gurtner, W., G. Mader (1990): "The RINEX Format: Current Status, Future
Developments." Proceedings of the Second International Symposium of Precise
Positioning with the Global Positioning system, pp. 977ff, Ottawa.
Gurtner, W., G. Mader (1990): "Receiver Independent Exchange Format
Version 2." CSTG GPS Bulletin Vol.3 No.3, Sept/Oct 1990, National Geodetic
Survey, Rockville.
Gurtner, W. (1994): "RINEX: The Receiver-Independent Exchange Format."
GPS World, Volume 5, Number 7, July 1994.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -