2.3.3. The Sessions and Baselines Page

Once the files are scanned and named, this page decides what will be processed: which files were recorded simultaneously, and which pairs of them become baselines.

2.3.3.1. Sessions

A session is a set of files that observed at the same time. Two files belong to the same session when their observation windows overlap by at least the minimum overlap; sessions then grow transitively, so a base station that ran all day links the morning rovers and the afternoon rovers into one session.

Press Rebuild sessions to (re)compute the grouping. The tree on the left then shows:

All sessions
Session 1  (4 files)
    BASE1
    P101
    P102
    P103
Session 2  (3 files)
    ...

Selecting a session filters the baseline grid to that session; selecting All sessions shows every baseline in the project.

2.3.3.1.1. Minimum overlap

Min overlap (s) is the threshold that decides whether two occupations count as simultaneous. The default is 900 s (15 minutes).

Raise it if short, marginal overlaps are producing baselines you would never trust. Lower it if legitimate short occupations are being left out — the warnings panel tells you when a file has been excluded from every session for this reason.

Change the value and press Rebuild sessions for it to take effect.

2.3.3.1.2. Automatic reference classification

Rebuilding sessions also promotes long occupations to Reference automatically: a file qualifies when its span is at least 60 % of the whole campaign window, or longer than the project’s absolute reference-span setting.

There is a guard on this: if more than half the files would qualify, nothing is promoted at all. A campaign of uniformly long occupations has no meaningful “base station”, and marking everything as a reference would be worse than marking nothing.

Promotions are written back to the Files page, so you can always see — and override — what was decided for you.

2.3.3.2. Planning the Baselines

Re-plan baselines builds the candidate baseline list for every session, using the strategy selected in the Strategy drop-down.

Strategy	What it plans
Spanning tree	A maximum spanning tree over the session’s overlap graph, preferring the pairs with the longest common observation time. This is the classic independent baseline set: for a session of p files it produces p - 1 baselines, and every other possible pair is mathematically dependent on them (and so marked Trivial).
Rover x references	Every rover tied to every reference, plus the reference-to-reference ties. This produces more baselines than the minimum and is the strategy to use when you want an adjustable network with real redundancy.

Tip

If the warnings panel reports redundancy 0, the plan has no independent check in it at all. Switching from Spanning tree to Rover x references is usually the fix.

2.3.3.3. The Baselines Grid

Column	Editable	Meaning
Include	Yes	Tick to process this baseline. Untick to leave it out of the processing run, the diagnostics and the publish.
Base	No	The point the vector starts from.
Rover	No	The point the vector ends at. The stored vector is always rover minus base.
Length	No	Approximate baseline length from the RINEX header approximate positions. It is a planning aid, not a result — the solved length appears on the Results page.
Overlap	No	Common observation time of the two files. Short overlaps are the usual reason a baseline will not fix.
Trivial	No	Yes marks a pair that is mathematically dependent on the others already planned in the same session.
State	No	planned until it has been processed, then ok or failed.

Note

Every freshly planned baseline starts ticked, trivial ones included. The intent is that you start from everything and untick what you do not want, rather than having to hunt for what was quietly left out. The Trivial column still tells you which pairs are dependent, and the warnings panel still reports the redundancy that results — so if you leave the trivial baselines in, you can see the effect.

2.3.3.3.1. Re-planning and existing results

Re-planning does not throw away work: a planned pair that matches a baseline already solved keeps its result and its ok state. Only genuinely new pairs start as planned.

2.3.3.4. The Warnings Panel

The panel at the bottom of the page is refreshed on every change and is never quietly empty when the plan has a real problem. It reports:

A session with only one member

No baseline can be formed from a single file. The message names the file and quotes the current minimum overlap, since that is usually what isolated it.

A file excluded from every session

Its overlap with everything else never reaches the threshold. Either the occupation genuinely does not overlap anything, or the threshold is too high.

A disconnected session

Fewer included baselines than are needed to connect the session’s files — for example after unticking too many rows. The message states how many are included and how many are needed.

A file with no TIME OF LAST OBS

Such a header makes the occupation’s end time unknown, so its overlap with everything else computes as zero and it can be neither grouped nor planned. The file is named rather than left to vanish.

The redundancy line

Always present, in the form:

12 baselines · 7 points · redundancy 5

Redundancy is the number of independent checks the network contains.

Warning

When redundancy is zero or negative, the whole panel turns red and adds:

Redundancy is zero: this network cannot be adjusted meaningfully.
Switch strategy or include more baselines.

A zero-redundancy network has exactly enough observations to determine the unknowns and not one more, so the adjustment has nothing to check against and no residual can ever be non-zero. Do not publish it and call it adjusted.

The redundancy shown here is a preview: before anything has been processed, included baselines are counted as if they had solved cleanly, so you can judge the plan before spending the processing time on it.