RINEX 2 vs 3 vs 4: choosing a compatible GNSS format
Choose the RINEX version supported by both your receiver converter and your downstream processor. RINEX 3 provides constellation-specific observation identifiers; RINEX 4 extends the navigation-message framework. A newer format does not make measurements more accurate, and converting to an older version can discard information.
The differences that affect a workflow
| Format family | Practical distinction | Check before using it |
|---|---|---|
| RINEX 2 | Legacy observation conventions and two-character observable identifiers | Whether conversion loses signals needed by your analysis |
| RINEX 3 | Three-character observable identifiers, declared separately for each satellite system | The exact minor version and observation codes supported by the processor |
| RINEX 4 | Revised navigation records and support for additional navigation-message content | Observation and navigation support separately; one does not imply the other |
Sources: IGS: formats and standards
Do not confuse a standard with an implementation
The IGS formats page is the reference for published RINEX specifications. A program advertising RINEX 4 support may support only a subset of minor versions, constellations or navigation record types. Test one representative file through the entire conversion, QC and positioning chain before changing your field logging standard.
- Record the converter version and output version in the processing record.
- Confirm the target engine accepts the observation signals you will retain.
- Check the navigation file independently. Successfully opening the observation file is not an end-to-end compatibility test.
Sources: IGS: formats and standards
Check these header records after conversion
- RINEX VERSION / TYPE: verify version, file purpose and satellite-system designation.
- SYS / # / OBS TYPES in RINEX 3/4: compare the declared code, phase, Doppler and strength fields with the source.
- TIME OF FIRST OBS and TIME OF LAST OBS, when present: confirm the intended session and declared time system against actual epochs.
- INTERVAL: compare it with measured epoch spacing instead of assuming the header is correct.
- ANT # / TYPE and ANTENNA: DELTA H/E/N: reconcile with the station log and the field height measurement convention.
- APPROX POSITION XYZ: check for plausible Earth-centred coordinates. An approximate header position is not necessarily surveyed control.
Sources: IGS: formats and standards
Hatanaka compression is a separate choice
A .crx file is a compact representation of RINEX observations. A .gz suffix represents an additional general-purpose compression layer, so a .crx.gz file commonly needs both layers decoded. Compression does not turn observations into navigation data or resolve a version mismatch. Keep a decompression-capable tool in the workflow and compare decoded observations when checking preservation.
Sources: IGS: formats and standards
A safe compatibility trial
Start with a short, representative multi-GNSS session containing the signals you actually use. Convert it to the proposed version, then compare the start and end times, epoch count, satellites, observation types and missing-data flags. Run QC and a positioning trial, and inspect warnings before adopting the new version for a whole archive.
- Do not declare a conversion lossless from file size or successful exit status alone.
- Retain the original receiver file and the conversion log.
- If a legacy processor requires RINEX 2, document which modern observations were removed or mapped.
References and methodology
Technical definitions follow the sources below. Worked examples are illustrative; product-specific thresholds are identified as PosFlow settings. For corrections, contact PosFlow with the article URL and the relevant specification.