Uncovering the history, philosophy and benefits of RINEX for the storage and exchange of GNSS data.

By Dr Volker Janssen

The Receiver Independent Exchange (RINEX) format is the international standard for the storage and exchange of Global Navigation Satellite System (GNSS) data. It allows efficient and unambiguous archiving of GNSS data and associated metadata in one place (in a human-readable form), while also facilitating the easy transfer and distribution of such data, independent of the equipment used and the data processing software employed.

Over the years, the RINEX format has continually been improved and expanded to cater for modern satellite positioning data collected by a growing number of satellite constellations and their signals. Without RINEX, the generation of many valuable products and services by the International GNSS Service (IGS) would not have been possible.

RINEX files are universally used by international and national organisations, academia, all levels of government and private industry. Online processing services, such as Geoscience Australia’s AUSPOS, require the user to submit data in RINEX format.

Consequently, it is important for professional surveyors to understand the contents and format of these files. This article provides a brief history of the RINEX format, outlines examples of recent RINEX versions and discusses the editing of observation files.

RINEX history

All manufacturers store raw GNSS (and most other survey) data in proprietary, binary (non-human readable) formats. These are designed to be compact, optimise specific observations, enhance performance with their own algorithms and software modules (or suites) and lock users into their brand.

Swapping raw survey data between brands was never intended — until RINEX was invented.

The RINEX format was initially developed in the late 1980s by the Astronomical Institute of the University of Bern, Switzerland, to facilitate the exchange of GPS data to be collected during the first large European GPS campaign, EUREF89, which involved more than 60 GPS receivers of four different manufacturers.

Note the complexity and delicacy of negotiations and confidence that was entrusted to this organisation to gain access to the proprietary intellectual property of the major manufacturers and the very idea of championing interoperability.

RINEX defined three different file types to account for GPS observation data, navigation messages and meteorological data. Each RINEX file consisted of a header section containing metadata related to the station occupied and the equipment used, followed by a main body with the actual data.

The files were designed to have a maximum line length of 80 characters, written in American Standard Code for Information Interchange (ASCII) to enable humans to read (and edit) the data and guarantee the easy exchange between different computer systems. Consequently, data observed by a multitude of receiver brands and models could be processed together.

Over many years, and under the umbrella of the IGS, the RINEX format has since been modified, expanded and improved to allow multi-GNSS data to be handled, thus becoming the international standard for the archival and distribution of GNSS data by the IGS and countless other users worldwide.

For example, this has resulted in the computation of the ever-improving International Terrestrial Reference Frame (ITRF). Based on the collation and processing of globally collected GNSS data, the IGS provides a wide range of valuable products, including precise satellite orbits and clocks, terrestrial reference frame products (e.g. station positions and earth rotation parameters) and global ionospheric maps.

RINEX versions

The original RINEX version 1 was introduced in 1989. Version 2 followed in 1990, adding the possibility to include tracking data from different satellite systems. Over time, it was modified via several sub-versions, culminating in version 2.11.

Version 3 was developed in the early 2000s and initially released in 2007 to support multi-GNSS and clearly identify the different tracking modes by introducing 3-character observation codes for all GNSS constellations. Over time, it was modified via several sub-versions, culminating in version 3.05.

Version 4 was released in 2021 as a necessary step to support the modern multi-GNSS navigation messages by introducing navigation ‘data records’ to hold individual satellite navigation messages, constellation-wide parameters and global parameters transmitted by the different GNSS constellations. It has since been updated to version 4.01.

RINEX 3.04 and 3.05

Following several revisions for improvement and clarification, RINEX 3.05 is the last official version 3 format. Its major difference to the earlier RINEX 2.11 is that it fully supports multi-GNSS (G = GPS, R = GLONASS, E = Galileo, C = Beidou, J = QZSS, I = NavIC/IRNSS, S = SBAS) and clearly identifies the tracking mode of each observation via 3-character observation codes.

Some software currently supports formats up to RINEX 3.04 only, which has minor differences to the latest version (apart from missing signals and tracking codes to fully support the second and third generation of Beidou).

The RINEX 3.04/3.05 file naming convention (Figure 1) stipulates a much longer file name than RINEX 2.11, providing more detailed information about the dataset collected by being more descriptive, flexible and extendable. Introduced with RINEX 3.02, this facilitates the efficient storage and exchange of RINEX data in large communities like the IGS.

