ZED-F9T - Integration Manual
The monitor is reporting any currently detected interference over all currently configured signal
bands.
3.7.2 Spoofing detection / monitoring
3.7.2.1 Introduction
Spoofing is the process whereby someone tries to forge a GNSS signal with the intention of fooling
the receiver into calculating a different user position than the true one.
The spoofing detection feature monitors the GNSS signals for suspicious patterns indicating that
the receiver is being spoofed. A flag in UBX-NAV-STATUS message (flags2 -
spoofDetState
) alerts
the user to potential spoofing.
The spoofing detection feature monitors suspicious changes in the GNSS signal indicating external
manipulation. Therefore the detection is only successful when the signal is genuine first and when
the transition to the spoofed signal is being observed directly. When a receiver is started up
to a spoofed signal the detection algorithms will be unable to recognize the spoofing. Also, the
algorithms rely on availability of signals from multiple GNSS constellations; the detection does not
work in single GNSS mode.
3.8 u-blox protocol feature descriptions
3.8.1 Broadcast navigation data
This section describes the data reported via UBX-RXM-SFRBX.
The UBX-RXM-SFRBX reports the broadcast navigation data message collected by the receiver
from each tracked signal. When enabled, a separate message is generated every time the receiver
decodes a complete subframe of data from a tracked signal. The data bits are reported, as received,
including preambles and error checking bits as appropriate. However because there is considerable
variation in the data structure of the different GNSS signals, the form of the reported data also
varies. Indeed, although this document uses the term "subframe" generically, it is not strictly the
correct term for all GNSS (e.g. GLONASS has "strings" and Galileo has "pages").
3.8.1.1 Parsing navigation data subframes
Each UBX-RXM-SFRBX message contains a subframe of data bits appropriate for the relevant
GNSS, delivered in a number of 32 bit words, as indicated by numWords field.
Due to the variation in data structure between different GNSS, the most important step in parsing
a UBX-RXMSFRBX message is to identify the form of the data. This should be done by reading
the gnssId field, which indicates which GNSS the data was decoded from. In almost all cases, this
is sufficient to indicate the structure and the following sections are organized by GNSS for that
reason. However, in some cases the identity of the GNSS is not sufficient, and this is described,
where appropriate, in the following sections.
In most cases, the data does not map perfectly into a number of 32 bit words and, consequently,
some of the words reported in UBX-RXM-SFRBX messages contain fields marked as "Pad". These
fields should be ignored and no assumption should be made about their contents.
UBX-RXM-SFRBX messages are only generated when complete subframes are detected by the
receiver and all appropriate parity checks have passed.
Where the parity checking algorithm requires data to be inverted before it is decoded (e.g. GPS
L1C/A), the receiver carries this out before the message output. Therefore, users can process data
directly and do not need to worry about repeating any parity processing.
The meaning of the content of each subframe depends on the sending GNSS and is described in the
relevant Interface Control Documents (ICD).
UBX-19005590 - R01
3 Receiver functionality
Page 48 of 80
Advance Information
