ENGINEERING REFERENCE

Carrier-Smoothed Pseudorange: What Smoothing Changes

Carrier smoothing uses precise changes in carrier phase to reduce noise in code pseudoranges while retaining a code-referenced range. It does not, by itself, resolve the carrier's integer ambiguity or produce an ambiguity-fixed position. A longer smoothing memory gives less weight to each new code measurement, changing noise rejection, response to code/carrier discrepancies and recovery after a reset.

For an integrator comparing receiver logs or processing options, “smoothed”, “carrier-based” and “fixed” therefore describe different things. The useful comparison is the measurement being delivered and how its errors evolve, not simply which trace looks smoother.

How phase changes help a code measurement

Let P be code pseudorange and L be carrier phase converted to metres, for the same satellite signal. The carrier's initial ambiguity is an unknown offset. During a continuous arc that offset stays constant, so subtracting consecutive carrier observations cancels it. The resulting phase change can help propagate a previous range estimate to the current epoch.

The smoother combines that propagated estimate with the new code measurement. Code anchors the apparent range; phase supplies fine relative changes. ESA-hosted Navipedia describes this Hatch-filter construction:

Sₖ = Pₖ/n + (n − 1)/n × [Sₖ₋₁ + (Lₖ − Lₖ₋₁)]

S is the smoothed code pseudorange. The initial value is S₁ = P₁. In this version, n grows with the valid observation count until it reaches a chosen cap M; it then remains M. P, L and S all use metres. A carrier field in cycles must first be interpreted and converted using the appropriate signal convention. This is an explanatory algorithm, not a ResiNav implementation or a command recipe.

Why this is not ambiguity fixing

The smoother can use Lₖ − Lₖ₋₁ without determining the initial integer ambiguity of the carrier observation. The smoothing cap M is a chosen sample count, not an estimated whole-cycle offset.

In contrast, an ambiguity-fixing process establishes an integer interpretation of relevant ambiguity parameters after accounting for the required biases and measurement model. Navipedia's ambiguity-fixing reference explains that separate task. Feeding carrier increments into a code smoother does not perform it.

Consequently, a code-based position calculated from smoothed pseudoranges can become less noisy without becoming an RTK-fixed solution. Conversely, having a carrier-phase positioning mode does not identify whether the logged code observations were smoothed. The pseudorange and carrier-phase guide supplies the measurement definitions; inspect the documented output and solution status for the particular receiver.

A longer memory changes the correction, not every motion equally

Consider an illustrative filter update after warm-up. Suppose the previous smoothed range is 20,000,000 m. The valid carrier-derived change to the next epoch is +4 m, so the propagated value is 20,000,004 m. The new code measurement is 20,000,014 m: a +10 m discrepancy relative to that prediction.

With a fixed weight 1/10 on new code, the updated value is 20,000,005 m. With weight 1/100, it is 20,000,004.1 m. The latter accepts less of that code discrepancy at the first update. Neither result demonstrates that the discrepancy was noise rather than a real code/carrier bias; those are hypotheses to investigate.

Notice that both calculations propagate the +4 m carrier change. It would be misleading to describe this filter as simply delaying every real platform movement by the smoothing interval. Its response depends on which input contains the change. The original analysis by Petovello, Lo Presti and Visintin, “Can you list all the properties of the carrier-smoothing filter?”, likewise treats the response to different inputs rather than noise reduction alone.

For a second idealized calculation, assume a persistent code-only step Δ, unchanged carrier increments, no resets and an already fixed filter weight 1/M. After m updates, the remaining discrepancy to the new code level is Δ(1 − 1/M)ᵐ. For M = 100 at one update per second, 100 updates incorporate about 63.4% of that step. This is a response of the stated recurrence, not a receiver latency specification or advice to choose a 100-second setting.

Compare the trade-offs on a common basis

Filter choice What it changes What to inspect alongside the smoothness
More weight on each new code observation The result adapts faster to a code/carrier discrepancy and retains more short-term code variation Whether that discrepancy represents noise, multipath, a bias change or initialization
Less weight on each new code observation More reliance on accumulated carrier changes, with slower correction toward a changed code level Continuity, time-varying code/carrier bias, reset frequency and the duration of stable tracking
A different multi-frequency smoothing construction Can address specified ionospheric terms using additional measurements Which combination is actually used and which delays and noise remain in its output

NovAtel's OEM7 carrier-smoothing documentation explicitly discusses noise attenuation, observation correlation, step response and ionospheric divergence. It also describes filter restart and the time needed for a new setting to take effect. These details belong to those NovAtel configurations; one parameter value should not be copied to another receiver or treated as a universal optimum.

Code and carrier do not respond identically to the ionosphere

To first order, ionospheric propagation delays code while advancing carrier phase. Their difference therefore includes a changing ionospheric contribution, not just code noise and a constant offset. A long-memory single-frequency smoother can carry this mismatch into its output.

Navipedia's code-carrier divergence analysis distinguishes a divergence-free construction from an ionosphere-free construction. A divergence-free smoothed code can retain the original code's ionospheric delay while removing the smoothing divergence; an ionosphere-free combination targets the first-order ionospheric term itself. These are different outputs with different measurement combinations. “Dual-frequency smoothing” alone does not identify which one is supplied.

This is why smoother-looking code is not automatically closer to the correct range. Compare both random variation and systematic effects over the relevant conditions; the expected benefit depends on the error being reduced and the method actually implemented.

A discontinuity resets the assumption behind smoothing

The phase-difference step assumes continuity. If the carrier ambiguity changes across a cycle slip, its difference includes the jump as well as the physical evolution. Carrying that difference directly through the smoother can introduce an error into subsequent estimates.

GNSS-SDR's observables documentation provides an implementation example in which smoothing restarts on a flagged phase discontinuity rather than spanning it. A restarted filter needs fresh observations to build its memory. A nominal long smoothing interval can therefore deliver little long-arc benefit where interruptions repeatedly reset it.

For this failure mechanism, retain the phase-continuity record and reset state, not just the final position plot. The general principle does not establish that any ResiNav product exports those records or runs this smoother.

Identify what the recorded data already contain

When software will perform later processing, determine whether the saved pseudoranges were already carrier-smoothed and how their status and settings are represented. Code and carrier from the same smoothing chain need not be statistically independent. Adding another smoothing stage does not automatically provide a second independent noise-reduction benefit.

Use the receiver interface guide for the field and configuration record, then the real-time versus post-mission guide for the processing deliverable. For the filter comparison itself, distinguish unsmoothed code, carrier-smoothed code and an ambiguity-fixed navigation result. That identifies whether the change you are buying or enabling reduces measurement noise, changes response, or actually adds a different positioning method.

NEXT STEP

Turn available platform information into an engineering review.

Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.

Request an engineering review Explore Technology