2.3.4. The Processing Page
This page holds the RTKLIB solve settings and runs the batch. Everything here applies to every baseline in the run — the settings are per-run, not per-baseline. If one baseline needs different treatment, change the settings and re-solve just that row from the Results page.
The page opens on this module’s own defaults. Most come straight from RTKLIB; three are set deliberately for static control work:
Setting |
Default |
Why |
|---|---|---|
Ambiguity resolution mode |
Fix-and-hold |
Holds the integer solution once found, which strengthens a long static occupation. |
GLONASS AR mode |
Fix-and-hold |
As above for GLONASS. Set it to Off when the two ends are different receiver makes. |
Ratio threshold |
2.0 |
Accepts fixes RTKLIB’s own 3.0 would leave as FLOAT. |
Warning
The first two hold a wrong integer solution as firmly as a right one, and the third accepts marginal fixes. That is a deliberate trade for this kind of work, not a free win: read the Ratio column on the Results page and the loop closures before trusting a fix.
The settings are not stored with the project — every project opens on these defaults.
2.3.4.1. Solve Options
2.3.4.1.1. Mode
Value |
Use it for |
|---|---|
Static |
Both ends of the baseline are stationary throughout the occupation. This is the setting for a control campaign and the one you will use almost always. |
Kinematic |
The rover was moving. Use only if you know that is what you recorded. |
2.3.4.1.2. Constellations
Five tick-boxes: GPS, GLONASS, Galileo, QZSS, BeiDou. Only the ticked systems are used in the solution.
Ticking a system that your files did not track costs nothing. Unticking one your files did track is a real tool: if the Quality page shows a constellation with heavy cycle slips or poor SNR at your site, excluding it often turns a stubborn FLOAT into a FIX.
2.3.4.1.3. Elevation mask (deg)
Satellites below this elevation are not used. Range 0 to 90 degrees.
Low-elevation satellites carry the worst multipath and the longest atmospheric path, but they also carry the geometry that separates height from tropospheric delay. Raising the mask is the standard response to a site with obstructions or heavy multipath; raising it too far leaves too few satellites to fix the ambiguities.
2.3.4.1.4. Ionosphere model
Value |
Meaning |
|---|---|
Off |
No ionospheric correction. Acceptable on short baselines, where the ionospheric delay is common to both ends and differences out. |
Broadcast |
Apply the ionosphere model from the broadcast navigation message. |
Estimate |
Estimate the ionospheric delay as part of the solution. The option for long baselines, at the cost of a weaker ambiguity resolution. |
2.3.4.1.5. Troposphere model
Value |
Meaning |
|---|---|
Off |
No tropospheric correction. |
Saastamoinen |
The standard a-priori model. The usual choice. |
Estimate |
Estimate a residual zenith delay per station. Worth using when the two ends differ substantially in height, or on long occupations. |
2.3.4.1.6. Ambiguity resolution mode
Value |
Meaning |
|---|---|
Off |
No integer ambiguity resolution. Every baseline comes back FLOAT. |
Continuous |
Ambiguities are estimated and resolved continuously over the whole occupation. The conservative choice: it never carries a fix forward the way fix-and-hold does. |
Instantaneous |
Resolved epoch by epoch, without carrying the solution forward. |
Fix-and-hold |
Once fixed, the integers are held. Strengthens a long static solve, but will hold a wrong fix just as firmly as a right one. This module’s default. |
2.3.4.1.7. GLONASS AR mode (glomodear)
GLONASS needs its own ambiguity-resolution setting because its frequency-division signals suffer inter-channel biases that differ between receiver makes.
Value |
Meaning |
|---|---|
Mirror AR mode (auto) |
Follow whatever the main ambiguity resolution mode is set to. |
Off |
Do not resolve GLONASS ambiguities. The safe setting when the two ends are different receiver makes, which is exactly when the inter-channel biases bite. |
On |
Resolve them. Appropriate for a matched pair of receivers. |
Auto-cal |
Calibrate the inter-channel bias as part of the solution. |
Fix-and-hold |
As above, held once fixed. This module’s default. |
2.3.4.1.8. Ratio threshold
The ambiguity ratio test. A solution is accepted as FIX only when the ratio between the second-best and the best integer candidate exceeds this value. Range 1.0 to 10.0.
This module defaults to 2.0, below RTKLIB’s own 3.0, because it fixes more of the short baselines a control campaign is made of.
Raising it makes fixes rarer and more trustworthy; lowering it does the opposite. Lowering the threshold further to force a fix is a way of making a bad result look good — the ratio actually achieved is reported per baseline on the Results page, so a marginal fix is always visible. A fix at 2.1 against a threshold of 2.0 is worth a second look.
2.3.4.1.9. Interval override (s)
Process at this interval instead of the file’s own. 0 means “use the interval in the file”. Range 0 to 3600 seconds.
Decimating a 1 s file to 15 s or 30 s makes a batch dramatically faster and, for a static occupation, costs almost nothing in accuracy.
2.3.4.1.10. Start and End (UTC)
Restrict processing to a time window. Leave both blank for unbounded — the whole common span of each pair.
Use them to cut off a disturbed part of an occupation: the first minutes while the tripod settled, or the interval the Quality page shows as a gap or a slip storm.
2.3.4.2. Running a Batch
Button |
Action |
|---|---|
Run |
Solves every included baseline that has not been solved yet. This is the normal “process what is left” action, so pressing it twice does not redo work. |
Cancel |
Stops the batch. Everything already solved is kept — each baseline is committed as it completes, so a cancelled run is never wasted. |
Reprocess All (current settings) |
Re-solves every included baseline, including the ones already solved, with the settings currently on this page. This is what you press after changing an option and wanting it applied to the whole network. You are asked to confirm when it would discard existing results. |
2.3.4.2.1. Watching a run
Each baseline writes one line to the log when it is picked up, and that same line is rewritten with the outcome once it is known:
[11/55] K7 - K8 FIX ratio 8.60 18 sat 3509 epochs
[12/55] K10 - K9 FIX ratio 3.10 12 sat 3509 epochs
[13/55] G2 - K9 FLOAT ratio 1.40 11 sat 3509 epochs
[14/55] K1 - K6 FAILED: no navigation (broadcast ephemeris) file ...
So the log reads as a result list once the run is over, not just a record of what was attempted.
The label beside the progress bar carries a running tally, which answers “how is this going” without reading the log at all:
14 / 55 - 9 FIX, 4 FLOAT, 1 failed
Processing runs on a background thread, so the rest of the application keeps responding. While a run is in progress the other pages will not let you alter the plan underneath it.
2.3.4.3. Ephemeris Selection
For each baseline the module first looks for the navigation files that belong specifically to that pair of observation files. If it finds none, it falls back to the project-wide set of navigation files.
That fallback is recorded on the baseline and shown in the Notes column on the Results page, so “a generic ephemeris set was used for this baseline” is never a silent decision. The same column carries a note if the list of navigation files had to be truncated.