Ublox ZED-F9R Use and care manual


ZED-F9R
u-blox F9 high precision sensor fusion GNSS receiver
Integration manual
Abstract
This document describes how to enable a successful design with the ZED-
F9R module. It provides reliable multi-band RTK turnkey solution with up to
30 Hz real time position update rate and full GNSS carrier raw data.
www.u-blox.com
UBX-20039643 - R01
C1-Public

ZED-F9R-Integration manual
Document information
Title ZED-F9R
Subtitle u-blox F9 high precision sensor fusion GNSS receiver
Document type Integration manual
Document number UBX-20039643
Revision and date R01 11-Nov-2020
Document status Advance information
Disclosure restriction C1-Public
This document applies to the following products:
Product name Type number Firmware version PCN reference
ZED-F9R ZED-F9R-01B-00 HPS 1.20 N/A
u-blox reserves all rights to this document and the information contained herein. Products, names, logos and designs
described herein may in whole or in part be subject to intellectual property rights. Reproduction, use, modification or
disclosure to third parties of this document or any part thereof without the express permission of u-blox is strictly prohibited.
The information contained herein is provided "as is" and u-blox assumes no liability for the use of the information. No warranty,
either express or implied, is given with respect to, including but not limited to, the accuracy, correctness, reliability and fitness
for a particular purpose of the information. This document may be revised by u-blox at any time. For most recent documents,
please visit www.u blox.com.
Copyright © 2020, u-blox AG.
u-blox is a registered trademark of u-blox Holding AG in the EU and other countries.
UBX-20039643 - R01

Page 2 of 105
C1-Public Advance information

ZED-F9R-Integration manual
Contents
1 Integration manual structure............................................................................................ 6
2 System description...............................................................................................................7
2.1 Overview.................................................................................................................................................... 7
2.1.1 High precision sensor fusion (HPS)............................................................................................7
2.1.2 Priority navigation mode...............................................................................................................7
2.1.3 Real time kinematic......................................................................................................................8
2.2 Architecture..............................................................................................................................................8
2.2.1 Block diagram..................................................................................................................................8
3 Receiver functionality.......................................................................................................... 9
3.1 Receiver configuration........................................................................................................................... 9
3.1.1 Changing the receiver configuration..........................................................................................9
3.1.2 Default GNSS configuration.........................................................................................................9
3.1.3 Default interface settings..........................................................................................................10
3.1.4 Basic receiver configuration...................................................................................................... 10
3.1.5 RTCM corrections........................................................................................................................ 12
3.1.6 Navigation configuration............................................................................................................13
3.2 High precision sensor fusion (HPS).................................................................................................. 15
3.2.1 Introduction................................................................................................................................... 15
3.2.2 Solution type................................................................................................................................. 16
3.2.3 Installation configuration........................................................................................................... 16
3.2.4 Sensor configuration...................................................................................................................19
3.2.5 HPS system configuration......................................................................................................... 22
3.2.6 Operation....................................................................................................................................... 23
3.2.7 Priority navigation mode............................................................................................................ 31
3.3 Geofencing..............................................................................................................................................33
3.3.1 Introduction................................................................................................................................... 33
3.3.2 Interface......................................................................................................................................... 33
3.3.3 Geofence state evaluation......................................................................................................... 33
3.4 Communication interfaces................................................................................................................. 34
3.4.1 UART............................................................................................................................................... 35
3.4.2 I2C interface..................................................................................................................................36
3.4.3 SPI interface..................................................................................................................................39
3.4.4 USB interface................................................................................................................................40
3.5 Predefined PIOs.....................................................................................................................................41
3.5.1 D_SEL..............................................................................................................................................41
3.5.2 RESET_N........................................................................................................................................ 41
3.5.3 SAFEBOOT_N................................................................................................................................41
3.5.4 TIMEPULSE................................................................................................................................... 42
3.5.5 TX_READY..................................................................................................................................... 42
3.5.6 EXTINT............................................................................................................................................43
3.5.7 WT and DIR inputs...................................................................................................................... 43
3.5.8 GEOFENCE_STAT interface....................................................................................................... 43
3.5.9 RTK_STAT interface.....................................................................................................................44
3.6 Antenna supervisor.............................................................................................................................. 44
UBX-20039643 - R01

Contents Page 3 of 105
C1-Public Advance information

