AG3335 Variants Explained: How to Choose Between M, A, AT, and AD

In the previous Deep Dive, we explained why Kalmix chose AG3335 as a GNSS platform for real machines. That article was about the platform decision: why this chip family gives Kalmix enough headroom for dual-band GNSS, raw observation output, RTK integration, and module-level product design.

This article is the next layer down. Once AG3335 is selected as the platform, the harder engineering question becomes: which variant should a product actually use? The answer is not hidden in the suffix alone. It depends on what the host processor can own, what the GNSS subsystem should deliver, what regional or automotive requirements apply, and how much software control the customer really needs.

AG3335 Is a Family, Not a Single Chip

AG3335 is best read as a family of product definitions built around one shared hardware platform. The familiar suffixes — M, MN, MA, MNA, A, AT, AD, and AE — do not form a simple low-to-high ranking. They point to different firmware paths, memory configurations, RAW data behavior, algorithm packages, qualification targets, and market requirements.

That matters because two modules can both be AG3335-based while carrying different engineering assumptions. One may be a compact PVT-first positioning module. Another may package RTK+DR behavior inside the GNSS subsystem. A third may expose more application-side compute for teams that want to run their own logic close to the positioning engine.

This is why part-number selection cannot be separated from system architecture. The chip is shared, but the responsibility boundary changes.

AG3335 Series Baseline — Compute, Process, and Tracking Capacity

The AG3335 family starts from three shared hardware characteristics that explain why one platform can support different GNSS product roles:

On the signal side, AG3335 is best understood as a dual-band L1/L5, multi-constellation platform across GPS, GLONASS, Galileo, BeiDou, and QZSS. NavIC / IRNSS should be evaluated through the MN / MNA branch, rather than assumed as the default reason to choose every AG3335 variant.

AG3335M / AG3335MA — The PVT-First Starting Point

AG3335M is the standard PVT-first branch: 4MB Flash, no PSRAM, RAW 1Hz, and no packaged onboard positioning algorithm.

M is not a weak version of AG3335. It is the branch to start from when the product already has a capable host and mainly needs reliable GNSS output, raw observations, and a clean module integration path. That is why M often fits robotics, drones, handheld devices, trackers, and cost-sensitive IoT systems better than a heavier algorithm-side variant.

For advanced teams, RAW 1Hz output is still useful. It can feed a host-side RTK engine, custom filtering, or a deeper integration path on RTOS, Linux, or Android. This route can make sense for products that already have a host processor, modem, and cloud connection.

The trade-off is clear: M keeps the silicon path lighter, but it asks the host system to own more correction handling, RTK logic, validation, and long-term software maintenance.

AG3335MA is the automotive-grade branch of AG3335M. It keeps the same PVT-first logic and RAW 1Hz behavior, but moves the product path toward AEC-Q100-oriented validation for vehicle and automotive-adjacent programs. MA is not an algorithm upgrade over M; it is the automotive branch of the M path.

AG3335MN / AG3335MNA — The India / NavIC Branch

AG3335MN and AG3335MNA keep the PVT-first logic, but shift the product definition toward India-market NavIC / IRNSS and AIS-140 / VLT requirements.

This is a different kind of suffix. MN should not be read as M plus every signal. It is better understood as a regional product-definition branch. If the customer requirement explicitly calls for NavIC / IRNSS in the India vehicle-location context, MN or MNA becomes relevant.

If the product depends on global L1/L5 behavior — for example GPS L5, Galileo E5a, or BeiDou B2a outside the India-market context — do not treat MN as a drop-in replacement for M or MA. For background on why signal and constellation choices matter, see GNSS Signals Explained.

AG3335A — Packaged RTK+DR Inside the GNSS Subsystem

AG3335A is the integrated RTK+DR branch: 4MB Flash, 4MB PSRAM, RAW 10Hz, and firmware support for packaged RTK plus dead reckoning.

This is where the product philosophy changes. With M, the host may own more of the RTK engine. With A, more of the positioning behavior is packaged inside the GNSS subsystem. That can shorten the integration path for a module, receiver, or boxed positioning device.

