Host-Based RTK: Why Moving the RTK Engine Off-Chip Still Matters
TL;DR
- Host-based RTK means the RTK engine runs outside the GNSS chip, on a host processor or communications SoC that consumes raw GNSS measurements.
- This architecture is not new. A 2G-era implementation path separated measurement quality from algorithm compute and pushed high-precision positioning toward single-digit-dollar solution costs.
- Modern GNSS platforms can include application-side compute, so off-chip RTK is no longer only a workaround for limited silicon. It is an intentional responsibility-boundary decision.
- The longer-term question is whether GNSS will follow automotive radar toward a more decoupled architecture: sensing close to the antenna, more signal processing and positioning logic on centralized compute.
Platform Decision
Do not assume the RTK engine belongs inside the GNSS chip. On-chip RTK and host-based RTK are both valid architectures. The right boundary depends on measurement quality, available host compute, cost targets, update strategy, and how much positioning behavior the product team needs to own.
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.
What Is Host-Based RTK?
Host-based RTK is an architecture where the GNSS front end outputs raw measurements and an external processor, modem, or host CPU runs the software RTK engine. The host consumes rover observations, correction data, and system context, then calculates or helps calculate the high-precision position.
This split only makes sense because RTK positioning is a workflow, not a single chip feature. Raw measurements, correction handling, ambiguity resolution, confidence checks, and position output all have to meet at the engine boundary. For the full correction-side background, start with the RTK GPS correction workflow.
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.
A Fair Reading of M8P
M8P and later host-based architectures solved different problems. M8P demonstrated that integrated RTK could enter compact products. The off-chip path addressed the next question: how far could the cost fall when the measurement front end and RTK engine were no longer required to live in the same silicon package?
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.
Off-Chip RTK Processing and Raw Measurements
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.
Host-Based RTK Responsibility Boundary
The boundary becomes easier to see when the positioning stack is split into responsibility layers.
Layer 1
GNSS RF + Baseband
Tracks satellite signals and generates pseudorange, carrier-phase, Doppler, and related measurements.
Layer 2
Raw Measurements
The measurement stream passed from the GNSS front end to the positioning engine.
Layer 3
RTK Engine
Consumes rover observations and correction data to calculate a centimeter-level solution.
Layer 4
Host or Comms SoC
Provides the external compute environment when the RTK engine is moved off-chip.
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:
Host-Based RTK Data Path
GNSS RF + Baseband
Tracks satellite signals close to the antenna.
Raw Measurements
Passes carrier phase, pseudorange, and Doppler observables outward.
MTK6261 / Host Compute
Provides the external processor already present for connectivity.
Software RTK Engine
Consumes rover observations and corrections to resolve the solution.
High-Precision Position
Outputs the corrected position to the product system.
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.
In that practical architecture, 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.
Where the RTK Engine Should Live
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 GNSS platform.
How Host-Based RTK Relates to AG3335
Host-based RTK is an architecture choice. AG3335 is a GNSS platform that can support multiple product shapes and responsibility boundaries. The distinction matters: this page explains where the RTK engine can live, while the AG3335 variants page explains how M, A, AT, and AD variants differ.
Within the Kalmix portfolio, AG3335 is the silicon platform, GUIDE is the module-level path built on it for OEM integration, and SCOUT PRO is the field-ready receiver for teams that need a finished device rather than a board-level design.
Comparing Engine Placement: On-Chip, Host-Based, and Cloud-Assisted
Engine placement is easiest to reason about once it is separated from product packaging. A module, a receiver, and a host-driven architecture answer different questions; for the packaging decision, use the module vs receiver architecture framework instead. This section stays on one axis: where the RTK engine actually runs.
The engine-placement trade-offs are easier to compare directly:
| Architecture | Engine Location | Latency / compute | Control and maintenance | Best fit |
|---|---|---|---|---|
| On-chip RTK | Inside the GNSS subsystem | Low integration latency; compute is bundled with the GNSS subsystem | Firmware behavior depends more heavily on the GNSS vendor | Packaged receivers, simpler product integration, teams that want less engine ownership |
| Host-based RTK | External host, modem, or communications SoC | Depends on measurement transport, host CPU margin, and scheduling discipline | Product team owns measurement transport, compute budget, engine validation, OTA updates, and long-term maintenance | OEM products that need cost control, algorithm ownership, or application-specific behavior, and that gain value from controlling cost and RTK behavior together |
| Cloud-assisted processing | Server or cloud service supports part of the positioning workflow | Network latency and availability become part of the positioning budget | Centralized updates are easier, but offline behavior and data governance must be designed | Adjacent reference for fleet analytics, post-processing, monitoring, or workflows where real-time autonomy is not dependent on the cloud |
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.
Architecture Question
The long-term boundary may not be “RTK on-chip or off-chip.” It may be “how much GNSS processing still needs to remain inside a dedicated GNSS chip at all?”
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.
Key Takeaway
Host-based RTK is a responsibility-boundary architecture: the GNSS side produces raw measurements, while an external host or communications SoC runs the software RTK engine. It mattered first because it lowered cost. It still matters because it gives product teams another way to balance silicon choice, software ownership, OTA iteration, and system economics.
Frequently Asked Questions
What is host-based RTK?
Host-based RTK is an architecture in which the GNSS chip outputs raw measurements while an external host processor, modem, or communications SoC runs the software RTK engine. The external processor consumes rover observations and correction data, then calculates the high-precision position.
Why can moving the RTK engine off-chip reduce BOM cost?
By avoiding dedicated RTK compute on the GNSS side when equivalent processing capacity already exists elsewhere in the product. A communications SoC or Cat.1 module may already be handling connectivity, correction-data transport, and system control. Running the software RTK engine on that existing processor means the product does not pay twice for compute.
If GNSS chips now have more compute, why still run RTK off-chip?
Off-chip RTK is no longer only a workaround for limited GNSS silicon. It can also provide algorithm ownership, application-specific tuning, an OTA path controlled by the product team, less dependence on one GNSS vendor’s roadmap, and better use of compute already present elsewhere in the device.
Can RTK run on a Cat.1 module today?
Yes, when the product validates CPU margin, memory, raw-measurement transport, correction-data flow, OTA updates, and long-term software support. Cat.1 bandwidth alone is not enough. The module must provide a maintainable compute environment for the RTK engine.
Will GNSS follow automotive radar toward centralized compute?
Possibly, but it is not a settled direction. Automotive radar is moving some processing from edge sensors toward centralized compute. GNSS may test a similar separation between RF sensing, raw-measurement generation, positioning, RTK, and fusion. The practical boundary will still depend on power, bandwidth, latency, certification, and fault-isolation requirements.
You Might Also Like
Why Kalmix Chose AG3335
Read the platform-level reasoning behind Kalmix’s AG3335-based GNSS architecture for real machines.
FoundationalInside NTRIP
Understand how correction data moves from a caster to a rover over an IP network.
ProtocolRTCM Unpacked
See how binary correction messages carry the observations an RTK receiver actually depends on.
