How long to occupy a GNSS point
What a two-hour static occupation buys over thirty minutes, measured on one lab run.
A static occupation trades time for precision, and the first minutes are worth far more than the last. The curve below is from one real occupation — a point on the Washington University campus recorded for two hours with an Emlid Reach RS2 on 13 September 2023 and solved by Natural Resources Canada's CSRS-PPP service.
This is precise point positioning: one receiver, no base station, with the satellite orbit, clock and bias corrections supplied by the processing service. RTK and PPK reach centimeters in seconds by differencing against a nearby base, which makes occupation length a different question there; everything below is PPP.
For this run, the height component is the slowest of the three, never reaching 1 cm inside the two hours. Height here is ellipsoidal height, not an elevation above a geoid.
Convergence within one occupation
95% uncertainty in each component, at every processed epoch of the two-hour run.
Drawn from the 240 epochs of the run's CSRS-PPP solution file by
scripts/guides/gnss_occupation_time_figure.py.
The values are unsmoothed.
CSRS-PPP solved 240 epochs (measurement instants) spaced 30 seconds apart across 119.5 minutes, and it reports a 95% uncertainty for north, east and height at each one.
The first epoch's height uncertainty is 9.83 m. Five minutes later it is 0.49 m, better by a factor of 20. The rest of the run improves it by a further factor of 42, to 0.012 m at the last epoch. Both stretches are large, and only the first one was quick.
Across the epochs after the first ten minutes, uncertainty falls as a power of elapsed time, with a fitted exponent of −1.29 for north, −1.42 for east and −1.15 for height. That is steeper than the 1/√t of averaging independent fixes. A PPP filter does not average fixes: it estimates the position jointly with the receiver clocks, the zenith tropospheric delay and its two horizontal gradients, and a carrier-phase ambiguity for every satellite and signal, and those parameters sharpen as the satellite geometry changes. That is the likely reason the slope is steeper, though a single run cannot separate the causes.
Why height converges last
Past the first 17 minutes of this run, height is the largest of the three uncertainties at every epoch, and by one hour it is 2.9 times the north value. The cause is geometry: every satellite is above the antenna. Horizontal position is fixed by satellites on opposite sides of the sky pulling against each other, while the vertical has only the difference between overhead and low satellites to work with. The zenith tropospheric delay, which the filter is estimating at the same time, pushes in that same direction.
Plan around the height number. Quoting a horizontal figure for a survey whose product is elevations understates the uncertainty, and by an amount that depends on which one: at one hour, height is 2.9 times north but only 1.8 times east, and at five minutes east is looser than height.
The uncertainty the report quotes
In a PPP report the reported position is not the last forward-filter row of the epoch-by-epoch file, which is an easy place to go looking for it. CSRS-PPP version 3 resolves carrier-phase ambiguities on a backward pass, starting from the last epoch it processed and working back, then back-substitutes for the final parameters.
The position moves. Between the forward filter's last epoch and the reported position, north and height each shifted 0.6 cm and east shifted 2.5 cm. East moving most is expected: NRCan notes that resolving the ambiguities improves the longitude component in particular, because of satellite geometry.
The uncertainty grows. The file ends with two rows for the same position: an unscaled one, at 0.24, 0.19 and 0.80 cm for north, east and height, and a scaled one at 0.87, 0.71 and 2.93 cm. The scaled row is the file's last, and it is what the summary report quotes, coordinates and uncertainties alike. NRCan applies that scaling in static mode "to obtain more realistic values".
Measure each forward epoch against the position the full run settled on, and the height estimate sits outside that epoch's own 95% interval at 149 of the 240 epochs. At five minutes the estimate was 0.74 m from the final position while its own interval was 0.49 m. Those excursions are not independent, because a filter that drifts holds its offset over many epochs. That is why the scaled row is the one worth quoting.
Choosing a length
Elapsed time at the first epoch whose 95% uncertainty dropped below each value, in this run.
| 95% uncertainty | North | East | Height |
|---|---|---|---|
| 10 cm | 12 min | 19.5 min | 20 min |
| 5 cm | 19 min | 31 min | 43 min |
| 2 cm | 38 min | 58 min | 87 min |
| 1 cm | 67 min | 97 min | not reached |
These are the filter's uncertainties as the run went on. They are not what the service would report for a shorter file submitted on its own, which comes back scaled. Only the two-hour file was processed, so a 30-minute submission is not measured here.
NRCan quotes up to millimeter-level accuracy for static sessions of 24 hours and more, and "an accuracy of a few centimeters can typically be achieved in an hour". What this run shows is centimeter-scale uncertainty: the filter reads 3.4 cm in height after an hour, and the reported two-hour uncertainty is ±2.9 cm. An uncertainty is not an accuracy, and this occupation has no independent coordinate to check against.
This solution was produced with CSRS-PPP version 3.54.2 on GPS and GLONASS observations. Version 5, released 14 May 2025, adds Galileo ambiguity resolution for data collected from 27 November 2022, and NRCan reports accuracy improvements of up to 40 to 60 percent for sessions up to an hour. Whether resubmitting this file would gain anything is a separate question: its Galileo observations are on E1 and E5b, and version 3 used neither.
Logging faster does not shorten the occupation. This receiver logged at 5 Hz, which made the two-hour file 93 MB, and CSRS-PPP decimated it to 30 seconds before solving. The service does that to high-rate static submissions automatically and says why: at rates faster than 30 seconds static accuracy does not improve, and on short data sets it can get worse, because the precise clock products are at 30 seconds. For a static point headed to CSRS-PPP, log at 30 seconds and stay longer.
Checks on a finished run
- Height is usually the loosest component. That is the usual pattern rather than a test a solution has to pass, but a static report whose height is tighter than its horizontal is worth understanding before the number goes into anything.
- Read the ambiguity resolution field. For this run it reads 91.76%. It is not a share of every carrier-phase observation in the file: version 3 makes no attempt at GLONASS ambiguities, and GLONASS supplied 1,537 of this run's 3,403 satellite-epochs. NRCan's own tutorial shows a 30-minute session where cycle slips chopped the data into arcs too short to resolve and none were fixed, leaving a float solution. Occupation length was not the problem there.
- Check how far the solution moved. Here it landed 0.92 m south, 0.16 m west and 2.13 m below the rough position the receiver had written into the RINEX header. A move of that size is unsurprising for a receiver's own autonomous position, though one run says little about the usual range; a solution that barely moved may mean the header already held a postprocessed one.
What this measures, and what it does not
Everything here comes from one occupation, recorded by one receiver at one site under an open sky. The curve is the internal convergence of a single solution rather than a comparison of separate solutions against a known coordinate, so it shows how the estimate settles, not how close it lands to truth. Only an independent coordinate, such as a published control mark, would answer that second question. Repeating the occupation would test repeatability instead, and two runs of the same method can share a bias.
The lab holds 8-hour and 21-hour cuts of this same recording, all three starting at the same instant. Neither longer file has been submitted for processing, which is why this page stops at two hours. Submitting them would extend the curve and give three separately processed solutions of nested durations to compare. They would not be independent measurements: the shorter files are prefixes of the longer ones, so all three rest on the same first two hours of data.
Sources for the service behavior quoted here, both from Natural Resources Canada: CSRS-PPP Version 3: Tutorial (S. Banville, Canadian Geodetic Survey, 2020) and the CSRS-PPP information page. Every figure from the occupation itself is computed by the script named under the plot.
GNSS surveying at the lab
The lab runs GNSS control surveys, base-station occupations, and PPK workflows, and postprocesses the results.