2.3.1. Introduction

2.3.1.1. What the Module Does

The GNSS Processing module turns a folder of RINEX observation files into adjusted network observations. It is the missing link between a static GNSS campaign and the Network Adjustment module: you point it at the files your receivers produced, it works out who observed with whom and when, solves the baselines with RTKLIB, lets you inspect and reject what came out, and finally writes the accepted baselines into the same adjustment project the network tools read.

The module is opened from the sidebar under Calculations > GNSS Processing.

The whole job is organised as six pages, worked left to right:

Page	What you do there
Files	Scan a folder of RINEX files, check what the headers say, name the points and mark the reference (base) stations.
Sessions & Baselines	Let the module group the files into simultaneous sessions, choose the baseline planning strategy, and tick the baselines to process.
Processing	Set the RTKLIB solve options (constellations, elevation mask, ionosphere / troposphere models, ambiguity resolution) and run the batch.
Results	Read the per-baseline solutions, the loop-closure diagnostics, the occupation timeline and the network sketch. Re-solve anything you are not happy with.
Quality	Inspect one observation file in detail: epoch completeness, sky plot, SNR over time, satellite count, cycle slips.
Control & Publish	Enter your control coordinates, choose the datum, and publish the accepted baselines into the network adjustment.

2.3.1.2. The Project File

The module does not keep its own project format. It works on an ordinary adjustment project — the same .adjproj file that Station Adjustment and Network Adjustment use.

That is deliberate: when you publish your baselines at the end, they land in exactly the file the Network Adjustment module opens, so the two tools see the same data with no import step in between.

Nothing can be scanned or processed until a project is open. The bar at the top of the module shows either the project path or:

No project open -- create or open one to scan RINEX files.

Use New Project… to create a fresh .adjproj, or Open Project… to work inside an existing one.

Note

Because the GNSS data lives in the project file, everything you do here is saved as you go — the scanned file list, the sessions, the baseline plan and every solved baseline. There is no separate “save” step for the GNSS pages.

2.3.1.3. What You Need Before You Start

1. Observation files (RINEX). One file per receiver per occupation. Both RINEX 2 and RINEX 3 are read. The module reads the header for the marker name, receiver and antenna type, antenna offsets, first and last observation time, the observation interval and the constellations present.

2. Navigation (ephemeris) files. Broadcast ephemeris is required — a baseline cannot be solved without it. Put the navigation files in the same folder as the observations; they are indexed by the same scan. Only genuine RINEX navigation extensions are accepted as ephemeris (see Observation and Navigation Files).

3. The RTKLIB engine. Baseline solving is done by a native library shipped alongside the executable — libiqrtk.so on Linux, iqrtk.dll on Windows. The module opens and works without it: you can scan files, plan sessions and read a Quality report. Only the Run, Reprocess All and Re-solve selected buttons need it, and when it is missing the Processing page says so in red, quoting the exact reason:

GNSS processing is unavailable: cannot load libiqrtk.so ...

See Troubleshooting if you see that message.

2.3.1.4. Conventions Used Throughout

Term	Meaning
Point	The survey mark a file was recorded on. Taken from the RINEX MARKER NAME at first scan, and editable afterwards.
Reference	A file (and so a point) treated as a base station. References drive one of the two baseline planning strategies.
Session	A group of files that were recorded at the same time — strictly, files linked by an observation overlap of at least the minimum overlap. Baselines are only ever formed inside one session.
Baseline	The vector from a base file to a rover file, stored as dX, dY, dZ in ECEF metres, together with its 3x3 covariance. The vector convention throughout the module is rover minus base (To - From).
Trivial baseline	A baseline that is mathematically dependent on the others already planned in the same session. It is listed but not ticked by default.
Solq	RTKLIB’s solution quality for a solved baseline: FIX (integer ambiguities resolved, the result you want) or FLOAT (they were not).
Ratio	RTKLIB’s ambiguity-resolution ratio test. Higher is more confident; the threshold that decides FIX from FLOAT is set on the Processing page.
Publishing	Copying accepted baselines out of the GNSS tables into the network adjustment’s observation table, as GPSBaseline observations.

Units are metres for lengths, coordinates and vector components, seconds for spans and intervals, and degrees for the elevation mask. Loop misclosures are reported in metres and in PPM of the loop perimeter.