Why Kalmix Chose AG3335: Building a GNSS Platform for Real Machines

High-precision GNSS is moving into real machines. For Kalmix, that changed the decision. We were not choosing only a chip. We were choosing the foundation for a product family.

Why GNSS Platform Choices Started to Matter More

Two transactions in 2025 caught our attention. Hexagon agreed to acquire Septentrio NV, a leading OEM provider of GNSS technologies, and the deal closed later that year, with Septentrio absorbed into Hexagon's Autonomous Solutions division. Around the same time, u-blox agreed to be taken private by US private equity firm Advent International.

Both companies remain important GNSS suppliers. The point is not that existing platforms are weakening. The point is simpler: high-precision positioning is becoming part of larger autonomy and machine-control systems, and that made platform choices more important to us.

For Kalmix, that shaped a longer-term decision. We are building modules and receivers around a shared GNSS foundation, so the question was not “which chip wins on today’s specification sheet?” It was: which platform can still support our product architecture three years from now, when customers move from evaluation to production?

This article is a record of that reasoning — why Airoha’s AG3335 fit the architecture Kalmix wanted to build. We are not claiming it is the only way to build a high-precision receiver. It is the engineering math that made sense for our roadmap.

High-Precision GNSS Has Moved Into Real Machines

For most of GNSS history, “high-precision” meant a surveyor with a tripod in an open field, waiting for the rover to converge. The user was a person, the environment was cooperative, and the system could afford to wait.

Real machines do not get those luxuries.

A robotic mower navigating between trees, an outdoor delivery robot moving along a service road, a survey drone working near power lines — these are GNSS receivers placed inside a real-time control loop, fused with IMU and perception data on a deterministic schedule. The receiver no longer serves a person reading a screen. It feeds a state estimator that is about to make a steering or thrust decision in the next control cycle.

When a machine is closing the loop on its own, the definition of a “good” GNSS receiver changes. Three requirements drove our platform thinking.

The first is solution stability. A two-meter altitude jump is not just an accuracy error. To a flight controller, it is a disturbance that demands a correction the controller has no good way to evaluate. The issue is solution consistency, epoch over epoch. That stability lives at the observation and engine layer, not somewhere the host can patch later.

The second is honest trust signaling. A high-confidence wrong answer is more dangerous than a low-confidence honest one. A machine can safely degrade or stop on a Float solution. It cannot safely act on a Fixed solution that is not really fixed. We have written separately about what centimeter-level accuracy actually means probabilistically; the same lens applies here. Confidence reporting is part of the output the host has to use, not a side metric.

The third is integrability. Position data has to line up with IMU samples, wheel odometry, and perception output. If the timing is off, the fusion layer ends up solving the wrong problem.

For machines, the receiver does not need to look perfect at every epoch. It needs to be explainable enough for the host system to decide what to do next. These three requirements set the bar for the platform underneath.

For the operational view of these requirements — what they look like during robot bring-up, how they break down in real worksites, and the four common failure modes RTK actually exhibits in the field — see our companion article, RTK GPS for Robotics. The rest of this piece focuses on the platform decision itself.

Why Dual-Frequency GNSS Became Practical for More Machines

For many years, mass-market GNSS platforms were optimized around low power, small size, and meter-level navigation. RTK-grade observables were not the main design pressure for those applications.

Two things changed at roughly the same time. RTK, PPP, and tightly coupled GNSS+IMU fusion started moving into more industrial products. These systems need cleaner carrier-phase and pseudorange observations than meter-level navigation does. At the same time, advances in CMOS process and tighter RF integration made dual-frequency L1/L5 GNSS designs easier to build at compact form factors and lower cost.

Those changes started to meet in the early 2020s. That is what made L1/L5 reachable for large-volume automation hardware rather than a survey-grade luxury.

The framing that mattered for Kalmix was not whether dual-frequency was available. It was whether dual-frequency was deployable at the volumes our customer base targets. For a robotic mower, an autonomous cart, or an outdoor service robot, BOM economics, supply continuity, firmware maintainability, and yield consistency all become binding constraints — constraints the professional GNSS industry has not historically had to solve at the same volumes.

That is the window AG3335 sits in. It is not perfect — no platform is. It fits this set of constraints well: L1/L5 capability, mass-market semiconductor economics, and the architectural flexibility automation products need.

Why Kalmix Needed a Platform, Not Another Black Box

This is the part of the analysis where chip-selection conversations usually get derailed by datasheets. So let’s be direct about what actually breaks in the field.

High-precision positioning is a long signal chain:

