Why SSR Corrections Look Different From RTCM's Older Format
Every method discussed earlier in this series, traditional RTK and network RTK alike, has used the same underlying philosophy for representing the errors it cancels. SSR represents them differently, and understanding that difference explains why PPP-RTK needs it specifically.
Traditional RTK differencing compares two locations and produces a single combined result that bundles every shared error source together, useful only nearby. SSR instead transmits each error source as its own distinct, physically meaningful piece, usable across a much wider area.
The Older Approach: One Number, One Station
Traditional RTK, whether from a single base or a network's modeled virtual station, works in what is often called observation space. The base transmits its own raw satellite observations, and the rover differences those observations directly against its own, canceling whatever error the two locations share. The result of that differencing is, in effect, a single combined figure for each satellite and band/frequency that bundles orbit error, clock error, and atmospheric delay together, since all three were present in both sets of raw observations and cancel out as one lump sum. That bundled result works extremely well nearby, precisely because RTK's whole strategy depends on the rover experiencing nearly the same combined error the reference station did.
The Newer Approach: Separate Pieces, Reusable Anywhere
SSR, state-space representation, breaks that single combined number back apart into its individual physical causes: how far off the satellite's broadcast orbit actually is, how far off its broadcast clock actually is, and what the atmospheric delay looks like across a region, each transmitted as its own distinct piece. A receiver anywhere within the network's coverage can then reconstruct whatever correction actually applies to its own specific location, rather than relying on a single number computed for one particular nearby station.
SSR corrections are not simply a more compressed version of the same information RTCM's traditional format sends. They describe fundamentally different things, individual physical error sources rather than one bundled total, which is exactly what allows them to be reused flexibly across a wide area instead of only near one station.
Why This Distinction Made PPP-RTK Possible
PPP-RTK needs regional atmospheric information that a single, sparse set of reference stations can still describe usefully across a wide area, something a bundled, station-specific correction was never designed to provide. SSR's separated components are what make that possible, letting a comparatively sparse network supply exactly the atmospheric piece a PPP-style receiver needs, without also needing to supply a dense, RTK-style total correction at every point in between.
A Concrete Example Worth Checking Carefully
PointPerfect Flex, introduced in the last chapter, is also a useful lesson in not assuming too much from a brand name alone. Its native SPARTN option is genuinely SSR: separated orbit, clock, and atmospheric components, delivered from a comparatively sparse regional network, exactly as this chapter describes. Its RTCM option, offered under the same PointPerfect Flex name, is documented by Thingstream, u-blox's own service platform, as a separate observation-space product, not the same SSR correction repackaged for a different wire format. SparkPNT hardware paired with PointPerfect Flex over RTCM is a working, everyday example of the OSR side of that same product line.
A correction service offers both an SPARTN option and an RTCM option under one product name. Is it safe to assume both are the same underlying correction, just packaged differently? Not automatically. PointPerfect Flex itself demonstrates that a single brand can offer two architecturally distinct services side by side, and the only way to know which one a receiver is actually getting is to check the documentation rather than assume from the name.
SSR separates a correction into individual physical components, satellite orbit, satellite clock, and atmospheric delay, rather than bundling them into one combined, station-specific number the way traditional RTK formats do. That separation is what allows a comparatively sparse regional network to support PPP-RTK's fast convergence across a wide area, and it is worth confirming directly which architecture a given branded service is actually using rather than assuming it from the name.
With PPP, PPK, and PPP-RTK all covered individually, this companion can now bring the two-question framework back and place every method on it explicitly, side by side.