Buy a real-time navigation output when equipment or an operator needs the result during operation. Buy a post-mission trajectory when recorded data can be processed after collection for survey work, analysis or a reference dataset. If the job needs both, specify both deliverables: the later trajectory does not replace the output that was needed while the platform was moving.
For GNSS/inertial navigation system (GNSS/INS) procurement, this choice changes more than a software name. It determines whether the offer must include a working live output, the acquisition and logging needed for later processing, a processing licence or service, and the final files. Start with the consumer and the deadline, then compare equipment and software against that task.
Compare the purchase by when the result is needed
These are alternative purchasing tasks, not three packages every buyer needs. An existing system may already cover part of the scope. Count that part as existing equipment only when its actual configuration supplies the required output or records; do not buy a replacement merely because a software brochure shows another receiver.
A later trajectory answers a different time question
NovAtel describes Inertial Explorer as GNSS+INS post-processing software for post-mission position, velocity and attitude trajectories. Its published workflow includes processing, export and quality-control reports. This is a concrete commercial example of a later deliverable, not evidence that purchasing the software supplies a live navigation system.
SBG Systems' Qinertia dataset documentation distinguishes the recorded real-time solution from forward, backward and merged processing results. A backward pass uses a recorded sequence in reverse order. A result that uses later observations to refine an earlier epoch is available after those observations have been collected; it was not the same information the live consumer had at that earlier epoch.
The buying consequence is specific. Keep the live solution in the comparison when the machine needs information then. Assess the post-processed dataset for the later job. Do not transfer a final-trajectory accuracy statement to the earlier operational output. A fast or near-real-time processing workflow still needs to meet the particular consumer's availability requirement before it can be treated as that consumer's live input.
Keep existing acquisition equipment when it supplies the needed records
For a post-processing purchase, the first equipment decision is whether the acquisition path already records the inputs the chosen method consumes. A recorded position stream can support replay or analysis of that stream. It is not automatically the satellite and inertial measurement dataset needed to calculate a new GNSS/INS solution. The receiver interface guide explains this input distinction without treating every buyer as needing raw observations.
OxTS provides a useful equipment example. Its RT3000 v4 manual, in the software and post-processing sections, separates live-data viewing from NAVsolve processing of the unit's recorded raw files. Those records can be processed after the mission with changed settings. That capability belongs to the documented OxTS configuration; it is not a generic property of a GNSS output port.
If the existing equipment records a supported dataset, retaining it and adding the appropriate processing scope can be a complete purchasing option. If the necessary records are absent, a software-only offer leaves a specific gap. Compare enabling a documented output or logging option, changing the acquisition equipment, or choosing a workflow that actually uses the available data. A new cable or a different filename does not add missing measurement fields.
Choose the software scope for the result being purchased
A GNSS-only trajectory and a fused GNSS/INS trajectory are different processing deliverables. SBG's Qinertia product comparison distinguishes GNSS-only from inertial-plus-GNSS editions and lists different sensor support. Select the edition or service that covers the intended computation and the recorded inputs. This is a software-scope comparison, not a recommendation of a ResiNav-compatible package.
The final file is part of the order too. Name the required quantities, time convention, coordinate frame and point of reference, together with the export format and accompanying quality information. A vehicle-origin trajectory is not automatically the trajectory at a camera or another sensor. NovAtel's published Inertial Explorer export functions illustrate why the output location and format belong in the processing scope.
Buying a licence and buying a processed dataset also allocate work differently. In the first case, the buyer needs the processing entitlement, a supported computing environment and responsibility for producing the result. In the second, the service scope needs to include processing, export and delivery of the agreed files. Compare those completed outcomes rather than treating a software line item as an already delivered reference trajectory.
Compare two hypothetical offers against the actual job
Assume a hypothetical vehicle-testing team needs a navigation stream during each run and a reference trajectory for analysis afterwards. Offer A supplies the configured live navigation system and integration but no processing entitlement. Offer B supplies processing software and final-file preparation from supported logs, but no live navigation output.
For that two-deliverable requirement, neither offer alone covers the whole job. A can cover the operational output; B can cover later processing only if acquisition supplies its required records. Compare an offer that names both scopes, including who records the data and who delivers the processed files. This is a scope example, not a supplier quotation, price comparison or claimed test result.
Now change the job: the platform already has suitable operational navigation, and the unmet requirement is a survey trajectory after collection. Additional live-navigation hardware is not automatically required. Retain the existing acquisition equipment when it supplies the supported inputs; otherwise include the specific acquisition change. The choice follows the missing deliverable, not a rule that the more comprehensive hardware package is always better.
Identify which trajectory is delivered
Require the delivery to identify whether it contains the recorded live output or a newly processed solution. Preserve the original live record when the later analysis needs to compare what was available during the run. SBG's dataset documentation explicitly allows selecting and exporting different datasets; a plausible-looking trajectory plot alone does not identify which one was used.
Specify the usable result and its quality information before comparing headline accuracy. A processed result used as a reference still needs an agreed basis for that role; the word “reference” does not by itself make it independently verified ground truth. This keeps the operational record and the later analytical result traceable without assuming that one is an interchangeable copy of the other.
Keep GNSS reception protection in the relevant part of the order
When interference protection is required during acquisition, compare that reception path separately from navigation computation and later processing. A post-processing licence is not an RF-protection device. Conversely, a protection product's signal and RF-output specifications do not describe a GNSS/INS processing service.
Use the ResiNav product catalogue for the reception-protection portion. For an existing receiver path requiring GPS L1 and BeiDou B1, the RN-S65-4CH-SNB product record provides a published signal and RF-output basis for initial screening. It does not establish compatibility with the software or navigation systems cited here.
Follow the selected product's existing enquiry route for that portion of the purchase. State whether the navigation output is needed during operation, after collection or both, and identify equipment you plan to retain. The acquisition and processing scope can then be discussed as actual parts of the order rather than assumed to be included with GNSS reception protection.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.