ZED-F9R-Integration manual
3.6.1 Antenna voltage control - ANT_OFF........................................................................................45
3.6.2 Antenna short detection - ANT_SHORT_N............................................................................ 46
3.6.3 Antenna short detection auto recovery..................................................................................46
3.6.4 Antenna open circuit detection - ANT_DETECT................................................................... 47
3.7 Multiple GNSS assistance (MGA)..................................................................................................... 47
3.7.1 Authorization................................................................................................................................ 48
3.7.2 Multiple servers............................................................................................................................48
3.7.3 Preserving information during power-off................................................................................48
3.7.4 AssistNow Online......................................................................................................................... 48
3.8 Save-on-shutdown feature................................................................................................................. 52
3.9 Clocks and time.....................................................................................................................................53
3.9.1 Receiver local time.......................................................................................................................53
3.9.2 Navigation epochs....................................................................................................................... 53
3.9.3 iTOW timestamps........................................................................................................................54
3.9.4 GNSS times................................................................................................................................... 54
3.9.5 Time validity.................................................................................................................................. 54
3.9.6 UTC representation..................................................................................................................... 55
3.9.7 Leap seconds................................................................................................................................ 56
3.9.8 Real-time clock............................................................................................................................. 56
3.9.9 Date.................................................................................................................................................56
3.9.10 Time pulse...................................................................................................................................57
3.9.11 Timemark.................................................................................................................................... 60
3.10 Security.................................................................................................................................................61
3.10.1 Spoofing detection / monitoring............................................................................................ 61
3.10.2 Jamming/interference indicator............................................................................................ 62
3.10.3 GNSS receiver integrity............................................................................................................63
3.11 u-blox protocol feature descriptions.............................................................................................. 63
3.11.1 Broadcast navigation data...................................................................................................... 63
3.12 Forcing a receiver reset.....................................................................................................................71
3.13 Firmware upload................................................................................................................................. 71
4 Design..................................................................................................................................... 72
4.1 Pin assignment......................................................................................................................................72
4.2 Power supply..........................................................................................................................................74
4.2.1 VCC: Main supply voltage.......................................................................................................... 74
4.2.2 V_BCKP: Backup supply voltage............................................................................................... 74
4.2.3 ZED-F9R power supply...............................................................................................................75
4.3 ZED-F9R minimal design....................................................................................................................75
4.4 WT and DIR interface example..........................................................................................................76
4.5 Antenna...................................................................................................................................................77
4.5.1 Antenna bias................................................................................................................................. 79
4.6 EOS/ESD precautions.......................................................................................................................... 81
4.6.1 ESD protection measures.......................................................................................................... 81
4.6.2 EOS precautions...........................................................................................................................82
4.6.3 Safety precautions...................................................................................................................... 82
4.7 Electromagnetic interference on I/O lines.......................................................................................82
4.7.1 General notes on interference issues......................................................................................83
4.7.2 In-band interference mitigation................................................................................................83
4.7.3 Out-of-band interference........................................................................................................... 84
4.8 Layout......................................................................................................................................................84
4.8.1 Placement...................................................................................................................................... 84
UBX-20039643 - R01

Contents Page 4 of 105
C1-Public Advance information

ZED-F9R-Integration manual
4.8.2 Thermal management................................................................................................................ 84
4.8.3 Package footprint, copper and paste mask........................................................................... 85
4.8.4 Layout guidance........................................................................................................................... 86
4.9 Design guidance....................................................................................................................................88
4.9.1 General considerations............................................................................................................... 88
4.9.2 Backup battery............................................................................................................................. 88
4.9.3 RF front-end circuit options...................................................................................................... 88
4.9.4 Antenna/RF input........................................................................................................................ 89
4.9.5 Ground pads..................................................................................................................................90
4.9.6 Schematic design........................................................................................................................ 90
4.9.7 Layout design-in guideline......................................................................................................... 90
5 Product handling................................................................................................................. 91
5.1 ESD handling precautions.................................................................................................................. 91
5.2 Soldering.................................................................................................................................................91
5.3 Tapes....................................................................................................................................................... 94
5.4 Reels........................................................................................................................................................ 95
5.5 Moisture sensitivity levels.................................................................................................................. 95
Appendix.................................................................................................................................... 96
A Glossary......................................................................................................................................................96
B Reference frames.....................................................................................................................................97
C RTK configuration procedures with u-center.....................................................................................97
C.1 Receiver configuration with u-center..........................................................................................97
Related documents..............................................................................................................103
Revision history.................................................................................................................... 104
UBX-20039643 - R01

Contents Page 5 of 105
C1-Public Advance information

ZED-F9R-Integration manual
1 Integration manual structure
This document provides a wealth of information to enable a successful design with the ZED-F9R
module. The manual is structured according to system, software and hardware aspects.
The first section, "System description" outlines the basics of enabling RTK operation with the ZED-
F9R. This is essential reading for anyone new to the device to enable them to understand a working
RTK implementation.
The following section "Receiver functionality" provides an exhaustive description of the receiver's
functionality. Beginning with the new configuration messages, both existing and new users should
read this section to understand the new message types employed. Most of the following sub-
sections should be familiar to existing users of u-blox positioning products, however some changes
are introduced owing to the new configuration messages.
The sections from "Design" onwards address hardware options when designing the ZED-F9R
into a new product. This part gives power supply recommendations and provides guidance for
circuit design and PCB lay-out assistance. The "Antenna" section provides design information
and recommendation for this important component. A final "Design guidance" section helps the
designer to check that crucial aspects of the design-in process have been carried out.
The final section addresses the general product handling concerns giving guidance on ESD
precautions, production soldering considerations and module delivery tape and reel information.
UBX-20039643 - R01

1 Integration manual structure Page 6 of 105
C1-Public Advance information

ZED-F9R-Integration manual
2 System description
2.1 Overview
The ZED-F9R module with the u-blox F9 multi-band GNSS receiver features rapid convergence
time within seconds. This mass-market component combines high precision positioning with
highest availability, while making use of all four GNSS constellations simultaneously. It is the first
sensor fusion module with an integrated inertial measurement unit (IMU) capable of high precision
positioning. The sophisticated built-in algorithms fuse the IMU data, GNSS measurements, wheel
ticks, and a dedicated dynamic model to provide high accurate positioning where GNSS alone would
fail.
The module operates under open sky, sidewalks, roads, in the wooded countryside, in difficult
multipath environments, and even in tunnels and underground parking. For modern autonomous
robotic applications such as unmanned ground vehicles where control and availability are key to
success, ZED-F9R is the ultimate solution.
The device is a turnkey solution eliminating the technical risk of integrating third party libraries,
precise positioning engines, and the multi-faceted hardware engineering aspects of radio frequency
design and digital design. The u-blox approach provides a transparent evaluation of the positioning
solution and clear lines of responsibility for design support while reducing supply chain complexity
during production.
ZED-F9R offers support for a range of correction services allowing each application to optimize
performance according to the application's unique needs. ZED-F9R comes with built-in support
for RTCM formatted corrections, enabling high precision navigation using internet or satellite data
connectivity. In a future release, the product will support SSR-type correction services suitable for
mass-market deployment. Finally the full set of RAW data from IMU sensors and GNSS carriers are
provided.
ZED-F9R modules use GNSS chips qualified according to AEC‑Q100 and are manufactured in ISO/
TS 16949 certified sites. Qualification tests are performed as stipulated in the ISO16750 standard.
The professional-grade ZED-F9R module adheres to industrial standard quality specifications and
production flow.
2.1.1 High precision sensor fusion (HPS)
High precision sensor fusion (HPS) provides high-accuracy positioning in locations with poor or no
GNSS coverage. HPS is based on sensor fusion dead reckoning (SFDR) technology, which combines
multi-constellation GNSS measurements with the ZED-F9R's internal 6-axis IMU and wheel tick or
speed.
See the HPS section in this document for more information.
2.1.2 Priority navigation mode
Priority navigation mode provides a low-latency position, velocity, and vehicle attitude solution to
be output at a high rate by utilizing sensor-based propagation in between GNSS measurement
updates, thus prioritizing the time-critical data.
UBX-20039643 - R01

