ZED-F9P - Integration manual
The monitoring algorithm relies on comparing the currently measured spectrum with a
reference from when a good fix was obtained. Thus the monitor will only function when the
receiver has had at least one (good) first fix, and will report "Unknown" before this time.
The monitor is reporting any currently detected interference over all currently configured signal
bands.
3.12.3 GNSS receiver integrity
3.12.3.1 Secure boot
The ZED-F9P boots only with firmware images that are signed by u-blox. This prevents the execution
of non-genuine firmware images run on the receiver.
3.12.3.2 Secure firmware update
The firmware image itself is encrypted and signed by u-blox. The ZED-F9P verifies the signature at
each start.
3.13 u-blox protocol feature descriptions
3.13.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.13.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.
UBX-18010802 - R08
3 Receiver functionality
Page 63 of 110
Early production information