The practical value of A is packaging. For a module or receiver vendor, RTK+DR can be delivered as part of the GNSS subsystem instead of becoming a customer-owned algorithm project. That matters when the customer wants a positioning box, not a raw-observation integration program.

The host still has work to do. It must read the output, monitor fix quality, handle correction flow, log failures, and decide how the machine should react when confidence drops. For a deeper explanation of why GNSS confidence should be treated as probability rather than a fixed truth, see GNSS Accuracy Decoded.

But the host no longer has to rebuild the full positioning engine from raw observations upward.

The DR side still depends on external IMU integration. A gives the product a packaged RTK+DR path, not a free pass around sensor selection, mounting, calibration, vibration, and validation.

AG3335AD — Dead Reckoning for Vehicles and Two-Wheelers

AG3335AD is the vehicle dead-reckoning branch: 4MB Flash, 4MB PSRAM, RAW 1Hz, and DR firmware for use with an external 6-axis IMU.

AD is relevant when the motion profile looks like a vehicle or two-wheeler. A car, motorcycle, bicycle, or shared mobility device may need continuity through tunnels, garages, and urban canyons. In those cases, inertial bridging can matter more than open-sky accuracy alone.

The IMU is not inside the chip. AG3335AD provides the DR algorithm path, while the product still owns IMU selection, electrical integration, mechanical placement, calibration, vibration control, and validation. At the algorithm-integration level, the AD path can work with mainstream 6-axis IMU vendors such as ST, Bosch, and TDK, but the exact sensor choice remains a module or product-design decision.

AG3335AT / AG3335AE — OPEN Application-Layer Compute

AG3335AT and AG3335AE are OPEN application-layer branches. AT uses 4MB Flash, 4MB PSRAM, and RAW 1Hz. AE expands Flash to 8MB and outputs RAW 10Hz.

OPEN is not a shortcut for every team that wants flexibility. It means the chip exposes more application-side compute and memory room around the positioning engine, so a capable team can host its own positioning-related logic closer to the GNSS subsystem.

This is valuable only when there is a real software plan. If the customer does not have embedded software capability, test coverage, update strategy, and a clear reason to run code near the GNSS engine, OPEN becomes extra responsibility rather than extra value.

Selection Summary: Start from the Product Scenario

After the branch-level differences are clear, use the product scenario — not the suffix name — as the first filter:

This is not a ranking ladder. Each branch moves a different part of the positioning workload between the chip, the module firmware, and the host system.

Chip, Module, and Receiver Are Different Decisions

AG3335 is the silicon family. Module products such as Quectel LC29H, Telit Cinterion SE868K5, and Kalmix Guide sit one layer above that silicon.

A module adds RF layout, filtering, clocking, power design, firmware packaging, production testing, shielding decisions, and sometimes inertial integration. A receiver adds enclosure, connectors, waterproofing, mounting, power input, host interface, and field deployment behavior. Products such as Kalmix SCOUT PRO live at that receiver layer.

This is why the difference between RTK module and RTK receiver is not just packaging. It decides how much engineering risk the customer owns.

Variant selection and integration-level selection are related, but they are not the same decision.

Where Kalmix Guide Fits

Kalmix Guide is our module-level path into the AG3335 family. It gives OEM teams a way to use AG3335 without starting from bare silicon, RF design, and firmware packaging.

Different Guide models, including K35C and K35E, exist because customers do not all want the same integration depth. Some want packaged behavior and fast bring-up. Others want Kalmix RTK engine integration and deeper SDK control. Those Guide model names should not be read as public one-to-one mappings to specific AG3335 silicon variants.

For OEM integration, the module-level deliverables matter more than the public suffix: PVT output, raw observations, packaged RTK+DR behavior, SDK-level control, production firmware, and a support model that matches the customer’s integration depth.

Conclusion

The value of AG3335 is not that every variant does everything. The value is that one hardware foundation can be packaged into different responsibility boundaries: a simple PVT module, a host-driven RTK path, a packaged RTK+DR subsystem, a vehicle DR path, or an OPEN application-layer platform.

Good variant selection removes work from the wrong part of the system. It keeps automotive validation, India-market requirements, correction handling, IMU integration, and application-layer software in the places where the product team can actually support them.

Frequently Asked Questions