Host-Based RTK: Why Moving the RTK Engine Off-Chip Still Matters

The question that shaped low-cost RTK was not only which GNSS chip to buy. It was where the RTK engine should run.

Most RTK conversations start with a chipset, a frequency combination, or a line on a specification sheet. That is understandable. The chip is visible, easy to compare, and easy to price.

But there is another architecture question underneath the product choice: should the GNSS silicon generate measurements and calculate the RTK solution internally, or should it expose raw measurements and let another processor run the engine?

I watched — and participated in — this transition as high-precision positioning moved beyond professional surveying. The shift from specialized survey tools to repeatable, mass-deployed machines forced the industry to re-evaluate where the RTK engine should run.

This is the core idea behind host-based RTK: the GNSS chip outputs raw measurements, while an external processor runs the software RTK engine. A deeper look at carrier-phase mathematics and GNSS positioning fundamentals explains why that split is possible.

High Precision Used to Belong to Professional Instruments

For a long time, centimeter-level positioning lived inside professional workflows: surveying, construction layout, machine control, and geodetic monitoring. The hardware was expensive, the workflow was specialized, and the user understood that setup time, antenna placement, and correction access were part of the job.

That model works when each measurement justifies a specialized instrument and a trained operator. It becomes harder to sustain when high precision has to be embedded into repeatable products. A tracker may be constrained by a few dollars of BOM. A robot or agricultural controller may tolerate a higher unit price, but it still cannot carry survey-instrument cost, setup complexity, and operator dependence into every production unit.

The problem was not whether RTK worked. It did. The problem was whether the full positioning subsystem could become small enough, inexpensive enough, and simple enough to enter products whose unit economics were completely different from survey equipment.

The NEO-M8P Milestone: Bringing Integrated RTK into a Compact GNSS Module

In 2016, u-blox brought the NEO-M8P to market. u-blox described it as an affordable centimeter-level RTK module and highlighted applications such as commercial UAVs and robotic guidance systems. The important part was not only the accuracy number. NEO-M8P packaged RTK into a compact GNSS module that product teams could actually buy and integrate.

That made NEO-M8P an important milestone. It showed that centimeter-level positioning did not have to remain inside large professional instruments. Drones, agricultural equipment, and early robotics projects could evaluate RTK without rebuilding a survey-grade receiver stack from scratch.

NEO-M8P did not finish the cost-down story. It opened it. By the late 2010s, an approximately hundred-dollar RTK module was a major improvement over traditional professional equipment. But it remained too expensive for tracking and other high-volume connected devices, and unnecessarily costly as an embedded building block for fleet-deployed machines.

Network RTK Made Corrections Available at Scale

At roughly the same time, the correction-service side was changing. RTK depends on more than a rover receiver. It also needs correction data from a base station or a network of reference stations.

By 2018, network RTK services were also reaching national scale in China. Qianxun SI’s nationwide “ONE Network” was built on more than 2,000 Continuously Operating Reference Stations (CORS), turning correction access into shared infrastructure rather than a project-by-project base-station deployment.

The transport details sit one layer below this article. NTRIP carries correction streams over IP networks, while RTCM defines the correction-data messages a rover consumes. The architecture point is simpler: once corrections became broadly available, the remaining bottleneck was the cost and ownership boundary inside the receiver.

The Cost-Down Move Was to Split Measurements from the Engine

The mass-market GNSS industry of that period had a structural constraint. Consumer positioning chips competed on cost, size, and power. Their main job was meter-level navigation. High-quality carrier-phase measurements and dedicated RTK compute were not always the center of the product roadmap.

RTK needed two different capabilities:

• Clean raw GNSS measurements. Carrier phase, pseudorange, Doppler, and related observables must be stable enough for a precision engine to use.
• A software RTK engine. The algorithm consumes rover observations and correction data, resolves ambiguity, evaluates confidence, and generates the final position.

A useful way to lower cost was to stop forcing both responsibilities into one expensive GNSS module. The measurement front end could stay close to the antenna. The software engine could move to compute that already existed elsewhere in the product.

The u-blox M8 generation made this possible. Products such as the NEO-M8T exposed raw measurement data, including pseudorange, carrier phase, and Doppler observations. Those measurements could feed a separate software RTK engine.

In the 2G era, one practical compute target was the MTK6261 GSM/GPRS communications SoC. The modem was already in the product to receive correction data. Its processor could also host the RTK engine. The architecture looked like this:

