RCB-F9T - Integration manual
3.9.3.1 Secure boot
The RCB-F9T 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.9.3.2 Secure firmware update
The firmware image itself is encrypted and signed by u-blox. The RCB-F9T verify the signature at
each start.
3.10 u-blox protocol feature descriptions
3.10.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.10.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).
3.10.1.2 GPS
The data structure in the GPS L1C/A and L2C signals is dissimilar and thus the UBX-RXM-SFRBX
message structure differs as well. For the GPS L1C/A and L2C signals it is as follows:
UBX-19003747 - R04
3 Receiver functionality
Page 35 of 54
Early production information
