Werner Gurtner
Astronomical Insitute
University of Berne
Switzerland
Gerald M. Mader
National Geodetic Survey
Rockville, Maryland
U.S.A.
Abstract: The Receiver Independent Exchange Format RINEX has been presented at the 1989 Las Cruces workshop on Gps Exchange Formats. It has been recommended by the workshop to be used as an exchange format by the international geodetic user community. The format has been used for more than one year by many groups working with different receiver types. The paper describes some of the experiences gathered with the use of the format and with the writing of the necessary translator software for various receiver types. The first version of RINEX covers static positioning data only. We discuss possible enhancements to easily include rapid static, pseudokinematic, and kinematic data as well. INTRODUCTION
During the 5th International Geodetic Symposium on Satellite Positioning in Las Cruces, March 1989 a special workshop on GPS Exchange Formats was organized. After the presentation of different examples of exchange formats the workshop recommended that the Receiver Independent Exchange Format (RINEX) should be published and critiques of the format should be solicited from the GPS user community. (A summary of the workshop may be found in the proceedings, [Evans, 1989), a description of RINEX in [Gurtner et al, 1989). A GPS user meeting organized by the GPS subcommission of the International Coordination of Space Techniques for Geodesy and Geodynamics (CSTG) during the IAG Symposium in Edinburgh, August 1989, recommended RINEX to be used internationally as standard exchange format geodetic GPS data.
The user community was also encouraged to use the format developed at the Applied Research Laboratories of the University of Texas (called FICA for Floating Integer Character ASCII, [Scott et al, 1986]) as a standard archive format or as an exchange format if all original (receiver-dependent) data items have to be made available.
THE PHILOSOPHY OF RINEX
The first proposal for the "Receiver Independent Exchange Format" RINEX was developed by the Astronomical Institute of the University of Berne for the easy exchange of the GPS data 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 observable:
- 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.
The Description of RINEX [Gurtner et al, 1989] states that any receiver-dependent calibrations (delays) have to be applied to observable, any intentional internal offsets removed, but neither the code nor the phase observable are to be corrected by the influence of satellite or receiver clock offsets. The time tags are defined in GPS time (not UTC).
There are two important pieces, of information which are (or may be) receiver or antenna dependent:
i) Phase measurements performed on the original or the squared carrier. Ambiguities (and cycle slips) have to be formulated on either full-cycle or half-cycle level.
ii) The (average) phase center eccentricity for a specific antenna type, an information which is important as soon as different instrument/antenna types are to be combined.
RINEX, as it was presented in Las Cruces, defines three different file types: Observation file, navigation file, and meteorological data file. Each file consists of a header section containing station/receiver/antenna related information and a main body with the actual data. The files have a maximum record length of 80 characters and are written in ASCII to guarantee an easy exchange between different computer systems.
As soon as the data are exchanged in such a receiver-independent way only the provider of the data has to have available the means to interpret the instrument's raw data and format it into RINEX. Moreover, only the author of such a translator program has to really understand the definitions and the formats of the original raw data. Theoretically one such program per receiver type is necessary. This implies of course that every processing software accepts RINEX as standard (or optional)input format.
THE DEVELOPMENT OF TRANSLATOR PROGRAMS
The ideal case would be if the receiver manufacturers themselves developed the necessary software to translate the raw data of their receivers into RINEX because probably nobody else knows their receiver better. It may not be very easy to get the necessary information to be able to write one's own translator, to make sure that one takes into account all subtleties of the receiver, and - most difficult - to keep track on all changes and upgrades of the receiver hard- and software. During the time period of the EUREF-89 campaign there was no manufacturer-provided software available to transform the EUREF data into RINEX. The Astronomical Institute of the University of Berne (AIUB) therefore developed translators for WM-102, Trimble 4000 SLD, and Minimac 2816 instruments, and CIGNET data. The Geodetic Institute of the University of the Federal Armed Forces, Munich (Dr. H. Glasmacher) and the Geodetic Institute of the University of Hannover (Dr. G. Wuebbena) developed translators for the Texas Instrument TI-4100. The AIUB translator for WM-102 data does not start from the original raw data files (the cassette files) but from the "site measurement files" that have been created by the WM postprocessing software PoPS. The reason was the rather difficult reconstruction of the continuous L2 phase observable, which is done of course by PoPS. WILD Heerbrugg has written a small stand-alone program (WMAIUB) that extracts all station related information from the PoPS database and stores if into intermediate ASCII files.
All these translators are available upon request from the respective institutes.
Later the AIUB developed also translators for Ashtech and Rogue. Of course there are many other programs that translate raw data into either RINEX or other standardized formats, like e.g. the ARGO program developed at the US National Geodetic Survey (NGS) that accepts raw data from virtually all available geodetic receiver typed and transforms it into so-called NGS exchange format. (NGS plans to change ARCO, so that it will comply with RINEX format).
INTENTIONAL JUMPS IN THE RECEIVER CLOCK
With the introduction of receivers using low-cost oscillators we had to define methods to deal with instruments that reset the receiver clock by a distinct value (e.g. exactly 1 millisecond) as soon as the receiver clock offset (determined by the receiver in real-time) exceeds a certain limit.
Keeping in mind the original definition of the three fundamental RINEX qualities we have to reconstruct a consistent set of phase, code, and epoch values. Consistent means that the three quantities reflect the assumption that they all have been influenced by one and the same receiver oscillator:
i) The epoch value shows the reading of the receiver clock at the instant of measurement. The clock is driven by the receiver oscillator.
ii) The phase has been influenced by the oscillator through the reference frequency (which has been used to form the beat frequency) and the time of measurement
iii) The pseudorange by the offset of the receiver clock and the time of measurement
Given a certain receiver clock reading and assuming a certain receiver clock offset, dT, the phase will therefore show two differences with a phase measured with a perfectly synchronized receiver:
i) A contribution from the dynamics of the satellite/receiver system (especially motion, but also satellite clock drift) because the measurement has been performed too late (early), approximately dT* beat frequency *wl (in meters, wl being the carrier wavelength).
ii) A contribution from the wrong reference frequency. In meters its size is c * dT (c being the velocity of light).
(The latter contribution cancels as soon as we are forming differences between observations of different satellites, usually done as the second step on the way to the double difference observable).
The pseudorange will also show exactly the same two differences, the "dynamic' part as well as c * dT.
In order to generate a consistent set of observable we have three different possibilities:
i) We interpret the given epoch values as the readings of the original (i.e. non reset) receiver clock. We then have to correct the given observations by n * beat frequency * wl, n being the (signed) accumulated number of l millisecond resettings of the receiver clock. This linear correction is only an approximation, of course. We have now again a receiver clock drifting parallel with the driving receiver oscillator. We have to make sure that the phases and pseudoranges will also show the same clock drift (adding n * c, depending on what the receiver actually did with the raw observations).
ii) We correct the given epochs with the accumulated number of millisecond jumps. In this case we do not have to correct the phases. Here again we have a smoothly running receiver clock, and we have to verify that both the phases and pseudoranges show this clock drift.
iii) We leave the ephocs and observations as they are, i.e. we allow for a discontinuous receiver clock. However, we have to correct the phases by n * c to get a consistent set of observable even on the zero or single difference level.
The AIUB RINEX translators for Trimble and Ashtech receivers (which keep their receiver clocks within 1 millisecond clock offset) follow the second approach: In the subsequent data preprocessing it may have certain advantages to have a continuously running receiver clock, and we did not have to correct the phases with an approximate correction.
CORRECTION OF THE RECEIVER CLOCK OFFSET
Some receivers include into the raw data the current receiver clock offsets as they have been determined in real time by a navigation solution of the receiver. Either the receiver or the RINEX translator could now use these clock offsets to create fictitious observable corresponding to a fully synchronized receiver clock. Keeping in mind the definition of the RINEX observable such a procedure had to make sure that the resulting quantities again.make up a consistent system.
There are at least two possibilities:
i) Correction of the phase and the code observations
- by some interpolation (approximately dT * beat frequency * wl) to
"shift" them to the correct epoch and
- by the "frequency correction" c * dT
ii) Correction of the epoch value by dT and correction of the phase and the code observations the "frequency correction" c * dT
The second approach has the advantage to not use any approximations or difficult interpolations. There may be a slight disadvantage insofar as different receivers will then have different epoch value.
Observable corrected in such a consistent way will show in the usual phase and/or code post-processing a receiver clock offset nearer to zero the better the real-time estimation was. If the real-time correction failed it would automatically be corrected by the post-processing programs. There is of course a certain dilemma: An apriori correction will simplify the post-processing (we do not have to bother with receiver clock corrections anymore), but only if we fully rely on the real-time offset. If we decide to check the correction during post-processing there is not much difference to actually determining the clock offset anew.
CORRECTION OF THE SATELLITE CLOCK OFFSET
The definition of the RINEX observable explicitly asks for values NOT corrected by the influence of the satellite clock offsets; basically no corrections of any biases of external sources are to be applied to the observable. Especially in view of the selected availability (SA)it may be important to be able to correct the observable with an independently determined satellite clock model.
RECEIVE TIME VERSUS TRANSMIT TIME
There have been some requests from manufacturers as well as GPS users to allow for satellite transmit time as an optional time frame.
The consequences of such a request depend on what the stored raw data actually represent:
i) If they represented observations that have been collected for all satellites at the same instant (i.e. the received-signal times in the receiver time frame are identical for all satellites) the original phase and code observations would get satellite-dependent transmit times. RINEX however only allows for one common epoch for all satellites. The transmit times (in the satellite time frame) can easily be computed by subtracting the pseudorange observations (expressed in seconds) from the received- signal-time (in the receiver time frame). This is true even if the observable had previously been corrected for the clock offset - if done in the above-mentioned consistent way.
ii) If the data represented observations with a common epoch in satellite- transmit time, they could be easily stored in RINEX by flagging the epochs somehow, so that a user would be warned appropriately. One motivation for such a procedure could be the fact that only in this way could we guarantee simultaneous transmit times for measurements done at two different receivers in order to totally eliminate influences of the satellite clock (which looks very attractive in the presence of Selective Availability). However, identical transmit times inevitably lead to different received time's: different for the same satellite at the two receivers (which is no problem), but also different for the different satellites at one and the same receiver: In order to account for this effect we have to model the drift of the receiver oscillator between the different instants of signal reception with an accuracy according to the relationship
1 meter corresponds to 1/300th of a nanosecond!
Of course the same modeling has to be done for the satellite clocks if we have different transmit times for the observations of one satellite at two different receivers - obviously a sort of stalemate situation. However, there are three reasons to prefer identical receive time:
i) In view of the trend to cheap receiver oscillators it may be easier to model an unknown satellite clock than a receiver clock.
ii) Modern receivers try to synchronize the actual time of observation (received-signal time) to the full second GPS time. The maximum difference in satellite transmit time (the time period we have to model the satellite clock) is therefore 1 millisecond plus roughly the length of the baseline divided by c, i.e. an additional millisecond for each 300 km. Identical transmit times lead to a maximum difference in the received-signal times of two satellites at the same receiver (the time period we have to model the receiver clock) of nearly 20 ms! This difference could be even larger due to the satellite clock offsets, if they are not accounted for in the definition of the "transmit time".
iii) Most published observation equations (e.g. [Bauersima, 1983]) assume identical received-signal times for different satellites, and most geodetic receivers produce data with identical received-signal time tags (exception: Sercel receivers), so it appears the needs of more users are fulfilled by explicitly asking for simultaneous observations with respect to received-signal time tags. Consequently only the "exceptions", i.e. the RINEX translators for those receivers and the front end of processing software relying on simultaneous satellite transmission times have to develop special procedures.
CURRENT STATUS OF RINEX
An incomplete survey of receiver manufacturers and authors of GPS post-processing software about their use of RINEX as input or output format leads to the following overview:
| Instrument / Software | RINEX Output | RINEX Input |
Trimble / TRIMMBP |
yes |
yes |
WK-102 / PoPS |
*) |
no |
Minimac / AIMS |
planned |
planned |
Ashtech / GPPS |
announced |
? |
Sercel / |
no |
*) Officious RINEX translator: WMAIUB + W2RINEXN available at AIUB
Table 1: Manufacturer Software Creating RINEX
General Purpose Software |
RINEX Input |
Bernese Software (Bern) |
yes |
| DIPOP (New Brunswick) | yes |
| GAMIT (MIT) | yes |
| GAS (Nottingham) | yes |
| GIPSY (JPL) | ? |
| MAGNET (Magnavox) | planned |
| MicroCosm (Van Martin) | announced |
| OMNI (NGS) | planned |
| TOPAS (FAF Munich) | yes |
Table 2: General Purpose GPS Software Creating RINEX
PROPOSAL FOR RINEX VERSION 2
The first version of RINEX was intended to be used for static differential GPS applications only. We feel that in the first one and a half years of use RINEX proved to be a helpful means for easy exchange of GPS data. Especially the data collection and re-distribution of the-large EUREF-89 campaign (more than 60 receivers of four different types more than 90 sites) has been greatly facilitated by the receiver independent exchange format.
However, the following shortcomings have clearly come up:
i) The inclusion of rapid static data would call for as many observation files as there are station occupations.
ii) The inclusion of pseudokinematic or kinematic data is not possible because the data collected during motion could not be specially flagged.
This can easily be accounted for by additional definition of the epoch flag in the EPOCH/SAT record.
iii) Modem instruments may allow for full-cycle phase observations on some satellites and half-cycle measurements (squaring)in the presence of Antispoofing (AS) on other satellites. This asks for a satellite-dependent (maybe even epoch-dependent) wavelength factor.
iv) Some users would like to have the possibility to store the epoch-dependent receiver clock offset together with the observations into the RINEX files. (We would clearly see this as a free option and a certain break in the principle to not store any redundant information. These clock offsets would have to fulfill the same requirements of consistency as the phase and code observations and the time tags).
v) Although we do not yet know what GLONASS data will exactly look like we have to open up RINEX for data of other satellite systems. There are users who even would like to store TRANSIT data into a RINEX-type exchange file.
vi) We have been asked to include also a "site number" record into the header field. This request however is not as innocuous as it looks like at the beginning: We are immediately confronted with the problem of a numbering scheme. This is certainly beyond the scope of RINEX. We can include of course such a site number record, the "number" however would be just a string open to any denomination until somebody came up with an internationally accepted numbering scheme.
Possible enhancements of the format:
- We could insert event flag records between observation records to flag
a) the start of a new site occupation (followed by marker name and
antenna height records)
b) changes in the wavelength factors for some or all satellites
c) the start of a kinematic phase
d) external events
- We could allow for a free order of the records within the header (with
the exception of the first one, the RINEX VERSION record)
- We could allow for an additional number of optional header records
with default initialization
- We could additionally characterize the space vehicle number, namely to
indicate the satellite system it belongs to, if there are different
systems involved. We propose to store this information in the form:
snn where s = satellite system blank
defaults to GPS or the system
defined in the header
G:GPS, R: GLONASS, T: Transit
nn - 2-digit SV number
The appendix contains a proposal for a RINEX Format Version 2. The tables in the appendix contain the recommendations for additional changes agreed on during a format workshop held September 5, 1990 during the GPS 90 meeting in Ottawa.
CONCLUSIONS
The Receiver Independent Exchange Format (RINEX) has been successfully used in its first year of existence by many organizations all over the would as convenient means of data exchange and standard input format for static positioning data.
Relatively small changes in the current(RINEX) version of will account for data of multiple satellite systems, rapid static as well as pseudo-kinematic or kinematic data, and for data taken with systems, rapid static as we modem instruments under (partial) antispoofing conditions
REFERENCES
Bauersima, I. (1983): "Navstar/Global Positioning System (II)*. Mitteilungen der Satelltenbeobachtungsstation Zimmirwald, Nr. 10.
Evans, A. (1989), "Summary of the Workshop on GPS Exchange Formats". Proceedings of the Fifth International Geodetic Symposium on Satellite Systems,pp. 917ff, La Cruces
Gurtner, W., G. Mader, D. MacArthur (1989), "A Common Exchange Format for GPS Data." Proceedings of the Fifth International Geodetic Symposium on Satellite Systems,pp. 917ff, Las Cruces.
Scott, V.D., J. Clynch (1986),"A Proposed Standardized Exchange Format for Navstar GPS Geodetic Data". Proceedings of the Fourth International Geodetic Symposium on Satellite Systems, pp. 513ff, Austin, Texas.
APPENDIX
The following tables contain proposals for a RINEX Format Version 2.
Records marked with * are optional.
...................................................................
TABLE A1
OBSERVATION DATA FILE - HEADER DESCRIPTION
...................................................................
HEADER LABEL DESCRIPTION FORMAT
(columns 81-80)
.................................................................
RINEX VERSION/TYPE Format version (2) 16,14x,
File type ('O' for Observation Date) Al,19X,
Satellite System: blank or 'G: GPS ,A1,19X
"R" = GLONASS
"T" = NWSS Transit
"M" = Mixed
.......................................................................
PGM / RUN BY / DATE - Name of program creating current file A20,
- Name of agency creating current file A20,
- Date of file creation A20
.......................................................................
*COMMENT Comment Line(s) A60
.......................................................................
MARKER NAME Name of antenna marker A60
.......................................................................
*MARKER NUMBER Number of antenna marker A20
.......................................................................
OBSERVER / AGENCY Name of observer / agency A20,A40
.......................................................................
REC # / TYPE / VERS Receiver number, type, version 3A20
(Version: e.g. Internal Software Version)
.......................................................................
ANT # / TYPE Ant number and type 2A20
.......................................................................
APPROX POSITION XYZ Approximate marker position (WGS84) 3FI4.4
.......................................................................
ANTENNA: DELTA H/E/W -Antenna height: Height of bottom 3FI4.4
surface of antenna above maker
-Eccentricities of antenna center
relative to maker to the east
and north (all units in meters)
.......................................................................
WAVELENGTH FACT L1/2 - Wavelength factors for L1 will 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,
0: Default wavelength factors.
Max 7. If more than 7 satellites:
Repeat record.
- List of PRNS (satellite numbers) 7(3X,A1,I2)
.......................................................................
# / TYPES OF OBSERV - number of different observation types I6
stored in the file
- Observation types 9(4X,A2)
The following observation types are
defined in RINEX Version 2:
L1, L2: Phase measurements on L1 and L2
C1 : Pseudorange using C/A-Code on L1
P1, P2: Pseudorange using P-Code on L1,L2
D1, D2: Doppler frequency on L1 and L2
T1, T2: Transit Integrated Doppler on
150 (T1) and 400 KHz (T2)
Units : Phase : full cycles
Pseudorange : meters
Doppler : Hz
Transit : cycles
The sequence of the types in this record
has to correspond to the sequence of the
observations in the observation record
......................................................................
*INTERVAL Observation interval in seconds I6
......................................................................
TIME OF FIRST OBS Time of first observation record 5I6,F12.6
year (4 digits), month,day,hour,min,sec
.......................................................................
*TIME OF LAST OBS Time of last observation record 5I6,F12.6
year (4 digits), month.day.hour,min,sec
.......................................................................
# OF SATELLITES Number of Satellites for which I6
observations are stored in the file
.......................................................................
PRN / # OF OBS PRN (sat.number), number of observations 3X,A1,I2,9I6
for each observation type indicated
in the "# / TYPES OF OBSERV" - record
This record is repeated for each
satellite present in the data file
...........................................................................
END OF HEADER Last record in the header section. 60X
...........................................................................
---------------------------------------------------------------------------
TABLE A2
OBSERVATION DATA FILE - DATA RECORD DESCRIPTION
...........................................................................
OBS. RECORD DESCRIPTION FORMAT
...........................................................................
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
- Number of satellites in current epoch I3
- List of PRNS (sat.numbers) in current epoch 12(A1,I2)
If more than 12 satellites: Continued in
next line with n(A1,I2)
- Receiver clock offset (seconds, optional) F12.9
(GPS time = receiver time - offset)
If EVENT FLAG record (epoch flag >1):
-Event Flag:
2: start moving antenna
3: new site occupation (end on kinem. data)
(at least MARKER NAME record follows)
4: header information follows
5: external event (epoch is significant)
6: cycle slip records follow to optionally
report detected will repaired cycle slips
(same format as OBSERVATIONS records;
slip instead of observation; LL1 and
signal strength blank)
- "Number of satellites" contains number of
records to follow (0 for event flags 2,5)
..........................................................................
OBSERVATIONS - Observation rep. within record for m(FI4.3,
- LL1 each obs. type (same req I1,
- Signal strength as given In header) I1)
This record is repeated for each satellite
given in EPOCH/SAT - record.
If more than 5 observation types (=80 char):
Continue observations in next record.
Observations:
Phase : Units in whole cycles of carrier
Code : Units in meters
Missing observations are written as 0.0
or blanks.
Loss of lock indicator (LL1, important for
phase only)
0 or blank: OK or not known
1 (=bit 0): lost lock between previous and
current observation: cycle slip possible
2 (=bit 1): Inverse wavelength factor to
default (does NOT change default)
3 (=bits 0,1): lost lock, Inverse wlfact
Signal strength projected into interval 1-9:
1: minimum possible signal strength
5: threshold for good S/W ratio
9: maximum possible signal strength
0 or blank: not known, don't care
..........................................................................
--------------------------------------------------------------------------
TABLE A3
NAVIGATION MESSAGE FILE - HEADER SECTION DESCRIPTION
..........................................................................
HEADER LABEL DESCRIPTION FORMAT
(Columns 61-80)
...........................................................................
RINEX VERSION / TYPE Format version (2) I6,14X,
File type ('W' for Navigation data) A1,19X
...........................................................................
*COMMENT Comment lines (2) I6,14X
...........................................................................
*ION ALPHA Ionosphere parameters A0-A3 of almanac 2X,4D12.4
(page 18 of subframe 4
...........................................................................
*ION BETA Ionosphere parameters B0-B3 of almanac 2X,4D12.4
...........................................................................
*DELTA UTC: A0,A1,T,W Almanac parameters to compute time in 3X,2D l9.12,
UTC (page 18 of subframe 4) 219
AO,Al: term of polynomial
T : reference time for UTC data
W : UTC reference week number
...........................................................................
*LEAP SECONDS Delta time due to leap seconds I6
........................................ ..................................
END OF HEADER Last record in the header section. 60X
...........................................................................
---------------------------------------------------------------------------
TABLE A4
NAVIGATION MESSAGE FILE - DATA RECORD DESCRIPTION
---------------------------------------------------------------------------
PRN / EPOCH / SV CLK - Satellite PRN number I2,513,
F5.1,3D19.12
- Epoch: TOC - Time of Clock
year (2 digits)
month
day
hour
minute
second
- SV clock bias (seconds)
- Sv clock drift (sec/sec)
- SV clock drift rate (sec/sec2)
...........................................................................
BROADCAST ORBIT - 1 - AODE (age of data ephemeris) 3X.4Dl9.12
- Crs (meters)
- [EQN "Delta n"] (radians/sec)
- No (radians)
...........................................................................
BROADCAST ORBIT - 2 - Cuc (radians) 3X,4D19.12
- Eccentricity
- Cus (radians)
- Al/2 (meter 1/2)
...........................................................................
BROADCAST ORBIT - 3 - TOE Time of Ephemeris 3X,4D19.12
(seconds into GPS week)
- Cuc (radians)
- [EQN "Omega sub o"] (radians)
- Cis (radians)
...........................................................................
BROADCAST ORBIT - 4 - io (radians) 3X,4D19.12
- Crc (meters)
- [EGN "omega:] (radians)
- [EQN "omega dot"] (radians/sec)
...........................................................................
BROADCAST ORBIT - 5 - IDOT (radians/sec) 3X.4D19.12
- Codes on L2 channel
- GPS Week # (to go with TOE)
- L2 P data flag
...........................................................................
BROADCAST ORBIT - 6 - SV accuracy 3X,4D19.12
- SV health (MSB only)
- TGD (seconds)
- AODC (seconds)
...........................................................................
BROADCAST ORBIT - 7 - Transmission time of message 3X,4D19.12
(seconds into GPS week, derived e.g.
from Z-count in Hand Over Word (HOW)
- spare
- spare
- spare
...........................................................................
---------------------------------------------------------------------------
TABLE A5
OBSERVATION DATA FILE - EXAMPLE
...........................................................................
....|...1|0...|...2|0...|...3|0...|...4|0...|...5|0...|...6|0...|...7|0...|....8
2 OBSERVATION DATA M (MIXED) RINEX VERSION / TYPE
BLANK OR G = GPS, R = GLONASS, T = TRANSIT, M = MIXED COMMENT
XXRINEXO V9.9 AIUB 12-SEP-90 12:43 PGM / RUN BY / DATE
EXAMPLE OF A MIXED RINEX FILE COMMENT
A 9080 MARKER NAME
9080.1.34 MARKER NUMBER
BILL SMITH ABC INSTITUTE OBSERVER / AGENCY
X1234A123 XX ZZZ REC # / TYPE / VERS
234 YY ANT # / TYPE
4375274. 587466. 4589095. APPROX POSITION XYZ
.9030 .0000 .0000 ANTENNA: DELTA N/E/W
1 1 WAVELENGTH FACT L1/2
1 2 6 G14 G15 G16 G17 G18 G19 WAVELENGTH FACT L1/2
4 P1 L1 L2 P2 # / TYPES OF OBSERV
18 INTERVAL
1990 3 24 13 10 36.000000 TIME OF FIRST OBS
END OF HEADER
90 3 24 13 10 36.0000000 0 3Gl2G 9G 6 -.123456789
23629347.915 .300 8 -.353 23629364.158
20891534.648 .120 9 -.358 20891541.292
20607600.189 .430 9 .394 20607605.848
90 3 24 13 10 50.0000000 4 3
1 2 2 G 9 G12 WAVELENGTH FACT L1/2
*** WAVELENGTH FACTOR CHANGED FOR 2 SATELLITES *** COMMENT
COMMENT
90 3 24 13 1O 54.0000000 0 5Gl2G 9G 66R21R22 -.123456789
23619095.450 -53875.632 8 -41981.375 23619112.008
20886075.667 -28W.027 9 -22354.535 20886082.101
20611072.689 18247.789 9 14219.770 20611078.410
21345678.576 12345.567 5
22123456.789 23456.789 5
90 3 24 13 11 0.0000000 2
4 1
*** FROM NOW ON KINEMATIC DATA! *** COMMENT
90 3 24 13 11 48.000000 0 4Gl6G12G 9G 6 -.123456789
21110991.756 16119.980 7 12560.51O 21110998.441
23588424.398 -215050.557 6 -167571.734 23588439.570
20869878.790 -113803.187 8 -88677.926 20621649.276
20621643.727 73797.462 7 57505.177 20621649.276
3 4
A 9080 MARKER NAME
9080.1.34 MARKER NUMBER
.9030 .0000 .0000 ANTENNA: DELTA H/E/N
--> THIS IS THE START OF A NEW SITE <-- COMMENT
90 3 24 13 12 6.0000000 0 4G16G12G 6G 9 -.123456987
21112589.384 24515.877 6 19102.763 3 21112596.187
23579228.338 -268624.234 7 -209317.284 4 23578244.398
20625218.088 92581.207 7 72141.846 4 20625223.795
20864539.693 -141858.836 8 -110539.435 5 20864545.943
90 3 24 13 13 1.2345678 5 0
4 1
(AN EVENT FLAG WITH SIGNIFICANT EPOCH) COMMENT
................................................................................
-------------------------------------------------------------------------------- ................................................................................
OBSERVATION DATA FILE - EXAMPLE (continued)
................................................................................
90 3 24 13 14 12.0000000 0 4Gl6G12G 9G 6 -.123456012
21124965.133 89551.302 6 69779.626 4 21124972.275
23507272.372 -212616.150 7 -165674.789 5 23507288.421
20828010.354 -333820.093 6 -260119.395 5 20828017.129
20650944.902 227775.130 7 177487.651 4 20650950.363
90 3 24 13 14 12.0000000 6 2G16G 9
123456789.0 -9876543.5
0.0 -0.5
4 2
---> CYCLE SLIPS THAT HAVE BEEN APPLIED TO <--- COMMENT
THE OBSERVATIONS COMMENT
90 3 24 13 14 48.0000000 0 4G16G12G 9G 6 -.123456234
21128884.159 110143.144 7 85825.185 5 21128890.776
23487131.045 -318463.297 7 -248152.728 4 23487146.149
20817844.743 -387242.571 6 -301747.22925 20817851.322
20658519.895 267583.67817 205507.26234 20658525.869
4 3
*** SATELLITE G 9 THIS EPOCH ON WLFACT 1)(L2) COMMENT
*** G 6 LOST LOCK AND ON WLFACT 2 (L2) COMMENT
(INVERSE TO PREVIOUS SETTINGS) COMMENT
....|...1|0...|...2|0...|...3|0...|...4|0...|...5|0...|...6|0...|...7|0...|....8 ................................................................................
--------------------------------------------------------------------------------
................................................................................
TABLE A6
NAVIGATION MESSAGE FILE - EXAMPLE
................................................................................
....|...1|0...|...2|0...|...3|0...|...4|0...|...5|0...|...6|0...|...7|0...|....8
2 NAVIGATION DATA RINEX VERSION / TYPE
XXRINEXN v2.0 IGGP 12-SEP-90 15:22 PGM / RUN BY / DATE
EXAMPLE OF VERSION 2 FORMAT COMMENT
.1676D-07 .2235D-07 -.1192D-06 -.1192D-06 ION ALPHA
.1208D+06 .1310D+06 -.1310D+06 -.1966D+06 ION BETA
.133179128170D-06 .107469588780D-12 552960 551 DELTA-UTC: AO,A1,T,W
6 LEAP SECONDS
END OF HEADER
6 90 8 2 17 51 44.0 -.839701389031D-03 -.165982783074D-10 .000000000000D+00
.910000000000D+02 .934062500000D+02 .116040547840D-08 .162092304801D+00
.48410l474285D-05 .626740418375D-02 .652112066746D-05 .515365489006D+04
.09904000000OD+06 -.242143869400D-07 .329237003460D+00 -.596046447754D-07
.111541663136D+01 .326593750000D+03 .206958726335D+Ol -.638312302555D-08
.307155651409D-09 .OOOOOOOOOOOOD+00 .551OO0000000D+03 .000000000000D+00
.000000000000D+00 .000000000000D+00 .000000000000D+00 .910000000000D+02
.406800000000D+06
13 90 8 2 18 59 60.0 .490025617182D-03 .204636307899D-11 .000000000000D+00
.133000000000D+03 -.963125000000D+02 .146970407622D-08 .292961152146D+01
-.498816370964D-05 .200239347760D-02 .928156077862D-05 .515328476143D+04
.414000000000D+06 -.279396772385D-07 .243031939942D+01 -.558793544769D-07
.110192796930D+01 .271187500000D+03 -.232757915425D+01 -.619632953057D-08
-.785747015231D-11 .000000000000D+00 .551000000000D+03 .000000000000D+00
.000000000000D+00 .000000000000D+00 .000000000000D+00 .389000000000D+03
.410400000000D+06
....|...1|0...|...2|0...|...3|0...|...4|0...|...5|0...|...6|0...|...7|0...|....8 ................................................................................