For practical surveying applications, this naming convention may appear too detailed to be adopted. However, users of IGS products or Continuously Operating Reference Station (CORS) data need to understand the long RINEX file names to obtain the desired data for their purposes.

The following examples illustrate the benefit of the long file naming convention, with data source, start time, duration, sampling rate and data type now easily visible as part of the file name.

BATH00AUS_R_20230621500_03H_30S_MO.rnx indicates a RINEX observation file for Bathurst CORS (being the first monument [0] and the first receiver [0, unless additional receivers are connected to the same antenna] located at this site in Australia), sourced from a receiver (via vendor or other software), observed in 2023 on day of year 062 and starting at 15:00 hours, that contains 3 hours of data at a 30-second sampling rate and mixed GNSS observation data (as opposed to GPS-only).

Accordingly, BATH00AUS_R_20230620000_01D_MN.rnx.gz indicates a compressed (the added gz extension specifies gzip compression) RINEX navigation file collected at Bathurst CORS, being the first monument and receiver at this site, sourced from a receiver, observed in 2023 on day of year 062, starting at 00:00 hours and containing 1 day of mixed GNSS navigation data.

As in the older versions, the RINEX observation file consists of a header section followed by a data section and ends with a blank line. While each row in the header continues to have a maximum length of 80 characters, this limitation has been removed for the data section.

Figure 2 shows a typical RINEX 3.04 header, including the following information:

• Line 1: RINEX version, specifying an observation file with mixed GNSS data.
• Line 2: Program used to generate the RINEX file, who ran it (here blank) and when it was run.
• Line 3: Marker name, here the 4-character ID issued to NSW by Geoscience Australia.
• Line 4: Marker number, here the Survey Control Information Management System (SCIMS) number used in NSW.
• Line 5: Marker type, here geodetic (earth-fixed, high-precision monument). Selecting an attribute other than GEODETIC or NON_GEODETIC (low-precision monument) indicates that the data was collected by a moving receiver (e.g. on a person, car, aircraft, glacier or animal).
• Line 6: Observer and agency, here indicating an organisation external to DCS Spatial Services.
• Line 7: Receiver serial number, receiver type and firmware version.
• Line 8: Antenna serial number (for integrated antennas the same as the receiver) and antenna type (using the IGS naming convention).
• Line 9: Approximate site position in Cartesian coordinates.
• Line 10: Antenna height (measured vertically between ground mark and the Antenna Reference Point, ARP) and any horizontal offset from the mark (if applicable).
• Line 11-14: For each satellite system, the number and types of observations, here specifying eight observation types for GPS, four for GLONASS, six for QZSS and four for Galileo. The 3-character observation codes include observation type (C = pseudo-range, L = carrier phase, D = Doppler, S = signal strength, X = receiver channel number), band/frequency (range 1-9) and attribute (tracking mode or channel, e.g. C, P, W, I, Q). For instance, for GPS, L1C and C1C are the L1 carrier phase and pseudo-range derived from the C/A code, while L2W and C2W are the L2 carrier phase and pseudo-range derived from Z-tracking (an effective method to acquire the encrypted P(Y) code under Anti-Spoofing conditions). This example only contains code and carrier phase measurements to keep the file width manageable.
• Line 15: Signal strength unit (DBHZ = signal-to-noise ratio in dbHz).
• Line 16: Sampling interval, here 30 seconds.
• Line 17: Comment, here the raw binary file name (can be placed anywhere between the first and last line in the header).
• Line 18-19: Time of first and last observation epoch, here 01:46:00 and 05:15:30 hours (GPS time) on 29 June 2023, respectively.
• Line 20: Receiver clock offset applied (0 = no, 1 = yes).
• Line 21-22: GLONASS slot and frequency numbers, indicating the number of satellites in the list followed by each satellite number and its frequency number (range -7 to +6).
• Line 23-25: Phase shift correction used to generate phases consistent with respect to cycle shifts, stated for each affected satellite system and carrier phase observation code. Here, three observation codes include a correction of -0.25 or +0.25 cycles.
• Line 26: Number of leap seconds between GPS time and UTC, here 18.
• Line 27: End of RINEX header indicator.