2 System description Page 7 of 105
C1-Public Advance information

ZED-F9R-Integration manual
See the Priority navigation mode section in this document for more information.
2.1.3 Real time kinematic
u-blox ZED-F9R high precision sensor fusion receiver takes GNSS precision to the next level:
• Delivers accuracy down to the centimeter level: 0.01 m + 1 ppm CEP
• Fast time to first fix and robust performance with multi-band, multi-constellation reception
• Compatible with leading correction services for global coverage and versatility
2.2 Architecture
The ZED-F9R receiver provides all the necessary RF and baseband processing to enable multi-band,
multi-constellation operation. The block diagram below shows the key functionality.
2.2.1 Block diagram
Figure 1: ZED-F9R block diagram
UBX-20039643 - R01

2 System description Page 8 of 105
C1-Public Advance information

ZED-F9R-Integration manual
3 Receiver functionality
This section describes the ZED-F9R operational features and their configuration.
3.1 Receiver configuration
The ZED-F9R is fully configurable with UBX configuration interface keys. The configuration
database in the receiver's RAM holds the current configuration, which is used by the receiver
at run-time. It is constructed on start-up of the receiver from several sources of configuration.
The configuration interface and the available keys are described fully in the ZED-F9R Interface
description [2].
A configuration setting stored in RAM remains effective until power-down or reset. If stored in
BBR (battery-backed RAM), the setting will be used as long as the backup battery supply remains.
Configuration settings can be saved permanently in flash memory.
CAUTION The configuration interface has changed from earlier u-blox positioning receivers.
Legacy messages are deprecated, and will not be supported in future firmware releases.
Users are advised to adopt the configuration interface described in this document. See
legacy UBX-CFG message fields reference section in the ZED-F9R Interface description [2].
Configuration interface settings are held in a database consisting of separate configuration items.
An item is made up of a pair consisting of a key ID and a value. Related items are grouped together
and identified under a common group name: CFG-GROUP-*; a convention used in u-center and
within this document. Within u-center, a configuration group is identified as "Group name" and the
configuration item is identified as the "item name" under the "Generation 9 Configuration View" -
"Advanced Configuration" view.
The UBX messages available to change or poll the configurations are the UBX-CFG-VALSET, UBX-
CFG-VALGET, and UBX-CFG-VALDEL messages. For more information about these messages and
the configuration keys see the configuration interface section in the ZED-F9R Interface description
[2].
3.1.1 Changing the receiver configuration
The configuration messages UBX-CFG-VALSET, UBX-CFG-VALGET and UBX-CFG-VALDEL, will
result in a UBX-ACK-ACK or a UBX-ACK-NAK response.
3.1.2 Default GNSS configuration
The ZED-F9R default GNSS configuration is set as follows:
• GPS: L1C/A, L2C
• GLONASS: L1OF, L2OF
• Galileo: E1B/C, E5b
• BeiDou: B1I, B2I
• QZSS: L1C/A, L2C
UBX-20039643 - R01

3 Receiver functionality Page 9 of 105
C1-Public Advance information

ZED-F9R-Integration manual
For more information about the default configuration, see the ZED-F9R Interface description [2].
3.1.3 Default interface settings
Interface Settings
UART1 output 38400 baud, 8 bits, no parity bit, 1 stop bit.
NMEA protocol is enabled by default and GGA, GLL, GSA, GSV, RMC, VTG, TXT messages are
output by default.
UBX protocol is enabled by default but no output messages are enabled by default.
RTCM 3.3 protocol output is not supported.
UART1 input 38400 baud, 8 bits, no parity bit, 1 stop bit.
UBX, NMEA and RTCM 3.3 input protocols are enabled by default.
UART2 output 38400 baud, 8 bits, no parity bit, 1 stop bit.
UBX protocol cannot be enabled.
RTCM 3.3 protocol output is not supported.
NMEA protocol is disabled by default.
UART2 input 38400 baud, 8 bits, no parity bit, 1 stop bit.
UBX protocol cannot be enabled and will not receive UBX input messages.
RTCM 3.3 protocol is enabled by default.
NMEA protocol is disabled by default.
USB Default messages activated as in UART1. Input/output protocols available as in UART1.
I2C Fully compatible with the I2C1 industry standard, available for communication with an external
host CPU or u-blox cellular modules, operated in slave mode only. Default messages activated as
in UART1. Input/output protocols available as in UART1. Maximum bit rate 400 kb/s.
SPI Allow communication to a host CPU, operated in slave mode only. Default messages activated as
in UART1. Input/output protocols available as in UART1. SPI is not available unless D_SEL pin is
set to low (see the D_SEL section).
Table 1: Default interface settings
UART2 can be configured as an RTCM interface. RTCM 3.3 is the default input protocol. UART2
may also be configured for NMEA output. NMEA GGA output is typically used with virtual reference
service correction services.
By default the ZED-F9R outputs NMEA messages that include satellite data for all GNSS
bands being received. This results in a high NMEA load output for each navigation period.
Make sure the UART baud rate used is sufficient for the selected navigation rate and the
number of GNSS signals being received.
3.1.4 Basic receiver configuration
This section summarizes the basic receiver configuration most commonly used.
3.1.4.1 Communication interface configuration
Several configuration groups allow operation mode configuration of the various communication
interfaces. These include parameters for the data framing, transfer rate and enabled input/output
protocols. See Communication interfaces section for details. The configuration groups available for
each interface are:
Interface Configuration groups
UART1 CFG-UART1-*, CFG-UART1INPROT-*, CFG-UART1OUTPROT-*
UART2 CFG-UART2-*, CFG-UART2INPROT-*, CFG-UART2OUTPROT-*
1I2C is a registered trademark of Philips/NXP
UBX-20039643 - R01