If anything fails along that chain, the host sees the same symptom: the position is wrong. And if the most critical mid-stages — observable extraction, RTK engine, output policy — sit inside a closed firmware stack the integrator cannot touch, debugging those edge cases becomes slow and indirect. In many cases, the team ends up depending on vendor-side reproduction, firmware release cycles, and another round of black-box testing. That cadence is acceptable for prototypes. It is structurally hard to align with shipping a robotic product at scale, where a field regression has to be root-caused in days, not release cycles.

It is worth being honest about the trade-offs of fixed-output platforms. They are stable, well documented, and easy to bring up. For teams without GNSS engineering depth, or for products where positioning does not need to differentiate, they remain a sensible choice. The ceiling is what changes at scale: you can adjust parameters, but not strategies; you can tune thresholds, but not behaviors.

A closed chip behaves like a peripheral. It pushes coordinates out of a serial port and the host takes what it gets. Automation systems need a positioning subsystem that behaves more like a node inside the machine’s control architecture, with fix logic, output policy, and degradation behavior that can be shaped to fit the rest of the system.

To be clear, “platform” here does not mean access to the baseband. Commercial GNSS chip vendors generally do not open that layer, and AG3335 is no exception. The baseband is the silicon vendor’s core IP. What matters to Kalmix is the layer above it: access to raw observations like carrier phase and pseudorange, and enough application-layer room to run our own RTK engine, filtering and fusion logic, and output policy on top of the platform.

That boundary is the one that mattered to us. It is not “control over every layer.” It is control over the parts of the stack that decide field behavior: how the receiver fixes, filters, degrades, reports confidence, and talks to the host.

This is not a claim that fixed-output platforms are wrong. It is a description of what kind of company we are. For teams pursuing differentiation in autonomous machines, the platform model gives more leverage. For teams optimizing for fastest time-to-shipment with a generic positioning solution, fixed silicon is still defensible. We chose the path that fits our roadmap.

What Actually Matters in an Automation GNSS Platform

Strip away the marketing layer, and a GNSS platform for automation has to clear four bars. AG3335’s value to us was not that it ranked first on every one. It was that it gave a reasonable answer across all four, instead of optimizing only one of them.

A multi-frequency, multi-constellation signal foundation. Real machines work under tree canopies, in urban canyons, and beside reflective metal structures. L1/L5 dual-band tracking across major constellations gives compact receivers a stronger foundation for satellite visibility under obstruction. There is also a physical reason L1/L5 helps in obstructed environments: GPS L5 uses a 10.23 MHz chipping rate, while L2C uses a composite 1.023 MHz chipping rate. That ten-fold gap compresses the multipath error envelope at the signal-structure layer. Software can help, but signal structure still sets the starting point. This does not make L1/L2 obsolete. It explains why L1/L5 has become a strong direction for low-power, mass-deployable automation hardware.

Raw observation quality. Carrier-phase noise, pseudorange cleanliness, and consistent tracking under low SNR are the bedrock RTK runs on. No amount of clever engine work compensates for dirty observables. This is the trust anchor for everything else in the stack.

Compute headroom and firmware customizability above the baseband. The real value of having compute available is not running things faster. It is running different things — your own RTK engine instead of stock firmware, your own message structures instead of a fixed output set, your own degradation strategy when corrections drop out. Without this layer, signal capability and observation quality are just numbers on a datasheet.

Mass-deployment economics. Automation OEMs ship at much higher volumes than survey equipment. As customers move from evaluation units to production deployments, BOM cost, peripheral circuit simplicity, long-term supply continuity, and yield consistency at industrial scale all become binding constraints. A platform that performs well in evaluation but struggles with volume, cost, or supply continuity is hard to build an industrial product line around.

These four bars are Kalmix’s internal floor. AG3335 stood out because it gave a reasonable answer on each — not because it was the strongest on any single metric. Avoiding a weak link across signal, observables, application-layer control, and production economics mattered more to us than topping a single benchmark.

From AG3335 to Kalmix Product Architecture

A platform decision only matters if the product architecture built on top of it actually works.

The Kalmix product architecture translates Airoha’s AG3335 silicon into deployable hardware across four engineering layers: silicon platform, OEM module, receiver-level hardware, and application-specific behavior.

Layer 1 — AG3335 Platform. L1/L5 dual-band capability, high-quality raw observables, multi-constellation tracking, and an application-processor environment let us run positioning logic above the baseband. This is the silicon foundation shared across AG3335-based products in our line.

Layer 2 — Kalmix Guide Module. For OEM customers who want to skip the RF design, power management, and production validation work, Kalmix Guide is the module-level starting point. It includes our reference RF layout, supply design, factory test process, firmware configuration, and Kalmix’s RTK engine running in the application layer. For board-level evaluation, start with the Guide hardware overview before moving into pinout, specifications, and protocol details during PCB integration.