One implementation path I helped push forward in that era separated raw measurements from the RTK engine and moved the algorithm onto an MTK6261 communications SoC. It brought the positioning solution into the single-digit-dollar range and later supported million-scale deployment.

The point was not that one architecture defeated another. Host-based RTK changed the cost structure by separating measurement generation from algorithm compute.

This was host-based RTK in its most practical form: the GNSS component observed the sky, the communications SoC received corrections and ran the engine, and the product avoided paying for the same compute twice.

Why Off-Chip RTK Still Matters When Chips Have More Compute

The original constraint has changed. Platforms such as the AG3335 family now include an Arm Cortex-M4F application processor, so “the GNSS chip cannot run RTK” is no longer a sufficient reason to move the engine off-chip. The responsibility boundary can move between a PVT-first host-driven path and variants that package more positioning behavior inside the GNSS subsystem.

Today, off-chip processing is a deliberate architecture option rather than a workaround for limited silicon. It remains relevant for four reasons:

• Supplier independence. A software RTK engine reduces dependence on a single silicon vendor’s product roadmap, pricing structure, and firmware release cycle.
• Application-specific behavior. A product team can adapt filtering, correction handling, output policy, and degradation logic to the machine rather than accept a fixed pipeline.
• Software iteration. When the engine lives on an external host, updates can follow the product’s own OTA and validation process.
• Cost control. If a communications module or host processor is already present, using that compute can still produce a leaner system architecture.

This logic extends naturally from 2G to Cat.1. A Cat.1 module can be a viable home for RTK compute when its CPU margin, memory, measurement interface, correction flow, OTA path, and long-term software support have all been validated. The category label alone is not enough; the engineering boundary still has to be designed.

On-chip and off-chip RTK should not be treated as opposing camps. They are two ways to place responsibility. Designing for different responsibility boundaries is one of the engineering reasons behind Kalmix’s adoption of the AG3335 platform.

Within the Kalmix portfolio, AG3335 is the silicon platform behind GUIDE, the module-level path for OEM integration. SCOUT PRO serves teams that need a field-ready receiver rather than a board-level design.

The trade-offs are easier to compare directly:

Could GNSS Follow Automotive Radar Toward a Satellite Architecture?

Automotive radar offers a useful comparison. Traditional radar sensors perform substantial processing at the edge and send processed objects to the vehicle ECU. Newer satellite radar architectures move more processing toward centralized compute. Texas Instruments describes this as an emerging architecture that uses centralized processing, while Infineon describes centralized radar systems that stream raw ADC data to the ADAS compute unit instead of only sending object data.

The analogy is not exact. GNSS and radar have different signal chains, bandwidth requirements, and safety constraints. But the architecture question is similar: what must remain close to the RF front end, and what can move into centralized compute?

For GNSS, RF reception and tracking begin close to the antenna. Position calculation, RTK, filtering, fusion, and output policy do not have to remain in the same package. Host-based RTK already proved that one part of the positioning stack can move outward.

Could future GNSS systems expose a thinner sensing front end and move more baseband processing, observable generation, positioning, and fusion into shared compute? Possibly. That would not make sense for every product. Power, latency, bandwidth, certification, and fault isolation still matter.

But it is a worthwhile question. The first wave of host-based RTK separated measurements from the engine to reduce cost. A future GNSS satellite architecture could push the same principle further: keep the parts that must see the sky close to the antenna, and move more of the parts that calculate position into software-defined compute.

Conclusion

High-precision GNSS moved downmarket in stages. Compact integrated RTK modules proved that centimeter-level positioning could leave professional instruments. National-scale correction networks made RTK data broadly available. Host-based RTK then showed that the measurement front end and RTK engine did not need to remain inside one expensive package.

GNSS architecture is expanding from a fixed assumption that measurements and RTK compute must share one package toward a wider set of decoupled designs, where sensing stays close to the antenna and more positioning logic can move onto host compute.

The original implementation conditions have changed, but the architecture choice remains useful. Modern chips can run far more logic internally. External hosts and communications modules can also carry more positioning responsibility than before. The decision is no longer forced by compute scarcity alone. It is a system-design choice about cost, software ownership, iteration speed, and where a product team wants the debugging boundary to sit.

The next question is larger than RTK. As more signal-processing systems move toward centralized compute, GNSS engineers should keep asking which layers truly belong inside dedicated positioning silicon — and which layers are there mostly because that is where the industry learned to put them.

Frequently Asked Questions