3 Receiver functionality Page 10 of 105
C1-Public Advance information

ZED-F9R-Integration manual
Interface Configuration groups
USB CFG-USB-*, CFG-USBINPROT-*, CFG-USBOUTPROT-*
I2C CFG-I2C-*, CFG-I2CINPROT-*, CFG-I2COUTPROT-*
SPI CFG-SPI-*, CFG-SPIINPROT-*, CFG-SPIOUTPROT-*
Table 2: Interface configurations
3.1.4.2 Message output configuration
This product supports two protocols for output messages. One is NMEA and the other one is a u-
blox proprietary "UBX" protocol. NMEA is a well-known industry standard, used mainly for providing
information about position, time and satellites. UBX messages can be used to configure the receiver
and also to periodically provide information about position, time and satellites. With the UBX
protocol it is easy to monitor the receiver status and get much deeper information about the receiver
status. The rate of NMEA and UBX protocol output messages are configurable and it is possible to
enable or disable single NMEA or UBX messages individually.
If the rate configuration value is zero, then the corresponding message will not be output. Values
greater than zero indicate how often the message is output.
For periodic output messages the rate relates to the event the message is related to. For example,
the UBX-NAV-PVT (navigation, position, velocity and time solution) is related to the navigation
epoch. If the rate of this message is set to one (1), it will be output for every navigation epoch. If the
rate is set to two (2), it will be output every other navigation epoch. The rates of the output messages
are individually configurable per communication interface. See the CFG-MSGOUT-* configuration
group.
Some messages, such as UBX-MON-VER, are non-periodic and will only be output as an answer to
a poll request.
The UBX-INF-* and NMEA-Standard-TXT information messages are non-periodic output messages
that do not have a message rate configuration. Instead they can be enabled for each communication
interface via the CFG-INFMSG-* configuration group.
All message output is additionally subject to the protocol configuration of the
communication interfaces. Messages of a given protocol will not be output until the protocol
is enabled for output on the interface (see the Communication interface configuration).
3.1.4.3 GNSS signal configuration
The GNSS constellations and bands are configurable with configuration keys from configuration
group CFG-SIGNAL-*. Each GNSS constellation can be enabled or disabled independently. A GNSS
constellation is considered to be enabled when the constellation enable key is set and at least one
of the constellation's band keys is enabled.
ZED-F9R only supports certain combinations of constellations and bands. For all constellations,
both L1 and L2 bands must either be enabled or disabled. BeiDou B2 is the exception (can either
have BeiDou B1+B2 or B1-only). Unsupported combinations will be rejected with a UBX-ACK-NAK
and the warning: "invalid sig cfg" will be sent via UBX-INF and NMEA-TXT messages (if enabled).
The following table shows possible configuration key combinations for the GPS constellation.
Constellation key
CFG-SIGNAL-GPS_ENA
Band key
CFG-SIGNAL-GPS_L1CA_ENA
Band key
CFG-SIGNAL-GPS_L2C_ENA
Constellation
enabled?
false (0) false (0) false (0) no
false (0) false (0) true (1) no
false (0) true (1) false (0) no
UBX-20039643 - R01

3 Receiver functionality Page 11 of 105
C1-Public Advance information

ZED-F9R-Integration manual
Constellation key
CFG-SIGNAL-GPS_ENA
Band key
CFG-SIGNAL-GPS_L1CA_ENA
Band key
CFG-SIGNAL-GPS_L2C_ENA
Constellation
enabled?
false (0) true (1) true (1) no
true (1) false (0) false (0) no
true (1) false (0) true (1) Unsupported
combination
true (1) true (1) false (0) Unsupported
combination
true (1) true (1) true (1) yes
Table 3: Example of possible values of configuration items for the GPS constellation
3.1.4.4 NMEA high precision mode
ZED-F9R supports NMEA high precision mode. This mode increases precision of the position
output; latitude and longitude will have seven digits after the decimal point, and altitude will have
three digits after the decimal point. By default it is not enabled since it violates the NMEA standard.
NMEA high precision mode cannot be used while in NMEA compatibility mode or when NMEA output
is limited to 82 characters. See configuration item CFG-NMEA-HIGHPREC in ZED-F9R Interface
description [2] for more details.
3.1.5 RTCM corrections
RTCM is a binary data protocol for communication of GNSS correction information. The ZED-F9R
high precision sensor fusion receiver supports RTCM as specified by RTCM 10403.3, Differential
GNSS (Global Navigation Satellite Systems) Services – Version 3 (October 7, 2016).
The RTCM specification is currently at version 3.3 and RTCM version 2 messages are not supported
by this standard.
To modify the RTCM input settings, see the configuration section in the u-blox ZED-F9R Interface
description [2].
Users need to be aware of the datum used by the correction source. The receiver position will
provide coordinates in the correction source reference frame. This may need to be taken into account
when using the RTK-derived position. See the Reference frames section in the Appendix for more
information.
3.1.5.1 List of supported RTCM input messages
Message type Description
RTCM 1001 L1-only GPS RTK observables
RTCM 1002 Extended L1-only GPS RTK observables
RTCM 1003 L1/L2 GPS RTK observables
RTCM 1004 Extended L1/L2 GPS RTK observables
RTCM 1005 Stationary RTK reference station ARP
RTCM 1006 Stationary RTK reference station ARP with antenna height
RTCM 1007 Antenna descriptor
RTCM 1009 L1-only GLONASS RTK observables
RTCM 1010 Extended L1-only GLONASS RTK observables
RTCM 1011 L1/L2 GLONASS RTK observables
RTCM 1012 Extended L1/L2 GLONASS RTK observables
RTCM 1033 Receiver and Antenna Description
RTCM 1074 GPS MSM4
UBX-20039643 - R01

