A GNSS/INS can start without platform motion only when its documented initialization method supports that condition. A GNSS position fix alone does not establish that the fused position, velocity and attitude solution is ready for the task. Select the startup method and the required readiness state together, especially if the platform cannot move before it receives usable navigation data.
The buying question is not just whether a device can display heading while stationary. It is whether the selected navigation system can initialize after the intended restart and reach the required operating state within the movement and waiting time actually available.
Separate a GNSS fix, initial alignment and navigation readiness
GNSS acquisition establishes the satellite-derived information the receiver can provide. INS alignment establishes the initial conditions used by the inertial navigation process. Subsequent convergence can be another stage before the required performance is available.
NovAtel’s SPAN startup documentation explicitly separates an initial position, velocity and attitude estimate, completed alignment and filter convergence. For those products, an alignment-complete state is not the final evidence that specified performance has been reached. The supported methods also depend on the selected IMU and configuration.
This distinction changes an order. “Outputs a position after power-up” and “provides the required fused navigation solution before movement” are different deliverables. If the controller needs the latter, an offer that demonstrates only the former leaves the startup condition unanswered.
Choose a startup route that the platform can actually use
These are configuration choices, not three capabilities automatically included in every GNSS/INS. Nor does “stationary capable” identify a single universal technique.
NovAtel documents static coarse, kinematic, dual-antenna, stored-state and manual alignment methods for its SPAN products. Static coarse alignment is not available with every listed IMU; initial coarse attitude and subsequent convergence are also different stages. Those are product-specific examples. Their timings and movement thresholds should not be copied into another manufacturer’s acceptance requirement.
SBG Systems’ EKF modes explanation illustrates another important distinction: a vertical-reference mode, an orientation mode and full navigation are not interchangeable outputs. It describes different heading-initialization methods and motion profiles. A roll-and-pitch output at startup therefore should not be bought as evidence of a ready full navigation solution.
Stationary heading is an input to the decision, not the entire answer
A documented dual-GNSS heading function can remove dependence on vehicle motion for that heading observation. VectorNav’s GNSS Compass/INS explanation describes obtaining orientation from the relative GNSS observations rather than a motion-based estimate.
The existing dual-antenna heading guide covers what to buy when heading is required and why an anti-jamming array’s element count is not a heading specification. Use it for that product distinction. Here, the additional question is what the chosen INS does with the heading input and when its required navigation state becomes available.
A two-antenna feature in an offer is therefore relevant, but it is not the whole startup acceptance statement. Compare the supported initialization process and its status outputs, not merely the number of connectors or the presence of a heading value.
SBG’s land-application handbook separately discusses heading initialization and an alignment/warm-up phase for optimal performance. Its operational-before-convergence distinction is a concrete reason to retain the performance condition beside the quoted startup capability. The stated procedures apply to SBG equipment, not to a ResiNav terminal.
Compare the restart that changes the purchase
Consider a hypothetical outdoor platform that is powered off, transported to another location and orientation, and then restarted. Its controller must receive the required fused navigation state before the platform is allowed to move. No startup manoeuvre is available.
Offer A documents motion-based initial alignment. Offer B documents a stationary-capable initialization route, including the inputs it uses and the readiness state it reports. For this restart condition, A is incomplete unless another supported route is supplied. B remains a candidate; whether it meets the required startup time and accuracy is still a comparison of the documented configuration and evidence.
Now change the operation: movement before the mission is permitted, and the permitted manoeuvre satisfies A’s documented initialization conditions. A can return to the shortlist. The decision changed because the startup constraint changed, not because one system has a longer feature list.
A saved alignment from before transport is not automatically a valid solution to the first case. Likewise, a manually supplied orientation only addresses the case where that initial orientation is actually known. Name which restart the offer covers: first installation, unchanged-position power cycle, or relocation. This avoids comparing a convenient warm restart with a different cold-start requirement.
Put the ready state into the deliverable
Define the navigation output needed before movement and the documented status that identifies it. Where the selected system reports estimated uncertainty, include the criterion that matters to the task rather than accepting the mere presence of a message as readiness.
For the hypothetical platform, the useful evidence records power-up, first GNSS solution, initialized attitude, the required fused-navigation state and any permitted movement. The order should identify who configures the startup method and exposes that status to the host. An output adapter or a monitoring screen alone does not supply an absent initialization method.
This is an operational purchasing condition, not a new generic laboratory-test package. For broader navigation during a GNSS interruption, the outage-planning guide already defines the operating interval and aiding scope. Do not use an already-converged outage result to answer a restart that has not yet initialized.
Keep GNSS protection separate from the startup function
If RF interference protection is required as well, compare the ResiNav product catalogue for the documented GNSS reception role and signals. For a retained receiver path requiring GPS L1 and BeiDou B1, the RN-S65-4CH-SNB record provides a signal and RF-output starting point.
That reception-protection record does not establish an INS alignment mode, a stationary heading output or a complete navigation package. Select the navigation startup function from its own approved documentation, then review how the required reception path is protected. The receiver compatibility guide supports that separate interface discussion.
An initial enquiry can state the restart condition, whether movement is possible and which receiver is already installed. Those three facts make the next configuration discussion concrete without requiring a complete engineering dossier before first contact.
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.