GNSS files explained: RINEX, SP3, CLK, ANTEX and RTCM
RINEX observation files hold receiver measurements; RINEX navigation files hold broadcast satellite messages. SP3 and CLK provide precise satellite orbit and clock products, while ANTEX supplies antenna calibration models. RTCM is a family of exchange messages, often delivered as a stream. These files have different roles and are not interchangeable.
Which file answers which question?
| Data | Role | It does not replace |
|---|---|---|
| RINEX observation | Code, phase and other measurements recorded by a receiver | A reliable coordinate for a base station |
| RINEX navigation | Broadcast satellite orbit, clock and related navigation information | Receiver observations |
| SP3 | Precise satellite positions and optional additional fields | The clock product required by a particular processing strategy |
| CLK | Clock corrections in the clock exchange format | A precise orbit file |
| ANTEX | Satellite and receiver antenna phase-centre models | The antenna height and radome recorded at your site |
| RTCM stream or recording | Message types carrying observations, corrections or reference-station information | A guarantee that all messages needed for post-processing are present |
Sources: IGS: formats and standards · IGS: GNSS products
Identify the content, not just the filename
A receiver can create proprietary binary logs, ASCII messages and solved-position exports in the same session. Renaming any of those to .rnx does not convert it. Inspect the header or message inventory, then use a converter that supports the actual receiver protocol and firmware. For compressed data, identify both the compression layer and the enclosed GNSS format.
- A RINEX observation file should expose epochs and observation-type declarations.
- A navigation file contains satellite navigation records rather than station observation epochs.
- A coordinate CSV or NMEA track is an output or navigation log, not a substitute for raw phase measurements.
Sources: IGS: formats and standards
Match precise products as a set
For PPP, follow the processing engine’s requirements for orbit, clock, antenna and bias products. Products from different analysis centres or processing conventions should not be mixed casually. Check the product family, satellite coverage, reference frame, sampling interval and observation date, including coverage around the edges of a session.
- Cover the full observation interval, especially sessions crossing midnight.
- Check that the selected products include the satellite systems the engine will process.
- Use antenna calibrations consistent with the processing conventions and the actual receiver antenna.
- Record product filenames and processing settings so the run can be reproduced.
Sources: IGS: GNSS products
Prepare inputs for three common jobs
| Job | Start with | Then confirm |
|---|---|---|
| Observation QC | A readable observation file | Navigation data or auxiliary products required for the selected metrics |
| Relative PPK | Overlapping rover and base observations | Base coordinates, antenna information, navigation data and engine requirements |
| PPP | Code and phase observations from the rover or station | Compatible precise products, antenna model and the intended output frame |
An upload succeeds, but processing reports missing data
Treat upload acceptance and scientific input completeness as different checks. A server can store a valid file that is the wrong role for a job. Read the report for missing epochs, unavailable satellite products, unsupported navigation records or antenna-model mismatches. Add the required companion data or correct the configuration before repeating the same run.
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.