3 Receiver functionality Page 12 of 105
C1-Public Advance information

ZED-F9R-Integration manual
Message type Description
RTCM 1075 GPS MSM5
RTCM 1077 GPS MSM7
RTCM 1084 GLONASS MSM4
RTCM 1085 GLONASS MSM5
RTCM 1087 GLONASS MSM7
RTCM 1094 Galileo MSM4
RTCM 1095 Galileo MSM5
RTCM 1097 Galileo MSM7
RTCM 1124 BeiDou MSM4
RTCM 1125 BeiDou MSM5
RTCM 1127 BeiDou MSM7
RTCM 1230 GLONASS code-phase biases
Table 4: ZED-F9R supported input RTCM version 3.3 messages
3.1.5.2 NTRIP - networked transport of RTCM via internet protocol
Networked Transport of RTCM via internet protocol, or NTRIP, is an open standard protocol for
streaming differential data over the internet in accordance with specifications published by RTCM.
There are three major parts to the NTRIP system: The NTRIP client, the NTRIP server, and the NTRIP
caster:
1. The NTRIP server is a PC or an on-board computer running NTRIP server software
communicating directly with a GNSS reference station. The NTRIP server serves as the
intermediary between the GNSS receiver (NTRIP Source) streaming correction data and the
NTRIP caster.
2. The NTRIP caster is an HTTP server which receives streaming correction data from one or
more NTRIP servers and in turn streams the correction data to one or more NTRIP clients via
the internet.
3. The NTRIP client receives streaming correction data from the NTRIP caster to apply as real-
time corrections to a GNSS receiver.
u-center GNSS evaluation software provides an NTRIP client application that can help to evaluate a
ZED-F9R design. The u-center NTRIP client connects over the internet to an NTRIP service provider,
using access credentials such as user name and password from the service provider. The u-center
NTRIP client then forwards the RTCM 3.3 corrections to a ZED-F9R receiver connected to the local
u-center application. RTCM corrections from a virtual reference service are also supported by the u-
center NTRIP client.
3.1.6 Navigation configuration
This section presents various configuration options related to the navigation engine. These options
can be configured through CFG-NAVSPG-* configuration keys.
3.1.6.1 Platform settings
u-blox receivers support different dynamic platform models (see the table below) to adjust the
navigation engine to the expected application environment. These platform settings can be
changed dynamically without performing a power cycle or reset. The settings improve the receiver's
interpretation of the measurements and thus provide a more accurate position output. Setting the
receiver to an unsuitable platform model for the given application environment is likely to result in
a loss of receiver performance and position accuracy.
UBX-20039643 - R01

3 Receiver functionality Page 13 of 105
C1-Public Advance information

ZED-F9R-Integration manual
The dynamic platform model can be configured through the CFG-NAVSPG-DYNMODEL
configuration item. The supported dynamic platform models and their details can be seen in Table
5 and Table 6 below.
Platform Description
Portable Applications with low acceleration, e.g. portable devices. Suitable for most situations.
Stationary Used in timing applications (antenna must be stationary) or other stationary applications.
Velocity restricted to 0 m/s. Zero dynamics assumed.
Pedestrian Applications with low acceleration and speed, e.g. how a pedestrian would move. Low
acceleration assumed.
Automotive (default) Used for applications with equivalent dynamics to those of a passenger car. Low vertical
acceleration assumed.
At sea Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity assumed.
Sea level assumed.
Airborne <1g Used for applications with a higher dynamic range and greater vertical acceleration than a
passenger car. No 2D position fixes supported.
Airborne <2g Recommended for typical airborne environments. No 2D position fixes supported.
Airborne <4g Only recommended for extremely dynamic environments. No 2D position fixes supported.
Wrist Only recommended for wrist-worn applications. Receiver will filter out arm motion.
Table 5: Dynamic platform models
Platform Max altitude [m] Max horizontal
velocity [m/s]
Max vertical velocity
[m/s]
Sanity check type Max
position
deviation
Portable 12000 310 50 Altitude and velocity Medium
Stationary 9000 10 6 Altitude and velocity Small
Pedestrian 9000 30 20 Altitude and velocity Small
Automotive 6000 100 15 Altitude and velocity Medium
At sea 500 25 5 Altitude and velocity Medium
Airborne <1g 80000 100 6400 Altitude Large
Airborne <2g 80000 250 10000 Altitude Large
Airborne <4g 80000 500 20000 Altitude Large
Wrist 9000 30 20 Altitude and velocity Medium
Table 6: Dynamic platform model details
Applying dynamic platform models designed for high acceleration systems (e.g. airborne <2g) can
result in a higher standard deviation in the reported position.
If a sanity check against a limit of the dynamic platform model fails, then the position solution
is invalidated. Table 6 above shows the types of sanity checks which are applied for a particular
dynamic platform model.
3.1.6.2 Navigation input filters
The navigation input filters in CFG-NAVSPG-* configuration group provide the input data of the
navigation engine.
Configuration item Description
CFG-NAVSPG-FIXMODE By default, the receiver calculates a 3D position fix if possible but reverts to 2D
position if necessary (auto 2D/3D). The receiver can be forced to only calculate 2D
(2D only) or 3D (3D only) positions.
CFG-NAVSPG-CONSTR_ALT, CFG-
NAVSPG-CONSTR_ALTVAR
The fixed altitude is used if fixMode is set to 2D only. A variance greater than zero
must also be supplied.
UBX-20039643 - R01

