Ublox ZED-F9H Use and care manual


ZED-F9H
u-blox F9 module for heading applications
Integration manual
Abstract
This document describes the features and application of ZED-F9H, a multi-
band GNSS module for heading applications, designed to provide the best
possible heading information to applications where precise attitude is of
greatest importance.
www.u-blox.com
UBX-19030120 - R04
C1-Public

ZED-F9H-Integration manual
Document information
Title ZED-F9H
Subtitle u-blox F9 module for heading applications
Document type Integration manual
Document number UBX-19030120
Revision and date R04 18-Jun-2021
Disclosure restriction C1-Public
This document applies to the following products:
Type number FW version PCN reference RN reference
ZED-F9H-00B-01 HDG 1.12 UBX-19057484 UBX-19027215
ZED-F9H-01B-00 HDG 1.13 - UBX-20047673
u-blox or third parties may hold intellectual property rights in the products, names, logos and designs included in this
document. Copying, reproduction, modification or disclosure to third parties of this document or any part thereof is only
permitted with the express written permission of u-blox.
The information contained herein is provided "as is" and u-blox assumes no liability for its use. No warranty, either express
or implied, is given, including but not limited to, with respect 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 without notice. For the most recent
documents, visit www.u-blox.com.
Copyright © 2021, u-blox AG.
UBX-19030120 - R04

Page 2 of 101
C1-Public

ZED-F9H-Integration manual
Contents
1 Integration manual overview............................................................................................. 6
2 System description...............................................................................................................7
2.1 Overview.................................................................................................................................................... 7
2.1.1 GNSS-based attitude determination........................................................................................7
2.2 Architecture..............................................................................................................................................8
2.2.1 Block diagram..................................................................................................................................8
2.2.2 Typical ZED-F9H application setups......................................................................................... 8
3 Receiver functionality........................................................................................................11
3.1 Receiver configuration.........................................................................................................................11
3.1.1 Changing the receiver configuration....................................................................................... 11
3.1.2 Default GNSS configuration...................................................................................................... 11
3.1.3 Default interface settings..........................................................................................................12
3.1.4 Basic receiver configuration...................................................................................................... 12
3.1.5 Moving base RTK configuration............................................................................................... 15
3.1.6 Legacy configuration interface compatibility........................................................................ 18
3.1.7 Navigation configuration............................................................................................................18
3.2 SBAS........................................................................................................................................................23
3.3 QZSS SLAS............................................................................................................................................ 25
3.3.1 Features......................................................................................................................................... 25
3.3.2 Configuration................................................................................................................................ 26
3.4 Geofencing..............................................................................................................................................26
3.4.1 Introduction................................................................................................................................... 26
3.4.2 Interface......................................................................................................................................... 26
3.4.3 Geofence state evaluation......................................................................................................... 26
3.4.4 Using a PIO for geofence state output................................................................................... 27
3.5 Logging....................................................................................................................................................27
3.5.1 Introduction................................................................................................................................... 27
3.5.2 Setting the logging system up................................................................................................. 28
3.5.3 Information about the log.......................................................................................................... 28
3.5.4 Recording....................................................................................................................................... 29
3.5.5 Retrieval......................................................................................................................................... 30
3.5.6 Command message acknowledgment....................................................................................30
3.6 Communication interfaces................................................................................................................. 31
3.6.1 UART............................................................................................................................................... 32
3.6.2 I2C interface..................................................................................................................................33
3.6.3 SPI interface..................................................................................................................................36
3.6.4 USB interface................................................................................................................................37
3.7 Predefined PIOs.....................................................................................................................................38
3.7.1 D_SEL..............................................................................................................................................38
3.7.2 RESET_N........................................................................................................................................ 38
3.7.3 SAFEBOOT_N................................................................................................................................38
3.7.4 TIMEPULSE................................................................................................................................... 39
3.7.5 TX_READY..................................................................................................................................... 39
3.7.6 EXTINT............................................................................................................................................39
UBX-19030120 - R04

Contents Page 3 of 101
C1-Public

