Werner Gurtner

Astronomical Institute
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 interpt 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 epochs 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 processing 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:

*) Officious RINEX translator: WMAIUB + W2RINEXN available at AIUB

---

Table 1: Manufacturer Software Creating RINEX

---

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 pseudo-kinematic 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 Anti-spoofing (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) anti-spoofing 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 (provided in a text document to preserve formatting)