3 Receiver functionality Page 14 of 105
C1-Public Advance information

ZED-F9R-Integration manual
Configuration item Description
CFG-NAVSPG-INFIL_MINELEV Minimum elevation of a satellite above the horizon in order to be used in the
navigation solution. Low elevation satellites may provide degraded accuracy, due to
the long signal path through the atmosphere.
CFG-NAVSPG-INFIL_NCNOTHRS,
CFG-NAVSPG-INFIL_CNOTHRS
A navigation solution will only be attempted if there are at least the given number of
SVs with signals at least as strong as the given threshold.
Table 7: Navigation input filter parameters
If the receiver only has three satellites for calculating a position, the navigation algorithm uses a
constant altitude to compensate for the missing fourth satellite. When a satellite is lost after a
successful 3D fix (min four satellites available), the altitude is kept constant at the last known value.
This is called a 2D fix.
u-blox receivers do not calculate any navigation solution with less than three satellites.
3.1.6.3 Navigation output filters
The result of a navigation solution is initially classified by the fix type (as detailed in the fixType
field of UBX-NAV-PVT message). This distinguishes between failures to obtain a fix at all ("No Fix")
and cases where a fix has been achieved, which are further subdivided into specific types of fixes
(e.g. 2D, 3D, dead reckoning).
Where a fix has been achieved, a check is made to determine whether the fix should be classified as
valid or not. A fix is only valid if it passes the navigation output filters as defined in CFG-NAVSPG-
OUTFIL. In particular, both PDOP and accuracy values must be below the respective limits.
Important: Users are recommended to check the gnssFixOK flag in the UBX-NAV-PVT or
the NMEA valid flag. Fixes not marked valid should not be used.
UBX-NAV-STATUS message also reports whether a fix is valid in the gpsFixOK flag. These
messages have only been retained for backwards compatibility and users are recommended to use
the UBX-NAV-PVT message.
3.1.6.4 Weak signal compensation
In normal operating conditions, low signal strength (i.e. signal attenuation) indicates likely
contamination by multipath. The receiver trusts such signals less in order to preserve the quality of
the position solution in poor signal environments. This feature can result in degraded performance
in situations where the signals are attenuated for another reason, for example due to antenna
placement. In this case, the weak signal compensation feature can be used to restore normal
performance. There are three possible modes:
• Disabled: no weak signal compensation is performed
• Automatic: the receiver automatically estimates and compensates for the weak signal
• Configured: the receiver compensates for the weak signal based on a configured value
These modes can be selected using CFG-NAVSPG-SIGATTCOMP. In the case of the "configured"
mode, the user should input the maximum C/N0 observed in a clear-sky environment, excluding
any outliers or unusually high values. The configured value can have a large impact on the receiver
performance, so it should be chosen carefully.
3.2 High precision sensor fusion (HPS)
3.2.1 Introduction
u-blox solutions for high precision sensor fusion (HPS) allow high-accuracy positioning in places
with poor or no GNSS coverage. HPS is based on sensor fusion dead reckoning (SFDR) technology,
UBX-20039643 - R01

3 Receiver functionality Page 15 of 105
C1-Public Advance information

ZED-F9R-Integration manual
which combines GNSS measurements with those from external sensors. The ZED-F9R computes
a solution type called GAWT by combining GNSS measurements with the outputs of a 3-axis
accelerometer, a 3-axis gyroscope and wheel tick (sometimes called a speed tick) or speed
measurements. The utilization of these sensors ensures a quick recovery of a high precision
navigation solution after short GNSS signal outage (going under a bridge, signaling panels, and so
on).
The firmware automatically detects and continuously calibrates the sensors.
3.2.2 Solution type
ZED-F9R produces a solution that combines raw GNSS signals with data from gyroscopes,
accelerometers and wheel tick sensors to compute a fused navigation solution. The solution type is
called GAWT (gyroscope, accelerometers, wheel tick), and it is described in the following sections.
To operate the ZED-F9R in GAWT mode with optimal performance, the following tasks need to be
completed:
• The IMU misalignment angles are also essential. It is recommended to enable automatic
alignment with the CFG-SFIMU-AUTO_MNTALG_ENA key. The misalignment angles can also
be configured with CFG-SFIMU-IMU_MNTALG keys.
• It is mandatory to perform an initial calibration drive after flashing software, a cold start,
or changing sensor configuration keys (CFG-SFCORE-*, CFG-SFIMU-* or CFG-SFODO-*).
The calibration drive allows the software to detect and calibrate the sensors. See section
Accelerated Initialization and Calibration Procedure for additional information. Performance is
likely to be sub-optimal if the calibration drive is not performed correctly.
• If the maximum counter value of a wheel tick sensor cannot be represented as a power of 2
value, it must be configured manually. See section Odometer Types for additional information.
• It is strongly recommended that RTCM stream is available during the initial calibration drive, so
that the resulting calibration parameters can be estimated more accurately.
3.2.3 Installation configuration
If the GNSS antenna is placed at a significant distance from the receiver, position offsets
can be introduced which might affect the accuracy of the navigation solution. In order to
compensate for the position offset advanced configurations can be applied. Contact u-blox
support for more information on advanced configurations.
3.2.3.1 IMU-mount alignment
This section describes how IMU-mount misalignment angles, that is, the angles which rotate the
installation-frame to the IMU-frame, can be configured.
The IMU-mount misalignment angles are defined as follows:
• The transformation from the installation frame to the IMU frame is described by three Euler
angles about the installation frame axes denoted as IMU-mount roll, IMU-mount pitch and IMU-
mount yaw angles. All three angles are referred to as the IMU-mount misalignment angles.
The default assumption is that the IMU-frame and the installation-frame have the same orientation
( that is, all axes are parallel). If the IMU-mount misalignment angles are slightly incorrect (typically a
few degrees), the navigation solution can be degraded. If there are large (tens of degrees) IMU-mount
misalignments, the position calculation may fail. Therefore, it is essential to correctly configure the
IMU-mount misalignment settings.
It is strongly recommended to use the automatic IMU-mount alignment as described in the
following section.
UBX-20039643 - R01