ZED-F9H-Integration manual
3.7.7 GEOFENCE_STAT interface....................................................................................................... 40
3.7.8 RTK_STAT interface.....................................................................................................................40
3.8 Antenna supervisor.............................................................................................................................. 40
3.8.1 Antenna voltage control - ANT_OFF........................................................................................41
3.8.2 Antenna short detection - ANT_SHORT_N............................................................................ 42
3.8.3 Antenna short detection auto recovery.................................................................................. 42
3.8.4 Antenna open circuit detection - ANT_DETECT................................................................... 43
3.9 Multiple GNSS assistance (MGA)..................................................................................................... 44
3.9.1 Authorization................................................................................................................................ 44
3.9.2 Multiple servers............................................................................................................................44
3.9.3 Preserving information during power-off................................................................................44
3.9.4 AssistNow Online......................................................................................................................... 45
3.10 Clocks and time.................................................................................................................................. 48
3.10.1 Receiver local time.................................................................................................................... 48
3.10.2 Navigation epochs..................................................................................................................... 48
3.10.3 iTOW timestamps..................................................................................................................... 49
3.10.4 GNSS times.................................................................................................................................50
3.10.5 Time validity................................................................................................................................50
3.10.6 UTC representation...................................................................................................................50
3.10.7 Leap seconds..............................................................................................................................51
3.10.8 Real-time clock...........................................................................................................................51
3.10.9 Date...............................................................................................................................................51
3.11 Timing functionality...........................................................................................................................52
3.11.1 Time pulse...................................................................................................................................52
3.11.2 Timemark.................................................................................................................................... 56
3.12 Security.................................................................................................................................................57
3.12.1 Spoofing detection / monitoring............................................................................................ 57
3.12.2 Jamming/interference indicator............................................................................................ 58
3.12.3 GNSS receiver integrity............................................................................................................59
3.13 u-blox protocol feature descriptions.............................................................................................. 59
3.13.1 Broadcast navigation data...................................................................................................... 59
3.14 Forcing a receiver reset.....................................................................................................................66
3.15 Firmware upload................................................................................................................................. 66
3.16 Spectrum analyzer............................................................................................................................. 67
4 Design..................................................................................................................................... 68
4.1 Pin assignment......................................................................................................................................68
4.2 Power supply..........................................................................................................................................70
4.2.1 VCC: Main supply voltage.......................................................................................................... 70
4.2.2 V_BCKP: Backup supply voltage............................................................................................... 70
4.2.3 ZED-F9H power supply...............................................................................................................71
4.3 ZED-F9H minimal design....................................................................................................................71
4.4 Antenna...................................................................................................................................................72
4.4.1 Antenna bias.................................................................................................................................73
4.5 EOS/ESD precautions.......................................................................................................................... 76
4.5.1 ESD protection measures.......................................................................................................... 76
4.5.2 EOS precautions...........................................................................................................................77
4.5.3 Safety precautions...................................................................................................................... 77
4.6 Electromagnetic interference on I/O lines.......................................................................................77
4.6.1 General notes on interference issues......................................................................................78
4.6.2 In-band interference mitigation................................................................................................78
UBX-19030120 - R04

Contents Page 4 of 101
C1-Public

ZED-F9H-Integration manual
4.6.3 Out-of-band interference........................................................................................................... 79
4.7 Layout...................................................................................................................................................... 79
4.7.1 Placement...................................................................................................................................... 79
4.7.2 Thermal management................................................................................................................ 79
4.7.3 Package footprint, copper and paste mask........................................................................... 80
4.7.4 Layout guidance........................................................................................................................... 81
4.8 Design guidance....................................................................................................................................83
4.8.1 General considerations............................................................................................................... 83
4.8.2 Backup battery............................................................................................................................. 83
4.8.3 RF front-end circuit options...................................................................................................... 83
4.8.4 Antenna/RF input........................................................................................................................ 84
4.8.5 Ground pads..................................................................................................................................85
4.8.6 Schematic design........................................................................................................................ 85
4.8.7 Layout design-in guideline......................................................................................................... 85
5 Product handling................................................................................................................. 86
5.1 ESD handling precautions.................................................................................................................. 86
5.2 Soldering.................................................................................................................................................86
5.3 Tapes....................................................................................................................................................... 89
5.4 Reels........................................................................................................................................................ 90
5.5 Moisture sensitivity levels.................................................................................................................. 90
Appendix.................................................................................................................................... 91
A Glossary......................................................................................................................................................91
B RTK configuration procedures with u-center.....................................................................................91
B.1 Rover configuration with u-center...............................................................................................91
C Stacked patch antenna.......................................................................................................................... 95
Related documents................................................................................................................ 99
Revision history.................................................................................................................... 100
UBX-19030120 - R04

