Adding spoofing detection does not automatically mean replacing your GNSS receiver. First establish whether you need to read the status from a detector already supported by the receiver or add a new detection method. The first task needs a supported status output and host integration. The second needs the measurements or independent evidence used by that method. Those are different purchases, even if both quotations say “spoofing detection”.
For an integrator retaining equipment, the useful starting point is the detector’s input—not the connector name or the promise of a software upgrade.
Three proposals that can describe different equipment
These are implementation choices, not a ranking of detection performance. A proposed method must be assessed against the deception it is intended to detect.
To understand what those methods actually test, read how GNSS spoofing detection uses signal, navigation and spatial evidence.
If the receiver already detects, buy the alert integration
NovAtel describes spoofing detection within its OEM7 signal-processing chain. Its RXSTATUS documentation separately exposes a spoofing-detection indication. This is an example of a receiver performing the detection and the host consuming the result; it is not evidence that an arbitrary receiver can acquire the same detector through a generic application. [1][2]
For this route, the order should identify the supported receiver configuration, detector setup and exported indication, then the host’s response to that indication. The host integration does not have to reproduce the receiver’s internal detection algorithm.
This can avoid replacing working equipment merely to obtain an alert that it already offers. However, an absent alert is not a certificate of authentic positioning: detector availability, initialization and status validity still belong to the selected implementation. For example, NovAtel’s documented setup includes calibration under specified good-signal conditions. [3] That is a supplier-specific commissioning requirement, not a setting to apply to other products.
If you add a detector, buy its missing inputs too
A host application can examine a position stream for implausible changes. That does not give it access to the RF observations or internal signal metrics used by a receiver-native detector. The receiver interface guide separates navigation results, satellite observations and diagnostics; here, the purchasing question is which of those a proposed detection implementation actually requires.
For a consistency-based proposal, identify what the navigation result is compared with. A second calculation derived from the same suspect input is not automatically an independent reference. A motion constraint and a separate sensor also have different error limits. FOI’s published research summary treats navigation-data plausibility and additional sensor or receiver information as distinct contributions to detection. [4]
Do not assume that simply adding an IMU resolves the problem. Septentrio explains how gradual GNSS deception can remain within the drift expected by an inertial consistency check. [5] This supports defining the intended check and its limits; it does not establish a ResiNav GNSS/INS configuration or a guaranteed way to detect every attack.
Keep the receiver when the chosen implementation can obtain its required inputs from the retained configuration. Change the quoted scope when it cannot. Missing access may require a different receiver option or additional measurement equipment. A port adapter cannot create measurements the receiver does not export.
Compare quotations by what performs the detection
Consider a hypothetical project whose requirement is to pass a receiver-generated spoofing indication to an existing controller:
- Offer A supplies software that flags unusual position changes.
- Offer B configures a documented receiver-native detector and integrates its status into the host.
For that stated requirement, B addresses the requested function if the retained receiver supports it. A is a different plausibility-checking function, not an equivalent implementation merely because its description includes “spoofing”. If the buyer instead wants an additional motion-consistency check, A may address that separate requirement—provided its reference and operating limits are defined.
The comparison changes when a proposal needs measurements unavailable from the current receiver. That offer is incomplete for this installation until it includes a way to obtain those measurements. Compare the complete configuration against alternatives, rather than comparing a software-only price with a receiver-and-integration price.
This example describes purchase boundaries, not real offers, prices or tested performance.
Where ResiNav fits in that decision
If the requirement is GNSS reception protection rather than adding a host detection application, continue to the ResiNav product catalogue and compare documented model functions and signals. Detection software and reception protection should not be treated as interchangeable deliverables.
For a combined anti-jamming/anti-spoofing terminal with published BDS B1 and GPS L1 support, RN2501-AJS-4CH-DPA is one product to examine. Its current configuration provides position, velocity and time through HDMI without a separate GNSS receiver to obtain those outputs. [6] That confirmed PVT function does not establish an exported spoofing-status interface, raw-measurement access or compatibility with a named host detector.
Continue through the model page’s enquiry route for that terminal, or use the catalogue for other signal requirements. If the required purchase is specifically detector software, a status API or a sensor-fusion package, this article does not establish those as ResiNav supply items.
Sources
- NovAtel — GNSS Spoofing Detection: receiver-internal detection example.
- NovAtel OEM7 — RXSTATUS: exported receiver status example.
- NovAtel — GRIT Configuration Settings: implementation-specific initialization.
- FOI — Report FOI-R–4694–SE, English abstract: plausibility and additional information in detection. Only the public abstract is used.
- Septentrio — Why secure GPS receivers are crucial for GNSS/INS systems: limits of inertial consistency under gradual deception; supplier example only.
- ResiNav — RN2501-AJS-4CH-DPA: approved current product role, signals and PVT scope.
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.