Figure 3 shows a typical RINEX 3.04 observation data block, containing the following information:

• Line 28: Observation epoch date and time in the format year, month, day, hours, minutes, seconds (here 01:46:00 hours on 29 June 2023), epoch flag (0 = OK, 1 = power failure between current and previous epoch, >1 = special event, e.g. 2 = start moving antenna), and the number of satellites in the current epoch (here 15). The special character ‘>’ preceding the epoch information was introduced as an identifier to enable reading programs to easily detect the next epoch in case of a corrupted data file or when streaming observation data in a RINEX-like format.
• Each following line contains the observations from a single satellite, starting with the system identifier and satellite identifier (PRN). In this example, two Galileo, seven GPS, one QZSS and five GLONASS satellites were observed. The previous length limitation to 80 characters per row no longer applies as this now depends on the observation type list declared in the RINEX header and the available observables per satellite per epoch.
• Line 29: Observations recorded for the first satellite (E02) — see line 14 in Figure 2 for the corresponding Galileo observation types in the RINEX header. Each observation value continues to be defined as a float value of total length 14 with 3 decimals (F14.3), followed by two optional single-digit integer records (I1) representing the Loss of Lock Indicator (range 0-7 or blank, phase observations only) and the Signal Strength Indicator (range 1-9 for increasing signal strength or blank).
• Line 30-43: Observations recorded for the other satellites in this epoch, with missing observations (or those not observed) indicated as blanks.

RINEX 4.00 and 4.01

Adopted by the IGS in December 2021, RINEX 4.00 was necessary to accommodate the modernised navigation messages from all the different GNSS constellations. Once fully implemented, version 4 will future-proof the format of the navigation messages long term.

RINEX 4.00 observation files are backward compatible with RINEX 3.0X, hence there is no issue with their storage and usage. RINEX 4.00 provides minor extensions in observation types and extended header lines but no major format change, making adoption a minor evolution.

However, RINEX 4.00 navigation files are not backward compatible with RINEX 3.0X files. This is why the RINEX version number was increased rather than utilising another RINEX 3.0X sub-version.

But no change is necessary in file naming and storage because navigation files of all types can be stored together in different RINEX versions without any issue. All RINEX files state the version number in the first line and most reader programs will skip over unknown navigation file versions until they are ready to process them.

Development has since continued to add clarifications and new observation codes for upcoming GPS satellites and for L1 NavIC signals, resulting in RINEX 4.01 being released in July 2023. This development has been conducted in collaboration with equipment manufacturers and software generators, ensuring that equipment and software tools able to produce and process RINEX version 4 files will be available in due course to enable implementation and broader adoption.

Editing RINEX observation files

Regardless of the version used, the RINEX header often contains incorrect or incomplete information when initially generated (e.g. the manufacturer’s receiver and antenna names not following the IGS naming convention, a default antenna type or a zero antenna height), so thorough editing is important to avoid confusion further downstream.

For example, the RINEX format stipulates the antenna type as a 20-character name (see columns 21-40 of line 8 in Figure 2), including several spaces and ending with a 4-character indication of the radome (antenna cover) used (NONE = no radome present). This IGS naming convention is also used by AUSPOS.

If the antenna height was not measured directly and vertically to the ARP in the field, then it must be converted using the offsets and method specified in the GNSS equipment manual (generally applying Pythagoras in conjunction with a vertical offset). The correctness of antenna height and type is crucial to allow the correct antenna model to be applied correctly in processing.

This particularly applies for data archival, data sharing or submission to third parties (especially where machine-to-machine processes are likely to be employed). Ensuring the correctness of the information in the RINEX header is not only good practice but also very valuable when mining data for purposes not envisaged when originally collected (see Position 122, Dec/Jan 2022–23).

The RINEX file should be visually inspected to ensure that the first and last few epochs contain reasonably complete data blocks. If epochs at the start/end of the observation are deleted, the time of the first/last observation in the RINEX header should be modified accordingly.

Hopefully, this article has helped you to better understand the RINEX format, the philosophy behind it, and its benefits.

Dr Volker Janssen works at DCS Spatial Services, a unit of the NSW Department of Customer Service.

This article was first published in Issue 129 (Feb/Mar 2024) of Position magazine. Please consider subscribing.