Manual
Table Of Contents
- Title
- Contents
- 1 Integration manual structure
- 2 System description
- 3 Receiver functionality
- 3.1 Receiver configuration
- 3.1.1 Changing the receiver configuration
- 3.1.2 Default GNSS configuration
- 3.1.3 Default interface settings
- 3.1.4 Basic receiver configuration
- 3.1.5 Differential timing mode configuration
- 3.1.6 Legacy configuration interface compatibility
- 3.1.7 Navigation configuration
- 3.2 Geofencing
- 3.3 Logging
- 3.4 Communication interfaces
- 3.5 Predefined PIOs
- 3.6 Antenna supervisor
- 3.7 Multiple GNSS assistance (MGA)
- 3.8 Clocks and time
- 3.9 Timing functionality
- 3.10 Security
- 3.11 u-blox protocol feature descriptions
- 3.12 Forcing a receiver reset
- 3.13 Firmware upload
- 3.1 Receiver configuration
- 4 Design
- 5 Product handling
- Appendix
- Related documents
- Revision history
- Contact
ZED-F9T-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.10.3 GNSS receiver integrity
3.10.3.1 Secure boot
The ZED-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.10.3.2 Secure firmware update
The firmware image itself is encrypted and signed by u-blox. The ZED-F9T verifies the signature at
each start.
3.11 u-blox protocol feature descriptions
3.11.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.11.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. 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.
UBX-19005590 - R05
3 Receiver functionality Page 52 of 87
C1-Public Early production information