Yes. Interference mitigation can improve signal reception while also changing the measurements extracted from those signals. The effect depends on the method, its parameters, the interference and the GNSS waveform. Continued tracking, an unchanged position and unbiased measurements are different results; none should be substituted for the others in an evaluation.
The practical question is not whether every mitigation method introduces an error. It is which outputs were compared, against what reference, and under which processing conditions. That distinction matters when a protection demonstration is used to support positioning, timing or downstream measurement processing.
Follow the change beyond the signal display
Pre-correlation digital mitigation acts on samples before the receiver estimates signal delay, phase and frequency. For example, GNSS-SDR documents input filtering, pulse blanking and notch-filter implementations separately from acquisition and tracking. These are examples from that software project, not descriptions of ResiNav algorithms.
Changing the samples supplied to an estimator can change its result. Removing conspicuous interference energy is therefore one part of the evidence, not a complete measurement-quality test. Conversely, a change in a measurement is not automatically a harmful position error: the navigation model can absorb some shared effects into estimated clock or bias states.
A notch changes a complex frequency response, not merely the height of a line on a spectrum display. Its phase response can delay wanted signal components, with the effective delay depending on their spectral relationship to the notch. Adaptation can make that delay vary. The open timing study examines this mechanism; it is not a claim that every filter necessarily creates the same tracking bias.
The existing pseudorange and carrier-phase guide explains what those observations contain. Here the additional issue is what a mitigation change can do to them, even when navigation remains available.
A real study separates range, position and time
JRC researchers Daniele Borio and Ciro Gioia publish a detailed author-written assessment of mitigation and measurement effects. They reprocessed recorded data with a custom software receiver, comparing an adaptive notch filter with four robust-processing approaches, and examined pseudoranges, single-point position and clock results separately.
In their tested configurations, the adaptive notch filter introduced signal-dependent range delays. Much of a shared delay appeared in the estimated clock rather than as a corresponding position displacement. The studied robust approaches did not show the same bias behavior, but method and parameter choice still affected operation. These findings are conditional experimental results, not proof that all notch filters are unsuitable or all robust methods are bias-free.
The distinction is substantive: a demonstration can preserve the displayed coordinates while changing an output relevant to a different user. It cannot establish every measurement or timing requirement merely by showing continued navigation.
Why a common range shift can hide in the clock
Navipedia's code-positioning equations include a common receiver-clock unknown alongside position coordinates. In a simplified single-system solution, an equal added range term on every observation can be represented by that clock term. This is a property of the model, not a mechanism that makes the added delay disappear physically.
Consider two invented measurement-difference patterns, expressed in metres for four matched satellite observations at one epoch. All other model terms and the usable geometry are held fixed.
- Pattern A: +3, +3, +3, +3.
- Pattern B: +3, +3, +3, +6.
Pattern A is entirely common-mode in this simplified example. A free common clock-range parameter can absorb it. Pattern B contains an additional non-common contribution on one observation; one clock term cannot represent the entire pattern. How that remainder appears in position, residuals or exclusion decisions depends on geometry, weighting, redundancy and the actual estimator. No position error is calculated or promised by these invented numbers.
This example is not a new explanation of why pseudorange contains a clock offset. It shows why the pattern of differences caused by changing processing matters. A position-only comparison can miss a common measurement shift; the same reasoning does not justify dismissing unequal shifts or extrapolating a single-system result to every multi-signal solution.
Timing needs its own result
Borio and Gioia's open-access GNSS timing study uses a surveyed, stationary position and estimates clock quantities. Its tests include specified L1 and E5b signals, recorded through an SDR front end and processed with a custom receiver.
The authors distinguish clock bias, drift and stability, reporting different behavior for these quantities. Their experimental clock-state result is not automatically a result about an external time output from another receiver.
For an integrator, the consequence is clear: if timing is a required deliverable, include the applicable time reference and timing output in acceptance. A position trace cannot supply that missing evidence. If downstream software uses satellite observations, inspect those observations rather than assuming that a valid PVT message certifies them.
Compare evidence at three levels
| Evaluation level | Question it answers | What it leaves open |
|---|---|---|
| Signal availability and tracking | Are the required signals acquired or continuously followed under the defined input? | Whether the resulting measurements have a systematic shift |
| Measurement behavior | How do matched observations and their errors change with the processing? | Whether the selected navigation estimator meets its output requirement |
| Position and timing outputs | How do the required outputs compare with an independent reference? | The quality of unreported observations or other untested solution modes |
These are complementary views of one processing chain, not a mandatory purchase of three different instruments. The available evidence depends on what the receiver exports and what the application actually consumes.
Make a mitigation comparison interpretable
For a sample-processing comparison, replaying the same captured input through alternative documented configurations helps isolate processing differences. It does not by itself reproduce an external protection device that was absent from that recording. Preserve the actual hardware boundary as well as the software setting.
Pair observations by satellite, signal and epoch, retain lock/state information, and compare the common component and the remaining differences—not only an average across changing membership. Separate systematic shifts from random spread and missing observations. Where errors are reported, identify whether the reference is an independently known truth or merely another processing output; two outputs can agree while sharing an error.
Include a quiet-input comparison as well as the stated interference condition. A method's behavior when unwanted energy is negligible is part of understanding the change. For position or timing, retain the estimator mode and appropriate reference; do not extend a single-point result to precise positioning or all time interfaces without evidence.
Use the receiver evaluation guide to place these comparisons in the configuration and event record. The AGC and C/N0 guide explains the separate reception indicators; they do not replace the measurement comparison described here.
For a reception-protection procurement task, continue to the ResiNav catalogue and the selected model's existing enquiry path. The studies above neither identify a ResiNav mitigation algorithm nor establish its raw-observation export, delay, precision or compatibility. What they establish is why the acceptance question must follow the required output: usable reception, suitable measurements, and suitable position or time are related, but independently assessable outcomes.
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.