On 31 October, Betaflight pull request #15946 proposed showing a GPS spoofing warning in the on-screen display. That is a useful case study in how integrity information should travel from a GNSS receiver to a pilot. The proposed change is open, with unit and build tests reported by its author but no end-to-end demonstration against a spoofing source. The broader issue predates this proposal and remains relevant to any aircraft that uses GNSS for an automated return.
What the receiver is actually reporting
The u-blox UBX-NAV-STATUS message has a field called spoofDetState in bits 3 and 4 of the flags2 byte for supported protocol versions. The documented states are 0 for unknown or inactive detection, 1 for no spoofing indicated, 2 for spoofing indicated and 3 for multiple indications.
The distinction between an indication and a guarantee is deliberate. In the u-blox M10 SPG 5.20 interface description, page 108, u-blox says the detector state reflects the current navigation epoch. Detection is often most likely when the receiver moves from a real signal into a spoofed one. A later value of 1 therefore says only that the detector did not trigger in that epoch. It does not say that the reported position is authentic.
This is a narrower statement than satellite count, fix type or dilution of precision. Those values describe characteristics of the receiver's navigation solution. They are not an independent authentication of the radio signals supplying it. A seemingly good fix and a spoofing indication can coexist.
Why GPS Rescue makes the interpretation consequential
Betaflight's GPS Rescue documentation describes an automatic sequence that climbs, turns toward the recorded home position, flies home and descends. It also warns that false or erratic GPS data can send the aircraft the wrong way, or defeat sanity checks.
That makes two errors possible:
- Ignoring a real integrity warning. The rescue controller may pursue a geometrically consistent route toward a false home vector. A healthy-looking GPS fix does not exclude this.
- Automatically treating every warning as grounds to stop flight. If a spoofing indication is false or transient, an immediate disarm or forced exit from rescue can be hazardous when the pilot's link is already lost.
Neither outcome can be resolved by a single boolean without an explicit safety policy. The aircraft's current mode, availability of manual control, terrain and obstacle margins, uncertainty in home position, and alternative sensor estimates change the risk. A safe response in a controlled line-of-sight test is not necessarily a safe response in an actual failsafe.
This problem is also distinct from a weak-signal GPS loss. A missing fix is conspicuous. A compromised but numerically plausible position may survive ordinary threshold checks.
What the Betaflight proposal would change
The 31 October proposal reads the u-blox detection state into Betaflight's GPS solution, keeps UBX-NAV-STATUS enabled on later receiver generations and exposes a blinking GPS SPOOFING OSD warning. The author proposes retaining a recent indication for ten seconds. That hold addresses a specific property documented by u-blox: detection may fire primarily during the changeover, then return to a no-indication state even though trust has not been restored.
The design preserves another distinction. The PR changes the warning behavior, not GPS Rescue's flight-control policy. Its author explicitly leaves automatic gating of Rescue or position hold for later discussion because an incorrect automatic response can introduce its own hazard.
The author reports parser and OSD unit tests, including state decoding, invalid checksums, warning aging and clearing after receiver communication is lost, plus two build targets. These tests support implementation correctness under the modelled inputs. They do not establish field detection sensitivity, false-positive rate, receiver-to-receiver consistency or pilot response time.
There is a useful compatibility caveat too. A Betaflight build, a GNSS module's chipset name and the module's protocol version are separate facts. The warning needs a firmware version that implements it, a supported receiver that actually emits the relevant status and an OSD configuration that displays the alert. None should be assumed merely because the receiver can produce latitude and longitude.
Validation needs two different test plans
The data-path test should be deterministic and safe to repeat on a bench. Feed known, synthetic receiver status messages through the normal parser; verify the four states, checksum rejection, age-out behavior, receiver-disconnect clearing and on-screen priority. Check that an ordinary position update cannot silently overwrite a recent indication. Logs should preserve the state and timestamps needed to reconstruct the alert.
The flight-policy test asks a different question: what should the aircraft do when it has an integrity indication but no usable RC link? Simulated trajectories can compare continued rescue, degraded-navigation handling and conservative fallback behaviors under controlled assumptions. The test needs to include false indications as well as incorrect positions, rather than optimising only for successful detection.
Real RF interference or spoofing trials require appropriate authorisation and controlled facilities. A hobby flight near other airspace users is not a valid way to establish detector sensitivity or exercise adverse GNSS scenarios. The FAA's GNSS interference resource guide collects pilot-facing information about jamming and spoofing but is not a substitute for validating the specific drone's recovery logic.
What a pilot can infer today
On present evidence, an explicit spoofing indication is a reason to distrust GNSS-dependent guidance and inspect the flight context. Silence from the detector is not an all-clear. Even the proposed Betaflight implementation does not remove the established GPS Rescue checks for a valid home point, credible home direction, receiver quality, update rate, wind margin and verified failsafe behavior.
For a builder, the most useful engineering question is whether the receiver's integrity information survives the full route into logs, warnings and controller decisions without losing its timing or uncertainty. For an operator, the question is which action remains safe when the only navigation source is in doubt and manual recovery may be unavailable.
Until independent controlled tests quantify the warning's detection behavior and a validated response policy exists, the spoofing state belongs in the warning and diagnostic chain. Treating it as an automatic verdict on flight safety would give a two-bit receiver report more authority than its own specification allows.