← Blog

RINEX Files Explained: Versions, Converters, OPUS and PPP

By Antonio Liska • June 9, 2022 • Updated September 2, 2026

What is a RINEX file?

A RINEX file is a plain-text record of what a GNSS receiver measured: which satellites it tracked, when, and the pseudorange, carrier phase, Doppler and signal strength for each one. RINEX stands for Receiver Independent Exchange Format, and the middle word is the point: it is the neutral format that OPUS, CSRS-PPP, RTKLIB, Trimble Business Center and everything else can read, whatever receiver produced the data. If someone has asked you “what is a RINEX file, and can you send me one,” this is the answer, including which version to pick and what the services check.

The two files you will actually meet

Observation file (.obs, .o, or .25o-style extensions): the measurements, one block per epoch; the file OPUS and PPP services want.

Navigation file (.nav, .n, .g, .p): the broadcast ephemeris, the satellites’ own description of their orbits and clocks. Online services do not need it, because they substitute precise IGS orbits; local software such as RTKLIB does.

What the header looks like

Every RINEX file opens with a header: version, receiver and antenna type, approximate position, antenna offsets and the observation codes that follow. Most rejections trace back to it. This one is from a RINEX 3.03 file converted from a RoboDot recording, mixed GPS, GLONASS and Galileo, with the first epoch marker at the end:

     3.03           OBSERVATION DATA    M: Mixed            RINEX VERSION / TYPE
RBTCONV                                 20250313 172247 UTC PGM / RUN BY / DATE
log: C:\xxx\Downloads\dot585m03d13y25h15m32s41gpst.r        COMMENT
format: RUB                                                 COMMENT
Robota                                                      COMMENT
                                                            MARKER NAME
                                                            MARKER NUMBER
                                                            MARKER TYPE
                                                            OBSERVER / AGENCY
                                                            REC # / TYPE / VERS
0                   ADVNULLANTENNA                          ANT # / TYPE
  -642265.0939 -5335069.5516  3424687.5522                  APPROX POSITION XYZ
        0.0000        0.0000        0.0000                  ANTENNA: DELTA H/E/N
G   12 C1C L1C D1C S1C C2L L2L D2L S2L C2S L2S D2S S2S      SYS / # / OBS TYPES
R    8 C1C L1C D1C S1C C2C L2C D2C S2C                      SYS / # / OBS TYPES
E    8 C1C L1C D1C S1C C7Q L7Q D7Q S7Q                      SYS / # / OBS TYPES
  2025     3    13    15    33    1.0040000     GPS         TIME OF FIRST OBS
  2025     3    13    16    35   37.0050000     GPS         TIME OF LAST OBS
G                                                           SYS / PHASE SHIFT
R                                                           SYS / PHASE SHIFT
E                                                           SYS / PHASE SHIFT
 0                                                          GLONASS SLOT / FRQ #
 C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS
                                                            END OF HEADER
> 2025  3 13 15 33  1.0040000  0  7

Read the SYS / # / OBS TYPES lines first: G 12 means twelve GPS observables (code, phase, Doppler and signal strength on L1 C/A and both L2C codes), and the E line confirms Galileo E1 and E5b made it in. Field-by-field definitions for every version are in the gAGE format library.

RINEX 2 vs 3 vs 4

Version	Date	What changed	Use it when
2.11	2004 (corrected 2012)	GPS, GLONASS, SBAS and Galileo with two-character codes (C1, P2, L1, L2); no BeiDou; one navigation file per constellation	The tool is old, or the tool is OPUS
3.0x (3.05 final)	2007–2020	All constellations in one file; three-character codes (C1C, L2W, C5Q) that name band, channel and tracking mode; long filenames from 3.02	Default for multi-GNSS or multi-band data
4.0x (4.02 current)	2021 onward	Observation records essentially unchanged; navigation records restructured for modern messages (CNAV, Galileo I/NAV and F/NAV, ionosphere, system time)	Only when the software asks for it

Pick the version your tools read, not the newest. 3.04 is what most desktop packages and converters write today, ours included, and is a safe default; 2.11 is the safe choice for OPUS and legacy software. Do not reach for 4.x by default: OPUS documents versions 2 and 3 only, and older programs will not parse it.

One caution on 2.11: it has no BeiDou, and although Galileo is defined in the format, many converters drop it when you force that version, so check the header. Harmless for OPUS, which uses GPS only; a real loss for PPK.

How to get a RINEX file from your receiver

Many receivers log a native binary format that you convert afterward; some, including Septentrio, Emlid and certain Trimble and Leica configurations, can write RINEX directly.

u-blox (ZED-F9P, NEO-M8T and similar). Enable UBX-RXM-RAWX and UBX-RXM-SFRBX at 1 Hz and log the stream to a .ubx file with u-center. Convert it with RTKLIB’s RTKCONV, or upload the .ubx to Robota’s free converter at robognss.com/tools/convert-to-rinex, which reads UBX directly and needs no software installed. Without SFRBX you get observations but no navigation file.

RoboDot Touch. Turn on “Record on Boot” and it starts recording once it has a GNSS lock, or use the Rec/Stop button on the Status or Rover pages; a green indicator confirms it is logging. For an OPUS coordinate, start recording as soon as the base is on its mark and leave it running for at least two hours: that qualifies the file for OPUS static, and the rapid-static mode OPUS falls back to for shorter files is notoriously hit-or-miss. Download the .rub recording from the Files page in the web UI, then convert it with the free converter at robognss.com or with the RoboDot Utility software, which writes two files at once: a GPS-only one for OPUS and an all-constellation one for every other processor. Base and rover recordings work the same way, which is what makes the PPK workflow possible when the radio or NTRIP link drops.