Contents Page 5 of 101
C1-Public

ZED-F9H-Integration manual
1 Integration manual overview
This document is an important source of information on all aspects of ZED-F9H system, software
and hardware design. The purpose of this document is to provide guidelines for a successful
integration of the receiver with the customer's end product.
UBX-19030120 - R04

1 Integration manual overview Page 6 of 101
C1-Public

ZED-F9H-Integration manual
2 System description
2.1 Overview
The ZED-F9H positioning module features the u-blox F9 receiver platform, which provides multi-
band GNSS to high-volume industrial applications in a compact form factor. The module with
integrated RTK enables precise heading, even when not moving, for automation of moving
machinery in industrial and consumer-grade products in a small surface-mounted form factor of
17.0 x 22.0 x 2.4 mm.
2.1.1 GNSS-based attitude determination
u-blox ZED-F9H high precision receiver takes GNSS precision to the next level:
• Delivers accurate heading for receiver pairs mounted on the same moving platform: 0.4 deg
50% for 1 m baseline
• Heading accuracy independent of vehicle motion and calibration
• Fast time to heading output and robust performance with multi-band, multi-constellation
reception
• Compatible with ZED-F9P moving bases
Some typical applications for the ZED-F9H are shown below:
Figure 1: Typical applications for the ZED-F9H
2.1.1.1 RTK modes of operation
The ZED-F9H supports the following modes of operation:
1. ZED-F9H operating as a rover in a moving baseline setup: It receives RTCM correction data
from a ZED-F9P operating as a moving base and then provides heading information.
UBX-19030120 - R04

2 System description Page 7 of 101
C1-Public

ZED-F9H-Integration manual
2.2 Architecture
The ZED-F9H receiver provides all the necessary RF and baseband processing to enable multi-
constellation operation. The block diagram below shows the key functionality.
2.2.1 Block diagram
Figure 2: ZED-F9H block diagram
An active antenna is mandatory with the ZED-F9H.
2.2.2 Typical ZED-F9H application setups
The moving base feature also enables derivation of the vehicle orientation by mounting two or three
GNSS receivers on the same vehicle platform, i.e. by fixing the position of the GNSS antennas relative
to each other.
See the ZED-F9H Moving Base application note [4] for more information on designing in
and using moving base.
UBX-19030120 - R04

2 System description Page 8 of 101
C1-Public

ZED-F9H-Integration manual
Figure 3: ZED-F9H orientation of a vehicle in space
Figure 4: ZED-F9H used for drone heading determination
UBX-19030120 - R04

2 System description Page 9 of 101
C1-Public

ZED-F9H-Integration manual
Figure 5: ZED-F9H used for automotive heading determination
UBX-19030120 - R04

2 System description Page 10 of 101
C1-Public

ZED-F9H-Integration manual
3 Receiver functionality
This section describes the ZED-F9H operational features and their configuration.
3.1 Receiver configuration
The ZED-F9H 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 applicable 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 applicable 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 applicable interface description
[2].
3.1.1 Changing the receiver configuration
All configuration messages, including legacy UBX-CFG messages, will result in a UBX-ACK-ACK
or UBX-ACK-NAK response. If several configuration messages are sent without waiting for this
response then the receiver may pause processing of input messages until processing of a previous
configuration message has been completed. When this happens a warning message "wait for cfg
ACK" will be sent to the host.
3.1.2 Default GNSS configuration
The ZED-F9H 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
•SBAS 1 : L1C/A
1Supported from firmware version HDG 1.13 onwards
UBX-19030120 - R04

3 Receiver functionality Page 11 of 101
C1-Public

ZED-F9H-Integration manual
For more information about the default configuration, see the applicable 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 with 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 I2C2 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 function as the main correction interface; RTCM 3.3 (from a ZED-F9P moving base)
is the default input protocol. UART2 can also optionally be configured for NMEA input or output
protocol.
Refer to the applicable interface description [2 ] for information about further settings.
By default the ZED-F9H 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-*
2I2C is a registered trademark of Philips/NXP
UBX-19030120 - R04

