AG3335 Variants Explained: How to Choose Between M, A, AT, and AD
On this page
TL;DR
AG3335 is one hardware platform with several product definitions, so the suffix is a responsibility boundary rather than a rank. M and MA keep RTK work on the host, MN and MNA serve NavIC programs, A packages RTK+DR, AD handles vehicle dead reckoning, and AT and AE open application-layer compute for teams with a real software plan.
AG3335 is a GNSS platform family, not one interchangeable chip. Its suffixes point to different responsibility boundaries: PVT-first output, packaged RTK+DR, vehicle dead reckoning, OPEN application compute, regional positioning requirements, and module-level implementation choices.
In the previous Deep Dive, we explained the AG3335 GNSS platform decision for real machines. That article was about 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 from Airoha. 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.
How to Read Suffixes
Read suffixes as selection signals, not as a universal public feature matrix. Public briefings, supplier naming, module firmware, and customer-specific product implementations may differ. Final module specifications, firmware release notes, and supplier documentation always win before layout or production commitment.
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:
| Characteristic | What the shared baseline provides |
|---|---|
| Compute | Arm Cortex-M4F application processor up to 530MHz. This gives the platform room for packaged algorithms and application-layer behavior. |
| Process Node | Built on a 12nm semiconductor process, AG3335 can combine dual-band GNSS, onboard compute, and low-power operation in a compact module platform. |
| Tracking | 135-channel GNSS tracking engine. This gives the receiver enough channel budget for multi-constellation and L1/L5 operation. |
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 and AG3335MA
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 off-chip RTK processing, 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 L1/L5 GNSS signals.
AG3335A: Packaged RTK+DR
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. AG3335A reduces algorithm-integration work, but it does not remove system-level confidence monitoring.
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
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, how GNSS and IMU split responsibility in a fused stack matters 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 and AG3335AE: OPEN Application 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.
AG3335 Variant Selection Table
After the branch-level differences are clear, use the product scenario and responsibility boundary as the first filter:
| Variant | GNSS Role | RTK / DR Boundary | OPEN Compute | Best Fit / Avoid If |
|---|---|---|---|---|
| AG3335M | PVT-first mainstream branch with RAW 1Hz. | Host-side RTK path when the product owns correction handling; no packaged DR branch. | No. |
Best: robotics, drones, handhelds, trackers, embedded GNSS modules, and cost-sensitive IoT with a capable host. Avoid: packaged RTK+DR behavior is required inside the GNSS subsystem. |
| AG3335MA | Automotive-oriented branch of the M path. | Same PVT-first responsibility model as M; no packaged DR branch. | No. |
Best: vehicle or automotive-adjacent products that need an automotive validation route. Avoid: the project needs an algorithm upgrade over M rather than a qualification path. |
| AG3335MN / MNA | India / NavIC-oriented PVT-first branch. | Evaluate by final module specification and regional certification scope; no generic packaged DR assumption. | No. |
Best: India-market programs where NavIC / IRNSS or AIS-140 / VLT requirements are explicit. Avoid: a global drop-in L1/L5 replacement is needed without an India-market requirement. |
| AG3335A | Packaged RTK+DR GNSS subsystem with RAW 10Hz. | RTK+DR behavior moves closer to the GNSS subsystem; external IMU integration still belongs to the product. | No. |
Best: RTK modules, receivers, and OEM products that want less host-side algorithm work. Avoid: the host team wants maximum control over the full RTK engine and correction stack. |
| AG3335AD | Vehicle dead-reckoning branch with RAW 1Hz. | Dedicated DR firmware path for external 6-axis IMU integration; RTK is not the primary reason to choose AD. | No. |
Best: cars, two-wheelers, shared mobility devices, and vehicle-like motion profiles that face tunnels or urban canyons. Avoid: motion is non-vehicle-like or IMU mounting and vibration cannot be validated. |
| AG3335AT | OPEN application-layer branch with RAW 1Hz. | Depends on software architecture built around the OPEN path; no packaged vehicle-DR assumption. | Yes. |
Best: teams that need positioning-adjacent logic close to the GNSS subsystem and can maintain embedded software. Avoid: the product only needs simple module bring-up. |
| AG3335AE | OPEN branch with more Flash and RAW 10Hz. | Depends on implementation and software ownership; no packaged vehicle-DR assumption. | Yes. |
Best: OPEN compute programs that need more memory room and higher raw-data rate than AT. Avoid: OPEN compute or RAW 10Hz does not justify the added responsibility. |
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 chip-to-product responsibility boundaries are not just packaging choices. They decide how much engineering risk the customer owns at each level:
| Level | Layer | What this layer owns |
|---|---|---|
| 01 | Chip Family | Airoha AG3335 defines silicon capability, variant branches, raw observation behavior, algorithm paths, and compute headroom. |
| 02 | Module Layer | LC29H, SE868K5, and Kalmix Guide package RF layout, firmware, testing, interfaces, and support around the chip family. |
| 03 | Receiver Layer | Field-ready units add enclosure, connectors, power, mounting, waterproofing, host behavior, and deployment expectations. |
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.
Key Takeaway
Do not choose AG3335 by suffix hierarchy. Choose it by responsibility boundary: what the chip should output, what the module firmware should package, and what the host system is ready to own.
Frequently Asked Questions
What is the difference between AG3335M, AG3335A, and AG3335AD?
AG3335M is the PVT-first branch with RAW 1Hz and more host-side responsibility. AG3335A packages RTK+DR behavior closer to the GNSS subsystem and outputs RAW 10Hz. AG3335AD is the vehicle dead-reckoning branch with RAW 1Hz and an external 6-axis IMU path. The right choice depends on whether the host, module firmware, or GNSS subsystem should own positioning behavior.
Which AG3335 variant supports RTK+DR?
AG3335A is the clearest RTK+DR branch when a module or receiver should package more positioning behavior inside the GNSS subsystem. AG3335M can still support advanced host-side RTK paths through raw observations, but the host must own correction handling, RTK logic, validation, and maintenance. For a product team buying integration speed, A is usually the cleaner starting point.
What does OPEN compute mean in AG3335AT and AG3335AE?
OPEN compute means the variant exposes more application-side compute and memory room around the GNSS engine. AG3335AT uses this path with RAW 1Hz, while AG3335AE adds more Flash and RAW 10Hz. OPEN is valuable only when the product team has embedded software capability, test coverage, update control, and a real reason to run positioning-adjacent logic near the GNSS subsystem.
What is AG3335MN?
AG3335MN is an India / NavIC-oriented branch, not a simple upgrade over AG3335M. It becomes relevant when NavIC / IRNSS, AIS-140, VLT, or India-market vehicle-location requirements are explicit. Do not assume MN is a global L1/L5 replacement for M or MA; final supplier documentation and module specifications should decide signal, certification, and application fit.
What is AG3335AT used for?
AG3335AT is used when a team wants OPEN application-layer compute around the GNSS engine rather than a simple fixed-output module path. It can fit products that need custom positioning-adjacent logic close to the GNSS subsystem. It is not the default choice for teams without embedded firmware ownership, regression testing, update strategy, and a clear software reason for the OPEN path.
Does AG3335A or AG3335AD include an IMU?
No. AG3335A and AG3335AD provide firmware support for DR behavior, but the IMU is external. The AD path can work with mainstream 6-axis IMU vendors such as ST, Bosch, and TDK. Sensor selection, electrical integration, placement, calibration, vibration control, temperature behavior, and validation remain part of the module or product design.
Continue exploring
GNSS Signals Explained
Why constellation and L1/L5 behavior set the ceiling every variant branch inherits.
LateralRTK Accuracy Trap
How to verify a variant choice in the field instead of trusting datasheet numbers.
ApplyGNSS Receiver Guide
Compare module, board, and field-ready receiver options once the suffix is settled.
