Code-based DGNSS uses reference-station information to reduce errors shared with a user's code measurements. RTK uses carrier-phase observations and reference information to estimate a relative position while handling phase ambiguities. PPP applies precise satellite products to the user's own observations and estimates the remaining receiver and propagation parameters. These are different measurement models. A working NTRIP connection or a receiver label saying “RTCM input” does not make their data interchangeable.
DGNSS is also an umbrella term for differential GNSS, which includes RTK. In the comparison below, code-based DGNSS means the classical code-differential method, not every differential technique. The useful distinction is what the reference information represents and how the positioning engine uses it—not whether the equipment has a network connector.
Keep the model, message and connection separate
Consider a hypothetical integrator retaining the same GNSS receiver and Internet connection. One available stream supplies code corrections from a surveyed reference. Another supplies reference-station code and carrier observations. A third supplies satellite orbit, clock and bias corrections. Receiving bytes from all three would not give the receiver three equivalent ways to run its existing RTK mode.
Four layers have different jobs. The positioning model decides how observations and reference information constrain the unknown position. The correction representation describes what the transmitted quantities mean. The message specification encodes those quantities, identities, epochs and conventions. The transport delivers the messages. The receiver implementation must decode and use the particular content in the intended estimator.
The BKG-hosted NTRIP documentation illustrates this separation in its source table: a mountpoint has separate fields for data format, format details and GNSS content. NTRIP is a transport mechanism, not a universal positioning algorithm. The RTCM compatibility guide covers message and input matching; here, the question is why those different payloads require different processing.
Code-based DGNSS transfers a reference measurement discrepancy
At a surveyed reference station, the expected satellite range can be compared with the measured code range after the relevant modelling and clock treatment. A correction derived there can reduce the corresponding error at a user when enough of that error is shared in space and time. This exploits correlated errors; it does not measure the user's local error directly. ESA-hosted Navipedia's DGNSS explanation describes code differencing and why uncorrelated effects such as local multipath remain.
For a hypothetical single-satellite illustration, express residual code errors in metres after geometry and receiver-clock terms have been dealt with in the simplified model. Let the reference error be e_B = g_B + l_B, and the user error e_U = g_U + l_U. Here, g denotes the component that is approximately shared, while l collects site-specific effects. Applying the illustrative additive correction −e_B leaves:
e_U − e_B = (g_U − g_B) + (l_U − l_B).
Assume g_B = 2.0 m, l_B = 0.2 m, g_U = 2.6 m and l_U = 0.8 m. The reference discrepancy is 2.2 m and the user error before correction is 3.4 m. Subtracting 2.2 m leaves 1.2 m, consisting of 0.6 m of imperfectly shared error and 0.6 m of local-error difference.
This is error bookkeeping for one range, not a literal RTCM message recipe, a position-error prediction or a service test. It shows why a correction can help without removing everything, and why reference noise can enter the corrected result. The hypothetical numbers are not an accuracy specification or a recommended baseline length.
RTK uses precise phase differences and an ambiguity model
RTK adds the precision of carrier-phase measurements to a relative-positioning problem. In a common formulation, differences between reference and user observations, and between satellites, cancel clock terms and reduce sufficiently shared errors. The estimator still has to determine the relative coordinates and handle the initially unknown carrier-cycle ambiguities. It is not simply the same code correction applied more often. Navipedia's RTK fundamentals sets out that differenced carrier model.
The reference coordinates establish the coordinate connection for the user result. A receiver can obtain suitable reference information from an accessible base or network service; the user does not necessarily have to build a base station. A network can model spatially varying errors and deliver information for the user's vicinity, including through a virtual-reference arrangement. BKG's NTRIP source-table specification explicitly distinguishes streams generated by a single reference from network-generated streams.
The receiver must validate its ambiguity solution under its documented criteria. A fixed state does not independently verify reference coordinates, height conventions or the final delivered point. Those separate checks belong to the RTK Fixed verification guide. Here the distinction is the estimation mechanism, not another rule for accepting a green status indicator.
PPP uses satellite products without forming the user's short baseline
PPP combines the user's code and carrier observations with precise satellite orbit and clock information, compatible bias treatment and detailed observation modelling. It estimates receiver coordinates and clock along with such quantities as tropospheric delay and phase ambiguities. The user need not form a short baseline to a nearby reference receiver, although the precise products themselves depend on reference networks. “Single receiver” describes the user-side solution, not a system with no external infrastructure. Navipedia's PPP overview describes this undifferenced estimation.
A satellite clock correction is not a ready-made correction for every error on the user's signal path. The receiver still needs an appropriate treatment of ionosphere, troposphere, antenna effects and observation biases. Its selected measurements must be consistent with the product conventions. Navipedia's PPP modelling reference explains, for example, why clock products referenced to one signal combination can require additional bias treatment when other signals are used.
Dual-frequency ionosphere-free processing is one way to remove the first-order ionospheric term. It is not PPP by itself and does not remove every remaining error. The ionosphere-free combination guide derives that narrower operation; other PPP implementations can estimate ionosphere or use external ionospheric information rather than use that particular combination.
| Positioning approach | Main external reference information | What the user still estimates or handles |
|---|---|---|
| Classical code-based DGNSS | Reference-derived code or position correction information applicable to the observations and vicinity | User position and receiver clock as applicable; residual spatial/temporal differences and local errors |
| RTK relative positioning | Reference coordinates and suitable code/carrier information from a base or network arrangement | Relative coordinates and phase ambiguities; remaining atmospheric, observation and setup errors |
| PPP | Precise satellite orbits/clocks and the compatible biases or other products required by the chosen model | User coordinates/clock, atmospheric parameters and ambiguities as appropriate; remaining local effects |
The table compares representative processing models, not universal message lists or an unconditional accuracy ranking. A particular service can combine techniques and deliver additional information.
OSR and SSR describe the information representation
Observation-space representation (OSR) expresses reference information at the observation level, such as reference observations or corrections applicable to a satellite and signal at a reference location. State-space representation (SSR) separates modelled error components, such as satellite orbit and clock corrections, biases and any supplied atmospheric states. The user evaluates the applicable components for its own observations. Swift Navigation's OSR and SSR explanations describe this distinction.
These labels are not a one-to-one replacement for the positioning methods. Conventional RTK commonly consumes observation-space reference data, and real-time PPP commonly uses state-space satellite corrections. But a network can generate observation-space data from an underlying error model. As a concrete vendor example, Swift lists both OSR and SSR delivery formats for its Skylark correction offering. That is a Swift service feature, not evidence of support in every receiver or any ResiNav product.
“SSR supported” also does not identify a complete correction set. The IGS real-time product descriptions distinguish streams with different constellations, orbit/clock information, code biases, phase biases and ionospheric information. A stream containing orbit and clock corrections must not be assumed to contain the regional atmosphere or phase-bias information another processing mode requires. RTCM itself can carry different kinds of GNSS information; its name does not select the model.
Initialization, coverage and age follow the actual implementation
Carrier-based estimation needs an adequately constrained set of unknowns, not just a connected correction source. Conventional float-ambiguity PPP can require observations over time to separate coupled parameters. PPP ambiguity-resolution approaches add suitable bias information; atmospheric assistance can further change initialization. PPP-RTK services use additional reference information for fast precise positioning, but the name alone does not identify the supplied states, region or achieved startup behaviour. Navipedia's PPP fundamentals discusses how external bias and ionospheric information change the conventional convergence problem.
RTK likewise does not guarantee an immediate valid integer solution under every geometry, tracking history or atmospheric condition. Compare the documented initialization and reinitialization conditions, supported signals and actual solution states. Neither “PPP is always slow” nor “RTK is always instant” is a sound requirement.
Coverage has two meanings: where the data can be received and where its model is applicable. A globally reachable Internet caster can serve a regional correction model. Wide-area satellite orbit/clock information does not automatically supply equally useful local atmospheric information everywhere. The station geometry, service area and processing method determine how much spatial separation matters; there is no universal base-distance limit supplied by a transport label.
Correction age concerns the time represented by the applicable correction, not merely the latest packet arrival. Orbit, clock, bias and atmospheric messages can have different update intervals and validity rules. Associate them with the correct observation epochs, satellites, signals and broadcast ephemeris reference where required. The IGS SSR format specification defines correction epochs, update intervals and navigation-data associations as distinct fields and conventions. A recent network packet containing an old applicable state is not a fresh correction. Use the service and receiver's actual age and validity definitions rather than a universal maximum-age threshold.
Follow the reference information through the full solution
Return to the integrator's three streams. Code corrections can support the intended code-differential model but do not supply an RTK carrier ambiguity solution. Reference-station carrier data can support an appropriate RTK estimator, but it is not the same object as a satellite clock/bias product. Satellite-state corrections can support a compatible PPP implementation, but forwarding them unchanged into an input expecting reference observations does not make that implementation exist.
Galileo HAS provides a useful real service example: the GSC describes corrections delivered by E6-B or Internet that still require a suitable PPP user algorithm. The HAS overview makes reception and computation separate functions. The existing HAS delivery guide covers the resulting antenna and delivery choice without repeating it here.
None of these correction models automatically removes user-local multipath, NLOS reception, receiver noise or RF interference. Nor can they repair a wrong coordinate frame, reference coordinate or output-point transformation merely by delivering more messages. These are different error sources and integration tasks. Where interference protection is separately needed, the anti-jamming versus RTK guide keeps that reception function distinct from correction processing; this comparison adds no ResiNav DGNSS, RTK, PPP, correction-service or decoder capability.
The useful selection question is therefore concrete: what physical quantities does this data describe, and which documented estimator will use them with these observations? Answering it explains both why a stream is useful and why another stream on the same connection may not be a substitute.
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.