3 Receiver functionality Page 12 of 101
C1-Public

ZED-F9H-Integration manual
Interface Configuration groups
UART2 CFG-UART2-*, CFG-UART2INPROT-*, CFG-UART2OUTPROT-*
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
The rate of the supported output messages is configurable.
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 except
for QZSS and SBAS which are functional only with GPS. 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-F9H 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
false (0) true (1) true (1) no
true (1) false (0) false (0) no
true (1) false (0) true (1) Unsupported
combination
UBX-19030120 - R04

3 Receiver functionality Page 13 of 101
C1-Public

ZED-F9H-Integration manual
Constellation key
CFG-SIGNAL-GPS_ENA
Band key
CFG-SIGNAL-GPS_L1CA_ENA
Band key
CFG-SIGNAL-GPS_L2C_ENA
Constellation
enabled?
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 Antenna supervisor configuration
This section describes the antenna supervisor configuration, its use and restrictions.
The antenna supervisor is used to control an active antenna. The configuration of the antenna
supervisor allows the following:
• Control voltage supply to the antenna, which allows the antenna supervisor to cut power to the
antenna in the event of a short circuit or optimize power to the antenna in power save mode
• Detect a short circuit in the antenna and auto recover the antenna supply in such an event
• Detect an open antenna, which can be used to indicate if the antenna has been disconnected
See the table below for a description of the configuration items related to the antenna supervisor
operation.
Configuration item Description Comments
CFG-HW-ANT_CFG_VOLTCTRL Enable active antenna voltage control
CFG-HW-ANT_CFG_SHORTDET Enable short circuit detection
CFG-HW-ANT_CFG_SHORTDET_POL Short antenna detection polarity Set to 1 if the required logic polarity is
active-low (default)
CFG-HW-ANT_CFG_OPENDET Enable open circuit detection
CFG-HW-ANT_CFG_OPENDET_POL Open antenna detection polarity Set to 1 if the required logic polarity is
active-low (default)
CFG-HW-ANT_CFG_PWRDOWN Power down antenna supply if short
circuit is detected
CFG-HW-ANT_CFG_PWRDOWN_POL Power down antenna logic polarity Set to 1 if the required logic polarity is
active-high (default)
CFG-HW-ANT_CFG_RECOVER Enable auto recovery in the event of a
short circuit
To use this feature, short circuit
detection should be enabled. See CFG-
HW-ANT_CFG_SHORTDET
CFG-HW-ANT_SUP_SWITCH_PIN PIO-Pin (PIO number) used for switching
antenna supply
It is recommended that you use the
default PIO and assigned pin
CFG-HW-ANT_SUP_SHORT_PIN PIO-Pin (PIO number) used for detecting
a short-circuit in the antenna supply
It is recommended that you use the
default PIO and assigned pin
CFG-HW-ANT_SHORT_THR Defines the threshold for the antenna
supervisor when a short status is
detected.
Only applicable for the discrete
antenna supervisor (based on MADC)
CFG-HW-ANT_OPEN_THR Defines the threshold for the antenna
supervisor when an open status is
detected.
Only applicable for the discrete
antenna supervisor (based on MADC)
CFG-HW-ANT_ENGINE With this configuration key, the antenna
supervisor engine can be selected.
Default value is "EXT"
Table 4: Antenna supervisor configuration
It is possible to obtain the status of the antenna supervisor through the UBX-MON-RF message.
Moreover, any changes in the status of the antenna supervisor are reported to the host interface in
the form of notice messages. See the applicable interface description [2] for antStatus and antPower
field description.
UBX-19030120 - R04

3 Receiver functionality Page 14 of 101
C1-Public

