GNSS ionospheric delay and tropospheric delay affect the same satellite observations through different mechanisms. The ionosphere is dispersive, so measurements at different frequencies can remove its first-order term. The neutral atmosphere, usually called the troposphere in GNSS processing, is effectively non-dispersive at GNSS radio frequencies. Its delay remains in an ionosphere-free combination and must be modeled, estimated or otherwise handled by the positioning method. Correcting one atmospheric effect does not remove the other.
For an integration engineer comparing dual-frequency measurements, positioning software or height results, the next question is not simply whether “atmospheric correction” is enabled. It is which delay the model represents, how that delay varies between satellite directions, and which remaining parameters are estimated together with position.
The two delays respond differently to frequency
Free electrons in the ionosphere produce a first-order range term proportional to slant electron content divided by frequency squared. In the conventional observation model, that term delays code pseudorange but advances carrier phase when the phase is expressed in metres. ESA-hosted Navipedia explains the frequency dependence and sign convention.
Neutral-atmosphere refraction instead contributes a positive propagation delay to both code and carrier observations. The GNSS use of “tropospheric delay” includes the modeled neutral-atmosphere path, rather than requiring that every contribution originate below a sharp meteorological boundary. Its hydrostatic and wet components are treated as non-dispersive over the GNSS radio bands in the Galileo tropospheric correction reference.
| Comparison | Ionospheric term | Neutral-atmosphere term |
|---|---|---|
| Physical origin | Free electrons along the signal path | Refractivity associated with atmospheric gases and water vapour |
| Frequency behavior relevant here | Leading term varies as 1/f² | Effectively frequency-independent at GNSS radio frequencies |
| Code and carrier sign in a range model | Opposite signs for the first-order term | Positive delay in both |
| Effect of a conventional dual-frequency ionosphere-free combination | Cancels the specified first-order term, not every ionospheric effect | Retains the common delay |
The combination preserves common range terms because its coefficients sum to one. That same property preserves the neutral-atmosphere delay. The ionosphere-free combination guide derives those coefficients and their noise cost. Receiving more frequencies supplies more information, but frequency diversity alone cannot separate a delay that follows the same frequency-independent behavior as other common terms.
Zenith delay is not the delay to every satellite
A zenith delay describes the path in the local upward direction. A satellite at a lower elevation traverses a different atmospheric path. A common model separates a zenith hydrostatic delay, ZHD, from a zenith wet delay, ZWD, and maps each into the satellite direction:
T(E) = mh(E) × ZHD + mw(E) × ZWD.
T, ZHD and ZWD are path delays in metres. E is elevation above the local horizon. The mapping factors mh and mw are dimensionless. They need not be the same function. In the Niell mapping formulation, separate hydrostatic and wet functions account for elevation dependence, with additional location, height and time dependencies in the applicable terms. The functions are normalized at the zenith.
Hydrostatic does not simply mean that all water-related physics has been removed. Operational decompositions use a hydrostatic component closely tied to total surface pressure and a wet component associated with water vapour. The Galileo reference describes pressure-based ZHD estimation and the dependence of wet delay on the atmospheric water-vapour profile. A surface humidity reading does not describe that entire vertical profile.
This also explains why one correction in metres cannot generally be subtracted unchanged from every satellite. A zenith quantity needs a directional mapping. More detailed models can include horizontal gradients when the atmosphere is not azimuthally symmetric. As an institutional example, GFZ's atmospheric-model project uses numerical weather-model fields and ray tracing to obtain zenith delays, mapping coefficients and gradients. Those are model components, not a universal implementation inside every receiver.
Modeled and estimated delay are different information
An a priori model predicts a delay from specified inputs or climatological assumptions. An estimated correction is a parameter inferred from observations within a positioning solution. The two can be used together.
For example, Navipedia's linear PPP observation model writes the tropospheric contribution as a nominal model plus a mapped residual zenith term. The observation equations also contain position, receiver clock and carrier ambiguity terms. Calling the residual parameter “wet delay” identifies its role in that model; it does not make it an independently measured humidity profile or establish that every other model error is absent.
Estimated atmospheric quantities can themselves be useful outputs. EarthScope's tropospheric processing-products description is an example of GNSS processing producing estimated tropospheric parameters. That is different from assuming that any position message contains such a diagnostic, or that a receiver's reported position uncertainty independently verifies the atmospheric model.
When comparing processing results, distinguish the nominal atmosphere model, any estimated residual or gradients, the mapping function, and the constraints placed on those parameters. A difference between two solutions can reflect those choices even when they use the same observations and frequency combination.
A hypothetical example of delay and height coupling
Consider a deliberately simplified teaching model. Hold the horizontal coordinates exact, and estimate only an upward height change Δh and a receiver clock-range change Δb. Express both in metres. Assume one observation at 30° elevation and one at 90°. This is not an unconstrained three-dimensional GNSS solution.
For this example only, approximate the atmospheric mapping by m(E) = 1/sin(E). This flat, horizontally layered, straight-path approximation illustrates the geometry; it is not a substitute for operational mapping functions, particularly toward the horizon. Let an unmodeled zenith wet-delay residual be +0.030 m.
The resulting unmodeled slant delays are +0.060 m at 30° and +0.030 m at 90°. These are observation errors, not automatically height errors.
In a local linear range model with horizontal position fixed, an upward displacement changes geometric range by −sin(E)Δh. A receiver clock-range change adds the same Δb to each observation. If processing omits the residual atmospheric term, it can fit the two assumed observation errors using:
−0.5Δh + Δb = 0.060 m
−Δh + Δb = 0.030 m.
Subtracting the equations gives Δh = +0.060 m, followed by Δb = +0.090 m. Both equations then have zero remaining residual. The assumed zenith error was 0.030 m, yet the fitted height change is 0.060 m in this particular constrained geometry.
This is a calculated counterexample to interpreting every centimetre of delay as one centimetre of height error, or treating a small post-fit residual as independent proof of a correct height. It is not a prediction for a real receiver, constellation or filter. If the zenith residual were also estimated as an unknown, these two equations would not uniquely determine all three parameters. Additional observations, geometry, time evolution or prior constraints would be needed.
The PPP design matrix cited above shows the underlying reason: height, clock and mapped atmosphere occupy different but potentially coupled columns of the estimation problem. Real observations and constraints change the result; there is no universal height multiplier or error sign. The measurement-residuals guide explains the separate role of post-fit residuals.
Low elevations create a tradeoff, not a universal mask
The mapping example shows why a zenith-model error can have a larger slant effect at low elevation. Rejecting a low-elevation observation may remove a problematic range, but it also removes geometry and redundancy. Keeping it with a model and a suitable weight is another processing choice, not proof that its atmospheric or local propagation errors have disappeared.
Use the actual observation model and evaluation objective to judge that tradeoff. The DOP and position-accuracy guide explains why geometric improvement and measurement quality are separate inputs. No single elevation cutoff follows from the distinction between ionospheric and tropospheric delay.
Keep propagation delay separate from height reference and signal loss
Tropospheric modeling affects the estimate of the antenna's geometric position, including ellipsoidal height. Converting an ellipsoidal height into an orthometric height is a different operation involving a compatible vertical reference and model. A geoid conversion does not remove a range-model error already present in the estimated height. The ellipsoidal and orthometric height guide covers that delivery distinction.
Likewise, removing a first-order ionospheric delay term does not guarantee uninterrupted tracking during scintillation. Atmospheric phase and amplitude fluctuations are a separate reception problem, explained in the scintillation and RF-jamming guide. An RF anti-jamming function is not a replacement for either atmospheric parameter estimation or vertical-reference handling.
For a useful comparison of GNSS processing, identify which frequency-dependent term was removed, which neutral-atmosphere model or estimated parameters remain, and which position and height reference the output represents. Those three questions explain more than an undifferentiated “atmosphere corrected” label. They do not establish any particular ResiNav receiver mode, atmospheric diagnostic or positioning performance.
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.