Layer 3 — Receiver-Level Products. When the customer wants a deployable receiver rather than a module, Kalmix can package the same platform into a field-ready form factor with enclosure, antenna, interface, mounting design, and production testing. The module and receiver layers share the same AG3335 foundation, RF design logic, firmware engineering, and RTK engine. They differ in form factor and in how deeply the customer engages with the underlying stack. For a broader decision framework on this boundary, see our Deep Dive on RTK module vs RTK receiver selection.

Layer 4 — Application-Specific Tuning. The same Layer 1–3 hardware behaves differently depending on the host. A mower, UAV, agricultural machine, and delivery robot may all use the same positioning platform, but they should not necessarily use the same output rate, message structure, confidence reporting, degradation behavior, or host protocol. The chip sets the limits; the product work happens above it.

The point of this architecture is simple: the same AG3335-based stack can support module-level OEM integration, deployable receivers, and application-specific tuning without restarting from a different GNSS foundation each time.

Three Problems We Kept Seeing in Real Deployments

In many automation deployments, the hard part is not only the positioning algorithm. It is the boundary between the receiver and the machine. Three problems showed up consistently when GNSS got deployed into real systems. None of them is unique to AG3335 or to Kalmix, but each one decides whether the positioning subsystem actually works in production.

Data fit with the host system. ROS, ArduPilot, PX4, and automotive ECUs all want different message structures, timestamps, output frequencies, and confidence representations. The same RTK fix has to look different depending on who is consuming it. A platform with configurable application-layer output can adapt to the host. A fixed-output receiver forces the host to adapt instead, effectively passing an ongoing integration tax to the application side.

Installation and lever-arm calibration. A receiver measures the antenna phase center, not the vehicle’s control reference point. The lever-arm offset, mounting tilt, and vibration coupling between antenna and chassis all need to be addressed in engineering. They should not be handed to every customer as homework. A platform with configurable application-layer firmware lets us provide calibrated mounting workflows and clearer host-side compensation paths, instead of leaving each customer to solve the same problem from scratch.

Honest degradation under correction loss. When NTRIP drops or the RTCM stream stalls, the wrong answer is to silently maintain a stale Fixed status. That feeds high-confidence wrong data into whatever fusion logic the host runs, and there is no graceful way for the filter to recover from corrupted state. The right answer is honest state reporting through the degradation chain — Fixed, Float, DR-assisted where supported, then no-fix — with confidence metadata the host can act on.

These problems do not get solved by picking the “best” chip. They get solved by having enough control points to address them, which loops back to the platform-versus-component argument from earlier.

The deployment-side treatment of these problems — the four common ways RTK fails in field deployments, the trust/degrade/stop state machine that handles them, and the broader engineering details that decide whether a robot survives its first season — is the focus of RTK GPS for Robotics.

Choosing AG3335 Does Not Mean Other Platforms Are Wrong

We are not arguing that AG3335 is the universal answer. It is not.

Platforms like u-blox ZED-F9P have one of the most mature toolchains in dual-frequency GNSS, with a large developer base and a deep catalog of integration examples. For teams whose products are already validated and shipping, replacing a proven F9P-based design is rarely a defensible engineering decision. Switching costs, regression risks, and recertification overhead almost always outweigh the upside.

Survey-grade platforms from NovAtel, Trimble, and Septentrio’s AsteRx line remain strong choices for measurement-first applications where absolute performance matters more than unit cost.

Where Airoha’s AG3335 fits differently is in its semiconductor background. It comes from a product family closer to high-volume electronics than to traditional survey-grade GNSS receivers. That background matters for automation customers, whose question is not only “can this platform deliver the precision I need?” but also “can this platform support production volume, cost targets, and long-term supply for the next several years?”

Survey-grade silicon was never architected for cost-sensitive volume deployments. That is not a technical deficiency. It is a deliberate market positioning. Different platforms are built for different priorities.

Kalmix’s choice is not a claim that those platforms are wrong. The priority for our product direction was different: L1/L5 capability, application-layer room for our RTK engine, configurable behavior, and production economics suitable for automation customers. Platform selection is an engineering trade-off, not a loyalty decision.

Closing: Building GNSS for Real Machines

The next generation of GNSS products will not be judged only by static accuracy numbers on a datasheet. They will be judged by how they behave on real machines: under vibration, partial obstruction, correction loss, mounting constraints, and production cost pressure.

Airoha’s AG3335 gives Kalmix a platform foundation aligned with that direction. Kalmix builds the modules, receivers, and firmware behaviors tuned for specific deployment conditions on top of it.

Frequently Asked Questions