ZED-F9H-Integration manual
Status Description
OFF Antenna is off
ON Antenna is on
DONTKNOW Antenna power status is not known
Table 5: Antenna power status
3.1.5 Moving base RTK configuration
Moving base (MB) RTK technology introduces the concept of a ZED-F9P moving base and a ZED-
F9H rover. In such a setup, the base and the rover are mounted on the same moving platform. The
ZED-F9P moving base sends correction to the ZED-F9H rover, enabling it to compute its heading
relative to the base, i.e. the platform heading, with high accuracy.
In the MB RTK context, the base and rover receivers are referred to as MB base and MB rover
respectively.
After describing the RTCM protocol and corresponding supported message types, this section
describes how to configure the ZED-F9H high precision receiver as an MB rover receiver.
See the ZED-F9H Moving Base application note [4] for more information on designing in, configuring
and using a moving base setup.
3.1.5.1 ZED-F9P base RTCM corrections for the ZED-F9H
RTCM is a binary data protocol for communicating GNSS correction information. The ZED-F9H high
precision receiver only supports RTCM corrections provided by a ZED-F9P base receiver operating
in moving-base mode.
The following ZED-F9P moving-base messages are required:
•RTCM 4072.03 (Reference station PVT)
•MSM44 or MSM7 GNSS observations for systems configured on the rover
• GLONASS code phase biases message RTCM 1230 if GLONASS is configured on the rover
3.1.5.2 List of supported RTCM input messages
Message type Description
RTCM 1074 GPS MSM4
RTCM 1077 GPS MSM7
RTCM 1084 GLONASS MSM4
RTCM 1087 GLONASS MSM7
RTCM 1094 Galileo MSM4
RTCM 1097 Galileo MSM7
RTCM 1124 BeiDou MSM4
RTCM 1127 BeiDou MSM7
RTCM 1230 GLONASS code-phase biases
RTCM 4072.0 Reference station PVT (u-blox proprietary RTCM Message)
Table 6: ZED-F9H supported input RTCM version 3.3 messages
3Message 4072.1 it is also necessary if using firmware version HDG 1.12
4MSM4 messages in moving-base mode are supported from firmware version HDG 1.13 onwards
UBX-19030120 - R04

3 Receiver functionality Page 15 of 101
C1-Public

ZED-F9H-Integration manual
3.1.5.3 MB rover operation
In its default configuration, the ZED-F9H will attempt to provide the best heading accuracy
depending on the received correction data from a ZED-F9P base in moving base mode. It will enter
RTK float mode as soon as it receives an input stream of RTCM correction messages. Once the rover
has resolved the carrier phase ambiguities, it will enter RTK fixed mode. When in this mode, the
relative heading between base and rover can be expected to be accurate. The time period between
RTK float and RTK fixed operation is referred to as the convergence time. Note that the convergence
time is affected by multipath and satellite visibility at both rover and base station.
The ZED-F9H should receive RTCM corrections matching its GNSS signal configuration to function
optimally. The rover requires both base station observation (MSM4 or MSM7 messages) and
position message (RTCM 4072.0) in order to attempt ambiguity fixes. The rover will attempt to
provide RTK fixed operation when sufficient number of ambiguities are available. If phase lock on
sufficient number of signals cannot be maintained, the rover will drop back to RTK float mode. The
rover will continue to attempt to resolve carrier ambiguities and revert to RTK fixed mode once the
minimum number of signals has been restored.
The RTK mode that an RTK rover operates in can be configured through the CFG-NAVHPG-
DGNSSMODE configuration item. The following two RTK modes are available:
• RTK fixed: The rover will attempt to fix ambiguities whenever possible.
• RTK float: The rover will estimate the ambiguities as float but will make no attempts at fixing
them.
To provide accurate heading information RTK fixed mode should be kept.
The received correction messages stream should comply with the following:
• The reference station ID in the reference station message (RTCM 4072.0) must match that
used in the MSM observation messages. Otherwise, the rover cannot compute its position.
With a direct connection between the ZED-F9P moving base and the ZED-F9H rover this will
not be an issue. On a more complex networked communication system such as automotive or a
shipping vessel this needs to be considered.
• In order to fix GLONASS ambiguities the correction stream must contain message 1230.
Otherwise, the carrier ambiguities will be estimated as float even when set to operate in RTK
fixed mode. This will significantly degrade heading accuracy.
CFG-RTCM-DF003_IN5 can be used to configure the desired reference station ID and CFG-RTCM-
DF003_IN_FILTER can be used to configure how strict the filtering should be (RELAXED is the
recommended setting).
3.1.5.3.1 Message output in MB RTK mode
When operating in MB RTK rover mode users should take note of the modified information within
the following NMEA and UBX messages:
• NMEA-GGA: The quality field will be 4 for RTK fixed and 5 for RTK float (see NMEA position fix
flags in interface description). The age of differential corrections and base station ID will be set.
• NMEA-GLL, NMEA-VTG: The posMode indicator will be D for RTK float and RTK fixed (see
NMEA position fix flags in interface description).
• NMEA-RMC, NMEA-GNS: The posMode indicator will be F for RTK float and R for RTK fixed (see
NMEA position fix flags in interface description).
• UBX-NAV-PVT: The carrSoln flag will be set to 1 for RTK float and 2 for RTK fixed.
5CFG-RTCM-DF003_* items are supported from firmware version HDG 1.13 onwards
UBX-19030120 - R04

