u-blox ZED-F9K Integration manual
ZED-F9K
u-blox F9 high precision automotive DR GNSS receiver
Integration manual
Abstract
This document describes how to enable a successful design with the ZEDF9K module. The ZED-F9K module provides lane accurate positioning
under challenging conditions and decimeter-level accuracy for automotive
mass markets. The ZED-F9K module is ideal for ADAS, V2X and head-up
displays. It provides a low-risk multi-band RTK turnkey solution with builtin inertial sensors and lag-free displays with up to 30 Hz real-time position
update rate.
www.u-blox.com
UBX-20046189 - R01
C1-Public
ZED-F9K-Integration manual
Document information
Title ZED-F9K
Subtitle u-blox F9 high precision automotive DR GNSS receiver
Document type Integration manual
Document number UBX-20046189
Revision and date R01 06-Nov-2020
Document status Early production information
Disclosure restriction C1-Public
This document applies to the following products:
Product name Type number Firmware version PCN reference
ZED-F9K ZED-F9K-00B-01 LAP 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-20046189 - R01
C1-Public Early production information
Page 2 of 105
ZED-F9K-Integration manual
Contents
1 Integration manual structure............................................................................................ 6
2 System description...............................................................................................................7
2.1 Overview.................................................................................................................................................... 7
2.1.1 Automotive dead reckoning (ADR)............................................................................................. 7
2.1.2 Priority navigation mode...............................................................................................................8
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 Automotive dead reckoning (ADR)....................................................................................................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 ADR system configuration.........................................................................................................22
3.2.6 Operation....................................................................................................................................... 22
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-20046189 - R01
C1-Public Early production information
Contents Page 3 of 105
ZED-F9K-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-F9K power supply............................................................................................................... 75
4.3 ZED-F9K 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-20046189 - R01
C1-Public Early production information
Contents Page 4 of 105
ZED-F9K-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-20046189 - R01
C1-Public Early production information
Contents Page 5 of 105
ZED-F9K-Integration manual
1 Integration manual structure
This document provides a wealth of information to enable a successful design with the ZED-F9K
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 ZEDF9K. 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 subsections 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-F9K
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-20046189 - R01
C1-Public Early production information
1 Integration manual structure Page 6 of 105
ZED-F9K-Integration manual
2 System description
2.1 Overview
The ZED-F9K module features the u-blox F9 multi-band L1/L2 GNSS receiver with rapid
convergence time within seconds. This mass-market component provides decimeter level
positioning with high availability, while making use of all 4 GNSS constellations simultaneously.
It is the first dead reckoning 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 (or speed in m/s), and vehicle dynamics model to provide lane accurate
positioning where GNSS alone would fail. The module operates under open-sky motorways, in the
wooded countryside, in difficult urban environments, and even in tunnels and underground parking.
In modern automotive applications, such as advanced driver assistance system (ADAS) where
availability can improve the safety of our roads, ZED-F9K 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, provides clear lines of responsibility for design support while reducing supply chain
complexity during production.
ZED-F9K is ideal for innovative automotive architecture designs with limited space and power.
The module provides accurate location services to the increasing number of intelligent electronic
control units (ECU) such as telematics control unit, navigation system, infotainment and V2x safety
systems.
In priority navigation mode the module reaches a navigation rate of up to 30 Hz. The on-board
processor augments fused GNSS position with additional IMU-based position estimates. Drivers
experience responsive, lag-free user interfaces. ZED-F9K can output raw IMU and raw GNSS data
for advanced applications.
The module supports a range of leading correction services. ZED-F9K comes with built-in support
for RTCM formatted OSR-type corrections, and in a future release, SSR-type corrections. SSRbased techniques use data sparingly and are suitable for both IP-based cellular networks and
broadcast- based satellite connectivity. The unique combination ensures the reliable distribution
of correction services scalable to millions of vehicles using mobile network in populated areas and
satellites for remote areas.
ZED-F9K modules are manufactured in ISO/TS 16949 certified sites and are fully tested on a system
level. Qualification tests are performed as stipulated in the ISO 16750 standard: “road vehicles–
environmental conditions and testing for electrical and electronic equipment”.
2.1.1 Automotive dead reckoning (ADR)
Automotive dead reckoning (ADR) provides high-accuracy positioning in locations with poor or no
GNSS coverage. ADR is based on sensor fusion dead reckoning (SFDR) technology, which combines
multi-constellation GNSS measurements with the ZED-F9K's internal 6-axis IMU and wheel tick or
speed.
UBX-20046189 - R01
C1-Public Early production information
2 System description Page 7 of 105
ZED-F9K-Integration manual
See the ADR 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.
See the Priority navigation mode section in this document for more information.
2.1.3 Real time kinematic
u-blox ZED-F9K high precision receiver takes GNSS precision to the next level:
• Delivers accuracy down to the decimeter level
• 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-F9K 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-F9K block diagram
UBX-20046189 - R01
C1-Public Early production information
2 System description Page 8 of 105
ZED-F9K-Integration manual
3 Receiver functionality
This section describes the ZED-F9K operational features and their configuration.
3.1 Receiver configuration
The ZED-F9K 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-F9K 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-F9K 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, UBXCFG-VALGET, and UBX-CFG-VALDEL messages. For more information about these messages and
the configuration keys see the configuration interface section in the ZED-F9K 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-F9K 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-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 9 of 105
ZED-F9K-Integration manual
For more information about the default configuration, see the ZED-F9K Interface description [2].
3.1.3 Default interface settings
Interface Settings
UART1 output
UART1 input
UART2 output
UART2 input
USB Default messages activated as in UART1. Input/output protocols available as in UART1.
I2C
SPI Allow communication to a host CPU, operated in slave mode only. Default messages activated as
Table 1: Default interface settings
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.
38400 baud, 8 bits, no parity bit, 1 stop bit.
UBX, NMEA and RTCM 3.3 input protocols are enabled by default.
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.
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.
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.
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).
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-F9K 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-*
1
I2C is a registered trademark of Philips/NXP
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 10 of 105
ZED-F9K-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 ublox 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.
The following table shows possible configuration key combinations for the GPS constellation.
Constellation key
CFG-SIGNAL-GPS_ENA
false (0) false (0) false (0) no
false (0) false (0) true (1) no
false (0) true (1) false (0) no
false (0) true (1) true (1) no
true (1) false (0) false (0) no
true (1) false (0) true (1) Unsupported
Band key
CFG-SIGNAL-GPS_L1CA_ENA
Band key
CFG-SIGNAL-GPS_L2C_ENA
Constellation
enabled?
combination
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 11 of 105
ZED-F9K-Integration manual
Constellation key
CFG-SIGNAL-GPS_ENA
true (1) true (1) false (0)
true (1) true (1) true (1) yes
Table 3: Example of possible values of configuration items for the GPS constellation
Band key
CFG-SIGNAL-GPS_L1CA_ENA
Band key
CFG-SIGNAL-GPS_L2C_ENA
Constellation
enabled?
2
yes
The GPS constellation can be disabled if the SBAS and QZSS system are also disabled at
the same time.
3.1.5 RTCM corrections
RTCM is a binary data protocol for communication of GNSS correction information. The ZED-F9K
high precision 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-F9K 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
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
2
The combination works only when GPS L2, GAL E5B, BDS B2, QZSS L2C, and GLO L2 are disabled at the same time.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 12 of 105
ZED-F9K-Integration manual
Message type Description
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-F9K 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 realtime corrections to a GNSS receiver.
u-center GNSS evaluation software provides an NTRIP client application that can help to evaluate a
ZED-F9K 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-F9K receiver connected to the local
u-center application. RTCM corrections from a virtual reference service are also supported by the ucenter 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.
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.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 13 of 105
ZED-F9K-Integration manual
Platform Description
Pedestrian Applications with low acceleration and speed, e.g. how a pedestrian would move. Low
Automotive Used for applications with equivalent dynamics to those of a passenger car. Low vertical
At sea Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity assumed.
Airborne <1g Used for applications with a higher dynamic range and greater vertical acceleration than a
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
acceleration assumed.
acceleration assumed.
Sea level assumed.
passenger car. No 2D position fixes supported.
Platform Max altitude [m] Max horizontal
velocity [m/s]
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
Max vertical velocity
[m/s]
Sanity check type Max
position
deviation
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
CFG-NAVSPG-CONSTR_ALT, CFGNAVSPG-CONSTR_ALTVAR
CFG-NAVSPG-INFIL_MINELEV Minimum elevation of a satellite above the horizon in order to be used in the
CFG-NAVSPG-INFIL_NCNOTHRS,
CFG-NAVSPG-INFIL_CNOTHRS
Table 7: Navigation input filter parameters
UBX-20046189 - R01
C1-Public Early production information
position if necessary (auto 2D/3D). The receiver can be forced to only calculate 2D
(2D only) or 3D (3D only) positions.
The fixed altitude is used if fixMode is set to 2D only. A variance greater than zero
must also be supplied.
navigation solution. Low elevation satellites may provide degraded accuracy, due to
the long signal path through the atmosphere.
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.
3 Receiver functionality Page 14 of 105
ZED-F9K-Integration manual
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-NAVSPGOUTFIL. 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 Automotive dead reckoning (ADR)
3.2.1 Introduction
u-blox solutions for automotive dead reckoning (ADR) allow high-accuracy positioning in places
with poor or no GNSS coverage. ADR is based on sensor fusion dead reckoning (SFDR) technology,
which combines GNSS measurements with those from external sensors. The ZED-F9K 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).
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 15 of 105
ZED-F9K-Integration manual
The firmware automatically detects and continuously calibrates the sensors.
3.2.2 Solution type
ZED-F9K 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-F9K 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.
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
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 16 of 105
ZED-F9K-Integration manual
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-SFIMUAUTO_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
If there is only a single IMU-mount misalignment angle, it may be measured as shown in the three
examples below.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 17 of 105
ZED-F9K-Integration manual
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
the IMU frame (roll = -23.5 degrees if the IMU-mount misalignment is composed of a single
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 18 of 105
ZED-F9K-Integration manual
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-F9K was designed to work with odometer input. Although the ZED-F9K 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-F9K via the following interfaces:
Hardware interface: ZED-F9K 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-F9K 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-SFODODIS_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).
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 19 of 105
ZED-F9K-Integration manual
• 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.
3.2.4.2 UBX-ESF-MEAS time tagging (software interface only)
To achieve optimal performance with the fusion solution it is essential to determine the epoch in
the receiver time frame when the UBX-ESF-MEAS sensor data were taken. This may be done in one
of the following ways:
• First byte reception: reception time of the first byte of the UBX-ESF-MEAS message
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 20 of 105
ZED-F9K-Integration manual
• Time mark on external input: reception time of time mark signal sent to external input
The latency of sensor data is the absolute difference between the time at which the sensor
measurement is taken and the time at which either the first byte of the UBX-ESF-MEAS message
or the pre-processor's time mark are detected at the receiver.
The latency for the wheel tick can be set with the CFG-SFODO-LATENCY key.
It is essential that the time tags used for all UBX-ESF-MEAS data have the same resolution.
ZED-F9K automatically generates UBX-ESF-MEAS messages containing measurements from the
internal IMU using the default time tag resolution of 1 millisecond. If the customer wants to input
odometer data with UBX-ESF-MEAS messages, it is essential that the odometer time tag has a
resolution of 1 millisecond.
3.2.4.2.1 First byte reception
The easiest way to determine the sensor measurement generation time is to have the GNSS receiver
assume the time of reception of the first byte of the UBX-ESF-MEAS message (minus the constant
configured latency in CFG-SFODO-LATENCY) to be the time of sensor measurement. This approach
is the simplest to implement, but Time mark on external input can yield better latency control and
compensation.
Figure 4: First byte reception
3.2.4.2.2 Time mark on external input
In this case, the preprocessor unit generating the measurements sends a signal to the EXTINT
input of the GNSS receiver, marking the moment of the measurement generation. The subsequent
UBX-ESF-MEAS message is then flagged accordingly, and the measurements in the message are
assumed to have been generated at the time of external signal reception (minus the constant
configured latency in CFG-SFODO-LATENCY). This approach is the preferred solution, but it can be
difficult to realize an exact analog time signal for the preprocessor unit.
Figure 5: Time mark on external input
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 21 of 105
ZED-F9K-Integration manual
3.2.4.2.3 UBX-ESF-MEAS time tagging configuration
The time tag factor can be used to convert the sensor time tags into the required seconds.
It is essential that the time tags used for all UBX-ESF-MEAS data have the same resolution.
ZED-F9K automatically generates UBX-ESF-MEAS messages containing measurements from the
internal IMU using the default time tag resolution of 1 millisecond. If the customer wants to input
odometer data with UBX-ESF-MEAS messages, it is essential that the odometer time tag has a
resolution of 1 millisecond.
ZED-F9K automatically generates UBX-ESF-MEAS messages containing measurements from the
internal IMU. If the customer inputs UBX-ESF-MEAS with odometer data with a different sensor
time tag factor than that used by ZED-F9K for IMU data, it will fail!
The same sensor time-tag (ttag) factor must be used for all UBX-ESF-MEAS data.
The following sensor time tagging settings need to be specified:
• CFG-SFCORE-SEN_TTAG_FACT: This parameter can be used to convert the sensor time tags
from their original time unit into the required seconds. It has a resolution of 1 micro second. The
default value is 1000 (1 millisecond).
• CFG-SFCORE-SEN_TTAG_MAX: External sensor time tags can be encoded in different data
types (signed/unsigned, varying number of bytes) which might vary across sensor types. For
example, if the IMU raw packet's time-tag field is encoded into an unsigned long integer (4
bytes), the maximum possible time-tag value is 4294967295 (0xFFFFFFFFin hexadecimal).
3.2.5 ADR system configuration
3.2.5.1 Enabling/disabling fusion filter
The ADR feature can be enabled and disabled with the CFG-SFCORE-USE_SF key. If ADR is disabled,
the receiver outputs a GNSS-only solution. IMU sensor measurements are still available in UBX-ESFMEAS and UBX-ESF-RAW messages.
3.2.5.2 Recommended configuration
In general, it is recommended to use the default configuration values in order to achieve optimal ADR
navigation performance.
By default, the navigation solution update rate is 1 Hz. It can be configured with the CFG-RATE-NAV
key.
At higher navigation rates, it is strongly recommended to check (and maybe reduce)
the number of enabled output messages. CPU load, memory and interface bandwidth
constraints may be a limiting factor.
3.2.6 Operation
This section describes how the ADR receiver operates.
3.2.6.1 Fusion filter modes
The fusion filter operates in different modes which are output in the UBX-ESF-STATUS message.
The table below summarizes the different fusion filter modes with the receiver's associated tasks.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 22 of 105
ZED-F9K-Integration manual
Mode Performed tasks / Possible causes Published fix type
Initialization
Fusion
Suspended fusion
Disabled fusion
Table 8: Fusion modes
Initialization of IMU
Initialization of IMU-mount alignment
Initialization of INS (position, velocity, attitude)
IMU sensor error (e.g. missing data) detected
Fine-calibration of IMU-mount misalignment angles
Fine-calibration of IMU sensors
Fine-calibration of wheel tick factors
UDR fallback mode when missing WT data detected
Sensor error (e.g. missing data) detected
Ferry detected
Fatal fusion filter error occurred
Fusion filter turned off by user
3D-fix (GNSS)
GNSS/DR fix
3D-fix (GNSS)
3D-fix (GNSS)
More details about each fusion mode are given in the following sections.
3.2.6.1.1 Initialization mode
The purpose of the initialization phase is to estimate all unknown parameters which are required
for achieving fusion. The initialization phase is triggered after a receiver cold start or a filter reset
in case of fusion failure. The receiver is in initialization mode if the fusionMode field in the UBXESF-STATUS message is 0:INITIALIZING. In this case the required sensor calibration status
(calibStatus) is flagged as 0: NOT CALIBRATED and the navigation solution output during
initialization is based on GNSS solely.
The initialization phase comprises the following internal steps whose status is published in the
initStatus field of the UBX-ESF-STATUS message:
• IMU initialization: Unknown crucial IMU parameters such as sensor sampling frequency are
estimated during initialization. As long as all required IMU parameters are not initialized, the
status of the IMU initialization (imuInitStatus) is flagged as 1:INITIALIZING in the UBXESF-STATUS message. Moreover, the required sensor calibration statuses (calibStatus)
are flagged as 0:NOT CALIBRATED in the UBX-ESF-STATUS message. Note that if the user
configured all required sensor settings, this step is skipped and IMU initialization is flagged as
2:INITIALIZED.
• IMU-mount alignment initialization: If automatic IMU-mount alignment is enabled (see the
Automatic IMU-mount alignment section), initial IMU-mount roll, pitch and yaw angles need to
be estimated. For that, good GNSS signal reception as well as sufficient vehicle dynamics (i.e.
a series of left and right turns during a normal drive) need to be at hand. As long as the IMU-
mount alignment is not initialized, the status of the IMU-mount alignment (mntAlgStatus)
is flagged as 1:INITIALIZING in the UBX-ESF-STATUS message. Once initialized, the IMUmount alignment status is flagged as 2:INITIALIZED. If no IMU-mount alignment is required,
the IMU-mount alignment is flagged as 0:OFF. A detailed description of the automatic IMU-
mount alignment operation can be found in the Automatic IMU-mount alignment section.
• INS initialization: Before entering fusion mode, the initial vehicle position, velocity and
especially attitude (vehicle roll, pitch and heading angles) need to be known with sufficient
accuracy. This is achieved during INS initialization phase using GNSS which comprises an
INS coarse alignment step. As long as the fusion filter is not initialized, the status of the INS
initialization (insInitStatus) is flagged as 1:INITIALIZING in the UBX-ESF-STATUS
message. Once initialized, the INS initialization is flagged as 2:INITIALIZED.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 23 of 105
ZED-F9K-Integration manual
•
Wheel tick sensor initialization: Solution enters fusion mode (fusionMode field in the UBX-
ESF-STATUS message is on 1:FUSION), even when wheel tick is not yet initialized, following a
UDR mode approach described in UDR fallback mode section. WT sensor parameters, such as
initial wheel tick factor, are estimated in parallel and are used once estimated with sufficient
accuracy. As long as the wheel tick parameters are not initialized, the status of the wheel
tick initialization (wtInitStatus) is flagged as 1:INITIALIZING in the UBX-ESF-STATUS
message. Once initialized, the wheel tick sensor initialization is flagged as 2:INITIALIZED,
WT data are used by the filter and the parameters are stored in non-volatile storage. If no wheel
tick data are required, the wheel tick initialization is flagged as 0:OFF.
• Sensor error (e.g. missing data) detected: Sensor timeout of more than 500 ms will trigger an
INS re-initialization.
Note that initialization phase requires good GNSS signal conditions as well as periods during which
vehicle is stationary and moving (including left and right turns). Once all required initialization steps
are achieved, fusion mode is triggered and continuous calibration begins.
3.2.6.1.2 Fusion mode
Once initialization phase is achieved, the receiver enters fusion mode. The receiver is in fusion
mode if the UBX-ESF-STATUS.fusionMode field is set to 1:FUSION. The fusion filter then
starts to compute combined GNSS/dead reckoning fixes (fused solutions) and to calibrate the
sensors required for computing the fused navigation solution. This is the case when the sensor
calibration status (UBX-ESF-STATUS.calibStatus) is set to 1:CALIBRATING. As soon as the
calibration reaches a status where optimal fusion performance can be expected, (UBX-ESF-
STATUS.calibStatus is set to 2/3:CALIBRATED.
3.2.6.1.2.1 UDR fallback mode
In case of WT sensor error / timeout (500 ms), or normal WT sensor initialization, the solution
falls back to UDR (untethered dead reckoning) mode. The UBX-ESF-STATUS.fusionMode field still
shows 1:FUSION when the receiver enters UDR fallback mode. However, the following flags can be
used to determine when the receiver has entered UDR mode:
•
The UBX-ESF-STATUS.wtInitStatus shows 1:INITIALIZING.
•
The WT fault flag, UBX-ESF-STATUS.missingMeas field, is set to 1, indicating a WT timeout
has been detected.
3.2.6.1.3 Suspended fusion mode
Sensor fusion is temporarily suspended in cases where no fused solution should/can be computed.
In this case, the receiver produces a GNSS-only solution. The receiver is considered to be
in temporarily-disabled fusion mode when the UBX-ESF-STATUS.fusionMode field is set to
2:SUSPENDED.
Fusion is suspended in the following scenarios:
• If one or several sensors deliver erroneous data or no data at all. Fusion is suspended during the
sensor failure period. The receiver automatically recovers once the affected sensor or sensors
are back to normal operation.
• If the vehicle is detected to be on a ferry or other moving platform, where odometer data does
not indicate any displacement.
3.2.6.1.4 Disabled fusion mode
Sensor fusion can be permanently disabled if recurrent fusion failures occur. The receiver is
considered to be in permanently disabled fusion mode if the UBX-ESF-STATUS.fusionMode field
is set to 3:DISABLED. In this case, the receiver produces a GNSS-only solution if possible.
Fusion is permanently disabled in the following cases:
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 24 of 105
ZED-F9K-Integration manual
•
If the fusion filter was manually turned off by the user with the CFG-SFCORE-USE_SF key.
• If the filter diverges due to significantly wrong installation or filter parameters.
3.2.6.2 Accelerated initialization and calibration procedure
This section describes how to perform fast initialization and calibration of the ADR receiver for
evaluation purposes.
The duration of the initialization phases depends on the quality of the GNSS signals and the
dynamics encountered by the vehicle.
You can shorten the initialization time required for reaching the fused navigation mode by following
the procedure in the order described in the table below.
Phase Procedure Indicator of success
IMU initialization
INS initialization
(position and velocity)
IMU-mount alignment
initialization
Wheel tick sensor
initialization
INS initialization
(attitude)
Table 9: Accelerated initialization procedure
After receiver cold start or first receiver use, turn
on car engine and stay stationary under good GNSS
signal reception conditions for at least 3 minutes.
Once IMU is initialized, stay stationary under good
GNSS signal reception conditions until a reliable
GNSS fix can be achieved.
Start driving at a minimum speed of 30 km/h and do
a series of approximately 10 left and right turns (at
least 90 degrees).
You can skip this step if automatic IMU-mount
alignment is turned off.
Drive for at least 500 meters at a minimum speed
of 30 km/h. To shorten this calibration step, drive
the car at a higher speed (around 50 km/h) for at
least 10 seconds under good GNSS visibility.
Drive straight for at least 100 meters at a
minimum speed of 40 km/h.
IMU initialization status UBX-ESF-
STATUS.imuInitStatus shows
2:INITIALIZED.
GNSS 3D fix achieved, good 3D position
accuracy (at least 5 m), high number of
used SVs (check UBX-NAV-PVT message).
IMU-mount alignment status (UBX-
ESF-STATUS.mntAlgStatus) shows
2:INITIALIZED, the IMU-mount
alignment status UBX-ESF-ALG.status
shows 3:COARSE ALIGNED.
Wheel tick sensor initialization status
UBX-ESF-STATUS.wtInitStatus shows
2:INITIALIZED.
INS initialization status UBX-ESF-
STATUS.insInitStatus shows
2:INITIALIZED.
Once initialization is completed, the UBX-ESF-STATUS.fusionMode field shows 1:FUSION,
combined GNSS/dead reckoning fixes (fused solutions) are output and the sensors used in
the navigation filter start to get calibrated. Calibration is a continuous process running in the
background, and it directly impacts the navigation solution quality.
You can shorten the calibration time required for reaching optimal ADR navigation performance by
following the procedure described in the table below.
Phase Procedure Indicator of success
IMU-mount alignment
calibration
UBX-20046189 - R01
C1-Public Early production information
Keep driving at a minimum speed of 30 km/h and
do a series of left and right turns (at least 90
degrees). At each turn the estimated IMU-mount
misalignment angles are refined and their accuracy
increased.
You can skip this step if automatic IMU-mount
alignment is turned off.
3 Receiver functionality Page 25 of 105
Once the IMU-mount alignment engine
has high confidence in its misalignment
angle estimates, the IMU-mount alignment
status UBX-ESF-ALG.status is set to
4:FINE ALIGNED.
ZED-F9K-Integration manual
Phase Procedure Indicator of success
IMU calibration
(gyroscope and
accelerometer)
Table 10: Accelerated calibration procedure
Drive curves and straight segments for a few
minutes by including a few stops lasting at least
30 seconds each. This drive should also include
some periods with higher speed (at least 50 km/
h) and can typically be carried out on normal
open-sky roads with good GNSS signal reception
conditions.
The calibration status of the used sensors
UBX-ESF-STATUS.calibStatus shows
2/3:CALIBRATED.
Note that the calibration status (UBX-ESF-STATUS.calibStatus) of some used sensors might
fall back to 1:CALIBRATING if the receiver is operated in challenging conditions. In such a case,
fused navigation solution uncertainty increases until optimal conditions are observed again for recalibrating the sensors.
In the presence of significant temperature gradient affecting the gyroscopes, the fused
navigation performance might also depend on how well the temperature compensation
table is populated. The table is gradually filled in while the vehicle is stationary and by
observing gyroscope biases at different temperatures. Therefore the quality of the
gyroscope temperature compensation depends on how many temperature bins could be
observed while the vehicle was stationary and on the duration of the observation for each
bin.
3.2.6.3 Automatic IMU-mount alignment
3.2.6.3.1 Alignment solution output
The IMU-mount misalignment angles are shown in UBX-ESF-ALG messages.
•
IMU-mount angle initialization: During IMU-mount angle initialization the (UBX-ESF-
ALG.status field is equal to 2), and the published angles (yaw, pitch and roll)
correspond to the current estimated values but are not yet applied for rotating the IMU
observations.
•
IMU-mount angle initialization complete: After initialization the (UBX-ESF-ALG.status field
is equal to or higher than 3), the published angles correspond to the estimated value and are
applied for rotating the IMU observations.
• Automatic IMU-mount alignment disabled: If automatic IMU-mount alignment is disabled, the
published angles correspond to the IMU-mount angles configured by the the user (see User-
defined IMU-mount Alignment section) and are applied for rotating the IMU observations.
CAUTION If user-defined IMU-mount misalignment angles were configured by the user
using CFG-SFIMU-IMU_MNTALG keys (see User-defined IMU-mount alignment section) and
automatic IMU-mount alignment is active, the angles output in the UBX-ESF-ALG message
still correspond to the definition given above: they represent the full rotation required for
transforming IMU data from installation frame to IMU frame. This means that the output
misalignment angles are computed from the composed rotation of the user-defined rotation
and the internally-estimated rotation.
3.2.6.3.2 Alignment progress
The progress of the automatic IMU-mount alignment can be monitored by checking the UBX-ESF-
ALG.status field.
• IMU-mount roll/pitch angle initialization ongoing: The alignment engine is initializing the IMU-
mount roll and pitch angles (UBX-ESF-ALG.status is 1). Both angles can only be initialized if
vehicle encounters left and right turns (as during a normal drive).
• IMU-mount yaw angle initialization ongoing: The alignment engine is initializing the IMU-
mount yaw angle (UBX-ESF-ALG.status is 2). IMU-mount yaw angle can only be initialized
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 26 of 105
ZED-F9K-Integration manual
once IMU-mount roll and pitch angles are initialized and if vehicle encounters left and right
turns (as during a normal drive).
•
IMU-mount alignment coarse calibration ongoing: Once initialized (UBX-ESF-ALG.status
is 3), the automatic IMU-mount alignment engine has sufficient confidence in all IMUmount misalignment angles and validates their use for compensating the accelerometer and
gyroscope data (fused navigation solutions can be computed). The IMU-mount misalignment
angles are filtered each time the observed vehicle dynamics are measurable.
• IMU-mount alignment fine calibration ongoing: Once the IMU-mount misalignment angles are
estimated with a good accuracy, the automatic IMU-mount alignment engine becomes more
conservative in updating the IMU-mount misalignment angles (UBX-ESF-ALG.status is 4).
3.2.6.3.3 Alignment reset
If for some reasons the IMU-mount misalignment angles estimated by the automatic IMU-mount
alignment engine are no longer valid (for example due to a change in the physical mounting of
the device), the IMU-mount misalignment angles can be reset by sending a UBX-ESF-RESETALG
message. In addition, the misalignment angles are also reset in the following cases:
• If a cold start command is sent.
• If the user-defined IMU-mount misalignment angles are changed by sending CFG-SFIMU-
IMU_MNTALG keys (see User-defined IMU-mount alignment section for more details.
The IMU-mount alignment engine then falls back into initialization mode.
3.2.6.3.4 Alignment errors
The following errors might be output in the UBX-ESF-ALG.error bit field:
• IMU-mount roll/pitch angle error: If the automatic IMU-mount alignment engine suspects
wrong IMU-mount roll and/or IMU-mount pitch misalignment angles (either due to a wrong
initialization or a change in the physical mounting of the device), the UBX-ESF-ALG.error bit
0 is set to 1.
• IMU-mount yaw angle error: If the automatic IMU-mount alignment engine suspects wrong
IMU-mount yaw misalignment angle (either due to a wrong initialization or a change in the
physical mounting of the device), the UBX-ESF-ALG.error bit 1 is set to 1.
•
Euler angle singularity ('gimbal-lock') error: The Euler angle singularity UBX-ESF-ALG.error
bit 2 is set when the automatic IMU-mount alignment engine detects an installation where the
IMU frame is misaligned in such a way that a degree of freedom is lost when two IMU-mount
misalignment (Euler) angles begin to describe the same rotations (or axes). This happens, for
example, with an IMU-mount misalignment of +/- 90 degrees around the IMU-mount pitch
axis, where IMU-mount roll and IMU-mount yaw cannot be distinguished from each other.
In such a case, these IMU-mount misalignment angles start to heavily fluctuate with time
due to the mathematical singularity occurring at these points, meaning that the IMU-mount
misalignment angles output in the UBX-ESF-ALG are not stable in time. Note however that
each individual set of IMU-mount misalignment angles output in such a case still describes the
correct rotation. Moreover, the internal rotation applied for aligning the IMU readings does not
suffer from this singularity issue and optimal fusion can still be achieved.
3.2.6.4 Navigation output
3.2.6.4.1 Local-level north-east-down (NED) frame
The local-level frame is a geodetic frame with the following features:
• The origin (O) is a point on the Earth's surface;
• The x-axis points to north;
• The y-axis points to east;
• The z-axis completes the right-handed reference system by pointing down.
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 27 of 105
ZED-F9K-Integration manual
The frame is referred to as North-East-Down (NED) since its axes are aligned with the North, East
and down directions.
3.2.6.4.2 Vehicle frame
The vehicle frame is a right-handed 3D Cartesian frame rigidly connected with the vehicle and is
used to determine the attitude of the vehicle with respect to the local-level frame. It has the following
features:
• The origin (O) is the VRP;
• The x-axis points towards the front of the vehicle;
• The y-axis points towards the right of the vehicle;
• The z-axis completes the right-handed reference system by pointing down.
3.2.6.4.3 Vehicle position and velocity output
The position and velocity information is output in several messages, for example, UBX-NAV-PVT.
Position and velocity computed by the ADR navigation filter are referenced to the IRP.
3.2.6.4.4 Vehicle attitude output
The transformation between the vehicle-frame and the local-level frame is described by three
attitude angles about the local-level axes denoted as vehicle roll, vehicle pitch and vehicle heading.
All three angles are referred to as vehicle attitude and are illustrated in the figure below:
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 28 of 105
ZED-F9K-Integration manual
Figure 6: Vehicle attitude output
The order of the sequence of rotations around the navigation axes defining the vehicle attitude
matrix in terms of vehicle attitude angles is illustrated below:
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 29 of 105
ZED-F9K-Integration manual
Figure 7: Vehicle attitude definition
Note that in this picture the body frame corresponds to the vehicle frame.
The vehicle attitude is output in the UBX-NAV-ATT message. The message provides all three angles
together with their accuracy estimates.
3.2.6.4.5 Vehicle dynamics output
The UBX-ESF-INS message outputs information about vehicle dynamics provided by the INS,
compensated vehicle angular rates and compensated vehicle accelerations. The acceleration data
is free of any gravitational acceleration. Its accuracy is directly dependent on the filter attitude
estimation accuracy.
Compensated vehicle dynamics information is output with respect to the vehicle frame.
The message outputs only dynamics information that is directly compensated by the fusion
filter. This implies that depending on the solution type and the sensor availability, dynamics
along some axes of the vehicle frame might not be available.
3.2.6.5 Sensor data types
The UBX-ESF-MEAS messages can be used as input and/or output messages. They can provide the
following functionality:
• Output the ZED-F9K internal IMU measurements;
• Input external wheel tick or speed measurements from a host to ZED-F9K.
A different number of data fields may be used, and these can contain different types of
measurements. The type of each measurement is specified in the UBX-ESF-MEAS.dataType field.
The supported sensor data types are:
Type Description Unit Format of the 24 data bits
0 none, data field contains no data
1...4 reserved
5 z-axis gyroscope angular rate deg/s *2^-12 signed
6...7 reserved
UBX-20046189 - R01
C1-Public Early production information
3 Receiver functionality Page 30 of 105
Loading...