3 Receiver functionality Page 16 of 105
C1-Public Advance information

ZED-F9R-Integration manual
3.2.3.1.1 Automatic IMU-mount alignment
The automatic IMU-mount alignment engine automatically estimates the IMU-mount roll, pitch and
yaw angles. It requires an initialization phase during which no INS/GNSS fusion can be achieved
(see the Fusion filter modes section for further details). The progress of the automatic alignment
initialization can be monitored with the UBX-ESF-STATUS message, and/or with the UBX-ESF-ALG
message providing more details. When the vehicle is subject to sufficient dynamics (i.e. left and
right turns during a normal drive), the automatic IMU-mount alignment engine will estimate the
IMU-mount misalignment angles. Once the automatic IMU-mount alignment engine has sufficient
confidence in the estimated angles, the IMU-mount misalignment angles initialization phase is
completed. The raw accelerometer and gyroscope data (that is, the IMU observations) are then
compensated for IMU-mount misalignment and sensor fusion can begin. The resulting IMU-mount
misalignment angles are output in the UBX-ESF-ALG message.
3.2.3.1.1.1 Enabling/disabling automatic IMU-mount alignment
The user can activate/deactivate the automatic IMU-mount alignment with the CFG-SFIMU-
AUTO_MNTALG_ENA configuration key.
If automatic IMU-mount alignment is deactivated while aligning, the estimated
misalignment angles that were available at deactivation time are used (only if they were
initialized, see the next section). If automatic IMU-mount alignment is re-activated,
alignment is pursued by starting from the state where deactivation happened.
3.2.3.1.2 User-defined IMU-mount alignment
It is possible to configure the IMU-mount misalignment angles using the CFG-SFIMU-IMU_MNTALG
configuration keys. The values that should be set in the configuration message are the Euler angles
required to rotate the installation-frame to the IMU-frame. The IMU-mount yaw rotation should be
performed first, then the IMU-mount pitch and finally the IMU-mount roll. At each stage, the rotation
is around the appropriate axis of the transformed installation frame, meaning that the order of the
rotation sequence is important (see the figure below).
Figure 2: Euler angles
UBX-20039643 - R01

3 Receiver functionality Page 17 of 105
C1-Public Advance information

ZED-F9R-Integration manual
If there is only a single IMU-mount misalignment angle, it may be measured as shown in the three
examples below.
Figure 3: Installation frame
In order to prevent significant degradation of the positioning solution the IMU-mount
misalignment angles should be configured with an accuracy of less than 5 degrees.
The following list describes in detail how the CFG-SFIMU-IMU_MNTALG keys are to be interpreted
with respect to the example illustrated in the figure above:
•CFG-SFIMU-IMU_MNTALG_YAW: The IMU-mount yaw angle (yaw) corresponds to the rotation
around the installation-frame z-axis (vertical) required for aligning the installation frame to
the IMU frame (yaw = 344.0 degrees if the IMU-mount misalignment is composed of a single
rotation around the installation-frame z-axis, that is, with no IMU-mount roll and IMU-mount
pitch rotation).
•CFG-SFIMU-IMU_MNTALG_PITCH: The IMU-mount pitch angle (pitch) corresponds to the
rotation around the installation-frame y-axis required for aligning the installation-frame to
the IMU-frame (pitch = 26.5 degrees if the IMU-mount alignment is composed of a single
rotation around the installation frame y-axis, that is, with no IMU-mount roll and IMU-mount
yaw rotation).
•CFG-SFIMU-IMU_MNTALG_ROLL: The IMU-mount roll angle (roll) corresponds to the
rotation around the installation-frame x-axis required for aligning the installation frame to
UBX-20039643 - R01

3 Receiver functionality Page 18 of 105
C1-Public Advance information

