RINEX

The RINEX stands for (Receiver Independant EXchange Format) and is a standard ASCII file format used to store RAW GNSS observables. This file format allows Qinertia to process any type of GNSS receiver RAW data.

RINEX conventions

RINEX standard defines the file format as well as the file naming conventions to use. This is especially helpful to properly store and organize GNSS base stations RINEX data.

The RINEX 3 and the RINEX 2 versions have two different naming conventions. This page provides only basic explanation about the different RINEX files and naming conventions.

Please visit the IGS web site https://kb.igs.org/hc/en-us/articles/201096516-IGS-Formats to access full RINEX standard.

RINEX 3.x

The RINEX 3.x standard introduces a new naming convention that is relying on modern file systems. The new naming convention is more descriptive as the old MS-DOS limitation is not relevant anymore.

The following file convention is defined to store all GNSS data including observations and navigation data:

The following file name examples are extracted from the official RINEX 3.04 specification.

RINEX 2.x

The 2.x standard defines a very simple naming convention and uses multiple files to store each type of measurements:

ssssdddf.yyt
|   |  | | |
|   |  | | +--  t: file type:
|   |  | |            O: Observation file
|   |  | |            N: GPS Navigation file
|   |  | |            M: Meteorological data file
|   |  | |            G: GLONASS Navigation file
|   |  | |            L: Future Galileo Navigation file
|   |  | |            H: Geostationary GPS payload nav mess file
|   |  | |            B: Geo SBAS broadcast data file
|   |  | |                          (separate documentation)
|   |  | |            C: Clock file (separate documentation)
|   |  | |            S: Summary file (used e.g., by IGS, not a standard!)
|   |  | |
|   |  | +---  yy: two-digit year
|   |  |
|   |  +-----   f: file sequence number/character within day
|   |                daily file: f = 0
|   |                hourly files:
|   |                f = a: 1st hour 00h-01h; f = b: 2nd hour 01h-02h; ...
|   |                f = x: 24th hour 23h-24h
|   |
|   +-------  ddd: day of the year of first record
|
+----------- ssss: 4-character station name designator

RINEX Support

Qinertia can import RAW GNSS data from RINEX files to process rover and base station data. Both kinematic and static computations are supported. Qinertia support also compressed GZIP RINEX files as it can be found on several CORS providers.

Qinertia supports observations files at any rate up to 100 Hz for rover kinematic data and down to 30 seconds for base station data. Qinertia also handles automatically GNSS observations interpolation so you can safely compute a PPK solution using rover data at 20 Hz and base stations data at 30 seconds.

Last but not least, Qinertia is able to cope with GNSS observations that are not aligned to plain seconds even for kinematics computations. This feature is very unique and has to be implemented in the RTK engine itself. There is absolutely no way to align GNSS data during RINEX conversion as this will only work for static observations.

Qinertia supports the following RINEX versions:

Native format vs RINEX

It's always better to use directly the GNSS manufacturer binary protocols as most RINEX converters tends to reduce accuracy and reliability. Qinertia supports natively several GNSS manufacturer file formats such as Septentrio, Ublox, Novatel and Trimble. Using native format both ease the post processing workflow but also avoids potential issues that could come from the RINEX conversion process.

RINEX Conversion

When you convert RAW GNSS data to RINEX, always try to disable all options that could modify the RAW GNSS data. For example, if you have a a GNSS receiver that outputs observations that are not aligned on the plain second such as u-blox F9 receivers, never ever use a RINEX converter tool to re-align the data to plain seconds!