Trimble, Leica, Topcon, CHC and others. Each has a proprietary raw format (.T02, .m00, .tps, .hcn) and a manufacturer utility to export RINEX. For editing and merging files afterward, gfzrnx has replaced the retired teqc, but it is free for non-commercial use only.

What OPUS expects

NGS’s OPUS is the standard way to get a precise coordinate for a base-station mark in the US. Its rules:

• GPS only. OPUS “only uses GPS observables (even if the file contains other GNSS observables).”
• Dual frequency. L1/L2 full-wavelength carrier phase is required. Files under two hours “must include both P2 observables and either P1 or C1 observables.” Single-band receivers cannot use OPUS.
• Session length. Rapid-static: 15 minutes to 2 hours. Static: 2 to 48 hours. The file may cross UTC midnight, but not more than once.
• Interval. 1 to 30 seconds; OPUS decimates everything to 30 seconds, so a 1 Hz file only makes the upload larger.
• Format. RINEX 2 or RINEX 3; compressed UNIX, gzip, pkzip and Hatanaka files are all accepted.
• Antenna. Pick the exact antenna model from the NGS list and enter the vertical height of the Antenna Reference Point above the mark, in meters. NGS warns that “choosing an incorrect antenna may result in a height error as large as 80 cm and a horizontal error up to 1 cm.”

When your antenna is not on the list: NONE

The RoboDot workflow tells you to choose NONE as the antenna type, and that alarms people the first time. It is well defined. For a listed antenna, OPUS knows the distance from the reference point at the base of the antenna up to its electrical phase center and applies it for you. With NONE, there is no such model, so the coordinate OPUS returns is the phase center itself, lowered by exactly the height you type in. Enter 0 and you get the phase center. Enter the distance from the mark up to the phase center and you get the mark. The one mistake is to enter a height measured to the bottom of the antenna under NONE, because then the phase-center offset is silently missing from the result. On a RoboDot Touch the phase center sits 9.4 cm above the bottom of the unit, so mark-to-phase-center is your pole or tripod height plus 0.094 m.

OPUS emails the solution. See the beginner’s toolbox for OPUS and its companion tools, and mapping a site without an initial survey point for feeding the result back into a drone survey.

What CSRS-PPP expects

Natural Resources Canada’s CSRS-PPP is the usual alternative outside the US and works anywhere on Earth. Where OPUS differences a baseline to nearby CORS stations, CSRS-PPP processes your file alone against precise orbits and clocks, the PPP approach. It uses GPS, GLONASS and Galileo (Galileo since 2014, with ambiguity resolution since late 2022), accepts RINEX 2 and 3 observation files (use 3 if the file contains Galileo), static or kinematic, single- or dual-frequency, single at reduced accuracy. Results arrive by email in NAD83(CSRS) or the ITRF; submitting needs a free NRCan account. Longer static sessions converge further, so log as long as the job allows.

Common conversion and submission pitfalls

1. Wrong antenna height or wrong reference point. Slant height entered as vertical, or a bottom-of-antenna height entered where a phase-center height was expected: the usual cause of a bad ellipsoid height.
2. Wrong antenna type. A mismatched model shifts your height by the difference between the two phase-center offsets. NONE is not wrong, as long as the height you enter is measured to the phase center (see above).
3. Forcing RINEX 2 on a multi-constellation log. BeiDou gone, Galileo often gone (see above); bad for PPK.
4. Session too short, or interrupted. A 12-minute file, a stop-and-restart, or a recording that crosses UTC midnight twice (OPUS allows one crossing). Under two hours you are in rapid-static territory, and rapid-static solutions fail or wander far more often than static ones.
5. Receiver moved. Recording that starts before the antenna is set produces cycle slips at the start; trim the file, or start recording later.
6. No SFRBX / no navigation data when processing locally. Online services do not care; RTKLIB does.
7. Missing approximate position in the header. Some converters leave it at zeros; some services reject the file for it.
8. Version 4 file into a version 3 tool. A “not a RINEX file” error, or a silent parse failure.
9. Hatanaka-compressed file with a normal extension. A .crx renamed to .obs looks corrupt to most tools.

Checklist before you upload

• Observation file, RINEX 2.11 or 3.04
• Antenna model chosen from the service’s list, with the height measured to the reference point that model expects; or NONE with a height measured to the phase center
• Session long enough for the mode you are requesting; two hours or more for OPUS static
• Header shows the right receiver, a non-zero approximate position, and the observation codes you expect
• Constellations you need are actually in the file (check the SYS / # / OBS TYPES lines, as in the sample above)

First base setup? Repeatably set up a GPS base station and build your RTK base station in 7 steps cover the fieldwork; the surveying glossary has the acronyms.

Where Robota fits

Robota’s free converter at robognss.com/tools/convert-to-rinex takes u-blox UBX, RTCM 2 and 3, NovAtel, Septentrio SBF, Javad, BINEX, Trimble RT17 and RoboDot .rub files up to 50 MB and writes RINEX 2.11, 3.02 or 3.04. A free RoboGNSS account is required. Upload a supported raw log, choose a RINEX version, and download the converted file.

The RoboDot Touch records raw observations to its 8 GB memory in base, rover and logger modes, so a day of base-station data is a download and a conversion away from an OPUS-grade coordinate. Deciding between your own base and a correction service? The RTK base station page and what is NTRIP cover the trade-off.