TLDR: Before evaluating any GNSS/RTK hardware, you need three inputs: design constraints (power, cost, form factor, and compute — compute being the most underestimated), operating environment (sky visibility, antenna mounting, and platform dynamics), and application use case (what the system must output in its worst moments, not its best). A focused hour of discovery on these three inputs produces two or three candidate architectures ready for real-world testing — and avoids the redesigns that kill programs at DVT.
The most common thing I hear when a new customer comes in is: “I need to achieve one centimeter accuracy with GPS.”
That number usually came from a receiver datasheet. They found a module that supports RTK, saw the spec — “one centimeter plus one part per million times baseline” — and wrote it into their requirements. The follow-on question: how does that receiver actually deliver one centimeter in every environment the product will operate in?
That’s the start of the discovery process.
The spec sheet number is real, but it’s measured under ideal conditions: perfect sky view, an antenna with nothing interfering with it, a short baseline to the base station. Most products don’t operate anywhere near those conditions. The datasheet doesn’t come with accuracy figures for six different environments, because those environments aren’t its problem — they’re yours to design for.
Discovery is the process of replacing a number that belongs to the datasheet with a set of requirements that belong to your product.
The instinct to get to hardware quickly is right — the order matters
Engineers want to build and test. The pull toward hardware makes sense. But acting on it before gathering the right inputs is where programs lose time.
The teams that compress schedule on the left side of the V-model are the ones that run discovery well. A focused discovery conversation covers the core inputs in about an hour. Architecture options start forming during that conversation, not after — and the result is a team that reaches representative hardware faster, with higher confidence in the architecture they’re testing.
The system being designed is the entire localization stack: antennas, receivers, IMU, positioning engine software, connectivity for corrections. Not just the GNSS module. Every element gets shaped by what comes out of discovery.
The three inputs are design constraints, operating environment, and application use case.
Input 1: Design constraints — the four physical limits that bound every hardware decision
Before evaluating hardware, you need to know the constraints any hardware choice has to survive. These define the outer walls of the design space.
Power budget. A wearable device has a small battery. That constraint immediately narrows the class of receivers available. Higher-capability receivers typically draw more power, so a tighter power budget forces tradeoffs elsewhere in the system.
Cost target. A high-end survey receiver on every drone in a fleet produces excellent positioning — and isn’t viable at scale. The cost target defines the hardware ceiling at volume. RTK corrections change this math meaningfully: a lower-cost receiver with access to a correction network can achieve accuracy it couldn’t reach standalone, which opens a cost-performance tradeoff most teams don’t initially factor in.
Size, form factor, and PCB real estate. The antenna has to fit somewhere on the platform with a clear view of the sky. The receiver and compute have to fit the mechanical envelope. PCB real estate is finite, and every component that shares it introduces potential for RF interference. Form factor shapes antenna placement, which shapes signal quality, which shapes the entire positioning stack.
Compute availability — don’t pick the wrong one. This is the constraint underestimated most often, and the one that causes the most painful late-stage redesigns.
Most RTK receivers are modular — the positioning engine runs on the module’s own compute, which is limited. For applications with good open sky, that’s fine. But when additional sensors need to be fused, platform dynamics are complex, or anything beyond a standard RTK plus IMU solution is required, the compute ceiling becomes a hard wall.
Teams that built around a modular receiver and discovered at DVT that the sensor fusion their environment required was beyond what the module could support faced two options: strip back the system, or redesign around a host-based architecture where the positioning engine runs on the platform’s main compute. Either choice is expensive at that stage.
The shift we’re seeing is teams asking earlier: can we leverage the compute already on the platform? Often the answer is yes — and identifying that early keeps the architecture decision cheap.
Input 2: Operating environment — three layers that determine what the hardware has to survive
Design constraints define what the hardware has to be. The operating environment defines what it has to survive.
Where GNSS lives. Open sky is the easiest case. If a product always operates in open sky with an internet connection available, an RTK-only engine may be the right solution — and that’s worth saying directly. But open sky is rarely the full picture. Urban environments, construction sites, indoor/outdoor transitions, and anything that operates near structures creates multipath and signal degradation that changes the architecture entirely. An underground utility scanner that works in a parking lot is not the same product as one that works scanning right against a building wall.
What the device is mounted on. A roof-mounted antenna on a car has excellent sky view and a ground plane working in its favor. A chest-worn or shoulder-worn device is a different signal environment — body blockage, orientation variability, and harder-to-manage signal quality. The physical mounting determines starting signal quality, which determines how hard the positioning engine has to work, which determines what sensors are needed in the fusion.
Platform dynamics, vibration, and motion models. A drone has different motion characteristics than a car. A four-wheel-steering vehicle behaves differently from a two-wheel-steer platform in ways that matter for how a sensor fusion algorithm models motion. An agricultural tractor has specific vibration and slip profiles. A person walking generates a completely different dynamic signature.
The motion model is where this becomes concrete. The sensor fusion software models how the specific platform moves — what it does when it accelerates, turns, vibrates, or loses GNSS momentarily. A generalized model handles a wide range of platforms adequately. At the performance edge, a solution tuned to the platform’s actual dynamics will outperform it. Most modular receivers ship a generalized inertial solution — that’s a known tradeoff, but it has to be the right tradeoff for the application.
Signal quality ties all three layers together. It’s the primary determinant of whether centimeter-level RTK is achievable in a given operating environment.
Input 3: Application use case — what the system has to output in its hardest moments
What does the system have to output in its hardest moments, not its easiest? A product that achieves centimeter accuracy in open sky but fails everywhere else isn’t a product — it’s a prototype that passed the wrong test. The goal is a system that works 99.9% of the time, across the full range of environments the application will see.
That means accuracy has to be stated at a level that’s designable to. One centimeter is a target. What matters is the one-sigma error, the two-sigma error, the protection level, and what the system does when it can’t meet those bounds. Position only, or attitude as well — heading, pitch, and roll? A vehicle that needs to know its orientation through a banked curve is a different problem than a scanner that only needs absolute location.
The application conversation also surfaces constraints that weren’t obvious upfront. A team that describes their product as an outdoor handheld device may not initially frame it as an urban environment problem — until the use case is understood. Once it’s clear, the design implications follow directly.
Business outcome and scale. How does the application scale? Target volume shapes correction strategy, connectivity requirements, and architecture decisions — even when those feel distant at the requirements stage. Discovery is itself a productivity investment: a focused hour of input gathering compresses weeks of iteration that would otherwise happen at DVT.
What good discovery produces
The output of a well-run discovery conversation isn’t a finalized design. It’s two or three reference architectures that plausibly meet the requirements, ready to be evaluated against each other with real hardware in real conditions.
Keeping multiple options open at this stage is the point. Discovery gives enough information to avoid eliminating the wrong architecture too early. The next step — architecture options and real-world prototyping — is building representative versions of each candidate and testing them in the actual operating environment before any board goes to fabrication.
That’s what the next post covers.
If you’re early in a localization system design program and want to run through the discovery inputs before committing to hardware, schedule a Discovery Workshop with a Point One engineer.
Watch the full conversation — Catalyst Episode 2
FAQs
What is the Catalyst discovery process?
Catalyst is Point One’s methodology for localization system design. The discovery phase is the first step: a structured conversation to surface design constraints, operating environment, and application requirements before evaluating any hardware. It typically takes about an hour and produces two or three candidate architectures ready for real-world validation.
What are the three inputs to a GNSS localization system design?
The three inputs are design constraints (power budget, cost target, size and form factor, and compute availability), operating environment (GNSS sky visibility, physical mounting, and platform dynamics), and application use case (required outputs, accuracy bounds, and business outcome at scale).
Why isn’t a receiver datasheet spec good enough as a system requirement?
Datasheet figures like “1 cm + 1 ppm” are measured under ideal conditions — open sky, short baseline, no interference. Real products operate in environments that don’t match those conditions, and the datasheet doesn’t tell you what performance looks like when they don’t. Using a datasheet spec as a requirement means designing to the best case you’ll ever see, not the conditions you’ll actually ship into.
What is compute availability and why does it matter for GNSS system design?
Most modular GNSS receivers ship with limited onboard compute. For applications that need complex sensor fusion — fusing GNSS with IMU, cameras, lidar, or non-standard platform dynamics — that compute ceiling becomes a hard constraint. Teams that discover this at design validation rather than at requirements face an expensive architectural redesign. Identifying it early keeps the decision cheap.
What is a motion model and why does it affect localization performance?
A motion model is the set of assumptions in sensor fusion software about how a platform moves — its dynamics, turning behavior, vibration profile, and response to acceleration. A generalized model handles a wide range of platforms adequately. Applications at the performance edge, with unusual dynamics or demanding accuracy requirements, benefit from a model tuned to their specific platform.
How does the operating environment affect GNSS hardware selection?
The environment determines what signal quality the system can expect, which drives fusion architecture, which drives hardware selection. Open sky supports a simpler RTK-only approach. Urban environments, body-worn applications, and platforms with complex dynamics require additional sensors, higher-grade IMUs, and positioning engine software tuned to the specific platform.
How long does the discovery phase take?
For most programs, the core discovery conversation takes about an hour. Architecture options start forming during it. For larger programs or more complex environments there may be internal follow-up before a formal proposal, but the bulk of input gathering is fast when the right questions are asked in the right order.
How can I learn more about sensor fusion for GNSS localization systems?
Sensor fusion — the combination of GNSS, IMU, and other sensor data into a single position output — is a thread that runs through every stage of localization system design. The Catalyst series covers it in depth across multiple posts. The V-model post explains why fusion decisions made early in the design process become the hardest constraints to change later. The six common mistakes post covers the specific fusion-related choices — IMU grade, compute architecture, motion model — that most often cause redesigns at DVT. Upcoming posts in the series go deeper into architecture options, proof-of-concept prototyping, and how fusion requirements change as a design scales from 10 units to 100,000. You can also explore Point One’s positioning engine directly, or schedule a conversation with a field engineer.