3 Receiver functionality Page 16 of 101
C1-Public

ZED-F9H-Integration manual
• UBX-NAV-RELPOSNED
• The diffSoln and relPosValid flags will be set
• The carrSoln flag will be set to 1 for RTK float and 2 for RTK fixed
• The isMoving flag will be set
• The relPosValid flag will be set if the rover managed to get the time-matched observations in
time and process the moving base solution
• The length of the relative position vector and its accuracy will be output
• The relative position vector will be normalized to 1m and the relPosNormalized flag will be
set
• The relPosHeading and its accuracy will be output
• The relPosHeadingValid flag will be set unless the length of the relative position vector and/
or its accuracy are not sufficient to reliably derive the heading information
• UBX-NAV-SAT
• The diffCorr flag will be set for satellites with valid RTCM data
• The rtcmCorrUsed, prCorrUsed, and crCorrUsed flags will be set for satellites for which the
RTCM corrections have been applied
• UBX-NAV-SIG
• For signals to which the RTCM corrections have been applied, the correction source will be
set to RTCM3 OSR and the crUsed, prCorrUsed, and crCorrUsed flags will be set
• UBX-NAV-STATUS
• The diffSoln flag and the diffCorr flag will be set
• The carrSoln flag will be set to 1 for RTK float and 2 for RTK fixed
No position information will be output in the messages. If position is required, consider the
ZED-F9P receiver as an alternative.
An illustrated procedure for configuring a rover using u-center is shown in the Appendix C.2.
3.1.5.4 Rover operation in MB RTK mode
When operating in MB RTK mode, the following performance limitations may apply:
• A moving base receiver typically experiences worse GNSS tracking than a static base receiver in
an open-sky environment and therefore the MB RTK performance may be degraded.
• The MB rover will wait as long as possible to compute a navigation solution, possibly lowering
the navigation rate all the way to 1 Hz while doing so. If not time-matched observations are
received in time, the receiver will flag the relative position as invalid.
• The achievable navigation update rate of the MB RTK solution is limited by the communication
link latency. Latency here refers to the delay we have in getting the RTCM messages on the
rover from the time they are sent from the base station.
• It is a good idea to try and minimize the latency in the communication link, especially if trying to
achieve high navigation update rate. As a rule of thumb, the communication link latency should
be less than the desired navigation update period minus 50 ms.
• If the communication link latency is too high to achieve the configured navigation update rate
the receiver will lower the navigation update rate until it reaches 1 Hz.
• If the communication link latency is too high for 1 Hz rover operation, the receiver will declare
the relative position as invalid.
• To ensure that the moving base processing works, the MB base and rover must use the same
navigation update rate and measurement rate.
With firmware version HDG 1.12, the time-matched observations must be received within
700 ms. When the limit is exceeded, the MB reference observations and/or position will be
extrapolated for up to 3 s before falling back to standard GNSS operation. The refPosMiss
and refObsMiss flags will be set for epochs during which the extrapolated base position or
UBX-19030120 - R04

3 Receiver functionality Page 17 of 101
C1-Public

ZED-F9H-Integration manual
observations have been used. These flags are no longer supported from firmware version
HDG 1.13 onwards.
3.1.6 Legacy configuration interface compatibility
Although there is some backwards compatibility for the legacy UBX-CFG configuration messages,
users are strongly advised to adopt the configuration interface described in this document.
See Legacy UBX-CFG message fields reference section in the applicable interface description [2].
3.1.7 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.7.1 Platform settings
u-blox receivers support different dynamic platform models 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 heading 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 heading 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
7 and Table 8 below.
Platform Description
Portable (default) 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 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 7: 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
UBX-19030120 - R04

