2.3.9. Troubleshooting
2.3.9.2. Every baseline failed
Read the Notes column on the Results page — it carries the reason per baseline.
The commonest cause by far is no ephemeris. A baseline cannot be solved without broadcast navigation data. Check that:
navigation files are in the folder you scanned, not in a sibling folder;
they are genuine RINEX navigation files. An almanac (
.ALM) or SBAS message (.EMS) file passes a naive header test but is deliberately refused as ephemeris here — one stray almanac has been measured turning a FIX at ratio 3.2 into a FLOAT at ratio 1.0 with a 34 cm bias.
The Recognised, not used list on the Files page names every file in the scanned folder that did not become an observation or navigation row, so a navigation file refused in this way is named there rather than simply absent.
2.3.9.3. Baselines come back FLOAT
FLOAT means the integer ambiguities were not resolved. In rough order of how often it helps:
Analyse both ends on the Quality page. A file that is 60 % complete, or a satellite with hundreds of cycle slips, is the answer and no solver setting will hide it.
Turn GLONASS ambiguity resolution off when the two ends are different receiver makes. Inter-channel biases between makes are a classic cause.
Raise the elevation mask if the sky plot shows obstructions.
Untick a constellation the Quality page shows as unhealthy at this site.
Cut the occupation with the Start / End fields to exclude a gap or a slip storm the satellite-count chart reveals.
Switch ionosphere to Estimate on a long baseline.
What is not a fix: lowering the ratio threshold until the solution is called a fix. The ratio actually achieved is printed per baseline, so a manufactured fix is visible to anyone who looks.
2.3.9.4. A file is in no session
The warnings panel names it and quotes the minimum overlap. Either the occupation genuinely does not overlap anything by that much, or the threshold is too high for this campaign. Change Min overlap (s) and press Rebuild sessions.
A separate warning covers the other cause: a file whose header has no TIME OF LAST OBS. Its end time is unknown, so its overlap with everything computes as zero and it can be neither grouped nor planned. Re-convert or re-download the file.
2.3.9.5. Redundancy is zero
The warnings panel turns red and says so. A zero-redundancy network has exactly enough observations to determine the unknowns and not one more, so there is nothing to check against and no residual can be non-zero.
Switch Strategy from Spanning tree to Rover x references, or include more baselines, and re-plan.
2.3.9.6. A point is missing from the network sketch
The label under the sketch names it. Its APPROX POSITION XYZ in the
RINEX header is a statistical outlier against the rest of the network —
typically a header that was never updated, putting the point hundreds of
kilometres away.
It is excluded from the drawing only so that one bad header cannot collapse every real point into a single dot. It does not necessarily harm the solve, since the solver refines the position from the observations, but it is worth correcting.
2.3.9.7. A point I surveyed is not in the adjustment
The publish log reports it as orphaned and names it. Every baseline touching that point was skipped — most often because they were all FLOAT and Allow FLOAT baselines was unticked.
Either re-solve those baselines to a fix, or tick Allow FLOAT baselines as a deliberate decision, and publish again.
2.3.9.8. Apply datum says it held fewer points than I ticked
It names the control points it could not find. A control point can only be held if the project has a station row for it, and a point reachable only through baselines that were never published has no station at all.
Publish first, then apply the datum.
2.3.9.9. A solved baseline reverted to “planned”
Its input file changed on disk since it was solved. The module records a hash of each file’s header and its size, and invalidates results computed from a file that has since been re-downloaded, re-converted or edited.
This is deliberate: a result whose input has changed is one you can no longer defend. Re-run the affected baselines.
2.3.9.10. The publish wrote fewer rows than I expected
The publish preview and the log both break the skips down by reason, and the two reasons are kept apart on purpose:
excluded or unsolved — the baseline is unticked, failed, or was never processed;
unacceptable fix quality — it solved, but FLOAT, and FLOAT is not allowed.
They call for different actions, which is why they are never pooled into a single “skipped” number.