ZED-F9R-Integration manual
the IMU frame (roll = -23.5 degrees if the IMU-mount misalignment is composed of a single
rotation around installation-frame x-axis, that is, with no IMU-mount pitch and IMU-mount yaw
rotation).
3.2.4 Sensor configuration
This section describes the external sensor configuration parameters.
3.2.4.1 Odometer configuration
Odometer is a generic term for wheel tick or speed sensor.
You can configure the odometer with the CFG-SFODO-* configuration keys.
The ZED-F9R was designed to work with odometer input. Although the ZED-F9R calculates
a position without odometer input, the accuracy of that position is compromised.
3.2.4.1.1 Odometer interfaces
Odometer data can be delivered to ZED-F9R via the following interfaces:
Hardware interface: ZED-F9R has a dedicated pin (WT) for analog wheel tick signal input, and
another pin (DIR) dedicated to wheel tick direction signal.
•The WT pin is enabled with the CFG-SFODO-USE_WT_PIN key.
• The DIR pin polarity is automatically detected by the receiver by default. To manually
configure the polarity, you must turn off automatic detection by setting the CFG-SFODO-
DIS_AUTODIRPINPOL key and you must define the polarity in the CFG-SFODO-DIR_PINPOL
key.
•Double-edge counting can be enabled via the CFG-SFODO-CNT_BOTH_EDGES key. It can
increase performance with low-resolution wheel ticks, but is not suitable for all types of wheel
tick signals. It must not be used with signals that are not generated with approximately 50%
duty signal as it would impair performance.
Software interface: Odometer data can be delivered to the receiver over one of the communication
interfaces. The data shall be contained in UBX-ESF-MEAS messages. UBX-ESF-MEAS (data type
10) shall be used for single-tick odometer data and UBX-ESF-MEAS (data type 11) shall be used for
speed odometer data. See the Interface description for more information.
• By default, the receiver automatically ignores the WT pin if wheel tick/speed data are detected
on the software interface. Therefore data coming from the software interface will be prioritized
over data coming from the hardware interface. To disable the automatic use of data detected
on the software interface, set the CFG-SFODO-DIS_AUTOSW key.
3.2.4.1.2 Odometer types
ZED-F9R supports sensors delivering the following types of data:
•Relative wheel tick data: If the wheel tick sensor delivers relative wheel tick counts (that is,
wheel tick count since the previous measurement), the CFG-SFODO-COUNT_MAX value must be
set to 0.
•Absolute wheel tick data: If the wheel tick sensor delivers absolute wheel tick counts (that
is, wheel tick count since startup at time tag 0) that always increase, regardless of driving
forward or backward (with driving direction indicated separately). If the counter is configured
to 1, the maximum absolute wheel tick counter value is automatically estimated by the
receiver for a maximum counter value that can be represented as a 2^N value. Other maximum
counter values must be manually configured. For example, a CFG-SFODO-COUNT_MAX=1024
roll-over value would be automatically estimated, but a CFG-SFODO-COUNT_MAX=1000
must be configured. The maximum counter value is configured by setting the CFG-SFODO-
UBX-20039643 - R01

3 Receiver functionality Page 19 of 105
C1-Public Advance information

ZED-F9R-Integration manual
DIS_AUTOCOUNTMAX key and setting the CFG-SFODO-COUNT_MAX value to the upper
threshold of the absolute wheel tick sensor count before starting again from zero (roll-over).
•Speed data: Data coming from this sensor type can only be delivered to the receiver via one
of the communication ports within a UBX-ESF-MEAS (data type 11). The speed data shall be
delivered in meters per second.
If speed data but no absolute or relative wheel tick data are detected, the receiver automatically uses
the speed data without the need for reconfiguring the CFG-SFODO-USE_SPEED key. This behavior
can be deactivated by setting the CFG-SFODO-DIS_AUTOSPEED key and by manually setting or
clearing the CFG-SFODO-USE_SPEED key. If wheel tick data (or both wheel tick and speed data)
are detected on the software interface, the receiver uses the data type (by default wheel tick data)
corresponding to the configured CFG-SFODO-USE_SPEED key.
To make the receiver interpret incoming speed data (data type 11 in ESF-MEAS) instead of the single
wheel tick data (data type 10 in ESF-MEAS) on the software interface, the CFG-SFODO-USE_SPEED
key must be set.
It is strongly recommended to use the absolute wheel tick sensors to ensure robust
measurement processing even after sensor failures or outages.
3.2.4.1.3 Odometer settings
You can configure the following odometer settings:
•Sampling frequency: The wheel tick/speed data sampling frequency (CFG-SFODO-FREQUENCY)
should be provided with an accuracy of approximately 10 %. If not provided, it is automatically
determined during the initialization phase: this requires a consistent data rate and can take
several minutes. Once initialized, the sampling frequency will be stored in a non-volatile
storage. For optimal navigation performance, the standard wheel tick/speed input at 10 Hz is
recommended.
•Latency: For best positioning performance, the latency of the wheel tick/speed data (CFG-
SFODO-LATENCY) should be given as accurately as possible (to within at least 10 ms). If not
provided, the wheel tick/speed data latency is assumed zero. More details about latency can be
found in the Sensor Time Tagging section.
•Quantization error: If absolute/relative wheel tick data are used (for example, if the tick data is
a distance), the quantization error can be defined in the CFG-SFODO-QUANT_ERROR key. The
quantization error can be calculated as 2*Pi*R / T with R the wheel radius, T the number of
ticks per wheel rotation. If the quantization error is not provided, it is automatically initialized by
the receiver.
•Speed data accuracy (software interface only): If speed data are used, the speed data
accuracy can be set in the CFG-SFODO-QUANT_ERROR key. If not provided, the speed data
accuracy is automatically initialized by the receiver.
•Scale factor: If the coarse WT scale factor is not configured in the CFG-SFODO-FACTOR key,
it is estimated automatically during the initialization (see section Initialization mode for more
details).
•Combination of multiple rear wheel ticks (software interface only): If wheel ticks are
being received from both rear wheels, the receiver can be configured with the CFG-SFODO-
COMBINE_TICKS key to use the combined rear wheel ticks rather than a single tick. It is
recommended to use combined rear wheel ticks if available, as they are often of higher quality
than the single ticks.
UBX-20039643 - R01

3 Receiver functionality Page 20 of 105
C1-Public Advance information