3 Receiver functionality Page 18 of 101
C1-Public

ZED-F9H-Integration manual
Platform Max altitude [m] Max horizontal
velocity [m/s]
Max vertical velocity
[m/s]
Sanity check type Max
position
deviation
Airborne <4g 80000 500 20000 Altitude Large
Wrist 9000 30 20 Altitude and velocity Medium
Table 8: 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 8 above shows the types of sanity checks which are applied for a particular
dynamic platform model.
3.1.7.2 Navigation input filters
The navigation input filters in CFG-NAVSPG-* configuration group provide the input data of the
navigation engine.
These settings are primarily for the initial standard 2D/3D only GNSS fix indication when
not in RTK float/fixed mode.
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.
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 9: 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.7.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).
The ZED-F9H firmware does not support the dead reckoning position fix type.
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-19030120 - R04

3 Receiver functionality Page 19 of 101
C1-Public

ZED-F9H-Integration manual
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.
The CFG-NAVSPG-OUTFIL_TDOP and CFG-NAVSPG-OUTFIL_TACC configuration items also define
TDOP and time accuracy values that are used in order to establish whether a fix is regarded as locked
to GNSS or not, and as a consequence of this, which time pulse setting has to be used. Fixes that
do not meet both criteria will be regarded as unlocked to GNSS, and the corresponding time pulse
settings of CFG-TP-* configuration group will be used to generate a time pulse.
When in RTK float/fixed mode there are no navigation output filter settings for this mode.
This is handled internally in the RTK core.
3.1.7.3.1 Speed (3D) low-pass filter
The CFG-ODO-OUTLPVEL configuration item offers the possibility to activate a speed (3D) low-pass
filter. The output of the speed low-pass filter is published in the UBX-NAV-VELNED message (speed
field). The filtering level can be set via the CFG-ODO-VELLPGAIN configuration item and must be
comprised between 0 (heavy low-pass filtering) and 255 (weak low-pass filtering).
The internal filter gain is computed as a function of speed. Therefore, the level as defined in
the CFG-ODO-VELLPGAIN configuration item defines the nominal filtering level for speeds
below 5 m/s.
3.1.7.3.2 Course over ground low-pass filter
The CFG-ODO-OUTLPCOG configuration item offers the possibility to activate a course over ground
low-pass filter when the speed is below 8 m/s. The output of the course over ground (also named
heading of motion 2D) low-pass filter is published in the UBX-NAV-PVT message (headMot field),
UBX-NAV-VELNED message (heading field), NMEA-RMC message (cog field) and NMEA-VTG
message (cogt field). The filtering level can be set via the CFG-ODO-COGLPGAIN configuration item
and must be comprised between 0 (heavy low-pass filtering) and 255 (weak low-pass filtering).
The filtering level as defined in the CFG-ODO-COGLPGAIN configuration item defines the
filter gain for speeds below 8 m/s. If the speed is higher than 8 m/s, no course over ground
low-pass filtering is performed.
3.1.7.3.3 Low-speed course over ground filter
The CFG-ODO-USE_COG activates this feature and the CFG-ODO-COGMAXSPEED, CFG-ODO-
COGMAXPOSACC configuration items offer the possibility to configure a low-speed course over
ground filter (also named heading of motion 2D). This filter derives the course over ground from
position at very low speed. The output of the low-speed course over ground filter is published in the
UBX-NAV-PVT message (headMot field), UBX-NAV-VELNED message (heading field), NMEA-RMC
message (cog field) and NMEA-VTG message (cogt field). If the low-speed course over ground filter
is not configured, then the course over ground is computed as described in section Freezing the
course over ground.
3.1.7.4 Static hold
Static hold mode allows the navigation algorithms to decrease the noise in the position output when
the velocity is below a pre-defined "Static Hold Threshold". This reduces the position wander caused
by environmental factors such as multi-path and improves position accuracy especially in stationary
applications. By default, static hold mode is disabled.
If the speed drops below the defined "Static Hold Threshold", the static hold mode will be activated.
Once static hold mode has been entered, the position output is kept static and the velocity is set to
zero until there is evidence of movement again. Such evidence can be velocity, acceleration, changes
UBX-19030120 - R04

3 Receiver functionality Page 20 of 101
C1-Public