RCB-F9T - Integration manual
3.11.4.2 Secure firmware update
The firmware image itself is encrypted and signed by u-blox. The RCB-F9T verifies the signature at
each start.
3.12 u-blox protocol feature descriptions
3.12.1 Broadcast navigation data
This section describes the data reported via UBX-RXM-SFRBX.
UBX-RXM-SFRBX reports the broadcast navigation data message the receiver has collected from
each tracked signal. When enabled, a separate message is generated each 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. This
document uses the term "subframe", but other GNSS data structures might use different terms, for
example, GLONASS uses "strings" and Galileo uses "pages".
3.12.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-RXM-SFRBX 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. Because of this, the following sections are organized by GNSS.
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.12.1.2 GPS
The data message structure in the GPS L1C/A (LNAV) and L2C/L5 (CNAV) signals is different and
thus the UBX-RXM-SFRBX message structure differs as well. For the GPS L1C/A and L2C/L5 signals
it is as follows:
3.12.1.2.1 GPS L1C/A
For GPS L1C/A signals, there is a fairly straightforward mapping between the reported subframe
and the structure of subframe and words described in the GPS ICD. Each subframe comprises ten
data words, which are reported in the same order they are received.
Each word is arranged as follows:
UBX-22004121 - R01
3 Receiver functionality
Page 40 of 64
C1-Public
Early production information
