Skip to main content
NavCore™ · Research preview

A second opinion on
every GNSS fix.

What it does

NavCore checks each GNSS fix against an inertial estimate, flags jamming and spoofing, picks a navigation mode, and writes each flag and mode change to a hash-chained log.

It is a navigation-integrity library inside QCOS, offered as a research preview. The logic is implemented; it has not been tested at sea, in the air or on track, and it holds no type approval.

50 m

GNSS vs inertial gate

10 dB

C/N0 drop that flags a jam

300 s

Holdover before denied

Thresholds set in the code, not measured performance.

NavCore integrity monitor · one update
INPUT
GNSS fix, C/N0, AGC, IMU sample
CHECKS
INERTIAL
50 m gate
JAMMING
FLAGGED
LOG
SHA-256 chain
OUTPUT
Navigation mode
HOLDOVER
Status
ALERT
EVIDENCE
sha256(event + previous_hash) · held in memory

Example: what the code returns when a jam is flagged.

Sensor-Agnostic Inputs

Plain inputs in.
Every decision out.

The integrity logic takes GNSS and inertial samples as plain values, so it is not tied to one receiver. There is no receiver driver; connecting a specific receiver is pilot work.

INPUTS
GNSS receiver
Position, clock bias, C/N0, AGC, satellites used
Inertial unit
Accelerations and rates for the filter
Recorded logs
The same values replayed from a voyage
NavCore™ integrity monitor
Python library in QCOS
GNSS vs inertial cross-check
Jamming and spoofing flags
Mode switching
Hash-chained event log
OUTPUTS
Navigation mode
Full GNSS, degraded, inertial-only or holdover
Integrity status
With the list of active faults
Event log
Spoofing flags, jamming flags and mode changes, chained by hash
Implemented in Code

What the Code Does Today

Each card says what is implemented and what we found when we replayed the logic on simulated voyages.

No detection rate, false-alarm rate or accuracy figure is published. None has been measured on real signals. The gaps below are OBSERVED by replaying NavCore's own logic on simulated inputs; real-signal results are TO-VALIDATE in a pilot.

Spoofing Flags

IMPLEMENTED

Raises a spoofing flag when the fix jumps more than 150 m between updates, the receiver clock bias jumps by more than 1,000 m, or the signals arrive suspiciously uniform and strong (spread under 2 dB, mean above 50 dB-Hz).

Gap OBSERVED in simulation: reacquiring after a GNSS outage of about 21 s at 14 kn trips the jump check.

Inertial Cross-Check

IMPLEMENTED

Compares each GNSS fix with an inertial position and flags a disagreement above 50 m. Given an independent inertial position, it flagged a simulated 0.5 m/s drag-away once the offset reached 50 m.

Gap OBSERVED in simulation: inside NavCore’s own fusion filter, the position it compares against has already absorbed earlier GNSS fixes, so the same drag-away was never flagged in 15 minutes, 420 m off. Catching drag-away needs an independent inertial reference; TO-VALIDATE on recorded data.

Jamming Flags

IMPLEMENTED

Flags a C/N0 drop of more than 10 dB against a rolling baseline, an AGC rise above 20, or the satellite count falling below four.

Gap OBSERVED in simulation: the baseline is the last 10 samples, so a jam that persists becomes the new normal after about 8 s.

Mode Switching

IMPLEMENTED

Each update picks a navigation mode: full GNSS, degraded GNSS, inertial-only, or holdover when a jam or spoof is flagged. After 300 s in holdover or inertial-only, the status drops to denied (alert while a threat is still flagged).

The mode is decided again on every update, so one clean update returns to GNSS while the threat may still be present.

Hash-Chained Event Log

IMPLEMENTED

Each spoofing flag, jamming flag and mode change is appended to a SHA-256 hash chain. Verification flags an entry whose hashed fields were edited.

Gaps OBSERVED: the chain is not keyed or signed, so an edit with the hashes recomputed from that entry on passes verification, and so does deleting the newest entries. The fault-flag snapshot is not hashed, holdover-limit and sensor faults are not logged, and the chain lives in memory; persistent storage is pilot scope.

Integrity Status

IMPLEMENTED

Each update also carries a status (nominal, caution, holdover, alert or denied) and the list of active faults, so the operator sees why the mode changed.

Not offered: protection levels. The code’s HPL/VPL fields are a DOP-scaled placeholder, not an integrity computation.

The Problem: A Receiver Rarely Says It Is Wrong

GNSS jamming and spoofing are reported by ships and aircraft in several regions. The fix on screen can look normal while it is not.

Drag-Away

A spoofer can move the reported position a little at a time, so no single update looks wrong. Only an independent reference, such as inertial navigation, disagrees.

Silent Degradation

Jamming lowers signal strength and drops satellites. A receiver can keep reporting a position long after it should have stopped being trusted.

Little Record

After an incident, few systems can show what the receiver reported, what was flagged, and when the navigation source changed.

First Pilot Domain: Maritime

A pilot replays your own recorded GNSS and IMU data through NavCore and reports what it flags, when, and what it misses. No figure is promised before the data is in.

Maritime

Integrity checks for vessels that sail through interference

Threats

  • GNSS jamming and spoofing reported in the Black Sea, the eastern Mediterranean and the Gulf
  • Slow drag-away that no single update reveals
  • Little record of what the receiver reported during an incident

What NavCore Runs

  • Checks: position and clock jumps, C/N0 and AGC, satellite count, and the GNSS vs inertial cross-check
  • Continuity: full GNSS, degraded, inertial-only or holdover, with a 300 s holdover limit
  • Record: a SHA-256 hash-chained event log held in memory; persistent storage is pilot scope

What a Pilot Measures

  • Which of your recorded jamming and spoofing events NavCore flags, and how late
  • How many flags it raises on clean passages, including after GNSS outages
  • How far the inertial estimate drifts on your IMU during holdover
  • Whether the event log answers the questions your incident reviews ask

What NavCore is not: it does not optimise routes, fuel or weather routing, and it does not replace type-approved navigation equipment.

Not in NavCore Today

Listed so nobody buys it for something it does not do.

Capabilities

  • No Galileo OSNMA authentication. The OSNMA code is research only.
  • No protection levels and no satellite exclusion.
  • No receiver drivers and no NMEA or AIS ingest. Connecting a receiver is pilot work.
  • No hosted API. The integrity monitor runs as a library; it is not served over HTTP today.
  • No published detection rate, false-alarm rate or accuracy figure, because none has been measured on real signals.
  • No quantum-sensor integration. The code’s quantum mode is never selected.

Standards and Approvals

NavCore is not certified and holds no type approval. It has not been assessed against IEC 61108, IMO performance standards for navigation equipment, or any aviation or railway standard.

Any standards work would follow a pilot, not precede it.

Have recorded voyage data?

Send us a passage with known interference. We replay it through NavCore and show you every flag, every mode change and every miss.