u-blox 8 / u-blox M8
Receiver Description
Including Protocol Specification

Abstract
The Receiver Description Including Protocol Specification
describes the firmware features, specifications andconfiguration for u-blox 8 / u-blox M8 high performance
positioning modules.
The Receiver Description provides an overview andconceptual details of the supported features.
The Protocol Specification describes the NMEA and
RTCM protocols as well as the UBX protocol (version 15.
00 up to 19.20, version 20.00 to 20.30, version 22.00 andversion 23.00 to 23.01) and serves as a reference manual.
It includes the Standard Precision GNSS, Time Sync,
Time & Frequency Sync, High Precision GNSS, ADR andUDR products.

www.u-blox.com
UBX-13003221 - R17

u-blox 8 / u-blox M8 Receiver Description - Manual

Document Information
Title

u-blox 8 / u-blox M8 Receiver Description

Subtitle

Including Protocol Specification v15-20.30,22-23.01

Document type

ManualDocument number

UBX-13003221

Revision and date

R17(5321fe3)

Document status

Early Production Information

17 May 2019

Document status explanation
Objective Specification

Document contains target values. Revised and supplementary data will be published later.

Advance Information

Document contains data based on early testing. Revised and supplementary data will be published later.

Early Production Information

Document contains data from product verification. Revised and supplementary data may be published later.

Production Information

Document contains the final product specification.

This document applies to the following products:
Product name

Type number

Firmware version

Product category

CAM-M8C

CAM-M8C-0-10

SPG 3.01

Standard Precision GNSS

CAM-M8Q

CAM-M8Q-0-10

SPG 3.01

Standard Precision GNSS

EVA-M8M

EVA-M8M-0-10

SPG 3.01

Standard Precision GNSS

EVA-M8M

EVA-M8M-1-10

SPG 3.01

Standard Precision GNSS

EVA-M8Q

EVA-M8Q-0-10

SPG 3.01

Standard Precision GNSS

MAX-M8C

MAX-M8C-0-10

SPG 3.01

Standard Precision GNSS

MAX-M8Q

MAX-M8Q-0-10

SPG 3.01

Standard Precision GNSS

MAX-M8W

MAX-M8W-0-10

SPG 3.01

Standard Precision GNSS

NEO-M8M

NEO-M8M-0-10

SPG 3.01

Standard Precision GNSS

NEO-M8N

NEO-M8N-0-10

SPG 3.01

Standard Precision GNSS

NEO-M8Q

NEO-M8Q-0-10

SPG 3.01

Standard Precision GNSS

NEO-M8Q

NEO-M8Q-01A-10

SPG 3.01

Standard Precision GNSS

LEA-M8S

LEA-M8S-0-10

SPG 3.01

Standard Precision GNSS

SAM-M8Q

SAM-M8Q-0-10

SPG 3.01

Standard Precision GNSS

ZOE-M8G

ZOE-M8G-0-10

SPG 3.01

Standard Precision GNSS

ZOE-M8Q

ZOE-M8Q-0-10

SPG 3.01

Standard Precision GNSS

ZOE-M8B

ZOE-M8B-0-10

SPG 3.51

Standard Precision GNSS

EVA-8M

EVA-8M-0-10

SPG 3.01

Standard Precision GNSSUBX-13003221 - R17

Early Production Information

Page ii

u-blox 8 / u-blox M8 Receiver Description - Manual

MAX-8C

MAX-8C-0-10

SPG 3.01

Standard Precision GNSS

MAX-8Q

MAX-8Q-0-10

SPG 3.01

Standard Precision GNSS

NEO-8Q

NEO-8Q-0-10

SPG 3.01

Standard Precision GNSS

NEO-M8P

NEO-M8P-0-10

HPG 1.30

High Precision GNSS

NEO-M8P

NEO-M8P-2-10

HPG 1.30

High Precision GNSS

NEO-M8P

NEO-M8P-0-11

HPG 1.40

High Precision GNSS

NEO-M8P

NEO-M8P-2-11

HPG 1.40

High Precision GNSS

EVA-M8E

EVA-M8E-0-11

UDR 1.00 / 1.21

Dead Reckoning

NEO-M8U

NEO-M8U-0-10

UDR 1.00 / 1.21

Dead Reckoning

NEO-M8U

NEO-M8U-04B-00

UDR 1.21

Dead Reckoning

NEO-M8T

NEO-M8T-0-10

TIM 1.10

Timing

LEA-M8T

LEA-M8T-0-10

TIM 1.10

Timing

LEA-M8F

LEA-M8F-0-00

FTS 1.01

Timingu-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, including but not limited, 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. For mostrecent documents, please visit www.u-blox.com.
Copyright © 2019, u-blox AG.
u-blox is a registered trademark of u-blox Holding AG in the EU and other countries.

UBX-13003221 - R17

Early Production Information

Page iii

u-blox 8 / u-blox M8 Receiver Description - Manual

Table of Contents
Preface ........................................................................................................................................................................ 1
1 Document Overview....................................................................................................................................... 1
2 Firmware and Protocol Versions ............................................................................................................... 1
2.1 How to Determine the Version and the Location of the Firmware........................................... 1
2.1.1 Decoding the Boot Screen (for Protocol Version 17 and Below)......................................... 1
2.1.2 Decoding the Boot Screen (for Protocol Version from 18 to 23.01).................................. 3
2.1.3 Decoding the output of UBX-MON-VER (for Protocol Version 17 and below)................ 4
2.1.4 Decoding the output of UBX-MON-VER (for Protocol Version from 18 and 23.01)....... 6
2.2 How to Determine the Supported Protocol Version of the u-blox Receiver .......................... 7
2.2.1 u-blox 8 / u-blox M8 Firmware and Supported Protocol Versions.................................... 7
Receiver Description.............................................................................................................................................. 9
3 Receiver Configuration................................................................................................................................ 9
3.1 Configuration Concept..................................................................................................................... 9
3.2 Organization of the Configuration Sections.............................................................................. 10
3.3 Permanent Configuration Storage Media................................................................................... 11
3.4 u-blox Receiver Default Configuration......................................................................................... 11
3.5 Save-on-Shutdown Feature........................................................................................................... 11
4 Concurrent GNSS ........................................................................................................................................ 12
4.1 GNSS Types....................................................................................................................................... 12
4.1.1 Major GNSS................................................................................................................................ 12
4.1.2 Augmentation Systems.......................................................................................................... 13
4.2 Configuration.................................................................................................................................... 14
4.2.1 Switching between GNSS....................................................................................................... 14
4.2.2 Configuring QZSS L1SAIF...................................................................................................... 15
5 SBAS Configuration Settings Description .......................................................................................... 15
5.1 SBAS (Satellite Based Augmentation Systems)....................................................................... 15
5.2 SBAS Features ................................................................................................................................. 17
5.3 SBAS Configuration........................................................................................................................ 18
6 QZSS L1S SLAS Configuration Settings Description...................................................................... 18
6.1 QZSS L1S SLAS (Sub-meter Level Augmentation Service).................................................... 18
6.2 QZSS L1S SLAS Features.............................................................................................................. 19
6.3 QZSS L1S SLAS Configuration..................................................................................................... 19
7 IMES Description ........................................................................................................................................ 20
7.1 IMES Features.................................................................................................................................. 20
8 Navigation Configuration Settings Description ............................................................................... 20
8.1 Platform settings............................................................................................................................. 21
8.2 Navigation Input Filters................................................................................................................. 22
8.3 Navigation Output Filters ............................................................................................................. 22
8.3.1 Speed (3-D) Low-pass Filter.................................................................................................. 23

UBX-13003221 - R17

Early Production Information

Page iv

u-blox 8 / u-blox M8 Receiver Description - Manual

8.3.2 Course over Ground Low-pass Filter................................................................................... 23
8.3.3 Low-speed Course Over Ground Filter................................................................................ 23
8.4 Static Hold ....................................................................................................................................... 23
8.5 Freezing the Course Over Ground ............................................................................................... 24
8.6 Degraded Navigation ..................................................................................................................... 24
8.6.1 2D Navigation........................................................................................................................... 24
8.7 Geodetic Coordinate Systems and Ellipsoids........................................................................... 24
9 Clocks and Time .......................................................................................................................................... 25
9.1 Receiver Local Time........................................................................................................................ 25
9.2 Navigation Epochs.......................................................................................................................... 26
9.3 iTOW Timestamps ......................................................................................................................... 26
9.4 GNSS Times ..................................................................................................................................... 27
9.5 Time Validity .................................................................................................................................... 27
9.6 UTC Representation....................................................................................................................... 27
9.7 Leap Seconds .................................................................................................................................. 28
9.8 Real Time Clock............................................................................................................................... 28
9.9 Date ................................................................................................................................................... 28
9.9.1 GPS-only Date Resolution...................................................................................................... 29
10 Broadcast Navigation Data................................................................................................................... 29
10.1 Parsing Navigation Data Subframes......................................................................................... 29
10.2 GPS.................................................................................................................................................. 30
10.2.1 GPS L1C/A................................................................................................................................ 30
10.3 GLONASS....................................................................................................................................... 30
10.4 BeiDou.............................................................................................................................................. 31
10.5 Galileo............................................................................................................................................... 31
10.5.1 Galileo E1OS.............................................................................................................................. 31
10.6 SBAS................................................................................................................................................ 32
10.7 QZSS................................................................................................................................................ 33
10.8 IMES................................................................................................................................................. 33
10.9 Summary........................................................................................................................................ 33
11 Serial Communication Ports Description........................................................................................... 34
11.1 TX-ready indication........................................................................................................................ 34
11.2 Extended TX timeout.................................................................................................................... 35
11.3 UART Ports..................................................................................................................................... 35
11.4 USB Port........................................................................................................................................... 36
11.5 DDC Port.......................................................................................................................................... 36
11.5.1 Read Access............................................................................................................................. 37
11.5.2 Write Access........................................................................................................................... 38
11.6 SPI Port............................................................................................................................................ 39
11.6.1 Maximum SPI clock speed..................................................................................................... 39
11.6.2 Read Access............................................................................................................................ 39
11.6.3 Back-To-Back Read and Write Access.............................................................................. 40
11.7 How to change between protocols............................................................................................. 40
UBX-13003221 - R17

Early Production Information

Page v

u-blox 8 / u-blox M8 Receiver Description - Manual

12 Multiple GNSS Assistance (MGA)....................................................................................................... 40
12.1 Introduction.................................................................................................................................... 40
12.2 Assistance Data............................................................................................................................. 41
12.3 AssistNow Online........................................................................................................................... 41
12.3.1 Host Software......................................................................................................................... 42
12.3.2 AssistNow Online Sequence............................................................................................... 43
12.3.3 Flow Control............................................................................................................................ 43
12.3.4 Authorization.......................................................................................................................... 43
12.3.5 Service Parameters............................................................................................................... 43
12.3.6 Multiple Servers..................................................................................................................... 45
12.4 AssistNow Offline......................................................................................................................... 46
12.4.1 Service Parameters................................................................................................................ 46
12.4.2 Authorization.......................................................................................................................... 47
12.4.3 Multiple Servers..................................................................................................................... 47
12.4.4 Time, Position and Almanac................................................................................................ 47
12.4.5 Flash-based AssistNow Offline.......................................................................................... 48
12.4.6 Host-based AssistNow Offline........................................................................................... 49
12.5 Preserving Information During Power-off................................................................................ 50
12.6 AssistNow Autonomous.............................................................................................................. 50
12.6.1 Introduction............................................................................................................................. 50
12.6.2 Concept................................................................................................................................... 50
12.6.3 Interface.................................................................................................................................. 52
12.6.4 Benefits and Drawbacks...................................................................................................... 53
13 Power Management................................................................................................................................. 54
13.1 Continuous Mode........................................................................................................................... 55
13.2 Power Save Mode.......................................................................................................................... 55
13.2.1 Operation................................................................................................................................. 56
13.2.2 Configuration......................................................................................................................... 60
13.2.3 Features.................................................................................................................................. 63
13.2.4 Examples................................................................................................................................. 64
13.3 Peak current settings................................................................................................................... 65
13.4 Power On/Off command.............................................................................................................. 65
13.5 EXTINT pin control when Power Save Mode is not active.................................................... 65
13.6 Measurement and navigation rate with Power Save Mode.................................................. 65
13.7 Power Mode Setup........................................................................................................................ 65
14 Forcing a Receiver Reset........................................................................................................................ 66
15 Receiver Status Monitoring................................................................................................................... 67
15.1 Input/Output system..................................................................................................................... 67
15.2 Jamming/Interference Indicator............................................................................................... 68
15.3 Jamming/Interference Monitor (ITFM).................................................................................... 68
16 Spoofing Detection.................................................................................................................................. 69
16.1 Introduction..................................................................................................................................... 69
16.2 Scope............................................................................................................................................... 69
UBX-13003221 - R17

Early Production Information

Page vi

u-blox 8 / u-blox M8 Receiver Description - Manual

17 Signal Attenuation Compensation...................................................................................................... 69
18 Remote Inventory..................................................................................................................................... 70
18.1 Description...................................................................................................................................... 70
18.2 Usage............................................................................................................................................... 70
19 Time pulse................................................................................................................................................... 70
19.1 Introduction..................................................................................................................................... 70
19.2 Recommendations......................................................................................................................... 71
19.3 GNSS time bases........................................................................................................................... 72
19.4 Time pulse configuration............................................................................................................. 73
19.5 Configuring time pulse with UBX-CFG-TP5............................................................................. 73
19.5.1 Example .1................................................................................................................................. 74
19.5.2 Example 2................................................................................................................................ 74
20 Timemark.................................................................................................................................................... 75
21 Odometer..................................................................................................................................................... 76
21.1 Introduction..................................................................................................................................... 76
21.2 Odometer Output.......................................................................................................................... 76
21.3 Odometer Configuration.............................................................................................................. 77
21.4 Resetting the Odometer.............................................................................................................. 77
22 Logging ........................................................................................................................................................ 77
22.1 Introduction.................................................................................................................................... 77
22.2 Setting the logging system up .................................................................................................. 78
22.3 Information about the log........................................................................................................... 78
22.4 Recording ....................................................................................................................................... 79
22.5 Retrieval ......................................................................................................................................... 80
22.6 Command message acknowledgement................................................................................... 81
23 Data Batching ............................................................................................................................................ 81
23.1 Introduction..................................................................................................................................... 81
23.2 Setting up the data batching ..................................................................................................... 81
23.3 Retrieval ......................................................................................................................................... 82
24 Geofencing ................................................................................................................................................. 83
24.1 Introduction.................................................................................................................................... 83
24.2 Interface......................................................................................................................................... 83
24.3 Geofence state evaluation.......................................................................................................... 83
24.4 Using a PIO for Geofence State Output................................................................................... 84
25 Time Mode Configuration...................................................................................................................... 84
25.1 Introduction.................................................................................................................................... 84
25.2 Fixed Position................................................................................................................................ 84
25.3 Survey-in ........................................................................................................................................ 84
26 Time & Frequency Sync (FTS) .............................................................................................................. 85
26.1 Introduction.................................................................................................................................... 85
26.2 Example use cases....................................................................................................................... 86
26.2.1 Stand-alone synchronization system............................................................................... 86
26.2.2 Oscillator control via host ................................................................................................... 87
UBX-13003221 - R17

Early Production Information

Page vii

u-blox 8 / u-blox M8 Receiver Description - Manual

26.2.3 Oscillator control via directly-connected DAC................................................................ 88
26.2.4 External (coherent) PPS...................................................................................................... 88
26.3 Synchronization Manager Concept.......................................................................................... 89
26.4 Oscillator and source specification ........................................................................................... 91
26.5 Calibration...................................................................................................................................... 92
26.6 FTS device Output and Top Of Second (TOS) message ...................................................... 93
26.7 Message transmission time slot reservations on host interfaces .................................... 94
26.7.1 Example setup........................................................................................................................ 94
27 RTK Mode Configuration........................................................................................................................ 95
27.1 Reference Station Mode Configuration.................................................................................... 95
27.2 Rover Mode Configuration.......................................................................................................... 96
27.3 Moving Baseline RTK Configuration......................................................................................... 96
27.3.1 MB Reference Configuration............................................................................................... 96
27.3.2 MB Rover Configuration...................................................................................................... 96
27.3.3 Expected Performance......................................................................................................... 97
28 Automotive Dead Reckoning (ADR).................................................................................................... 97
28.1 Introduction.................................................................................................................................... 97
28.2 ADR System Configuration ........................................................................................................ 97
28.2.1 Enabling/Disabling Fusion Filter......................................................................................... 97
28.2.2 Recommended Configuration ............................................................................................ 97
28.3 Operation ....................................................................................................................................... 98
28.3.1 Fusion Filter Modes.............................................................................................................. 98
28.3.2 Accelerated Initialization and Calibration Procedure.................................................... 99
28.3.3 Navigation Output................................................................................................................ 99
28.3.4 Sensor Data Types.............................................................................................................. 102
28.3.5 Raw Sensor Data Output................................................................................................... 103
28.3.6 Receiver Startup and Shutdown...................................................................................... 104
29 Untethered Dead Reckoning (UDR) .................................................................................................. 104
29.1 Introduction.................................................................................................................................. 104
29.2 UDR System Configuration ...................................................................................................... 104
29.2.1 Enabling/Disabling Fusion Filter....................................................................................... 104
29.2.2 Recommended Configuration .......................................................................................... 105
29.3 Operation...................................................................................................................................... 105
29.3.1 Fusion Filter Modes............................................................................................................. 105
29.3.2 Accelerated Initialization and Calibration Procedure.................................................. 106
29.3.3 Navigation Output .............................................................................................................. 106
29.3.4 Sensor Data Types.............................................................................................................. 109
29.3.5 Raw Sensor Data Output ................................................................................................... 110
29.3.6 Receiver Startup and Shutdown ....................................................................................... 111
30 High Navigation Rate (HNR) ................................................................................................................. 111
30.1 Introduction.................................................................................................................................... 111
30.2 Configuration ................................................................................................................................ 111
Interface Description ......................................................................................................................................... 112
UBX-13003221 - R17

Early Production Information

Page viii

u-blox 8 / u-blox M8 Receiver Description - Manual

31 NMEA Protocol.......................................................................................................................................... 112
31.1 Protocol Overview.......................................................................................................................... 112
31.1.1 Message Format.................................................................................................................... 112
31.1.2 Talker ID................................................................................................................................... 112
31.1.3 Protocol Configuration......................................................................................................... 113
31.1.4 Satellite Numbering.............................................................................................................. 114
31.1.5 Latitude and Longitude Format......................................................................................... 115
31.1.6 Position Fix Flags................................................................................................................... 115
31.1.7 Multi-GNSS Considerations................................................................................................ 116
31.1.8 Output of Invalid/Unknown Data........................................................................................ 117
31.1.9 Messages Overview............................................................................................................... 117
31.2 Standard Messages..................................................................................................................... 119
31.2.1 DTM.......................................................................................................................................... 119
31.2.2 GBQ......................................................................................................................................... 120
31.2.3 GBS......................................................................................................................................... 120
31.2.4 GGA.......................................................................................................................................... 121
31.2.5 GLL.......................................................................................................................................... 123
31.2.6 GLQ......................................................................................................................................... 124
31.2.7 GNQ......................................................................................................................................... 124
31.2.8 GNS......................................................................................................................................... 125
31.2.9 GPQ......................................................................................................................................... 126
31.2.10 GRS........................................................................................................................................ 127
31.2.11 GSA........................................................................................................................................ 128
31.2.12 GST........................................................................................................................................ 129
31.2.13 GSV........................................................................................................................................ 130
31.2.14 RMC........................................................................................................................................ 131
31.2.15 TXT........................................................................................................................................ 132
31.2.16 VLW....................................................................................................................................... 133
31.2.17 VTG........................................................................................................................................ 134
31.2.18 ZDA....................................................................................................................................... 135
31.3 PUBX Messages........................................................................................................................... 136
31.3.1 CONFIG (PUBX,41)................................................................................................................. 136
31.3.2 POSITION (PUBX,00)........................................................................................................... 137
31.3.3 RATE (PUBX,40)................................................................................................................... 138
31.3.4 SVSTATUS (PUBX,03)........................................................................................................ 139
31.3.5 TIME (PUBX,04).................................................................................................................... 140
32 UBX Protocol ............................................................................................................................................ 142
32.1 UBX Protocol Key Features........................................................................................................ 142
32.2 UBX Frame Structure................................................................................................................. 142
32.3 UBX Payload Definition Rules................................................................................................... 142
32.3.1 Structure Packing................................................................................................................ 143
32.3.2 Reserved Elements............................................................................................................. 143
32.3.3 Undefined Values................................................................................................................ 143
UBX-13003221 - R17

Early Production Information

Page ix

u-blox 8 / u-blox M8 Receiver Description - Manual

32.3.4 Message Naming ................................................................................................................ 143
32.3.5 Number Formats................................................................................................................. 143
32.4 UBX Checksum............................................................................................................................ 144
32.5 UBX Message Flow ..................................................................................................................... 145
32.5.1 Acknowledgement............................................................................................................... 145
32.5.2 Polling Mechanism.............................................................................................................. 145
32.6 UBX Class IDs............................................................................................................................... 145
32.7 UBX Messages Overview........................................................................................................... 146
32.8 UBX-ACK (0x05).......................................................................................................................... 152
32.8.1 UBX-ACK-ACK (0x05 0x01)................................................................................................ 152
32.8.2 UBX-ACK-NAK (0x05 0x00) .............................................................................................. 152
32.9 UBX-AID (0x0B) ........................................................................................................................... 153
32.9.1 UBX-AID-ALM (0x0B 0x30)................................................................................................ 153
32.9.2 UBX-AID-AOP (0x0B 0x33)................................................................................................ 155
32.9.3 UBX-AID-EPH (0x0B 0x31)................................................................................................. 157
32.9.4 UBX-AID-HUI (0x0B 0x02) ................................................................................................. 159
32.9.5 UBX-AID-INI (0x0B 0x01)..................................................................................................... 161
32.10 UBX-CFG (0x06)......................................................................................................................... 164
32.10.1 UBX-CFG-ANT (0x06 0x13)............................................................................................... 164
32.10.2 UBX-CFG-BATCH (0x06 0x93)........................................................................................ 165
32.10.3 UBX-CFG-CFG (0x06 0x09)............................................................................................. 166
32.10.4 UBX-CFG-DAT (0x06 0x06)............................................................................................. 168
32.10.5 UBX-CFG-DGNSS (0x06 0x70)........................................................................................ 170
32.10.6 UBX-CFG-DOSC (0x06 0x61)........................................................................................... 170
32.10.7 UBX-CFG-ESRC (0x06 0x60)........................................................................................... 172
32.10.8 UBX-CFG-GEOFENCE (0x06 0x69)................................................................................ 174
32.10.9 UBX-CFG-GNSS (0x06 0x3E).......................................................................................... 175
32.10.10 UBX-CFG-HNR (0x06 0x5C)........................................................................................... 178
32.10.11 UBX-CFG-INF (0x06 0x02).............................................................................................. 178
32.10.12 UBX-CFG-ITFM (0x06 0x39).......................................................................................... 180
32.10.13 UBX-CFG-LOGFILTER (0x06 0x47)............................................................................... 181
32.10.14 UBX-CFG-MSG (0x06 0x01)........................................................................................... 183
32.10.15 UBX-CFG-NAV5 (0x06 0x24)......................................................................................... 184
32.10.16 UBX-CFG-NAVX5 (0x06 0x23)....................................................................................... 187
32.10.17 UBX-CFG-NMEA (0x06 0x17)......................................................................................... 194
32.10.18 UBX-CFG-ODO (0x06 0x1E)............................................................................................ 201
32.10.19 UBX-CFG-PM2 (0x06 0x3B).......................................................................................... 202
32.10.20 UBX-CFG-PMS (0x06 0x86)......................................................................................... 209
32.10.21 UBX-CFG-PRT (0x06 0x00)............................................................................................ 210
32.10.22 UBX-CFG-PWR (0x06 0x57).......................................................................................... 221
32.10.23 UBX-CFG-RATE (0x06 0x08)........................................................................................ 221
32.10.24 UBX-CFG-RINV (0x06 0x34)......................................................................................... 223
32.10.25 UBX-CFG-RST (0x06 0x04).......................................................................................... 223
UBX-13003221 - R17

Early Production Information

Page xu-blox 8 / u-blox M8 Receiver Description - Manual

32.10.26 UBX-CFG-RXM (0x06 0x11)........................................................................................... 225
32.10.27 UBX-CFG-SBAS (0x06 0x16)......................................................................................... 226
32.10.28 UBX-CFG-SLAS (0x06 0x8D)....................................................................................... 228
32.10.29 UBX-CFG-SMGR (0x06 0x62)....................................................................................... 229
32.10.30 UBX-CFG-TMODE2 (0x06 0x3D)................................................................................. 232
32.10.31 UBX-CFG-TMODE3 (0x06 0x71)................................................................................... 233
32.10.32 UBX-CFG-TP5 (0x06 0x31)............................................................................................ 235
32.10.33 UBX-CFG-TXSLOT (0x06 0x53)................................................................................... 239
32.10.34 UBX-CFG-USB (0x06 0x1B)........................................................................................... 240
32.11 UBX-ESF (0x10).......................................................................................................................... 242
32.11.1 UBX-ESF-INS (0x10 0x15).................................................................................................. 242
32.11.2 UBX-ESF-MEAS (0x10 0x02)........................................................................................... 243
32.11.3 UBX-ESF-RAW (0x10 0x03)............................................................................................. 245
32.11.4 UBX-ESF-STATUS (0x10 0x10)....................................................................................... 246
32.12 UBX-HNR (0x28)....................................................................................................................... 249
32.12.1 UBX-HNR-INS (0x28 0x02).............................................................................................. 249
32.12.2 UBX-HNR-PVT (0x28 0x00)............................................................................................ 250
32.13 UBX-INF (0x04)......................................................................................................................... 253
32.13.1 UBX-INF-DEBUG (0x04 0x04)......................................................................................... 253
32.13.2 UBX-INF-ERROR (0x04 0x00)........................................................................................ 253
32.13.3 UBX-INF-NOTICE (0x04 0x02)....................................................................................... 254
32.13.4 UBX-INF-TEST (0x04 0x03)............................................................................................ 254
32.13.5 UBX-INF-WARNING (0x04 0x01).................................................................................... 255
32.14 UBX-LOG (0x21)......................................................................................................................... 256
32.14.1 UBX-LOG-BATCH (0x21 0x11).......................................................................................... 256
32.14.2 UBX-LOG-CREATE (0x21 0x07)...................................................................................... 259
32.14.3 UBX-LOG-ERASE (0x21 0x03)........................................................................................ 260
32.14.4 UBX-LOG-FINDTIME (0x21 0x0E).................................................................................. 260
32.14.5 UBX-LOG-INFO (0x21 0x08)............................................................................................ 262
32.14.6 UBX-LOG-RETRIEVEBATCH (0x21 0x10)..................................................................... 264
32.14.7 UBX-LOG-RETRIEVEPOSEXTRA (0x21 0x0f).............................................................. 265
32.14.8 UBX-LOG-RETRIEVEPOS (0x21 0x0b).......................................................................... 265
32.14.9 UBX-LOG-RETRIEVESTRING (0x21 0x0d)................................................................... 266
32.14.10 UBX-LOG-RETRIEVE (0x21 0x09)................................................................................. 267
32.14.11 UBX-LOG-STRING (0x21 0x04)...................................................................................... 268
32.15 UBX-MGA (0x13)........................................................................................................................ 269
32.15.1 UBX-MGA-ACK (0x13 0x60)............................................................................................. 269
32.15.2 UBX-MGA-ANO (0x13 0x20)............................................................................................ 270
32.15.3 UBX-MGA-BDS (0x13 0x03)............................................................................................. 271
32.15.4 UBX-MGA-DBD (0x13 0x80)............................................................................................ 275
32.15.5 UBX-MGA-FLASH (0x13 0x21)........................................................................................ 276
32.15.6 UBX-MGA-GAL (0x13 0x02)............................................................................................. 278
32.15.7 UBX-MGA-GLO (0x13 0x06)............................................................................................ 282
UBX-13003221 - R17

Early Production Information

Page xi

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.8 UBX-MGA-GPS (0x13 0x00)............................................................................................ 285
32.15.9 UBX-MGA-INI (0x13 0x40)............................................................................................... 290
32.15.10 UBX-MGA-QZSS (0x13 0x05)........................................................................................ 296
32.16 UBX-MON (0x0A)...................................................................................................................... 300
32.16.1 UBX-MON-BATCH (0x0A 0x32)...................................................................................... 300
32.16.2 UBX-MON-GNSS (0x0A 0x28)........................................................................................ 301
32.16.3 UBX-MON-HW2 (0x0A 0x0B)......................................................................................... 303
32.16.4 UBX-MON-HW (0x0A 0x09)............................................................................................ 304
32.16.5 UBX-MON-IO (0x0A 0x02)............................................................................................... 305
32.16.6 UBX-MON-MSGPP (0x0A 0x06).................................................................................... 306
32.16.7 UBX-MON-PATCH (0x0A 0x27)...................................................................................... 306
32.16.8 UBX-MON-RXBUF (0x0A 0x07)...................................................................................... 308
32.16.9 UBX-MON-RXR (0x0A 0x21)............................................................................................ 308
32.16.10 UBX-MON-SMGR (0x0A 0x2E)..................................................................................... 309
32.16.11 UBX-MON-TXBUF (0x0A 0x08)...................................................................................... 312
32.16.12 UBX-MON-VER (0x0A 0x04).......................................................................................... 313
32.17 UBX-NAV (0x01)......................................................................................................................... 314
32.17.1 UBX-NAV-AOPSTATUS (0x01 0x60).............................................................................. 314
32.17.2 UBX-NAV-ATT (0x01 0x05).............................................................................................. 315
32.17.3 UBX-NAV-CLOCK (0x01 0x22)......................................................................................... 316
32.17.4 UBX-NAV-DGPS (0x01 0x31)............................................................................................ 316
32.17.5 UBX-NAV-DOP (0x01 0x04).............................................................................................. 317
32.17.6 UBX-NAV-EOE (0x01 0x61)............................................................................................... 318
32.17.7 UBX-NAV-GEOFENCE (0x01 0x39)................................................................................. 318
32.17.8 UBX-NAV-HPPOSECEF (0x01 0x13)............................................................................... 319
32.17.9 UBX-NAV-HPPOSLLH (0x01 0x14)................................................................................. 320
32.17.10 UBX-NAV-ODO (0x01 0x09)............................................................................................ 321
32.17.11 UBX-NAV-ORB (0x01 0x34)............................................................................................ 322
32.17.12 UBX-NAV-POSECEF (0x01 0x01).................................................................................. 325
32.17.13 UBX-NAV-POSLLH (0x01 0x02).................................................................................... 325
32.17.14 UBX-NAV-PVT (0x01 0x07)............................................................................................ 326
32.17.15 UBX-NAV-RELPOSNED (0x01 0x3C)........................................................................... 329
32.17.16 UBX-NAV-RESETODO (0x01 0x10)................................................................................ 331
32.17.17 UBX-NAV-SAT (0x01 0x35)............................................................................................. 331
32.17.18 UBX-NAV-SBAS (0x01 0x32)......................................................................................... 333
32.17.19 UBX-NAV-SLAS (0x01 0x42)......................................................................................... 334
32.17.20 UBX-NAV-SOL (0x01 0x06)........................................................................................... 336
32.17.21 UBX-NAV-STATUS (0x01 0x03).................................................................................... 337
32.17.22 UBX-NAV-SVINFO (0x01 0x30).................................................................................... 340
32.17.23 UBX-NAV-SVIN (0x01 0x3B)......................................................................................... 342
32.17.24 UBX-NAV-TIMEBDS (0x01 0x24)................................................................................. 343
32.17.25 UBX-NAV-TIMEGAL (0x01 0x25)................................................................................. 344
32.17.26 UBX-NAV-TIMEGLO (0x01 0x23)................................................................................. 345
UBX-13003221 - R17

Early Production Information

Page xii

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.27 UBX-NAV-TIMEGPS (0x01 0x20)................................................................................. 346
32.17.28 UBX-NAV-TIMELS (0x01 0x26).................................................................................... 347
32.17.29 UBX-NAV-TIMEUTC (0x01 0x21).................................................................................. 349
32.17.30 UBX-NAV-VELECEF (0x01 0x11).................................................................................. 350
32.17.31 UBX-NAV-VELNED (0x01 0x12)..................................................................................... 351
32.18 UBX-RXM (0x02)....................................................................................................................... 352
32.18.1 UBX-RXM-IMES (0x02 0x61)............................................................................................ 352
32.18.2 UBX-RXM-MEASX (0x02 0x14)....................................................................................... 355
32.18.3 UBX-RXM-PMREQ (0x02 0x41)...................................................................................... 356
32.18.4 UBX-RXM-RAWX (0x02 0x15)......................................................................................... 358
32.18.5 UBX-RXM-RLM (0x02 0x59)........................................................................................... 365
32.18.6 UBX-RXM-RTCM (0x02 0x32)........................................................................................ 367
32.18.7 UBX-RXM-SFRBX (0x02 0x13)........................................................................................ 368
32.18.8 UBX-RXM-SVSI (0x02 0x20)........................................................................................... 369
32.19 UBX-SEC (0x27)......................................................................................................................... 371
32.19.1 UBX-SEC-UNIQID (0x27 0x03)......................................................................................... 371
32.20 UBX-TIM (0x0D) ....................................................................................................................... 372
32.20.1 UBX-TIM-DOSC (0x0D 0x11)............................................................................................ 372
32.20.2 UBX-TIM-FCHG (0x0D 0x16).......................................................................................... 372
32.20.3 UBX-TIM-HOC (0x0D 0x17)............................................................................................. 373
32.20.4 UBX-TIM-SMEAS (0x0D 0x13)....................................................................................... 374
32.20.5 UBX-TIM-SVIN (0x0D 0x04)........................................................................................... 376
32.20.6 UBX-TIM-TM2 (0x0D 0x03)............................................................................................ 377
32.20.7 UBX-TIM-TOS (0x0D 0x12)............................................................................................. 378
32.20.8 UBX-TIM-TP (0x0D 0x01)............................................................................................... 380
32.20.9 UBX-TIM-VCOCAL (0x0D 0x15)..................................................................................... 382
32.20.10 UBX-TIM-VRFY (0x0D 0x06)........................................................................................ 384
32.21 UBX-UPD (0x09)........................................................................................................................ 386
32.21.1 UBX-UPD-SOS (0x09 0x14).............................................................................................. 386
33 RTCM Protocol ....................................................................................................................................... 389
33.1 RTCM2.......................................................................................................................................... 389
33.1.1 Introduction.......................................................................................................................... 389
33.1.2 Supported Messages......................................................................................................... 389
33.1.3 Configuration....................................................................................................................... 389
33.1.4 Output................................................................................................................................... 389
33.1.5 Restrictions.......................................................................................................................... 390
33.1.6 Reference.............................................................................................................................. 390
33.2 RTCM version 3.......................................................................................................................... 390
33.2.1 Introduction.......................................................................................................................... 390
33.2.2 Supported Messages ......................................................................................................... 391
33.2.3 u-blox Proprietary RTCM Messages............................................................................... 392
33.2.4 Configuration ...................................................................................................................... 392
33.2.5 Output .................................................................................................................................. 393
UBX-13003221 - R17

Early Production Information

Page xiii

u-blox 8 / u-blox M8 Receiver Description - Manual

33.2.6 Reference............................................................................................................................. 393
Appendix............................................................................................................................................................... 394
A Satellite Numbering................................................................................................................................ 394
B UBX and NMEA Signal Identifiers....................................................................................................... 394
C u-blox 8 / u-blox M8 Default Settings ............................................................................................... 394
C.1 Antenna Supervisor Settings (UBX-CFG-ANT)...................................................................... 394
C.2 Data Batching Settings (UBX-CFG-BATCH) .......................................................................... 395
C.3 Datum Settings (UBX-CFG-DAT) ............................................................................................. 395
C.4 Geofencing Settings (UBX-CFG-GEOFENCE) ........................................................................ 395
C.5 High Navigation Rate Settings (UBX-CFG-HNR)................................................................... 396
C.6 GNSS System Settings (UBX-CFG-GNSS) ............................................................................. 396
C.7 INF Messages Settings (UBX-CFG-INF).................................................................................. 396
C.7.1 UBX Protocol........................................................................................................................... 396
C.7.2 NMEA Protocol...................................................................................................................... 397
C.8 Jammer/Interference Monitor Settings (UBX-CFG-ITFM).................................................. 397
C.9 Logging Settings (UBX-CFG-LOGFILTER).............................................................................. 397
C.10 Navigation Settings (UBX-CFG-NAV5).................................................................................. 397
C.11 Navigation Settings (UBX-CFG-NAVX5)................................................................................ 398
C.12 NMEA Protocol Settings (UBX-CFG-NMEA)......................................................................... 399
C.13 Odometer Settings (UBX-CFG-ODO)..................................................................................... 400
C.14 Power Management 2 Configuration (UBX-CFG-PM2)...................................................... 400
C.15 Port Configuration (UBX-CFG-PRT)........................................................................................ 401
C.15.1 UART Port Configuration.................................................................................................... 401
C.15.2 USB Port Configuration...................................................................................................... 401
C.15.3 SPI Port Configuration....................................................................................................... 402
C.15.4 DDC Port Configuration..................................................................................................... 402
C.16 Output Rate Settings (UBX-CFG-RATE)............................................................................... 402
C.17 Remote Inventory Settings (UBX-CFG-RINV)....................................................................... 403
C.18 Receiver Manager Configuration Settings (UBX-CFG-RXM)............................................ 403
C.19 SBAS Configuration Settings (UBX-CFG-SBAS)................................................................. 403
C.20 Timepulse Settings (UBX-CFG-TP5) ..................................................................................... 403
C.21 USB Settings (UBX-CFG-USB)................................................................................................. 404
Related Documents .......................................................................................................................................... 405
Overview .......................................................................................................................................................... 405
Revision History ................................................................................................................................................. 406
Contact ................................................................................................................................................................. 407
u-blox Offices.................................................................................................................................................. 407

UBX-13003221 - R17

Early Production Information

Page xiv

u-blox 8 / u-blox M8 Receiver Description - Manual

Preface
1 Document Overview
The Interface Description Including Receiver Description is an important resource for integrating
and configuring u-blox receivers. This document has a modular structure and it is not necessary
to read it from the beginning to the end. There are two main sections: The Receiver Description
and the Interface Description.
The Receiver Description describes the software aspects of system features and configuration of
u-blox receivers. The Receiver Description is structured according to areas of functionality, withlinks provided to the corresponding NMEA and UBX messages, which are described in theInterface Description.
The Interface Description is a reference describing the messages used by the u-blox receiver andis organized by the specific NMEA, UBX, and RTCM messages.
This document provides general information on u-blox receivers. Some information
might not apply to certain products. Refer to the product Data Sheet and/or Hardware
Integration Manual for possible restrictions or limitations.

2 Firmware and Protocol Versions
The protocol version defines a set of messages that are applicable across various u-blox products.
Each firmware used by a u-blox receiver supports a specific protocol version, which is notconfigurable.
The following sections will explain how to decode the shown information to get the firmware andthe protocol version.

2.1 How to Determine the Version and the Location of the Firmware
The u-blox receiver contains a firmware in two different locations:• Internal ROM• External Flash memory
The location and the version of the currently running firmware can be found in the boot screen orin the UBX-MON-VER message.
For firmware supporting Protocol Version 17 and below:• Boot screen, Protocol Version 17 and below• UBX-MON-VER, Protocol Version 17 and below
For firmware supporting Protocol Version from 18 to 23.01:• Boot screen, Protocol Version from 18 to 23.01• UBX-MON-VER, Protocol Version 18 to 23.01
2.1.1 Decoding the Boot Screen (for Protocol Version 17 and Below)
Boot screen for a u-blox receiver running from ROM:UBX-13003221 - R17

Early Production Information

Page 1 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Boot screen for a u-blox receiver running from Flash:Not every line is output by every u-blox receiver in the boot screen. This depends on the
product, the firmware location and the firmware version.
Possible lines in the boot screen and their meanings:
Entry

Description

u-blox AG - www.u-blox.com
HW UBX-M80xx 00800000
ROM CORE 2.01 (75331)
Oct 29 2013 13:28:17
EXT CORE 2.01 (75350)
Oct 29 2013 16:15:41
ROM BASE 2.01 (75331)
Oct 29 2013 13:28:17
PROTVER 15.00
GNSS OTP: GPS GLO,
SEL: GPS GLOANTSUPERV=AC SD PDoS SR

Start of the boot screen
Hardware version of the u-blox receiver (u-blox M8 receiver)Firmware version 2.01 running fromROM (revision number)compilation date/timeFirmware version 2.01 running fromFlash (revision number)compilation date/time
Underlying firmware version 2.01 inROM (revision number)compilation date/time
Supported protocol version
Default Major GNSS selection.
Current Major GNSS selection.
Configuration of the Antenna supervisor where
AC: Active Antenna Control enabled
SD: Short Circuit Detection enabledOD: Open Circuit Detection enabled
PDoS: Short Circuit Power Down Logic enabled
SR: Automatic Recovery from Short state
Low-level configuration of the u-blox receiver.

LLC FFFFFFFF-FF7F7C3FFFFFFF96-FFFFFFFF-FFFFFF79
FIS 0xEF4015 (100111) found Flash Information Structure (FIS) file for Flash memory withJEDEC 0xEF4015 found in the external flash memory. Revision
number of the file is indicated in brackets.
UBX-13003221 - R17

Early Production Information

Page 2 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Possible lines in the boot screen and their meanings: continued
Entry

Description

RF0 dev ok

RF channel 0 configured correctly.

The line containing the CORE indicates which version of the firmware is currently running.
The firmware is running either from ROM (indicated with ROM CORE) or from external
Flash memory (indicated with EXT CORE).
The line containing the CORE is called firmware string in the rest of the document.
2.1.2 Decoding the Boot Screen (for Protocol Version from 18 to 23.01)
Boot screen for a u-blox receiver running from ROM:

Boot screen for a u-blox receiver running from Flash:Not every line is output by every u-blox receiver in the boot screen. This depends on the
product, the firmware location and the firmware version.
Possible lines in the boot screen and their meanings:
Entry

Description

u-blox AG - www.u-blox.com
HW UBX-M8030 00800000
HW UBX-G8020 00800000
ROM CORE 3.01 (107888)
EXT CORE 3.01 (107900)
ROM BASE 3.01 (107888)

Start of the boot screen
Hardware version of the u-blox receiver (u-blox M8 receiver)Hardware version of the u-blox receiver (u-blox 8 receiver)Firmware version 3.01 running fromROM (revision number)
Firmware version 3.01 running fromFlash (revision number)
Underlying firmware version 3.01 inROM (revision number)

UBX-13003221 - R17

Early Production Information

Page 3 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Possible lines in the boot screen and their meanings: continued
Entry

Description

FWVER=SPG 3.01

Firmware of product category and version where
SPG: Firmware of Standard Precision GNSS product
HPG: Firmware of High Precision GNSS product
ADR: Firmware of ADR product
UDR: Firmware of UDR product
TIM: Firmware of Time Sync product
FTS: Firmware of Time & Frequency Sync productSupported protocol version
Module identification. Set in production.
Flash Information Structure (FIS) file for Flash memory withJEDEC 0xEF4015 found in the external flash memory. Revision
number of the file is indicated in brackets.
Supported Major GNSS.
Supported Augmentation systems.
Default Major GNSS selection.
Low-level configuration of the u-blox receiver.

PROTVER=18.00
MOD=NEO-M8N-0
FIS=0xEF4015 (100111)

GPS;GLO;GAL;BDS
SBAS;IMES;QZSSGNSS OTP=GPS;GLO
LLC FFFFFFFF-FFFFFFFFFFFFFFFF-FFFFFFFF-FFCFFFFF
ANTSUPERV=AC SD PDoS SR

PF=3FF

Configuration of the Antenna supervisor where
AC: Active Antenna Control enabled
SD: Short Circuit Detection enabledOD: Open Circuit Detection enabled
PDoS: Short Circuit Power Down Logic enabled
SR: Automatic Recovery from Short state
Product configuration.

The line containing the FWVER indicates which version of the firmware is currently
running and is called firmware version in the rest of the document.
The numbers in parentheses (revision numbers) should only be used to identify a known
firmware version and are not guaranteed to increase over time.
2.1.3 Decoding the output of UBX-MON-VER (for Protocol Version 17 and below)

UBX-13003221 - R17

Early Production Information

Page 4 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Possible fields in UBX-MON-VER and their meanings:
Entry

Description

Software Version

Currently running firmware version.
If no firmware version is shown in the first line of Extension(s),then the u-blox receiver runs from ROM.
If a firmware version is shown in the first line of Extension(s),then the u-blox receiver runs from Flash.
The hardware version of the u-blox receiver.
Extended information about the u-blox receiver firmware. See
table below for the entries.

Hardware Version
Extension(s)Not every entry is output by every u-blox receiver in the UBX-MON-VER extensions. Thisdepends on the product, the firmware location and the firmware version.
Possible entries in UBX-MON-VER Extension(s):EntryDescription

2.01 (75331)

Underlying firmware version in ROM.
If such an entry is present, then the u-blox receiver runs from
Flash.
Supported protocol version.
Flash Information Structure (FIS) file for Flash memory withJEDEC 0xEF4015 found in the external flash memory. Revision
number of the file is indicated in brackets.
Module identification. Set in production.
Supported GNSS.

PROTVER 15.00
FIS 0xEF4015 (100111)

MOD NEO-M8N-0
GPS;SBAS;GLO;BDS;QZSSUBX-13003221 - R17

Early Production Information

Page 5 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

2.1.4 Decoding the output of UBX-MON-VER (for Protocol Version from 18 and 23.01)

Possible fields in UBX-MON-VER and their meanings:
Entry

Description

Software Version
ROM CORE 3.01 (107888)
EXT CORE 3.01 (107900)
Hardware Version
Extension(s)Currently running firmware version.
If ROM CORE, then the u-blox receiver runs from ROM.
If EXT CORE, then the u-blox receiver runs from Flash.
The hardware version of the u-blox receiver.
Extended information about the u-blox receiver firmware. See
table below for the entries.

Not every entry is output by every u-blox receiver in the UBX-MON-VER extensions. Thisdepends on the product, the firmware location and the firmware version.
Possible entries in UBX-MON-VER Extension(s):EntryDescription

ROM BASE 3.01 (107888)

Underlying firmware version in ROM.
If such an entry is present, then the u-blox receiver runs from
Flash.
Firmware of product category and version where
SPG: Firmware of Standard Precision GNSS product
HPG: Firmware of High Precision GNSS product
ADR: Firmware of ADR product
UDR: Firmware of UDR product
TIM: Firmware of Time Sync product
FTS: Firmware of Time & Frequency Sync productSupported protocol version.
Module identification. Set in production.

FWVER=SPG 3.01

PROTVER=18.00
MOD=NEO-M8N-0

UBX-13003221 - R17

Early Production Information

Page 6 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Possible entries in UBX-MON-VER Extension(s): continued
Entry

Description

FIS=0xEF4015 (100111)

Flash Information Structure (FIS) file for Flash memory withJEDEC 0xEF4015 found in the external flash memory. Revision
number of the file is indicated in brackets.
Supported Major GNSS.
Supported Augmentation systems.

GPS;GLO;GAL;BDS
SBAS;IMES;QZSS

2.2 How to Determine the Supported Protocol Version of the u-blox Receiver
Each u-blox receiver reports its supported protocol version in the following ways:• On start-up in the boot screen• In the UBX-MON-VER message
with the line containing PROTVER (example: PROTVER=18.00).
Additionally, the firmware string, together with the firmware version, can be used to look up thecorresponding protocol version. The tables below give an overview of the released firmware andtheir corresponding protocol versions.
2.2.1 u-blox 8 / u-blox M8 Firmware and Supported Protocol Versions
Firmware for Standard Precision GNSS products
Firmware version

Firmware string

Protocol Version

SPG 2.01
SPG 2.01
SPG 3.01
SPG 3.01
SPG 3.50
SPG 3.51
SPG 3.51

ROM CORE 2.01 (75331) Oct 29 2013 13:28:17
EXT CORE 2.01 (75350) Oct 29 2013 16:15:41
ROM CORE 3.01 (107888)
EXT CORE 3.01 (107900)
EXT CORE 3.50 (190461)
ROM CORE 3.51 (19dc23)
EXT CORE 3.51 (19dc23)

15.00
15.00
18.00
18.00
23.00
23.01
23.01

Firmware for High Precision GNSS Products
Firmware version

Firmware string

Protocol Version

HPG 1.00
HPG 1.11
HPG 1.20
HPG 1.30
HPG 1.40

EXT CORE 3.01 (111160)
EXT CORE 3.01 (b8bc67)
EXT CORE 3.01 (d34ed4)
EXT CORE 3.01 (d080e3)
EXT CORE 3.01 (db0c89)

20.00
20.01
20.10
20.20
20.30

Firmware for Dead Reckoning products
Firmware version

Firmware string

ADR 3.00
ADR 3.10

EXT CORE 2.01 (77076) Dec 18 2013 09:40:24 ADR 3.00
EXT CORE 2.01 (87683) Nov 21 2014 14:03:10 ADR 3.10
M8L
EXT CORE 2.01 (89981) Jan 20 2015 17:22:06 ADR 3.11
M8L
EXT CORE 3.01 (16559bf) Apr 21 2016 15:49:07 ADR 4.00
EXT CORE 3.01 (c0c787c) Apr 24 2017 17:31:42 ADR 4.10
EXT CORE 3.01 (d189ff) Aug 22 2017 14:40:05 ADR 4.11

ADR 3.11
ADR 4.00
ADR 4.10
ADR 4.11

UBX-13003221 - R17

Protocol Version

Early Production Information

15.00
15.01
15.01
19.00
19.10
19.10

Page 7 of 407

u-blox 8 / u-blox M8 Receiver Description - ManualFirmware for Dead Reckoning products continued
Firmware version

Firmware string

ADR 4.21
UDR 1.00
UDR 1.21

EXT CORE 3.01 (3620e2)
EXT CORE 3.01 (16559bf) Apr 21 2016 15:50:59 UDR 1.00
EXT CORE 3.01 (3620e2)

Protocol Version

19.20
19.00
19.20

Firmware for Timing products
Firmware version

Firmware string

FTS 1.01
TIM 1.00
TIM 1.01
TIM 1.02
TIM 1.10

EXT CORE 2.20 (81289) May 14 2014 14:11:24
EXT CORE 2.30 (85522) Sep 29 2014 09:40:12
EXT CORE 2.30 (86283) Oct 20 2014 13:51:49
EXT CORE 2.30 (93796) Apr 8 2015 15:53:38
EXT CORE 3.01 (111141)

UBX-13003221 - R17

Protocol Version

Early Production Information

16.00
17.00
17.00
17.00
22.00

Page 8 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Receiver Description
3 Receiver Configuration
3.1 Configuration Concept
u-blox receivers are fully configurable with UBX protocol configuration messages (message class
UBX-CFG). The configuration used by the u-blox receiver during normal operation is termed"Current Configuration". The Current Configuration can be changed during normal operation bysending any UBX-CFG-XXX message to the u-blox receiver over an I/O port. The u-blox receiver willchange its Current Configuration immediately after receiving the configuration message. The ublox receiver always uses only the Current Configuration.
Unless the Current Configuration is made permanent by using UBX-CFG-CFG as described below,
the Current Configuration will be lost when there is:• a power cycle• a hardware reset• a (complete) controlled software reset
See the section on resetting a u-blox receiver for details.
The Current Configuration can be made permanent (stored in a non-volatile memory) by saving itto the "Permanent Configuration". This is done by sending a UBX-CFG-CFG message with anappropriate saveMask (UBX-CFG-CFG/save).
The Permanent Configuration is copied to the Current Configuration during start-up or when a
UBX-CFG-CFG message with an appropriate loadMask (UBX-CFG-CFG/load) is sent to the u-blox
receiver.
The Permanent Configuration can be restored to the u-blox receiver's Default Configuration bysending a UBX-CFG-CFG message with an appropriate clearMask (UBX-CFG-CFG/clear) to the ublox receiver. This only replaces the Permanent Configuration, not the Current Configuration. To
make the u-blox receiver operate with the Default Configuration which was restored to thePermanent Configuration, a UBX-CFG-CFG/load command must be sent or the u-blox receivermust be reset.
The mentioned masks (saveMask, loadMask, clearMask) are 4-byte bitfields. Every bit represents
one configuration sub-section. These sub-sections are defined in section "Organization of theConfiguration Sections". All three masks are part of every UBX-CFG-CFG message. Save, load andclear commands can be combined in the same message. Order of execution is: clear, save, load.
The following diagram illustrates the process:

UBX-13003221 - R17

Early Production Information

Page 9 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

It is possible to change the current communications port settings using a UBX-CFG-CFG message.
This could affect baud rate and other transmission parameters. Because there may be messages
queued for transmission there may be uncertainty about which protocol applies to suchmessages. In addition a message currently in transmission may be corrupted by a protocol
change. Host data reception parameters may have to be changed to be able to receive future
messages, including the acknowledge message associated with the UBX-CFG-CFG message.

3.2 Organization of the Configuration Sections
The configuration is divided into several sub-sections. Each of these sub-sections corresponds toone or several UBX-CFG-XXX messages. The sub-section numbers in the following tables
correspond to the bit position in the masks mentioned above. All values not listed are reserved
Configuration sub-sections
NumberName

CFG messages

Description0

PRT

Port and USB settings

1
2

MSG
INF

UBX-CFG-PRTUBX-CFG-USB
UBX-CFG-MSG
UBX-CFG-INF

3

NAV

4

RXM

9
10
11

RINV
ANT
LOG

UBX-13003221 - R17

Message settings (enable/disable, update rate)
Information output settings (Errors, Warnings, Notice,
Test etc.)
Settings for Navigation Parameters, Receiver Datum,
Measurement and Navigation Rate, SBAS, NMEA
protocol and Time mode (Timing products only)

UBX-CFG-NAV5UBX-CFG-NAVX5UBX-CFG-DATUBX-CFG-RATEUBX-CFG-SBASUBX-CFG-NMEAUBX-CFG-TMODE2UBX-CFG-GNSS
GNSS Settings, Power Mode Settings, Time Pulse
UBX-CFG-TP5
Settings, Jamming/Interference Monitor Settings
UBX-CFG-RXM
UBX-CFG-PM2
UBX-CFG-ITFM
UBX-CFG-RINV
Remote Inventory configuration
UBX-CFG-ANT
Antenna configuration
UBX-CFGLogging configuration
LOGFILTER

Early Production Information

Page 10 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Configuration sub-sections continued
NumberName

CFG messages

Description

12

FTS

UBX-CFG-DOSCUBX-CFG-ESRCUBX-CFG-SMGR

Disciplining configuration. Only applicable to the Time &Frequency Sync product.

3.3 Permanent Configuration Storage MediaThe Current Configuration is stored in the volatile RAM of the u-blox receiver. Hence, any changes
made to the Current Configuration without saving will be lost if any of the reset events listed in
the section above occur. By using UBX-CFG-CFG/save, the selected configuration sub-sections are
saved to all non-volatile memories available:• On-chip BBR (battery backed RAM). In order for the BBR to work, a backup battery must be
applied to the u-blox receiver.
• External flash memory, where available.

3.4 u-blox Receiver Default Configuration
The Permanent Configuration can be reset to Default Configuration through a UBX-CFG-CFG/clear
message. The Default Configuration of the u-blox receiver is normally determined when the u-blox
receiver is manufactured. Refer to specific product data sheet for further details.

3.5 Save-on-Shutdown Feature
The save-on-shutdown feature (SOS) enables the u-blox receiver to store the contents of thebattery-backed RAM to external flash memory and restore it upon startup. This allows the u-blox
receiver to preserve some of the features available only with a battery backup (preserving
configuration and satellite orbit knowledge) without having a battery backup supply present. It
does not, however, preserve any kind of time knowledge. The save-on-shutdown must becommanded by the host. The restore-on-startup is automatically done if the corresponding data
is present in the flash. No expiration check of the data is done.
The following outlines the suggested shutdown procedure when using the save-on-shutdown
feature:• With the UBX-CFG-RST message, the host commands the u-blox receiver to stop, specifying
reset mode 0x08 ("Controlled GNSS stop") and a BBR mask of 0 ("Hotstart").
• The u-blox receiver confirms the reception of a valid / invalid request with a UBX-ACK-ACK / UBXACK-NAK message.
• The host commands the saving of the contents of BBR to the flash memory using the UBX-UPDSOS-BACKUP message.
• The u-blox receiver confirms the reception of a valid / invalid request with a UBX-ACK-ACK / UBXACK-NAK message.
• For a valid request the u-blox receiver reports on the success of the backup operation with a UBXUPD-SOS-ACK message.
• The host powers off the u-blox receiver.
And consequently the startup procedure is as follows:• The host powers on the u-blox receiver.
• The u-blox receiver detects the previously stored data in flash. It restores the corresponding
UBX-13003221 - R17

Early Production Information

Page 11 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

memory and reports the success of the operation with a UBX-UPD-SOS-RESTORED message on
the port it had received the save command message (if the output protocol filter on that port
allows it). It does not report anything if no stored data has been detected.
• Additionally the u-blox receiver outputs a UBX-INF-NOTICE and/or a NMEA-TXT message withthe contents RESTORED in the boot screen (depends on port and information messages
configuration) upon success.
• Optionally the host can deliver coarse time assistance using UBX-MGA-INI-TIME_UTC for better
startup performance.
Once the u-blox receiver has started up it is suggested to delete the stored data using a UBX-UPDSOS-CLEAR message. The u-blox receiver responds with a UBX-ACK-ACK or UBX-ACK-NAK message.
Note that this feature must not be used with Power Save Mode and that saved data
must be deleted before switching to that mode.

4 Concurrent GNSS
Many u-blox positioning modules and chips are multi-GNSS receivers capable of receiving andprocessing signals from multiple Global Navigation Satellite Systems (GNSS).
u-blox concurrent GNSS receivers are multi-GNSS receivers that can acquire and track satellites
from more than one GNSS system at the same time, and utilize them in positioning.

4.1 GNSS Types
u-blox receivers support a wide range of different GNSS. Some GNSS have large numbers ofsatellites deployed globally and therefore are generally capable of providing navigation solutions
on their own. u-blox designates these as "major GNSS". By contrast, some are designed to be used
to enhance the use of one or more major GNSS and u-blox designates these "augmentation
systems".
In many cases, such as Satellite Numbering, this distinction does not matter as u-blox receivers
generally try to combine information from all available GNSS to create the best possible
navigation information. However, particularly in relation to configuring the receiver, the distinction
can be important.
4.1.1 Major GNSS
The major GNSS supported by u-blox receivers are described below.
4.1.1.1 GPS
The Global Positioning System (GPS) is a GNSS operated by the US department of defense. Its
purpose is to provide position, velocity and time for civilian and defense users on a global basis.
The system currently consists of 32 medium earth orbit satellites and several ground control
stations.
4.1.1.2 GLONASSGLONASS is a GNSS operated by Russian Federation department of defense. Its purpose is toprovide position, velocity and time for civilian and defense users on a global basis. The system
consists of 24 medium earth orbit satellites and ground control stations.
It has a number of significant differences when compared to GPS. In most cases, u-blox receivers
operate in a very similar manner when they are configured to use GLONASS signals instead of

UBX-13003221 - R17

Early Production Information

Page 12 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GPS. However some aspects of receiver output are likely to be noticeably affected.
4.1.1.3 Galileo
At the time of writing (early 2018), the Galileo system was still under development with
only a few fully operational SVs. Therefore, the precise performance and reliability of ublox receivers when receiving Galileo signals is effectively impossible to guarantee.
Galileo is a GNSS operated by the European Union. Its purpose is to provide position, velocity andtime for civilian users on a global basis. The system is currently not fully operational. It iseventually expected to consist of 30 medium earth orbit satellites.
On u-blox M8 receivers a maximum of ten channels can be assigned to Galileo for signal
acquisition and tracking. Note that at most eight Galileo satellites will be used for navigation. It is
recommended not to set the number of Galileo channels higher than eight in UBX-CFG-GNSS.
4.1.1.3.1 Search and Rescue Return Link Message
The receiver supports reception and output of Search and Rescue (SAR) Return Link Messages(RLM). When enabled, a UBX-RXM-RLM message will be generated whenever an RLM is detected by
the receiver.
At the time of writing (early 2018), no live transmission of RLMs by Galileo SVs had been
observed, so the details of their use was impossible to verify completely.
4.1.1.4 BeiDou
BeiDou is a GNSS operated by China. Its purpose is to initially provide position, velocity and time
for users in Asia. In a later stage when the system is fully deployed it will have worldwide coverage.
The full system will consist of five geostationary, five inclined geosynchronous and 27 medium
earth orbit satellites, as well as control, upload and monitoring stations. Although this implies afull constellation of 37 SVs, only SVs numbered 1 to 30 are fully supported in the D1/D2 NAV
message described by the Interface Control Document version 2.0. For SVs numbered above 30,
there is currently no almanac or differential correction. Consequently, u-blox receivers only use
BeiDou SVs numbered 1 to 30.
4.1.2 Augmentation Systems
The augmentation systems supported by u-blox receivers are described below.
4.1.2.1 SBAS
There are a number of Space Based Augmentation Systems (SBAS) operated by different
countries using geostationary satellites. u-blox receivers currently support the following:• WAAS (Wide Area Augmentation System) operated by the US.
• EGNOS (European Geostationary Navigation Overlay Service) operated by the EU.
• MSAS (Multi-functional Satellite Augmentation System) operated by Japan.
• GAGAN (GPS Aided Geo Augmented Navigation) operated by India.
See section SBAS for more details.
4.1.2.2 QZSSThe Quasi Zenith Satellite System (QZSS) is a regional satellite augmentation system operated
by Japan Aerospace Exploration Agency (JAXA). It is intended as an enhancement to GPS, toincrease availability and positional accuracy. The QZSS system achieves this by transmitting
UBX-13003221 - R17

Early Production Information

Page 13 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GPS-compatible signals in the GPS bands.
NMEA messages will show the QZSS satellites only if configured to do so (see section Satellite
Numbering).
The QZSS L1SAIF is an additional signal broadcast by QZSS satellites that contains
augmentation and other data.
4.1.2.3 IMESThe Indoor MEssaging System (IMES) is an extension to the QZSS specification.
See section IMES for more details.

4.2 Configuration
The UBX-CFG-GNSS message allows the user to specify which GNSS signals should be processedalong with limits on how many tracking channels should be allocated to each GNSS. The receiverwill respond to such a request with a UBX-ACK-ACK message if it can support the requested
configuration or a UBX-ACK-NAK message if not.
Customers enabling BeiDou and/or Galileo who wish to use the NMEA protocol arerecommended to select NMEA version 4.1, as earlier versions have no support for thesetwo GNSS. See the NMEA protocol section for details on selecting NMEA versions.
The combinations of systems which can be configured simultaneously depends on the receivers
capability to receive several carrier frequencies. The UBX-MON-GNSS message reports which major
GNSS can be selected. Please refer to the data sheet of the corresponding u-blox receiver for full
information. Usually GPS, SBAS (e.g. WAAS, EGNOS, MSAS), QZSS and Galileo can be enabled
together, because they all use the 1575.42MHz L1 frequency. GLONASS and BeiDou both operateon different frequencies, therefore the receiver must be able to receive a second or even third
carrier frequency in order to process these systems together with GPS.
It is recommended to disable GLONASS and BeiDou if a GPS-only antenna or GPS-only
SAW filter is used.
In all circumstances, it is necessary for at least one major GNSS to be enabled. It is also requiredthat at least 4 tracking channels are available to each enabled major GNSS, i.e. maxTrkCh musthave a minimum value of 4 for each enabled major GNSS. Further requirements on generating
configurations acceptable by the receiver can be found in UBX-CFG-GNSS.
4.2.1 Switching between GNSS
Users should be aware that switching between GNSS (and especially away from GPS) may affectthe long term accuracy of the receiver until the next cold start. In normal operation the receiver
selects the best models and corrections from the transmitted auxiliary data (e.g. UTC andIonospheric parameters), basing this selection on the configured GNSS. Disabling a major GNSS
prevents auxiliary data from that GNSS being refreshed and so it will become stale, resulting inprogressively degraded performance. This can occur even if the main power supply is removed, as
most receivers retain auxiliary data in non-volatile storage, e.g. Battery Backed RAM (BBR). For
this reason, u-blox recommends that receivers are cold started after any change that disables anactive GNSS, within a few weeks, but preferably immediately. This will ensure that the receiverthen uses only regularly refreshed information from the newly configured constellations.

UBX-13003221 - R17

Early Production Information

Page 14 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

4.2.2 Configuring QZSS L1SAIF
By default the receiver will be configured for QZSS L1C/A, this can be changed so the receiver canbe configured for QZSS L1SAIF also. See the table below forUBX-CFG-GNSS sigCfgMask settings
for signals on QZSS. For example, to enable QZSS L1C/A and QZSS L1SAIF, set thegnssId to 5
(for QZSS) and sigCfgMask to 0x05. If supported by the firmware, L1SAIF would then be enabled.
QZSS Signal configuration for UBX-CFG-GNSS
GnssIdDescription

Signal mask

5

QZSS

0x01 = QZSS L1C/A
0x04 = QZSS L1SAIF

5 SBAS Configuration Settings Description
5.1 SBAS (Satellite Based Augmentation Systems)
SBAS (Satellite Based Augmentation System) is an augmentation technology for GPS, whichcalculates GPS integrity and correction data with RIMS (Ranging and Integrity Monitoring
Stations) on the ground and uses geostationary satellites to broadcast GPS integrity andcorrection data to GPS users. The correction data is transmitted on the GPS L1 frequency (1575.42
MHz), and therefore no additional receiver is required to make use of the correction and integritydata.
u-blox receivers will only process corrections for GPS. Other corrections are not applied,even if, as planned, some SBAS satellites start to transmit them (e.g. SDCM for
GLONASS).
SBAS Principle

There are several compatible SBAS systems available or in development all around the world:

UBX-13003221 - R17

Early Production Information

Page 15 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• WAAS (Wide Area Augmentation System) for North America has been in operation since 2003.
• MSAS (Multi-Functional Satellite Augmentation System) for Japan has been in operation since
2007.
• EGNOS (European Geostationary Navigation Overlay Service) has been in operation since 2009.
• GAGAN (GPS Aided Geo Augmented Navigation), for India has been in operation since 2014.
• SDCM (System for Differential Corrections and Monitoring), for Russia is at the time of writing
in test mode.
Support of SBAS allows u-blox GPS technology to take full advantage of the augmentation
systems that are currently available (i.e. WAAS, EGNOS, MSAS, GAGAN). Signals from systems
currently being tested and/or planned (such as SDCM) may also work, when those systems
become fully operational, but this cannot be relied upon and u-blox receivers are not configured tosupport them by default.
With SBAS enabled, the user benefits from additional satellites for ranging (navigation). u-blox
GPS technology uses the available SBAS satellites for navigation just like GPS satellites, if the
SBAS satellites offer this service.
To improve position accuracy, SBAS uses different types of correction data:• Fast Corrections for short-term disturbances in GPS signals (due to clock problems, etc).
• Long-term corrections for GPS clock problems, broadcast orbit errors etc.
• Ionosphere corrections for Ionosphere activity
Another benefit of SBAS is the use of GPS integrity information. In this way SBAS control stations
can 'disable' the use of GPS satellites within a 6-second alarm time in case of major GPS satellite
problems. If integrity monitoring is enabled, u-blox GPS technology only uses satellites, for which
integrity information is available.
For more information on SBAS and associated services, refer to the following resources:• RTCA/DO-229D (MOPS). Available from www.rtca.org• gps.faa.gov for information on WAAS.
• www.esa.int for information on EGNOS.
• www.essp-sas.eu for information about European Satellite Services Provider (ESSP), the
EGNOS operations manager.
• www.isro.org for information on GAGAN.
• www.sdcm.ru for information on SDCM.
SBAS satellites tracked (as of November 2015)
Identification

Position

GPS PRN SBAS Provider

AMR
PanAmSat Galaxy XVTeleSat Anik F1R
Inmarsat 3F2 AOR-E
ArtemisInmarsat 3F5 IOR-W
MTSAT-1R
MTSAT-2
Inmarsat-4F1/IOR
GSAT-1098° W
133.0° W
107.3° W
15.5° W
21.5° W
25° E
140.1° E
145° E
64° E
83° E

133
135
138
120
124
126
129
137
127
128

UBX-13003221 - R17

Early Production Information

WAAS
WAAS
WAAS
EGNOS
EGNOS
EGNOS
MSAS
MSAS
GAGAN
GAGAN

Page 16 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

5.2 SBAS Features
This u-blox SBAS implementation is, in accordance with standard RTCA/DO-229D, aclass Beta-1 equipment. All timeouts etc. are chosen for the En Route Case. Do not use
this equipment under any circumstances for "safety of life" applications!
u-blox receivers are capable of receiving multiple SBAS signals concurrently, even from different
SBAS systems (WAAS, EGNOS, MSAS, etc.). They can be tracked and used for navigation
simultaneously. Every tracked SBAS satellite utilizes one vacant receiver tracking channel. Only
the number of receiver channels limits the total number of satellites used. Every SBAS satellitethat broadcasts ephemeris or almanac information can be used for navigation, just like a normal
GPS satellite.
For receiving correction data, the u-blox receiver automatically chooses the best SBAS satellite asits primary source. It will select only one since the information received from other SBAS satellites
is redundant and/or could be inconsistent. The selection strategy is determined by the proximityof the satellites, the services offered by the satellite, the configuration of the receiver (Testmodeallowed/disallowed, Integrity enabled/disabled) and the signal link quality to the satellite.
If corrections are available from the chosen SBAS satellite and used in the navigation calculation,
the DGPS flag is set in the receiver's output protocol messages (see UBX-NAV-PVT, UBX-NAV-SOL,UBX-NAV-STATUS, UBX-NAV-SVINFO, NMEA Position Fix Flags description). The message UBXNAV-SBAS provides detailed information about which corrections are available and applied.
The most important SBAS feature for accuracy improvement is Ionosphere correction. The
measured data from regional RIMS stations are combined to make a TEC (Total Electron Content)
Map. This map is transferred to the receiver via the satellites to allow a correction of theionosphere error on each received satellite.
Supported SBAS messages
Message Type

Message Content

Source0(0/2)
1
2, 3, 4, 5
6
7
9
10
12
17
18
24
25
26

Test Mode
PRN Mask Assignment
Fast Corrections
Integrity
Fast Correction Degradation
Satellite Navigation (Ephemeris)
Degradation
Time Offset
Satellite Almanac
Ionosphere Grid Point Assignment
Mixed Fast / Long term Corrections
Long term Corrections
Ionosphere Delays

All
Primary
Primary
Primary
PrimaryAll
Primary
PrimaryAll
Primary
Primary
Primary
Primary

Each satellite services a specific region and its correction signal is only useful within that region.
Planning is crucial to determine the best possible configuration, especially in areas where signals
from different SBAS systems can be received:
Example 1: SBAS Receiver in North America
In the eastern parts of North America, make sure that EGNOS satellites do not take preference
over WAAS satellites. The satellite signals from the EGNOS system should be disallowed by using
the PRN Mask.
UBX-13003221 - R17

Early Production Information

Page 17 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Example 2: SBAS Receiver in Europe
Some WAAS satellite signals can be received in the western parts of Europe, therefore it isrecommended that the satellites from all but the EGNOS system should be disallowed using the
PRN Mask.
Although u-blox receivers try to select the best available SBAS correction data, it isrecommended to configure them to disallow using unwanted SBAS satellites.
The EGNOS SBAS system does not provide the satellite ranging function.

5.3 SBAS Configuration
To configure the SBAS functionalities use the UBX proprietary message UBX-CFG-SBAS (SBAS
Configuration).
SBAS Configuration parameters
Parameter

Description

Mode - SBAS Subsystem

Enabled / Disabled status of the SBAS subsystem. To
enable/disable SBAS operation use UBX-CFG-GNSS. The field in
UBX-CFG-SBAS is no longer supported.
Allow / Disallow SBAS usage from satellites in Test Mode
(Message 0)
Use the SBAS satellites for navigation
Combined enable/disable switch for Fast-, Long-Term andIonosphere Corrections
Use integrity data

Mode - Allow test mode usage
Services/Usage - Ranging
Services/Usage - Apply SBAS
correction data
Services/Usage - Apply integrity
information
Number of tracking channels
PRN Mask

Should be set using UBX-CFG-GNSS. The field in UBX-CFG-SBAS
is no longer supported.
Allows selectively enabling/disabling SBAS satellites (e.g.
restrict SBAS usage to WAAS-only).

By default, SBAS is enabled with three prioritized SBAS channels and it will use any received SBAS
satellites (except for those in test mode) for navigation, ionosphere parameters and corrections.

6 QZSS L1S SLAS Configuration Settings Description
6.1 QZSS L1S SLAS (Sub-meter Level Augmentation Service)
The L1S signal was formerly known as L1SAIF.
QZSS SLAS (Sub-meter Level Augmentation Service) is an augmentation technology, which
provides correction data for pseudoranges of GPS and QZSS satellites (as of October 2017).
Ground monitoring stations (GMS) positioned in Japan calculate independent corrections for each
visible satellite and broadcast this data to the user via QZSS satellites. The correction stream istransmitted on the L1 frequency (1575.42 Mhz) and therefore no additional receiver is required tomake use of the correction data.
With QZSS SLAS enabled, u-blox receivers autonomously select the most suitable GMS based on
the user's location. The correction stream of this GMS will then be applied to the measurements inorder to improve position accuracy.
UBX-13003221 - R17

Early Production Information

Page 18 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Furthermore, QZSS SLAS provides the user with reports for disaster and crisis management (DCReports) from the Japan Meteorological Agency (JMA) and other sources. Those reports areprovided by UBX-RXM-SFRBX messages.
For more information on QZSS SLAS, refer to the Interface Document IS-QZSS-L1S-001 (March
28, 2017) issued by the Cabinet Office, available fromqzss.go.jp/en/.

6.2 QZSS L1S SLAS Features
Multiple SLAS signals can be tracked simultaneously. Only the number of receiver channels limits
the total number of satellites tracked.
The correction stream will be automatically detected from the most suitable ground monitoring
stations and QZSS satellites. The selection of the QZSS satellite is dependent on the quality ofthe signals and the receiver configuration to allow satellites in test mode. The GMS that is not
flagged as unhealthy and is closest to the user will be selected. If the distance to the closest GMS
exceeds 200 km, no corrections will be used. The receiver might then fall back to using SBAS
corrections. Changes of the most suitable GMS or QZSS satellite as well as transitions in theprovided correction data stream will be handled in the background leading to a continuous set ofcorrections for the navigation solution, if possible.
If corrections are available from the chosen QZSS satellite and used in the navigation calculation,
the DGNSS flag is set in the receiver's output protocol messages (see UBX-NAV-PVT, UBX-NAV-SOL,UBX-NAV-STATUS, UBX-NAV-SVINFO, NMEA Position Fix Flags description). The message UBXNAV-SLAS provides detailed information about which corrections are available and applied.
By setting the RAIM feature (see UBX-CFG-SLAS), the user can setup the receiver to provide
DGPS-only solutions or to mix corrected and uncorrected measurements.
If in UBX-CFG-SLAS the RAIM option is set, other GNSS time systems than the QZSS
time system can't be observed by measurements.
Supported QZSS L1S SLAS messages for navigation enhancing
Message Type

Message Content

0
47
48
49
50
51

Test Mode
Monitoring Station Information
PRN Mask
Data Issue Number
DGPS Correction
Satellite Health

6.3 QZSS L1S SLAS Configuration
To read and set the SLAS configurations use UBX-CFG-SLAS as follows:
QZSS L1S SLAS Configuration parameters
Parameter

Description

Mode - enabled
Mode - test

Apply QZSS SLAS corrections
Allow the correction provided by QZSS satellites that are in
test mode

UBX-13003221 - R17

Early Production Information

Page 19 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

QZSS L1S SLAS Configuration parameters continued
Parameter

Description

Mode - raim

If this configuration is set, the receiver will try to estimate theposition by using only corrected measurements; if all corrected
measurements are not available, it won't use any corrections. If
this configuration is not set, the receiver will mix corrected anduncorrected measurements for the navigation solution.

7 IMES Description
Indoor MEssaging System (IMES) is an extension to the QZSS specification using ground based
beacons that broadcast their location. Its purpose is to allow GNSS users to continue to navigate
inside buildings, when they can no longer reliably receive satellite based signals.
Operation of IMES beacons is only allowed within Japan.
u-blox receivers with IMES enabled conform to IS-QZSS v1.5and do not support v1.4 orearlier IMES signals. In particular, u-blox receivers rely on the IMES station's carrier
frequency being 1575.4282MHz ± 0.2ppm as specified in the IMES specification.
Transmissions from IMES stations that are not within this frequency range are unlikely
to be reliably received. Also the receiver expects the preamble 0x9E as well as the correct
sequence of CNT values as specified by the IS-QZSS.
u-blox receivers report the position information they receive from IMES transmitters directly withUBX-RXM-IMES. They do not, however, combine this information with navigation solutions derived
from satellite signals (reported via various NMEA and UBX-NAV messages). Consequently, theIMES position information may not always be consistent with satellite signal derived position
information.

7.1 IMES Features• 50/250bps Auto-Detection: Both 50bps and 250bps IMES signals are supported by u-blox
receivers. The transmitter's data rate is detected automatically which allows the receiver toeven work in a mixed 50bps/250bps IMES environment.
• Dynamic Tracking Channel Allocation: The allocation of the tracking channels is done
dynamically, in the same way that channels are allocated to other GNSS. If sufficient IMES
stations are within reach of the receiver, it will track as many signals as it can up to the value of
maxTrkCh configured in UBX-CFG-GNSS (8 by default). To reserve a certain number of channels
for IMES only (preventing them from being dynamically allocated to other GNSS), set the
resTrkCh field in UBX-CFG-GNSS accordingly.
• Data summary: A summary of all the tracked IMES signals and what position information they
are providing is given in the UBX-RXM-IMES message.
• Raw IMES frames: The raw IMES subframes received from the IMES stations are reported asthey are received with UBX-RXM-SFRBX messages.

8 Navigation Configuration Settings Description
This section relates to the configuration message UBX-CFG-NAV5.

UBX-13003221 - R17

Early Production Information

Page 20 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

8.1 Platform settings
u-blox receivers support different dynamic platform models (see table below) to adjust thenavigation engine to the expected application environment. These platform settings can bechanged dynamically without performing a power cycle or reset. The settings improve thereceiver'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.
Dynamic Platform Models
Platform

Description

Portable

Applications with low acceleration, e.g. portable devices. Suitable for mostsituations.
Used in timing applications (antenna must be stationary) or other stationary
applications. Velocity restricted to 0 m/s. Zero dynamics assumed.
Applications with low acceleration and speed, e.g. how a pedestrian would move.
Low acceleration assumed.
Used for applications with equivalent dynamics to those of a passenger car. Low
vertical acceleration assumed.
Recommended for applications at sea, with zero vertical velocity. Zero verticalvelocity assumed. Sea level assumed.
Used for applications with a higher dynamic range and greater verticalacceleration than a passenger car. No 2D position fixes supported.
Recommended for typical airborne environments. No 2D position fixes
supported.
Only recommended for extremely dynamic environments. No 2D position fixes
supported.
Only recommended for wrist worn applications. Receiver will filter out arm
motion. (just available for protocol version > 17)
Used for applications with equivalent dynamics to those of a motor bike. Low
vertical acceleration assumed.

Stationary
Pedestrian
Automotive
At seaAirborne <1g
Airborne <2g
Airborne <4g
Wrist
Bike

Dynamic Platform Model Details
Platform

Portable
Stationary
Pedestrian
Automotive
At seaAirborne <1g
Airborne <2g
Airborne <4g
Wrist
Bike

Max Altitude

MAX Horizontal

MAX Vertical[m]

Velocity [m/s]

Velocity [m/s]

12000
9000
9000
6000
500
50000
50000
50000
9000
6000

310
10
30
100
25
100
250
500
30
100

50
6
20
15
5
100
100
100
20
15

Sanity check typeMax Position
Deviation

Altitude and Velocity
Altitude and Velocity
Altitude and Velocity
Altitude and Velocity
Altitude and Velocity
Altitude
Altitude
Altitude
Altitude and Velocity
Altitude and Velocity

MediumSmall
Small
MediumMedium
Large
Large
Large
MediumMediumDynamic platforms designed for high acceleration systems (e.g. airborne <2g) can resultin a higher standard deviation in the reported position.

UBX-13003221 - R17

Early Production Information

Page 21 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

If a sanity check against a limit of the dynamic platform model fails, then the position
solution is invalidated. The table above shows the types of sanity checks which areapplied for a particular dynamic platform model.

8.2 Navigation Input Filters
The navigation input filters in UBX-CFG-NAV5 mask the input data of the navigation engine.
These settings are already optimized. Do not change any parameters unless advised byu-blox support engineers.
Navigation Input Filter parameters
Parameter

Description

fixModeBy 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.
fixedAlt and
The fixed altitude is used if fixMode is set to 2D only. A variance greater than
fixedAltVar
zero must also be supplied.
minElev
Minimum elevation of a satellite above the horizon in order to be used in thenavigation solution. Low elevation satellites may provide degraded accuracy,
due to the long signal path through the atmosphere.
cnoThreshNum A navigation solution will only be attempted if there are at least the given
SVs andnumber of SVs with signals at least as strong as the given threshold.
cnoThresh
See also comments in section Degraded Navigation below.

8.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 UBX-CFGNAV5. In particular, both PDOP and accuracy values must lie below the respective limits.
Valid fixes are marked using the valid flag in certain NMEA messages (see Position Fix Flags in
NMEA) and the gnssFixOK flag in UBX-NAV-PVT message.
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 normally be used.
The UBX-NAV-SOL and UBX-NAV-STATUS messages also report whether a fix is valid in
their gpsFixOK and GPSfixOk flags. These messages have only been retained forbackwards compatibility and users are recommended to use the UBX-NAV-PVT message
in preference.
The UBX-CFG-NAV5 message also defines TDOP and time accuracy values that are used in order toestablish whether a fix is regarded as locked to GNSS or not, and as a consequence of this, whichtime 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 UBX-CFG-TP5 will be used togenerate a time pulse.

UBX-13003221 - R17

Early Production Information

Page 22 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

8.3.1 Speed (3-D) Low-pass Filter
The UBX-CFG-ODO message offers the possibility to activate a speed (3-D) 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 UBX-CFG-ODO message (velLpGain field) and must be comprised
between 0 (heavy low-pass filtering) and 255 (weak low-pass filtering).
Strictly speaking, the internal filter gain is computed as a function of speed. Therefore,
the level as defined in the UBX-CFG-ODO message (velLpGain field) defines the nominal
filtering level for speeds below 5m/s.
8.3.2 Course over Ground Low-pass Filter
The UBX-CFG-ODO message offers the possibility to activate a course over ground low-pass filter
when the speed is below 8m/s. The output of the course over ground (also named heading of
motion 2-D) low-pass filter is published in the UBX-NAV-PVT message (headMot field), UBX-NAVVELNED message (heading field), NMEA-RMC message (cog field) and NMEA-VTG message (cogtfield). The filtering level can be set via the UBX-CFG-ODO message (cogLpGain field) and must becomprised between 0 (heavy low-pass filtering) and 255 (weak low-pass filtering).
The filtering level as defined in the UBX-CFG-ODO message (cogLpGain field) defines thefilter gain for speeds below 8m/s. If the speed is higher than 8m/s, no course over groundlow-pass filtering is performed.
8.3.3 Low-speed Course Over Ground Filter
The UBX-CFG-ODO message offers the possibility to activate a low-speed course over ground filter(also named heading of motion 2-D). This filter derives the course over ground from position atvery low speed. The output of the low-speed course over ground filter is published in the UBX-NAVPVT message (headMot field), UBX-NAV-VELNED message (heading field), NMEA-RMC message (cogfield) and NMEA-VTG message (cogt field). If the low-speed course over ground filter is not
activated or inactive, then the course over ground is computed as described in section Freezing
the Course Over Ground.

8.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 instationary 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 thevelocity is set to zero until there is evidence of movement again. Such evidence can be velocity,
acceleration, changes of the valid flag (e.g. position accuracy estimate exceeding the Position
Accuracy Mask, see also section Navigation Output Filters), position displacement, etc.
The UBX-CFG-NAV5 message additionally allows for configuration of distance threshold (fieldstaticHoldMaxDist). If the estimated position is farther away from the static hold position than
this threshold, static mode will be quit.

UBX-13003221 - R17

Early Production Information

Page 23 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

8.5 Freezing the Course Over GroundIf the low-speed course over ground filter is deactivated or inactive (see section Low-speed Course
over Ground Filter), the receiver derives the course over ground from the GNSS velocity
information. If the velocity cannot be calculated with sufficient accuracy (e.g., with bad signals) or
if the absolute speed value is very low (under 0.1m/s) then the course over ground value becomesinaccurate too. In this case the course over ground value is frozen, i.e. the previous value is kept
and its accuracy is degraded over time. These frozen values will not be output in the NMEA
messages NMEA-RMC and NMEA-VTG unless the NMEA protocol is explicitely configured to do so(see NMEA Protocol Configuration).

8.6 Degraded Navigation
Degraded navigation describes all navigation modes which use less than four Satellite Vehicles(SV).
8.6.1 2D Navigation
If the receiver only has three SVs for calculating a position, the navigation algorithm uses a
constant altitude to compensate for the missing fourth SV. When an SV is lost after a successful
3D fix (min. four SVs available), the altitude is kept constant at the last known value. This is calleda 2D fix.
u-blox receivers do not calculate any navigation solution with less than three SVs. Only ublox Timing products can calculate a timing solution with only one SV when they are instationary mode.

8.7 Geodetic Coordinate Systems and Ellipsoids
In order to have any useful meaning, the positions reported by a u-blox receiver must be
referenced to some coordinate system which defines the origin and, for example, which way is"up". For many reasons, including history, practical autonomy and politics, all the major GNSS
define their own theoretical coordinate systems from which they realize a practical reference
frame by means of a network of reference points. Specifically:• GPS uses WGS84• GLONASS uses PZ90
• Galileo uses GTRF
• BeiDou uses CGCS2000
In practice, the relevant organisations choose to keep their respective frames very close to theInternational Terrestrial Reference Frame (ITRF), defined and managed by the International Earth
Rotation and Reference Systems Service (IERS). However, because the Earth's tectonic plates andeven parts of the Earth's core move, new versions of ITRF are defined every few years, generallywith changes of the order of a few millimetres. Consequently, the major GNSS occasionally decidethat they need to update their reference frames to be better aligned to the latest ITRF. So, forexample, GPS switched to WGS84 (G1150) in GPS week 1150 (early 2002) based on ITRF2000, while
GLONASS switched from PZ90.02 to PZ90.11 at the end of 2013, based on ITRF2008. The net
effect of this, is that all the major GNSS use almost the same reference frame, but there are somesmall (generally sub-cm) differences between them and these differences occasionally change.
In order to produce positions that can be shown on a map, it is necessary to translate between raw
coordinates (e.g. x, y, z) and a position relative to the Earth's surface (e.g. latitude, longitude and

UBX-13003221 - R17

Early Production Information

Page 24 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

altitude) and that requires defining the form of ellipsoid that best matches the shape of the Earth.
Historically many different ellipsoid definitions have been used for maps, many of which predate
the existence of GNSS and show quite significant differences, leading to discrepencies of as muchas 100m in places. Fortunately, most digital maps now use the WGS84 ellipsoid, which is distinct
from the WGS84 coordinate system, but defined by the same body.
All u-blox receivers use (the current) version of WGS84 frame as their reference frame, carryingout any necessary corrections internally. What is more, by default, u-blox receivers use the
WGS84 ellipsoid and therefore all positions communicated from/to a u-blox receiver will be relative
to that. However, users can alter this by specifying their chosen geodetic datum parameters using
the UBX-CFG-DAT message. The table below indicates the values u-blox recommends for use.
Recommended UBX-CFG-DAT parameters
Ellipsoid

WGS84 (default)
PZ90
CGCS2000

majA

flat

dX

dY

dZ

rotX

rotY

rotZ

6378137.0 298.257223563 0.06378136.0 298.257839303 0.06378137.0 298.257227101 0.0

0.0
0.0
0.0

0.0
0.0
0.0

0.0
0.0
0.0

0.0
0.0
0.0

0.0
0.0
0.0

Where the receiver is configured to use differential correction data (e.g. via an RTCM
stream), as a direct consequence, the receiver's coordinate frame will switch to whateverframe the source of correction data is using.

9 Clocks and Time
9.1 Receiver Local TimeThe receiver is dependent on a local oscillator (normally a TCXO or Crystal oscillator) for both theoperation of its radio parts and also for timing within its signal processing. No matter what
nominal frequency the local oscillator has (e.g. 26 MHz), u-blox receivers subdivide the oscillator
signal to provide a 1 kHz reference clock signal, which is used to drive many of the receiver's
processes. In particular, the measurement of satellite signals is arranged to be synchronised withthe "ticking" of this 1 kHz clock signal.
When the receiver first starts, it has no information about how these clock ticks relate to othertime systems; it can only count time in 1 millisecond steps. However, as the receiver derives
information from the satellites it is tracking or from aiding messages, it estimates the time thateach 1 kHz clock tick takes in the time-base of the relevant GNSS system. In previous generationsof u-blox receivers this was always the GPS time-base, but for this generation it could be GPS,GLONASS, Galileo, or BeiDou. This estimate of GNSS time based on the local 1 kHz clock is calledreceiver local time.
As receiver local time is a mapping of the local 1 kHz reference onto a GNSS time-base, it may
experience occasional discontinuities, especially when the receiver first starts up and theinformation it has about the time-base is changing. Indeed after a cold start receiver local time will
initially indicate the length of time that the receiver has been running. However, when the receiverobtains some credible timing information from a satellite or aiding message, it will jump to an
estimate of GNSS time.

UBX-13003221 - R17

Early Production Information

Page 25 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

9.2 Navigation Epochs
Each navigation solution is triggered by the tick of the 1 kHz clock nearest to the desired
navigation solution time. This tick is referred to as a navigation epoch. If the navigation solution
attempt is successful, one of the results is an accurate measurement of time in the time-base of
the chosen GNSS system, called GNSS system time. The difference between the calculated
GNSS system time and receiver local time is called the clock bias (and the clock drift is the rate at
which this bias is changing).
In practice the receiver's local oscillator will not be as stable as the atomic clocks to which GNSS
systems are referenced and consequently clock bias will tend to accumulate. However, whenselecting the next navigation epoch, the receiver will always try to use the 1 kHz clock tick which it
estimates to be closest to the desired fix period as measured in GNSS system time. Consequently
the number of 1 kHz clock ticks between fixes will occasionally vary (so when producing one fix per
second, there will normally be 1000 clock ticks between fixes, but sometimes, to correct drift awayfrom GNSS system time, there will be 999 or 1001).
The GNSS system time calculated in the navigation solution is always converted to a time in boththe GPS and UTC time-bases for output.
Clearly when the receiver has chosen to use the GPS time-base for its GNSS system time,
conversion to GPS time requires no work at all, but conversion to UTC requires knowledge of thenumber of leap seconds since GPS time started (and other minor correction terms). The relevant
GPS to UTC conversion parameters are transmitted periodically (every 12.5 minutes) by GPS
satellites, but can also be supplied to the receiver via the UBX-MGA-GPS-UTC aiding message. By
contrast when the receiver has chosen to use the GLONASS time-base as its GNSS system time,
conversion to GPS time is more difficult as it requires knowledge of the difference between the
two time-bases, but conversion to UTC is easier (as GLONASS time is closely linked to UTC).
Where insufficient information is available for the receiver to perform any of these time-baseconversions precisely, pre-defined default offsets are used. Consequently plausible times arenearly always generated, but they may be wrong by a few seconds (especially shortly after receiver
start). Depending on the configuration of the receiver, such "invalid" times may well be output, butwith flags indicating their state (e.g. the "valid" flags in UBX-NAV-PVT).
u-blox receivers employ multiple GNSS system times and/or receiver local times (in orderto support multiple GNSS systems concurrently), so users should not rely on UBX
messages that report GNSS system time or receiver local time being supported infuture. It is therefore recommended to give preference to those messages that report
UTC time.

9.3 iTOW Timestamps
All the main UBX-NAV messages (and some other messages) contain an iTOW field whichindicates the GPS time at which the navigation epoch occurred. Messages with the same iTOW
value can be assumed to have come from the same navigation solution.
Note that iTOW values may not be valid (i.e. they may have been generated with insufficientconversion data) and therefore it is not recommended to use the iTOW field for any other purpose.
The original designers of GPS chose to express time/date as an integer week number(starting with the first full week in January 1980) and a time of week (often abbreviatedto TOW) expressed in seconds. Manipulating time/date in this form is far easier for
digital systems than the more "conventional" year/month/day, hour/minute/second

UBX-13003221 - R17

Early Production Information

Page 26 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

representation. Consequently, most GNSS receivers use this representation internally,
only converting to a more "conventional form" at external interfaces. The iTOW field isthe most obvious externally visible consequence of this internal representation.
If reliable absolute time information is required, users are recommended to use the UBX-NAV-PVTor UBX-HNR-PVT navigation solution messages which also contain additional fields that indicate
the validity (and accuracy in UBX-NAV-PVT) of the calculated times (see also the GNSS Times
section below for further messages containing time information).

9.4 GNSS Times
Each GNSS has its own time reference for which detailed and reliable information is provided in
the messages listed in the table below.
GNSS Times
Time Reference

Message

GPS Time
BeiDou Time
GLONASS Time
Galileo TimeUTC Time

UBX-NAV-TIMEGPSUBX-NAV-TIMEBDSUBX-NAV-TIMEGLOUBX-NAV-TIMEGALUBX-NAV-TIMEUTC

9.5 Time Validity
Information about the validity of the time solution is given in the following form:• Time validity: Information about time validity is provided in the valid flags (e.g. validDate andvalidTime flags in the UBX-NAV-PVT message). If these flags are set, the time is known andconsidered as valid for being used. These flags can be found in the GNSS Times table in the
GNSS Times section above as well as in the UBX-NAV-PVT and UBX-HNR-PVT messages.
• Time validity confirmation: Information about confirmed validity is provided in theconfirmedDate and confirmedTime flags in the UBX-NAV-PVT message. If these flags are set,
the time validity could be confirmed by using an additional independent source, meaning thatthe probability of the time to be correct is very high. Note that information about time validity
confirmation is only available if the confirmedAvai bit in the UBX-NAV-PVT message is set.
Check UBX-NAV-PVT which Protocol Version supports this flag.

9.6 UTC Representation
UTC time is used in many NMEA and UBX messages. In NMEA messages it is always reported
rounded to the nearest hundredth of a second. Consequently, it is normally reported with two
decimal places (e.g. 124923.52). What is more, although compatibility mode (selected usingUBXCFG-NMEA) requires three decimal places, rounding to the nearest hundredth of a second remains,so the extra digit is always 0.
UTC time is is also reported within some UBX messages, such as UBX-NAV-TIMEUTC and UBX-NAVPVT. In these messages date and time are separated into seven distinct integer fields. Six of these(year, month, day, hour, min and sec) have fairly obvious meanings and are all guaranteed tomatch the corresponding values in NMEA messages generated by the same navigation epoch.
This facilitates simple synchronisation between associated UBX and NMEA messages.
The seventh field is called nano and it contains the number of nanoseconds by which the rest of
the time and date fields need to be corrected to get the precise time. So, for example, the UTC
UBX-13003221 - R17

Early Production Information

Page 27 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

time 12:49:23.521 would be reported as: hour: 12, min: 49, sec: 23, nano: 521000000.
It is however important to note that the first six fields are the result of rounding to the nearest
hundredth of a second. Consequently the nano value can range from -5000000 (i.e. -5 ms) to+994999999 (i.e. nearly 995 ms).
When the nano field is negative, the number of seconds (and maybe minutes, hours, days, months
or even years) will have been rounded up. Therefore, some or all of them will need to be adjusted inorder to get the correct time and date. Thus in an extreme example, the UTC time 23:59:59.9993
on 31st December 2011 would be reported as: year: 2012, month: 1, day: 1, hour: 0, min: 0, sec: 0,
nano: -700000.
Of course, if a resolution of one hundredth of a second is adequate, negative nano values can
simply be rounded up to 0 and effectively ignored.
Which master clock the UTC time is referenced to is output in the message UBX-NAV-TIMEUTC.
For protocol versions 16 or greater, the preferred variant of UTC time can be specified using UBXCFG-NAV5.

9.7 Leap Seconds
Occasionally it is decided (by one of the international time keeping bodies) that, due to the slightly
uneven spin rate of the Earth, UTC has moved sufficiently out of alignment with mean solar time(i.e. the Sun no longer appears directly overhead at 0 longitude at midday). A "leap second" istherefore announced to bring UTC back into close alignment. This normally involves adding an
extra second to the last minute of the year, but it can also happen on 30th June. When thishappens UTC clocks are expected to go from 23:59:59 to 23:59:60 and only then on to 00:00:00.
It is also theoretically possible to have a negative leap second, in which case there will only be 59
seconds in a minute and 23:59:58 will be followed by 00:00:00.
u-blox receivers are designed to handle leap seconds in their UTC output and consequently users
processing UTC times from either NMEA and UBX messages should be prepared to handle
minutes that are either 59 or 61 seconds long.
Leap second information be be polled from the u-blox receiver with the message UBX-NAV-TIMELS
for Protocol Version 18 and above.

9.8 Real Time Clocku-blox receivers contain circuitry to support a real time clock, which (if correctly fitted andpowered) keeps time while the receiver is otherwise powered off. When the receiver powers up, it
attempts to use the real time clock to initialise receiver local time and in most cases this leads toappreciably faster first fixes.

9.9 Date
All GNSS frequently transmit information about the current time within their data message. In
most cases, this is a time of week (often abbreviated to TOW), which indicates the elapsed
number of seconds since the start of the week (midnight Saturday/Sunday). In order to map thisto a full date, it is necessary to know which week and so the GNSS also transmit a week number,
typically every 30 seconds. Unfortunately the GPS data message was designed in a way that only
allows the bottom 10 bits of the week number to be transmitted. This is not sufficient to yield acompletely unambiguous date as every 1024 weeks (a bit less than 20 years), the transmitted
week number value "rolls over" back to zero. Consequently, GPS receivers can't tell the difference

UBX-13003221 - R17

Early Production Information

Page 28 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

between, for example, 1980, 1999 or 2019 etc.
Fortunately, although BeiDou and Galileo have similar representations of time, they transmit
sufficient bits for the week number to be unambiguous for the forseeable future (the firstambiguity will be in 2078 for Galileo and not until 2163 for BeiDou). GLONASS has a different
structure, based on a time of day, but again transmits sufficient information to avoid any
ambiguity during the expected lifetime of the system (the first ambiguous date will be in 2124).
Therefore, u-blox 8 / u-blox M8 receivers using Protocol Version 18 and aboveregard the date
information transmitted by GLONASS, BeiDou and Galileo to be unambiguous and, where
necessary, use this to resolve any ambiguity in the GPS date.
Customers attaching u-blox receivers to simulators should be aware that GPS time isreferenced to 6th January 1980, GLONASS to 1st January 1996, Galileo to 22nd August
1999 and BeiDou to 1st January 2006; the receiver cannot be expected to work reliably
with signals that appear to come from before these dates.
9.9.1 GPS-only Date Resolution
In circumstances where only GPS signals are available and for receivers with earlier firmware
versions, the receiver establishes the date by assuming that all week numbers must be at least as
large as a reference rollover week number. This reference rollover week number is hard-coded into
the firmware at compile time and is normally set a few weeks before the s/w is completed, but it
can be overridden by the wknRollover field of the UBX-CFG-NAVX5 message to any value the user
wishes.
The following example illustrates how this works: Assume that the reference rollover weeknumber set in the firmware at compile time is 1524 (which corresponds to a week in calendar year
2009, but would be transmitted by the satellites as 500). In this case, if the receiver seestransmissions containing week numbers in the range 500 ... 1023, these will be interpreted asweek numbers 1524 ... 2047 (CY 2009 ... 2019), whereas transmissions with week numbers from 0
to 499 are interpreted as week numbers 2048 ... 2547 (CY 2019 ... 2028).
It is important to set the reference rollover week number appropriately when supplying ublox receivers with simulated signals, especially when the scenarios are in the past.

10 Broadcast Navigation Data
Reporting of broadcast navigation data is supported for products using protocol version
17 onwards.
The UBX-RXM-SFRBX reports the broadcast navigation data message collected by the receiverfrom each tracked signal. When enabled, a separate message is generated every time the receiver
decodes a complete subframe of data from a tracked signal. The data bits are reported, as
received, including preambles and error checking bits as appropriate. However because there isconsiderable variation in the data structure of the different GNSS signals, the form of thereported data also varies. Indeed, although this document uses the term "subframe" generically, it
is not strictly the correct term for all GNSS (e.g. GLONASS has "strings" and Galileo has "pages").

10.1 Parsing Navigation Data Subframes
Each UBX-RXM-SFRBX message contains a subframe of data bits appropriate for the relevant
GNSS, delivered in a number of 32 bit words, as indicated by numWords field.
Due to the variation in data structure between different GNSS, the most important step in

UBX-13003221 - R17

Early Production Information

Page 29 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

parsing a UBX-RXM-SFRBX message is to identify the form of the data. This should be done byreading the gnssId field, which indicates which GNSS the data was decoded from. In almost allcases, this is sufficient to indicate the structure and the following sections are organised by GNSS
for that reason. However, in some cases the identity of the GNSS is not sufficient, and this is
described, where appropriate, in the following sections.
In most cases, the data does not map perfectly into a number of 32 bit words and, consequently,
some of the words reported in UBX-RXM-SFRBX messages contain fields marked as "Pad". These
fields should be ignored and no assumption should be made about their contents.
UBX-RXM-SFRBX messages are only generated when complete subframes are detected by thereceiver and all appropriate parity checks have passed.
Where the parity checking algorithm requires data to be inverted before it is decoded (e.g. GPS
L1C/A), the receiver carries this out before the message output. Therefore, users can process data
directly and do not need to worry about repeating any parity processing.
The meaning of the content of each subframe depends on the sending GNSS and is described in
the relevant Interface Control Documents (ICD).

10.2 GPSThe data structure in the GPS L1C/A and L2C signals is dissimilar and thus theUBX-RXM-SFRBX
message structure differs as well. For the GPS L1C/A and L2C signals it is as follows.
10.2.1 GPS L1C/A
For GPS L1C/A signals, there is a fairly straightforward mapping between the reported subframe
and the structure of subframe and words described in the GPS ICD. Each subframe comprises ten
data words, which are reported in the same order they are received.
Each word is arranged as follows:

Note that as the GPS data words only comprise 30 bits, the 2 most significant bits in each word
reported by UBX-RXM-SFRBX are padding and should be ignored.

10.3 GLONASSFor GLONASS L1OF and L2OF signals, each reported subframe contains a string as described in
the GLONASS ICD. This string comprises 85 data bits which are reported over three 32 bit words
in the UBX-RXM-SFRBX message. Data bits 1 to 8 are always a hamming code, whilst bits 81 to 84
are a string number and bit 85 is the idle chip, which should always have a value of zero. The
meaning of other bits vary with string and frame number.
The fourth and final 32 bit word in the UBX-RXM-SFRBX message contains frame and superframe
numbers (where available). These values aren't actually transmitted by the SVs, but are deducedby the receiver and are included to aid decoding of the transmitted data. However, the receiver
does not always know these values, in which case a value of zero is reported.
The four words are arranged as follows:

UBX-13003221 - R17

Early Production Information

Page 30 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

In some circumstances, (especially on startup) the receiver may be able to decode data from a
GLONASS SV before it can identify the SV. When this occurs UBX-RXM-SFRBX messages will be
issued with an svId of 255 to indicate "unknown".

10.4 BeiDou
For BeiDou (B1I) signals, there is a fairly straightforward mapping between the reported subframe
and the structure of subframe and words described in the BeiDou ICD. Each subframe comprises
ten data words, which are reported in the same order they are received.
Each word is arranged as follows:

Note that as the BeiDou data words only comprise 30 bits, the 2 most significant bits in each word
reported by UBX-RXM-SFRBX are padding and should be ignored.

10.5 Galileo
The Galileo E1OS and E5b signals both transmit the I/NAV message but in different
configurations. The UBX-RXM-SFRBX structures for them are as follows.
10.5.1 Galileo E1OSFor Galileo E1OS signals, each reported subframe contains a pair of I/NAV pages as described in
the Galileo ICD.
Galileo pages can either be "Nominal" or "Alert" pages. For Nominal pages the eight words arearranged as follows:

UBX-13003221 - R17

Early Production Information

Page 31 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Alert pages are reported in very similar manner, but the page type bits will have value 1 and thestructure of the eight words will be slightly different (as indicated by the Galileo ICD).

10.6 SBASFor SBAS (L1C/A) signals each reported subframe contains eight 32 data words to deliver the 250
bits transmitted in each SBAS data block.
The eight words are arranged as follows:

UBX-13003221 - R17

Early Production Information

Page 32 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

10.7 QZSSThe structure of the data delivered by QZSS L1C/A signals is effectively identical to that forGPS(L1C/A). Similarly the QZSS L2C signal is effectively identical to the GPS (L2C).
The QZSS (L1SAIF) signal is different and uses the same data block format as used bySBAS(L1C/A). QZSS (SAIF) signals can be distinguished from QZSS (L1C/A and L2C) by noting that they
have 8 words, instead of 10 for QZSS (L1C/A and L2C).

10.8 IMES
Data messages from IMES are of variable length and u-blox receivers currently support thefollowing varieties:• Short - comprising of a single word
• Medium - comprising of two words• Position 1 - comprising of three words• Position 2 - comprising of four words
As a consequence, an IMES UBX-RXM-SFRBX message may have a numWords value of 1, 2, 3 or 4.
In all cases the structure of words follows the same pattern, with the first word being different
from any/all subsequent words as indicated by the following diagram:

10.9 Summary
The following table gives a summary of the different data message formats reported by the UBXRXM-SFRBX message.

UBX-13003221 - R17

Early Production Information

Page 33 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Data message formats reported by UBX-RXM-SFRBX
GNSSSignalgnssIdnumWords

periodGPS
SBAS
Galileo
BeiDouBeiDou
IMES
IMES
IMES
IMES
QZSS
QZSS
GLONASS

L1C/A
L1C/A
E1OS
B1I D1B1I D2
Short
MediumPosition 1
Position 2
L1C/A
L1SAIF
L1OF

0
1
2
3
3
4
4
4
4
5
5
6

10
8
8
10
10
1
2
3
4
10
8
4

6s
1s
2s
6s
0.6s
6s
1s
2s

11 Serial Communication Ports Description
u-blox receivers come with a highly flexible communication interface. It supports the NMEA andthe proprietary UBX protocols, and is truly multi-port and multi-protocol capable. Each protocol(UBX, NMEA) can be assigned to several ports at the same time (multi-port capability) withindividual settings (e.g. baud rate, message rates, etc.) for each port. It is even possible to assign
more than one protocol (e.g. UBX protocol and NMEA at the same time) to a single port (multiprotocol capability), which is particularly useful for debugging purposes.
To enable a message on a port, the UBX and/or NMEA protocol must be enabled on that port using
the UBX proprietary message UBX-CFG-PRT. This message also allows changing port-specificsettings (baud rate, address etc.). See UBX-CFG-MSG for a description of the mechanism forenabling and disabling messages.
The following table shows the port numbers reported in the messages UBX-MON-IO, UBX-MONMSGPP, UBX-MON-TXBUF, UBX-MON-RXBUF. Note that any numbers not listed are reserved for futureuse.
Port Number assignment
Port #

01
3
4Electrical Interface

DDC (I²C compatible)
UART 1
USB
SPI

11.1 TX-ready indication
This feature enables each port to define a corresponding pin, which indicates if bytes are ready to
be transmitted. By default, this feature is disabled. For USB, this feature is configurable but might
not behave as described below due to a different internal transmission mechanism. If the numberof pending bytes reaches the threshold configured for this port, the corresponding pin will become
active (configurable active-low or active-high), and stay active until the last bytes have beentransferred from software to hardware (note that this is not necessarily equal to all bytes
transmitted, i.e. after the pin has become inactive, up to 16 bytes can still need to be transferredto the host).
UBX-13003221 - R17

Early Production Information

Page 34 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The TX-ready pin can be selected from all PIOs which are not in use (see UBX-MON-HW for a list of
the PIOs and their mapping), each TX-ready pin is exclusively for one port and cannot be shared. If
the PIO is invalid or already in use, only the configuration for the TX-ready pin is ignored, the restof the port configuration is applied if valid. The acknowledge message does not indicate if the TXready configuration is successfully set, it only indicates the successful configuration of the port.
To validate successful configuration of the TX-ready pin, the port configuration should be polled
and the settings of TX-ready feature verified (will be set to disabled/all zero if the settings areinvalid).
The threshold should not be set above 2 kB, as the internal message buffer limit can be reached
before this, resulting in the TX-ready pin never being set as messages are discarded before thethreshold is reached.

11.2 Extended TX timeout
If the host does not communicate over SPI or DDC for more than approximately 2 seconds, thedevice assumes that the host is no longer using this interface and no more packets are scheduled
for this port. This mechanism can be changed by enabling "extended TX timeouts", in which casethe receiver delays idling the port until the allocated and undelivered bytes for this port reach 4 kB.
This feature is especially useful when using the TX-ready feature with a message output rate ofless than once per second, and polling data only when data is available, determined by the TXready pin becoming active.

11.3 UART Ports
One or two Universal Asynchronous Receiver/Transmitter (UART) ports are featured, that can beused to transmit GNSS measurements, monitor status information and configure the receiver.
See our online product descriptions for availability.
The serial ports consist of an RX and a TX line. Neither handshaking signals nor hardware flow
control signals are available. These serial ports operate in asynchronous mode. The baud rates
can be configured individually for each serial port. However, there is no support for setting
different baud rates for reception and transmission.
As of Protocol version 18+, the UART RX interface will be disabled when more than 100
frame errors are detected during a one-second period. This can happen if the wrong
baud rate is used or the UART RX pin is grounded. The error message appears when the
UART RX interface is re-enabled at the end of the one-second period.
Possible UART Interface Configurations
Baud Rate

4800
9600
19200
38400
57600
115200230400460800

Data Bits

ParityStop Bits

8
8
8
8
8
8
8
8

none
none
none
none
none
none
none
none

1
1
1
1
1
1
1
1

Note that for protocols such as NMEA or UBX, it does not make sense to change the default word
length values (data bits) since these properties are defined by the protocol and not by the

UBX-13003221 - R17

Early Production Information

Page 35 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualelectrical interface.
If the amount of data configured is too much for a certain port's bandwidth (e.g. all UBX messages
output on a UART port with a baud rate of 9600), the buffer will fill up. Once the buffer space is
exceeded, new messages to be sent will be dropped. To prevent message losses, the baud rateand communication speed or the number of enabled messages should be selected so that the
expected number of bytes can be transmitted in less than one second.
See UBX-CFG-PRT for UART for a description of the contents of the UART port configuration
message.

11.4 USB PortOne Universal Serial Bus (USB) port is featured. See the Data Sheet of your specific product foravailability. This port can be used for communication purposes and to power the positioning chipor module.
The USB interface supports two different power modes:• In Self Powered Mode the receiver is powered by its own power supply. VDDUSB is used todetect the availability of the USB port, i.e. whether the receiver is connected to a USB host.
• In Bus Powered Mode the device is powered by the USB bus, therefore no additional power
supply is needed. See the table below for the default maximum current that can be drawn by thereceiver. See UBX-CFG-USB for a description on how to change this maximum. Configuring Bus
Powered Mode indicates that the device will enter a low power state with disabled GNSS
functionality when the host suspends the device, e.g. when the host is put into stand-by mode.
Maximum Current in Bus Powered Mode
Generation

u-blox 8 / u-blox M8

Max Current

100 mAThe voltage range for VDDUSB is specified from 3.0 V to 3.6 V, which differs slightly
from the specification for VCC.
The boot screen is retransmitted on the USB port after the enumeration. However,messages generated between boot-up of the receiver and USB enumeration are notvisible on the USB port.

11.5 DDC PortThe Display Data Channel (DDC) bus is a two-wire communication interface compatible with the
I²C standard (Inter-Integrated Circuit). See our online product selector matrix for availability.
Unlike all other interfaces, the DDC is not able to communicate in full-duplex mode, i.e. TX and RX
are mutually exclusive. u-blox receivers act as a slave in the communication setup, therefore theycannot initiate data transfers on their own. The host, which is always master, provides the data
clock (SCL), and the clock frequency is therefore not configurable on the slave.
The receiver's DDC address is set to 0x42 by default. This address can be changed by setting themode field in UBX-CFG-PRT for DDC accordingly.
As the receiver will be run in slave mode and the DDC physical layer lacks a handshake mechanism
to inform the master about data availability, a layer has been inserted between the physical layer
and the UBX and NMEA layer. The receiver DDC interface implements a simple streaming
interface that allows the constant polling of data, discarding everything that is not parse-able.
The receiver returns 0xFF if no data is available. The TX-ready feature can be used to inform the

UBX-13003221 - R17

Early Production Information

Page 36 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

master about data availability and can be used as a trigger for data transmission.
11.5.1 Read Access
The DDC interface allows 256 slave registers to be addressed. As shown in Figure DDC Register
Layout only three of these are currently implemented. The data registers 0 to 252, at addresses
0x00 to 0xFC, each 1 byte in size, contain information to be defined later - the result of readingthem is undefined. The currently available number of bytes in the message stream can be read at
addresses 0xFD and 0xFE. The register at address 0xFF allows the data stream to be read. If
there is no data awaiting transmission from the receiver, then this register will deliver the value
0xff, which cannot be the first byte of a valid message. If message data is ready for transmission,then successive reads of register 0xff will deliver the waiting message data.
The registers 0x00 to 0xFC are reserved for future use and may be defined in a later
firmware release. Do not use them, as they don't provide any meaningful data!
DDC Register Layout

11.5.1.1 Read Access Forms
There are two forms of DDC read transfer. The 'random access' form includes a slave register
address and thus allows any register to be read. The second 'current address' form omits theregister address. If this second form is used, then an address pointer in the receiver is used todetermine which register to read. This address pointer will increment after each read unless it isalready pointing at register 0xff, the highest addressable register, in which case it remains
unaltered. The initial value of this address pointer at start-up is 0xff, so by default all current
address reads will repeatedly read register 0xff and receive the next byte of message data (or 0xff
if no message data is waiting). Figure DDC Random Read Access shows the format of the random
access form of the request. Following the start condition from the master, the 7-bit device
address and the RW bit (which is a logic low for write access) are clocked onto the bus by the
UBX-13003221 - R17

Early Production Information

Page 37 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

master transmitter. The receiver answers with an acknowledge (logic low) to indicate that itrecognises the address. Next, the 8-bit address of the register to be read must be written to thebus. Following the receiver’s acknowledge, the master again triggers a start condition and writes
the device address, but this time the RW bit is a logic high to initiate the read access. Now, themaster can read 1 toN bytes from the receiver, generating a not-acknowledge and a stop condition
after the last byte being read.
DDC Random Read Access

The format of the current address read request is :DDC Current Address Read Access11.5.2 Write Access
The receiver does not provide any write access except for writing UBX and NMEA messages to thereceiver, such as configuration or aiding data. Therefore, the register set mentioned in section
Read Access is not writeable. Following the start condition from the master, the 7-bit device
address and the RW bit (which is a logic low for write access) are clocked onto the bus by themaster transmitter. The receiver answers with an acknowledge (logic low) to indicate that it is
responsible for the given address. Now, the master can write 2 to N bytes to the receiver,generating a stop condition after the last byte being written. The number of data bytes must be
at least 2 to properly distinguish from the write access to set the address counter in random read

UBX-13003221 - R17

Early Production Information

Page 38 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

accesses.
DDC Write Access11.6 SPI Port
A Serial Peripheral Interface (SPI) bus is available with selected receivers. See our online productdescriptions for availability.
SPI is a four-wire synchronous communication interface. In contrast to UART, the master provides
the clock signal, which therefore doesn't need to be specified for the slave in advance. Moreover, abaud rate setting is not applicable for the slave. SPI modes 0-3 are implemented and can be
configured using the field mode.spiMode in CFG-PRT for SPI (default is SPI mode 0).
The SPI clock speed is limited depending on hardware and firmware versions!
11.6.1 Maximum SPI clock speed
u-blox 8 / u-blox M8 receivers support a maximum SPI clock speed of 5.5 MHz.
11.6.2 Read AccessAs the register mode is not implemented for the SPI port, only the UBX/NMEA message stream isprovided. This stream is accessed using the Back-To-Back Read and Write Access (see section
Back-To-Back Read and Write Access). When no data is available to be written to the receiver,
MOSI should be held logic high, i.e. all bytes written to the receiver are set to 0xFF.
To prevent the receiver from being busy parsing incoming data, the parsing process is stopped
after 50 subsequent bytes containing 0xFF. The parsing process is re-enabled with the first byte
not equal to 0xFF. The number of bytes to wait for deactivation (50 by default) can be adjusted
using the field mode.ffCnt in CFG-PRT for SPI, which is only necessary when messages shall besent containing a large number of subsequent 0xFF bytes.
If the receiver has no more data to send, it sets MISO to logic high, i.e. all bytes transmitted decode
to 0xFF. An efficient parser in the host will ignore all 0xFF bytes which are not part of a message
and will resume data processing as soon as the first byte not equal to 0xFF is received.

UBX-13003221 - R17

Early Production Information

Page 39 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

11.6.3 Back-To-Back Read and Write Access
The receiver does not provide any write access except for writing UBX and NMEA messages to thereceiver, such as configuration or aiding data. For every byte written to the receiver, a byte will
simultaneously be read from the receiver. While the master writes to MOSI, at the same time itneeds to read from MISO, as any pending data will be output by the receiver with this access. The
data on MISO represents the results from a current address read, returning 0xFF when no moredata is available.
SPI Back-To-Back Read/Write Access11.7 How to change between protocols
Reconfiguring a port from one protocol to another is a two-step process:• Step 1: the preferred protocol(s) needs to be enabled on a port usingUBX-CFG-PRT. One port canhandle several protocols at the same time (e.g. NMEA and UBX). By default, all ports are
configured for UBX and NMEA protocol so in most cases, it's not necessary to change the portsettings at all. Port settings can be viewed and changed using the UBX-CFG-PRT messages.
• Step 2: activate certain messages on each port using UBX-CFG-MSG.

12 Multiple GNSS Assistance (MGA)
12.1 Introduction
Users would ideally like GNSS receivers to provide accurate position information the moment they
are turned on. With standard GNSS receivers there can be a significant delay in providing the first
position fix, principally because the receiver needs to obtain data from several satellites and thesatellites transmit that data slowly. Under adverse signal conditions, data downloads from thesatellites to the receiver can take minutes, hours or even fail altogether.
Assisted GNSS (A-GNSS) is a common solution to this problem and involves some form ofreference network of receivers that collect data such as ephemeris, almanac, accurate time andsatellite status and pass this onto to the target receiver via any suitable communications link.
Such assistance data enables the receiver to compute a position within a few seconds, even underpoor signal conditions.
The UBX-MGA message class provides the means for delivering assistance data to u-blox
receivers and customers can obtain it from the u-blox AssistNow Online or AssistNow Offline
Services. Alternatively they can obtain assistance data from third-party sources (e.g. SUPL/RRLP)
and generate the appropriate UBX-MGA messages to send this data to the receiver.
UBX-13003221 - R17

Early Production Information

Page 40 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

12.2 Assistance Data
u-blox receivers currently accept the following types of assistance data:• Position: Estimated receiver position can be submitted to the receiver using the UBX-MGA-INIPOS_XYZ or UBX-MGA-INI-POS_LLH messages.
• Time: The current time can either be supplied as an inexact value via the standard
communication interfaces, suffering from latency depending on the baud rate, or using
hardware time synchronization where an accurate time pulse is connected to an externalinterrupt. The preferred option is to supply UTC time using the UBX-MGA-INI-TIME_UTC
message, but times referenced to some GNSS can be delivered with the UBX-MGA-INI-TIME_GNSS message.
• Clock drift: An estimate of the clock drift can be sent to the receiver using the UBX-MGA-INICLKD message.
• Frequency: It is possible to supply hardware frequency aiding by connecting a periodic
rectangular signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high phaseduration must not be shorter than 50 ns) to an external interrupt, and providing the appliedfrequency value using the UBX-MGA-INI-FREQ message.
• Current orbit data: Each different GNSS transmits orbit data in slightly different forms. For
each system there are separate messages for delivering ephemeris and almanac. So for
example GPS ephemeris is delivered to the receiver using the UBX-MGA-GPS-EPH message, while
GLONASS almanac is delivered with the UBX-MGA-GLO-ALM message.
• Predicted orbit data: UBX-MGA-ANO messages can be used to supply predictions of future orbit
information to a u-blox receiver. These messages can be obtained from the AssistNow Offline
Service and allow a receiver to improve its TTFF even when it is no longer connected to theInternet.
• Auxiliary information: Each GNSS transmits some auxiliary data (such as SV health information
or UTC parameters) to the receiver. A selection of messages exist for providing suchinformation to the receiver, such as UBX-MGA-GPS-IONO for ionospheric data from GPS.
• EOP: Earth Orientation Parameters can be sent to the receiver using the UBX-MGA-INI-EOP
message. This will replace the default model used by the AssistNow Autonomous feature andmay improve performance (particularly as the receiver gets older and the built-in model decays).
• Navigation Database: u-blox receivers can be instructed to dump the current state of theirinternal navigation database with the UBX-MGA-DBD-POLL message; sending this informationback to the receiver (e.g. after a period when the receiver was turned off) restores the database
to its former state, and thus allows the receiver to restart rapidly.

12.3 AssistNow Online
AssistNow Online is u-blox' end-to-end Assisted GNSS (A-GNSS) solution for receivers that haveaccess to the Internet. Data supplied by the AssistNow Online Service can be directly uploaded toa u-blox receiver in order to substantially reduce Time To First Fix (TTFF), even under poor signal
conditions. The system works by collecting data such as ephemeris and almanac from thesatellites through u-blox' Global Reference Network of receivers and providing this data tocustomers in a convenient form that can be forwarded on directly to u-blox receivers.
The AssistNow Online Service uses a simple, stateless, HTTP interface. Therefore, it works on all
standard mobile communication networks that support Internet access, including GPRS, UMTS
and Wireless LAN. No special arrangements need to be made with mobile network operators to
UBX-13003221 - R17

Early Production Information

Page 41 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualenable AssistNow Online.

The data returned by the AssistNow Online Service is a sequence of UBX-MGA messages, startingwith an estimate of the current time in the form of a UBX-MGA-INI-TIME_UTC message.
AssistNow Online currently supports GPS, GLONASS, BeiDou, Galileo, and QZSS.
Customers may choose to use third party sources of assistance data instead of using
the AssistNow Online Service. Customers choosing this option will need to ensure thatthe data is converted from the format used by the third party source to the appropriate
MGA messages. However, it is important to ensure that the receiver has an estimate of
the current time before it processes any other assistance data. For this reason, it isstrongly recommended to send a UBX-MGA-INI-TIME_UTC or UBX-MGA-INI-TIME_GNSS
as the first message of any assistance.
12.3.1 Host Software
As u-blox receivers have no means to connect directly with the Internet, the AssistNow Online
system can only work if the host system that contains the receiver can connect to the Internet,
download the data from the AssistNow Online Service and forward it on to the receiver. In thesimplest case that may involve fetching the data from the AssistNow Online Service (by means ofa single HTTP GET request), and sending the resulting data to the receiver.
Depending on the circumstances, it may be beneficial for the host software to include:• Creating an appropriate UBX-MGA-INI-TIME_UTC message to deliver a better sense of time to
the receiver, especially if the host system has a very good sense of the current time and candeliver a time pulse to one of the receiver's EXTINT pins.
• Enable and use flow control to prevent loss of data due to buffer overflow in the receiver.
u-blox provides the source code for an example library, called libMGA, that provides all of

UBX-13003221 - R17

Early Production Information

Page 42 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

the functionality we expect in most host software.
12.3.2 AssistNow Online Sequence
A typical sequence of use of the AssistNow Online Service comprises the following steps:• Power-up the u-blox receiver• Request data from the AssistNow Online Service• Optionally send UBX-MGA-INI-TIME_UTC followed by hardware time synchronization pulse if
hardware time synchronization is required.
• Send the UBX messages obtained from the AssistNow Online Service to the receiver.
12.3.3 Flow Control
u-blox receivers aim to process incoming messages as quickly as possible, but there will always bea small delay in processing each message. Uploading assistance data to the receiver can involve
sending as many as one hundred of individual messages to the receiver, one after the other. If thecommunication link is fast, and/or the receiver is busy (trying to acquire new signals), it is possiblethat the internal buffers will overflow and some messages will be lost. In order to combat this, ublox receivers support an optional flow control mechanism for assistance.
Flow control is activated by setting the ackAiding parameter in the UBX-CFG-NAVX5 message.
As a result the receiver will issue an acknowledgement message (UBX-MGA-ACK) for eachassistance message it successfully receives. The host software can examine theseacknowledgements to establish whether there were any problems with the data sent to thereceiver and deduce (by the lack of acknowledgement) if any messages have been lost. It may thenbe appropriate to resend some of the assistance messages.
The simplest way to implement flow control would be to send one UBX-MGA assistance message
at a time, waiting for the acknowledgement, before sending the next. However, such a strategy islikely to introduce significant delays into the whole assistance process. The best strategy will
depend on the amount of assistance data being sent and the nature of the communications link(e.g. baud rate of serial link). u-blox recommends that when customers are developing their host
software they start by sending all assistance messages and then analyse the resulting
acknowledgements to see whether there have been significant losses. Adding small delays during
the transmission may be a simple but effective way to avoid substantial loss of data.
12.3.4 Authorization
The AssistNow Online Service is only available for use by u-blox customers. In order to use theservices, customers will need to obtain an authorization token from u-blox. This token must be
supplied as a parameter whenever a request is made to either service.
12.3.5 Service Parameters
The information exchange with the AssistNow Online Service is based on the HTTP protocol. Uponreception of an HTTP GET request, the server will respond with the required messages in binary
format or with an error string in text format. After delivery of all data, the server will terminate theconnection.
The HTTP GET request from the client to the server should contain a standard HTTP query stringin the request URL. The query string consists of a set of "key=value" parameters in the followingform:

UBX-13003221 - R17

Early Production Information

Page 43 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

key=value;key=value;key=value;
The following rules apply:• The order of keys is not important.
• Keys and values are case sensitive.
• Keys and values must be separated by an equals character ('=').
• Key/value pairs must be separated by semicolons (';').
• If a value contains a list, each item in the list must be separated by a comma (',').
The following table describes the keys that are supported.
AssistNow Online Parameter Keys
Key Name

Unit/Range

Optional

token

Stringgnss

Stringdatatype

Stringlat

Numeric[degrees]

Optionallon

Numeric[degrees]

Optional

alt

Numeric[meters]

Optional

pacc

Numeric[meters]

Optional

tacc

Numeric
Optional[seconds]

latency

Numeric
Optional[seconds]

filteronpo (no valuesrequired)

UBX-13003221 - R17

MandatoryMandatoryMandatory

Optional

Description

The authorization token supplied by u-blox when a client
registers to use the service.
A comma separated list of the GNSS for which data should be
returned. Valid GNSS are: gps, qzss and glo.
A comma separated list of the data types required by theclient. Valid data types are: eph, alm, aux and pos. Time data isalways returned for each request. If the value of this parameteris an empty string, only time data will be returned.
Approximate user latitude in WGS 84 expressed in degrees andfractional degrees. Must be in range -90 to 90. Example:
lat=47.2.
Approximate user longitude in WGS 84 expressed in degrees
and fractional degrees. Must be in range -180 to 180. Example:
lon=8.55.
Approximate user altitude above WGS 84 Ellipsoid. If this value
is not provided, the server assumes an altitude of 0 meters.
Must be in range -1000 to 50000.
Approximate accuracy of submitted position (see position
parameters note below). If this value is not provided, the server
assumes an accuracy of 300km. Must be in range 0 to
6000000.
The timing accuracy (see time parameters note below). If thisvalue is not provided, the server assumes an accuracy of 10
seconds. Must be in range 0 to 3600.
Typical latency between the time the server receives therequest, and the time when the assistance data arrives at theu-blox receiver. The server can use this value to correct thetime being transmitted to the client. If this value is notprovided, the server assumes a latency of 0. Must be in range 0
to 3600.
If present, the ephemeris data returned to the client will only
contain data for the satellites which are likely to be visible fromthe approximate position provided by the lat, lon, alt and pacc
parameters. If the lat and lon parameters are not provided theservice will return an error.

Early Production Information

Page 44 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

AssistNow Online Parameter Keys continued
Key Name

Unit/Range

Optional

Description

filteronsv

StringOptional

A comma separated list of u-blox gnssId:svId pairs. The
ephemeris data returned to the client will only contain data forthe listed satellites.

Thus, as an example, a valid parameter string would be:
token=XXXXXXXXXXXXXXXXXXXXXX;gnss=gps,qzss;datatype=eph,pos,aux;lat=47.28;lon=8.56;
pacc=1000
12.3.5.1 Position parameters (lat, lon, alt and pacc)
The position parameters (lat, lon, alt and pacc) are used by the server for two purposes:• If the filteronpos parameter is provided, the server determines the currently visible satellites at
the user position, and only sends the ephemeris data of those satellites which should be in viewat the location of the user. This reduces bandwidth requirements. In this case the 'pacc' value istaken into account, meaning that the server will return all SVs visible in the given uncertainty
region.
• If the datatype 'pos' is requested, the server will return the position and accuracy in the
response data. When this data is supplied to the u-blox receiver, depending on the accuracy ofthe provided data, the receiver can then choose to select a better startup strategy. For example,
if the position is accurate to 100km or better, the u-blox receiver will choose to go for a more
optimistic startup strategy. This will result in quicker startup time. The receiver will decide
which strategy to choose, depending on the 'pacc' parameter. If the submitted user position isless accurate than what is being specified with the 'pacc' parameter, then the user will
experience prolonged or even failed startups.
12.3.5.2 Time parameters (tacc and latency)
Time data is always returned with each request. The time data refers to the time at which the
response leaves the server, corrected by an optional latency value.This time data provided by theservice is accurate to approximately 10ms but by default the time accuracy is indicated to be +/-10
seconds in order to account for network latency and any time between the client receiving thedata and it being provided to the receiver.
If both the network latency and the client latency can safely be assumed to be very low (or are
known), the client can choose to set the accuracy of the time message (tacc) to a much smaller
value (e.g. 0.5s). This will result in a faster TTFF. The latency can also be adjusted as appropriate.
However, these fields should be used with caution: if the time accuracy is not correct when thetime data reaches the receiver, the receiver may experience prolonged or even failed start-ups.
For optimal results, the client should establish an accurate sense of time itself (e.g. by calibrating
its system clock using a local NTP service) and then modify the time data received from theservice as appropriate.
12.3.6 Multiple Servers
u-blox has designed and implemented the AssistNow Online Service in a way that should provide
very high reliability. Nonetheless, there will be rare occasions when a server is not available (e.g.
due to failure or some form of maintenance activity). In order to protect customers against the
impact of such outages, u-blox will run at least two instances of the AssistNow Online Service on
independent machines. Customers will have a free choice of requesting assistance data from any
UBX-13003221 - R17

Early Production Information

Page 45 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualof these servers, as all will provide the same information. However, should one fail for whateverreason, it is highly unlikely that the other server(s) will also be unavailable. Therefore customers
requiring the best possible availability are recommended to implement a scheme where they
direct their requests to a chosen server, but, if that server fails to respond, have a fall-backmechanism to use another server instead.

12.4 AssistNow Offline
AssistNow Offline is a feature that combines special firmware in u-blox receivers and a proprietaryservice run by u-blox. It is targetted at receivers that only have occasional Internet access and so
can't use AssistNow Online. AssistNow Offline speeds up Time To First Fix (TTFF), typically toconsiderably less than 10s
AssistNow Offline currently supports GPS and GLONASS. u-blox intend to expand theAssistNow Offline Service to support other GNSS (such as BeiDou and Galileo) in due
course.
The AssistNow Offline Service uses a simple, stateless, HTTP interface. Therefore, it works on all
standard mobile communication networks that support Internet access, including GPRS, UMTS
and Wireless LAN. No special arrangements need to be made with mobile network operators toenable AssistNow Offline.
Users of AssistNow Offline are expected to download data from the AssistNow Offline Service,specifying the time period they want covered (1 to 5 weeks) and the types of GNSS. This data
must be uploaded to a u-blox receiver, so that it can estimate the positions of the satellites, when
no better data is available. Using these estimates will not provide as accurate a position fix as if
current ephemeris data is used, but it will allow much faster TTFFs in nearly all cases.
The data obtained from the AssistNow Offline Service is organised by date, normally a day at atime. Consequently the more weeks for which coverage is requested, the larger the amount ofdata to handle. Similarly, each different GNSS requires its own data and in the extreme cases,
several hundred kilobytes of data will be provided by the service. This amount can be reduced byrequesting lower resolution, but this will have a small negative impact on both position accuracy
and TTFF. See the section on Offline Service Parameters for details of how to specify these
options.
The downloaded Offline data is encoded in a sequence of UBX-MGA-ANO messages, one for every
SV for every day of the period covered. Thus, for example, data for all GPS SVs for 4 weeks will
involve in excess of 900 separate messages, taking up around 70kbytes. Where a u-blox receiver
has flash storage, all the data can be directly uploaded to be stored in the flash until it is needed.
In this case, the receiver will automatically select the most appropriate data to use at any time.
See the section on flash-based AssistNow Offline for further details.
AssistNow Offline can also be used where the receiver has no flash storage, or there is insufficientspare flash memory. In this case the customer's system must store the AssistNow Offline data
until the receiver needs it and then upload only the appropriate part for immediate use. See thesection on host-based AssistNow Offline for further details.
12.4.1 Service Parameters
The information exchange with the AssistNow Offline Service is based on the HTTP protocol.
Upon reception of an HTTP GET request, the server will respond with the required messages inbinary format or with an error string in text format. After delivery of all data, the server willterminate the connection.
UBX-13003221 - R17

Early Production Information

Page 46 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The HTTP GET request from the client to the server should contain a standard HTTP querystringin the request URL. The querystring consists of a set of "key=value" parameters in the following
form:
key=value;key=value;key=value;
The following rules apply:• The order of keys is not important.
• Keys and values are case sensitive.
• Keys and values must be separated by an equals character ('=').
• Key/value pairs must be separated by semicolons (';').
• If a value contains a list, each item in the list must be separated by a comma (',').
The following table describes the keys that are supported.
AssistNow Offline Parameter Keys
Key Name

Unit/Range

token

Stringgnss

StringperiodNumeric[weeks]resolution Numeric[days]

Optional

MandatoryMandatory
Optional

Optional

Description

The authorization token supplied by u-blox when a client
registers to use the service.
A comma separated list of the GNSS for which data should be
returned. The currently supported GNSS are: gps and glo.
The number of weeks into the future the data should be validfor. Data can be requested for up to 5 weeks in to the future. If
this value is not provided, the server assumes a period of 4
weeks.
The resolution of the data: 1=every day, 2=every other day,
3=every third day. If this value is not provided, the server
assumes a resolution of 1 day.

Thus, as an example, a valid parameter string would be:
token=XXXXXXXXXXXXXXXXXXXXXX;gnss=gps,glo;
12.4.2 Authorization
The AssistNow Offline Service uses the same authorization process as AssistNow Online; seeabove for details.
12.4.3 Multiple Servers
The AssistNow Offline Service uses the same multiple server mechanism to provide highavailability as AssistNow Online; see above for details.
12.4.4 Time, Position and Almanac
While AssistNow Offline can be used on its own, it is expected that the user will provide estimatesof the receiver's current position, the current time and ensure that a reasonably up to datealmanac is available. In most cases this information is likely to be available without the user
needing to do anything. For example, where the receiver is connected to a battery backup power
supply and has a functioning real time clock (RTC), the receiver will keep its own sense of time andwill retain the last known position and any almanac. However, should the receiver be completely
unpowered before startup, then it will greatly improve TTFF if time, position and almanac can besupplied in some form.

UBX-13003221 - R17

Early Production Information

Page 47 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Almanac data has a validity period of several weeks, so can be downloaded from the AssistNow
Online service at roughly the same time the Offline data is obtained. It can then be stored in thehost for uploading on receiver startup, or it can be transferred to the receiver straight away andpreserved there (provided suitable non-voltaile storage is available).
Obviously, where a receiver has a functioning RTC, it should be able to keep its own sense of time,
but where no RTC is fitted (or power is completely turned off), providing a time estimate via the
UBX-MGA-INI-TIME_UTC message will be beneficial.
Similarly, where a receiver has effective non-volatile storage, the last known position will berecalled, but if this is not the case, then it will help TTFF to provide a position estimate via one of
the UBX-MGA-INI-POS_XYZ or UBX-MGA-INI-POS_LLH messages.
Where circumstance prevent the provision of all three of these pieces of data, providing some islikely to be better than none at all.
12.4.5 Flash-based AssistNow Offline
Flash-based AssistNow Offline functionality means that AssistNow Offline data is stored in the
flash memory connected to the chip.
The user's host system must download the data from the AssistNow Offline service when an
Internet connection is available, and then deliver all of that data to the u-blox receiver. As the total
amount of data to be uploaded is large (typically around 100 kbytes) and writing to flash memoryis slow, the upload must be done in blocks of up to 512 bytes, one at a time. TheUBX-MGA-FLASHDATA message is used to transmit each block to the receiver.
AssistNow Offline data stored in flash memory is not affected by any reset of thereceiver. The only simple ways to clear it are to completely erase the whole flash memory
or to overwrite it with a new set of AssistNow Offline data. Uploading a dummy block ofdata (e.g. all zeros) will also have the effect of deleting the data, although a small
amount of flash storage will be used.
12.4.5.1 Flash-based Storage Procedure
The following steps are a typical sequence for transferring AssistNow Offline data into thereceiver's flash memory:• The host downloads a copy of a latest data from the AssistNow Offline service and stores it
locally.
• It sends the first 512 bytes of that data using theUBX-MGA-FLASH-DATA message.
• It awaits a UBX-MGA-FLASH-ACK message in reply.
• Based on the contents of the UBX-MGA-FLASH-ACK message it, sends the next block, resends
the last block or aborts the whole process.
• The above three steps are repeated until all the rest of the data has been successfullytransferred (or the process has been aborted).
• The host sends an UBX-MGA-FLASH-STOP message to indicate completion of the upload.
• It awaits the final UBX-MGA-FLASH-ACK message in reply. Background processing in the receiver
prepares the downloaded data for use at this stage. Particularly if the receiver is currently busy,
this maye take quite a few seconds, so the host has to be prepared for a delay before the UBXMGA-FLASH-ACK is seen.
Note that the final block may be smaller than 512 bytes (where the total data size is not perfectly
divisible by 512). Also, theUBX-MGA-FLASH-ACK messages are distinct from the UBX-MGA-ACKUBX-13003221 - R17

Early Production Information

Page 48 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

messages used for other AssistNow functions.
Any existing data will be deleted as soon as the first block of new data arrives, so no useful data
will be available till the completion of the data transfer. Each block of data has a sequencenumber, starting at zero for the first block. In order to guard against invalid partial data
downloads the receiver will not accept blocks which are out of sequence.
12.4.6 Host-based AssistNow Offline
Host-based AssistNow Offline involves AssistNow Offline data being stored until it is needed by
the user's host system in whatever memory it has available.
The user's host system must download the data from the AssistNow Offline service when an
Internet connection is available, but retain it until the time the u-blox receiver needs it. At thispoint, the host must upload just the relevant portion of the data to the receiver, so that thereceiver can start using it. This is achieved by parsing all the data and selecting for upload to thereceiver only those UBX-MGA-ANO messages with a date-stamp nearest the current time. As eachis a complete UBX message it can be sent directly to the receiver with no extra packaging. If
required the user can select to employ flow control, but in most cases this is likely to prove
unnecessary.
When parsing the data obtained from the AssistNow Offline service the following points should be
noted:• The data is made up of a sequence of UBX-MGA-ANO messages• Customers should not rely on the messages all being a fixed sized, but should read their lengthfrom the UBX header to work out where the message ends (and where the next begins).
• Each message indicates the SV for which it is applicable through the svId and gnssId fields.
• Each message contains a date-stamp within the year, month and day fields.
• Midday (UTC) on the day indicated should be considered to be the point at which the data ismost applicable.
• The messages will be ordered chronologically, earliest first.
• Messages with same date-stamp will be ordered by ascending gnssId and then ascending svId.
12.4.6.1 Host-based Procedure
The following steps are a typical sequence for host-based AssistNow Offline:• The host downloads a copy of a latest data from the AssistNow Offline service and stores it
locally.
• Optionally it may also download a current set of almanac data from the AssistNow Online
service.
• It waits until it want to use the u-blox receiver.
• If necessary it uploads any almanac, position estimate and/or time estimate to the receiver.
• It scans through AssistNow Offline data looking for entries with a date-stamp that most closely
matches the current (UTC) time/date.
• It sends each such UBX-MGA-ANO message to the receiver.
Note that when data has been downloaded from the AssistNow Offline service with the (default)
resolution of one day, the means for selecting the closest matching date-stamp is simply to lookfor ones with the current (UTC) date.

UBX-13003221 - R17

Early Production Information

Page 49 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

12.5 Preserving Information During Power-off
The performance of u-blox receivers immediately after they are turnned on is enhanced byproviding them with as much useful information as possible. Assistance (both Online and Offline)
is one way to achieve this, but retaining information from previous use of the receiver can be justas valuable. All the types of data delivered by assistance can be retained while the receiver ispowered down for use when power is restored. Obviously the value of this data will diminish as
time passes, but in many cases it remains very useful and can significantly improve time to firstfix.
The are several ways in which a u-blox receiver can retain useful data while it is powered down,
including:• Battery Backed RAM: The receiver can be supplied with sufficient power to maintain a small
portion of internal storage, while it is otherwise turned off. This is the best mechanism, provided
that the small amount of electrical power required can be supplied continuously.
• Save on Shutdown: The receiver can be instructed to dump its current state to the attachedflash memory (where fitted) as part of the shutdown procedure; this data is then automatically
retrieved when the receiver is restarted. See the description of the UBX-UPD-SOS messages formore information.
• Database Dump: The receiver can be asked to dump the state of its internal database in theform of a sequence of UBX messages reported to the host; these messages can be stored by
the host and then sent back to the receiver when it has been restarted. See the description of
the UBX-MGA-DBD messages for more information.

12.6 AssistNow Autonomous(Note: some functionality described in this chapter may not be available in protocol versions lessthan 18).
12.6.1 Introduction
The assistance scenarios covered by AssistNow Online and AssistNow Offline require an online
connection and a host that can use this connection to download aiding data and provide this to
the receiver when required.
The AssistNow Autonomous feature provides a functionality similar to AssistNow Offline without
the need for a host and a connection. Based on a broadcast ephemeris downloaded from thesatellite (or obtained by AssistNow Online) the receiver can autonomously (i.e. without any hostinteraction or online connection) generate an accurate satellite orbit representation («AssistNow
Autonomous data») that is usable for navigation much longer than the underlying broadcast
ephemeris was intended for. This makes downloading new ephemeris or aiding data for the first
fix unnecessary for subsequent start-ups of the receiver.
The AssistNow Autonomous feature is disabled by default. It can be enabled using the
UBX-CFG-NAVX5 message.
12.6.2 Concept
The figure below illustrates the AssistNow Autonomous concept in a graphical way. Note that thefigure is a qualitative illustration and is not to scale.
• A broadcast ephemeris downloaded from the satellite is a precise representation of a part (forGPS nominally four hours) of the satellite's true orbit (trajectory). It is not usable for positioning

UBX-13003221 - R17

Early Production Information

Page 50 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

beyond this validity period because it diverges dramatically from the true orbit afterwards.
• The AssistNow Autonomous orbit is an extension of one or more broadcast ephemerides. It
provides a long-term orbit for the satellite for several revolutions. Although this orbit is not
perfectly precise it is a sufficiently accurate representation of the true orbit to be used fornavigation.
• The AssistNow Autonomous data is automatically and autonomously generated fromdownloaded (or assisted) ephemerides. The data is stored automatically in the on-chip batterybacked memory (BBR). Optionally, the data can be backed-up in external flash memory or on thehost. The number of satellites for which data can be stored depends on the receiverconfiguration and may change during operation.
• If no broadcast ephemeris is available for navigation AssistNow Autonomous automaticallygenerates the required parts of the orbits suitable for navigation from the stored data. The datais also automatically kept current in order to minimize the calculation time once the navigationengine needs orbits.
• The operation of the AssistNow Autonomous feature is transparent to the user and theoperation of the receiver. All calculations are done in background and do not affect the normal
operation of the receiver.
• The AssistNow Autonomous subsystem automatically invalidates data that has become too old
and that would introduce unacceptable positioning errors. This threshold is configurable (seebelow).
• The prediction quality will be automatically improved if the satellite has been observed multiple
times. However, this requires the availability of a suitable flash memory (see the Hardware
Integration Manual for a list of supported devices). Improved prediction quality also positively
affects the maximum usability period of the data.
• AssistNow Autonomous considers GPS, GLONASS, Galileo and BeiDou satellites only. It will notconsider satellites on orbits with an eccentricity of >0.05 (e.g., Galileo E18). For GLONASS
support a suitable flash memory is mandatory because a single broadcast ephemeris spans tolittle of the orbit (only approx. 30 minutes) in order to extend it in a usable way. Only multiple
observations of the same GLONASS satellite that span at least four hours will be used togenerate data.

UBX-13003221 - R17

Early Production Information

Page 51 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

12.6.3 Interface
Several UBX protocol messages provide interfaces to the AssistNow Autonomous feature. Theyare:
• The UBX-CFG-NAVX5 message is used to enable or disable the AssistNow Autonomous feature.
It is disabled by default. Once enabled, the receiver will automatically produce AssistNow
Autonomous data for newly received broadcast ephemerides and, if that data is available,
automatically provide the navigation subsystem with orbits when necessary and adequate. The
message also allows for a configuration of the maximum acceptable orbit error. See the next
section for an explanation of this feature. It is recommended to use the firmware default valuethat corresponds to a default orbit data validity of approximately three days (for GPS satellites
observed once) and up to six days (for GPS and GLONASS satellites observed multiple times
over a period of at least half a day).
• Note that disabling the AssistNow Autonomous feature will delete all previously collectedsatellite observation data from the flash memory.
• The UBX-NAV-AOPSTATUS message provides information on the current state of the AssistNow
Autonomous subsystem. The status indicates whether the AssistNow Autonomous subsystem
is currently idle (or not enabled) or busy generating data or orbits. Hosts should monitor thisinformation and only power-off the receiver when the subsystem is idle (that is, when thestatus field shows a steady zero).
• The UBX-NAV-SAT message indicates the use of AssistNow Autonomous orbits for individual
satellites.
UBX-13003221 - R17

Early Production Information

Page 52 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• The UBX-NAV-ORB message indicates the availability of AssistNow Autonomous orbits forindividual satellites.
• The UBX-MGA-DBD message provides a means to retrieve the AssistNow Autonomous data fromthe receiver in order to preserve the data in power-off mode where no battery backup isavailable. Note that the receiver requires the absolute time (i.e. full date and time) to calculate
AssistNow Autonomous orbits. For best performance it is, therefore, recommended to supply
this information to the receiver using the UBX-MGA-INI-TIME_UTC message in this scenario.
• The Save-on-Shutdown feature preserves AssistNow Autonomous data.
12.6.4 Benefits and Drawbacks
AssistNow Autonomous can provide quicker start-up times (lower the TTFF) provided that data isavailable for enough visible satellites. This is particularly true under weak signal conditions where
it might not be possible to download broadcast ephemerides at all, and, therefore, no fix at all
would be possible without AssistNow Autonomous (or A-GNSS). It is, however, required that thereceiver roughly know the absolute time, either from an RTC or from time-aiding (see the Interface
section above), and that it knows which satellites are visible, either from the almanac or fromtracking the respective signals.
The AssistNow Autonomous orbit (satellite position) accuracy depends on various factors, suchas the particular type of satellite, the accuracy of the underlying broadcast ephemeris, or theorbital phase of the satellite and Earth, and the age of the data (errors add up over time).
AssistNow Autonomous will typically extend a broadcast ephemeris for up to three to six days.
The UBX-CFG-NAVX5 (see above) message allows changing this threshold by setting the«maximum acceptable modelled orbit error» (in meters). Note that this number does not reflect
the true orbit error introduced by extending the ephemeris. It is a statistical value that represents
a certain expected upper limit based on a number of parameters. A rough approximation that
relates the maximum extension time to this setting is: maxError [m] = maxAge [d] * f, where thefactor f is 30 for data derived from satellites seen once and and 16 for data derived for satellites
seen multiple time during a long enough time period (see the Concept section above).
There is no direct relation between (true and statistical) orbit accuracy and positioning accuracy.
The positioning accuracy depends on various factors, such as the satellite position accuracy, thenumber of visible satellites, and the geometry (DOP) of the visible satellites. Position fixes that
include AssistNow Autonomous orbit information may be significantly worse than fixes using only
broadcast ephemerides. It might be necessary to adjust the limits of the Navigation Output
Filters.
A fundamental deficiency of any system to predict satellite orbits precisely is unknown future
events. Hence, the receiver will not be able to know about satellites that will have becomeunhealthy, have undergone a clock swap, or have had a manoeuvre. This means that thenavigation engine might rarely mistake a wrong satellite position as the true satellite position.
However, provided that there are enough other good satellites, the navigation algorithms will
eventually eliminate a defective orbit from the navigation solution.
The repeatability of the satellite constellation is a potential pitfall for the use of the AssistNow
Autonomous feature. For a given location on Earth the (GPS) constellation (geometry of visible
satellites) repeats every 24 hours. Hence, when the receiver «learned» about a number of satellites
at some point in time the same satellites will in most places not be visible 12 hours later, and theavailable AssistNow Autonomous data will not be of any help. Again 12 hours later, however, usable
data would be available because it had been generated 24 hours ago.
UBX-13003221 - R17

Early Production Information

Page 53 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The longer a receiver observes the sky the more satellites it will have seen. At the equator, andwith full sky view, approximately ten (GPS) satellites will show up in a one hour window. After fourhours of observation approx. 16 satellites (i.e. half the constellation), after 10 hours approx. 24
satellites (2/3rd of the constellation), and after approx. 16 hours the full constellation will havebeen observed (and AssistNow Autonomous data generated for). Lower sky visibility reduces
these figures. Further away from the equator the numbers improve because the satellites can beseen twice a day. E.g. at 47 degrees north the full constellation can be observed in approx. 12 hours
with full sky view.
The calculations required for AssistNow Autonomous are carried out on the receiver. This requires
energy and users may therefore occasionally see increased power consumption during shortperiods (several seconds, rarely more than 60 seconds) when such calculations are running.
Ongoing calculations will automatically prevent the power save mode from entering the power-off
state. The power-down will be delayed until all calculations are done.
The AssistNow Offline and AssistNow Autonomous features are exclusive and should
not be used at the same time. Every satellite will be ignored by AssistNow Autonomous if
there is AssistNow Offline data available for it.

13 Power Management
u-blox receivers support different power modes. These modes represent strategies of how tocontrol the acquisition and tracking engines in order to achieve either the best possible
performance or good performance with reduced power consumption.
Receiver power management can split into two categories:• Externally Controlled Power Management: This includes various modes of power managementthat are directly operated by the user or host device. These modes are: 1. External cycling of thereceiver main power supply. 2. Instruct the receiver to turn On/Off via the UBX-RXM-PMREQ
message. 3. Instruct the receiver to turn On/Off via external pins (EXTINT0 or EXTINT1)• Internally Controlled Power Management: Here the receiver makes the decision when to power
down/up some/all of its internal components according to predefined parameters. It is also
referred to as Power Save Modes (PSM). In PSM one of three modes of operations can beselected (not all are supported in a single firmware): 1. ON/OFF Operation (PSMOO) 2. Cyclic
Tracking (PSMCT) 3. Super-Efficient Mode (Super-E).
The following figure illustrates u-blox power management modes.

UBX-13003221 - R17

Early Production Information

Page 54 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

u-blox Power Management

The majority of the Power Management section is detailing the Power Save Mode (InternallyControlled Power Management). However, some the concepts relevant to the ExternallyControlled Power Management are detailed, such as the EXTINT Control, Wake up and Power
On/Off Command.
Externally controlled power management operations can be used on top of the InternallyControlled Power Management and they do override their operation.

13.1 Continuous Modeu-blox receivers make use of dedicated signal processing engines optimized for signal acquisition
and tracking. The acquisition engine delivers rapid signal searches during cold starts or wheninsufficient signals are available for navigation. The tracking engine delivers signal measurements
for navigation and acquires new signals as they become available during navigation. The
resources of both engines are deployed adaptively to minimize overall power consumption.

13.2 Power Save Mode
Power Save Mode (PSM) allows a reduction in system power consumption by selectively switchingparts of the receiver on and off. It is selected using the message UBX-CFG-RXM and configured
using UBX-CFG-PM2. It is recommended to use UBX-CFG-PMS instead if available (only supported inprotocol versions 18+) as it provides a simplified interface; see section Power Mode Setup for
details.
PSM is designed to only support the operation of GPS, GLONASS, BeiDou, Galileo and QZSS.
Enabling SBAS or IMES is possible only if at least one of the other systems is enabled. The PSM
state machine behavior will not be altered by enabling SBAS or IMES and it will not take them into
account in operation. Therefore, it is recommended to disable them (i.e., SBAS or IMES) when
operating in Power Save Mode. They can be disabled using UBX-CFG-GNSS.
The logic within Power Save Mode is designed so that Time Pulse operation is notcompromised. This means that entering all power saving states is delayed until theconditions necessary to produce a Time Pulse have been met. Therefore, in order toobtain good Power Save Mode operation, it is essential that any Time Pulse is correctly

UBX-13003221 - R17

Early Production Information

Page 55 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

configured with an appropriate time base, or that Time Pulses are turned off if notneeded (by clearing the active flag in UBX-CFG-TP5).
For protocol versions less than 18: Power Save Mode can only be selected with GPS
signals. Other GNSS are not supported.
Note: Power Save Mode is not supported in conjunction with the ADR, UDR and FTS
products.
13.2.1 Operation
Power Save Mode has two modes of operation:• Power Save Mode Cyclic Tracking (PSMCT) Operation is used when position fixes are required in
short periods of 1 to 10s. In receivers that supportSuper-E Mode, Super-E replaces Cyclic
Tracking.
• Power Save Mode ON/OFF (PSMOO) Operation is used for periods longer than 10s, and can be in
the order of minutes, hours or days. (Not supported in protocol versions 23 to 23.01)
The mode of operation can be configured, and depending on the setting, the receiverdemonstrates different behavior: In ON/OFF operation the receiver switches between phases ofstart-up/navigation and phases with low or almost no system activity (backup/sleep). In cyclic
tracking the receiver does not shut down completely between fixes, but uses low power tracking
instead.
Currently PSMCT is restricted to update period between 1 and 10 seconds and PSMOO is
restricted to update period over 10 seconds. However, this may change in future firmware
releases.
PSM is based on a state machine with five different states: (Inactive) Awaiting Next Fix and(Inactive) Awaiting Next Search states, Acquisition state, Tracking state and Power Optimized
Tracking (POT) state.
• Inactive states: Most parts of the receiver are switched off.
• Acquisition state: The receiver actively searches for and acquires signals. Maximum power
consumption.
• Tracking state: The receiver continuously tracks and downloads data. Less power consumption
than in Acquisition state.
• POT state: The receiver repeatedly loops through a sequence of tracking (Track), calculating theposition fix (Fix), and entering an idle period (Idle). No new signals are acquired and no data is
downloaded. Much less power consumption than in Tracking state.
The following figure illustrates the PSM state machine:

UBX-13003221 - R17

Early Production Information

Page 56 of 407

u-blox 8 / u-blox M8 Receiver Description - ManualState machine

13.2.1.1 Acquisition Timeout Logic
The receiver has internal, external and user configurable mechanisms that determine the time tobe spent in acquisition state. This logic is put in place to ensure good performance and low power
consumption in different environments and scenarios. This collective logic is referred to as
Acquisition Timeout.
Internal mechanisms:• If the receiver is able to acquire weak signals but not of the quality needed to get a fix, it willtransition to (Inactive) Awaiting Next Search state after the timeout configured in
maxStartupStateDur or earlier if too few signals are acquired.
• If the receiver is unable to acquire any signals or it acquires a small number of extremely badsignals (e.g., no sky view), it will transition to (Inactive) Awaiting Next search state after 15
seconds or the timeout configured in maxStartupStateDur if shorter.
User configurable mechanisms:• minAcqTime is the minimum time that the receiver will spend in Acquisition state (seeminAcqTime for details.)• maxStartupStateDur is the maximum time that the receiver will spend in Acquisition state (seeUBX-13003221 - R17

Early Production Information

Page 57 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

maxStartupStateDur for details).
• doNotEnterOff forces the receiver to stay awake and in Acquisition state even when a fix is notpossible (see doNotEnterOff for details).
External mechanisms:• The receiver will be forced to stay awake if extintWake is enabled and the configured EXTINT pin
is set to "high" and it will be forced to stay in (Inactive) Awaiting Next Search/Fix states if
extintBackup is enabled and the configured EXTINT pin is set to "low" (see EXTINT pin control
for details).
13.2.1.2 ON/OFF operation - long update period(Not supported in protocol versions 23 to 23.01).
When the receiver is switched on, it first enters Acquisition state. If it is able to obtain a valid
position fix within the time given by the Acquisition Timeout, it switches to Tracking state.
Otherwise it enters (Inactive) Awaiting Next Search state and re-starts after the configured
search period (minus a start-up margin). As soon as the receiver gets a valid position fix (onepassing the navigation output filters), it enters Tracking state. Upon entering Tracking state, theonTime starts. Once the onTime is over, (Inactive) Awaiting Next Fix state is entered and thereceiver re-starts according to the configured update grid (see section Grid offset for an
explanation). If the signal is lost while in Tracking state, Acquisition state is entered. If the signal is
not found within the acquisition timeout, the receiver enters (Inactive) Awaiting Next Search state.
Otherwise the receiver will re-enter Tracking state and stay there until the newly started onTime isover.
The diagram below illustrates how ON/OFF operation works:
Diagram of ON/OFF operation

13.2.1.3 Cyclic tracking operation - short update period
When the receiver is switched on, it first enters Acquisition state. If it is able to obtain a position
fix within the time given by the acquisition timeout, it switches to Tracking state. Otherwise, it willenter (Inactive) Awaiting Next Search state and re-start within the configured search grid. After avalid position fix, Tracking state is entered and the onTime starts. In other words the onTime
starts with the first valid position fix. Once the onTime is over, POT state is entered. In POT state
the receiver continues to output position fixes according to the updatePeriod. To have maximum
power savings, set the onTime to zero. This causes the receiver to enter POT state as soon as
possible. If the signal becomes weak or is lost during POT state, Tracking state is entered. Oncethe signal is good again and the newly started onTime is over, the receiver will re-enter POT state.
If the receiver can't get a position fix in the Tracking state, it enters Acquisition state. Should theacquisition fail as well, (Inactive) Awaiting Next Search state is entered. If doNotEnterOff is

UBX-13003221 - R17

Early Production Information

Page 58 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualenabled and no fix is possible, the receiver will remain in Acquisition state until a fix is possible andit will never enter (Inactive) Awaiting Next Search state.
The diagram below illustrates how cyclic tracking operation works:
Diagram of cyclic tracking operation

13.2.1.4 Super-Efficient Mode(not supported in protocol versions less than 23).
Super-Efficient (Super-E) Mode is a power efficient mode of operation that replaces and improves
on cyclic tracking Power Save Mode (PSMCT). It uses improved clocking techiques to reduce
power consumption and more sophisticated decision making for switching between "Acquisition","Tracking" and "Power Optimized Tracking" states. This mode was developed and optimized toprovide a good compromise between power efficiency and positioning accuracy in wearable
applications.
13.2.1.5 User controlled operation - update and search period of zero
Setting the updatePeriod to zero causes the receiver to wait in the (Inactive) Awaiting Next Fix
state until woken up by the user. Setting the search period to zero causes the receiver to wait inthe (Inactive) Awaiting Next Search state indefinitely after an unsuccessful start-up. Any wake-up
event will re-start the receiver. See section Wake up for more information on wake-up events.
External wake-up is required when setting update or search period to zero.
13.2.1.6 Satellite data download
The receiver is not able to download satellite data (e.g. the ephemeris) while it is working in
ON/OFF or cyclic tracking operation. Therefore it has to temporarily switch to continuous
operation for the time the satellites transmit the desired data. To save power the receiverschedules the downloads according to an internal timetable and only switches to continuous
operation while data of interest is being transmitted by the satellites.
Each SV transmits its own ephemeris data. Ephemeris data download is feasible when thecorresponding satellite has been tracked with a sufficient C/No over a certain period of time. The
download is scheduled in a 30 minute grid or immediately when fewer than a certain number ofvisible satellites have valid ephemeris data.
Almanac, ionosphere, UTC correction and SV health data are transmitted by all SVs
simultaneously. Therefore these parameters can be downloaded when a single SV is tracked witha high enough C/No.
Allowing more ephemerides to be downloaded before going into POT or (Inactive) Awaiting Next Fix
state can help improve the quality of the fixes and reduce the number of wake ups needed to

UBX-13003221 - R17

Early Production Information

Page 59 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

download ephemerides at the cost of extra time in Acquisition state (only when an inadequate
number of ephemerides are downloaded from tracked satellites).
13.2.2 Configuration
Power Save Mode is enabled and disabled with the UBX-CFG-RXM message and configured with the
UBX-CFG-PM2 message.
When enabling Power Save Mode, the receiver will be unable to download or process any
SBAS or IMES data. Therefore, there is no benefit in enabling them and it isrecommended to disable both systems. SBAS support and IMES support can bedisabled using UBX-CFG-GNSS.
A number of parameters can be used to customize PSM to your specific needs. These parameters
are listed in the following table:
Power Save Mode configuration options on UBX-CFG-PM2
Parameter

Description

mode
updatePeriod
searchPeriod

Receiver mode of operation
Time between two position fix attempts
Time between two acquisition attempts if the receiver is unable to get a
position fix
minAcqTime
Minimum time the receiver spends in Acquisition state
onTimeTime the receiver remains in Tracking state and produces position fixes
waitTimeFix
Wait for time fix before entering Tracking state
doNotEnterOff
Receiver does not enter (Inactive) Awaiting Next Search state if it can't get
a position fix but keeps indefinitely attempting a position fix instead
updateRTC
Enables periodic Real Time Clock (RTC) update
updateEPH
Enables periodic ephemeris update
extintSelectSelects EXTINT pin used with pin control feature
extintWake
Enables force-ON pin control feature
extintBackup
Enables force-OFF pin control feature
gridOffset
Time offset of update grid with respect to start of week
maxStartupStateDur Maximum time in Acquisition state
optTarget
The PSM settings will be weighed towards a specific target (onlysupported in protocol versions 23 to 23.01)
13.2.2.1 Mode of operation (mode)
The mode of operation to use mainly depends on the update period: For short update periods (inthe range of a few seconds), cyclic tracking should be configured. For long update periods (in therange of minutes or longer), only use ON/OFF operation.
See section ON/OFF operation - long update period and Cyclic tracking operation - short update
period for more information on the two modes of operation.
13.2.2.2 Reference Time Standard
In older versions ( in protocol versions less than 18), only GPS can be configured for PSM,
therefore, GPS time standard is used for the operation of PSM. Whereas, in newer versions wheremultiple GNSS can operate simultaneously ( in protocol versions 18+), UTC time standard is used.

UBX-13003221 - R17

Early Production Information

Page 60 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

13.2.2.3 Update period (updatePeriod) and search period (searchPeriod)
The update period specifies the time between successive position fixes. If no position fix can beobtained within the acquisition timeout, the receiver will retry after the time specified by thesearch period. Update and search periods are fixed with respect to an absolute time grid based onreference time standard (i.e., GPS Time or UTC. see Reference Time Standard). They do not referto the time of the last valid position fix or last position fix attempt.
New settings are ignored if the update period or the search period exceeds the maximum
number of milliseconds in a week. In that case the previously stored values remain
effective.
13.2.2.4 Minimum Acquisition Time (minAcqTime)The receiver tries to obtain a position fix for at least the time given in minAcqTime. If the receiver
determines that it needs more time for the given starting conditions then it will automaticallyprolong this time. If minAcqTime is set to zero then the minimum acquisition time is exclusively
determined by the receiver. Once the minAcqTime has expired, the receiver will terminate theacquisition state if either a fix is achieved or if the receiver estimates that any signals received are
insufficient (too weak or too few) for a fix to be possible.
13.2.2.5 On time (onTime)
The onTime parameter specifies how long the receiver stays in Tracking state before switching to
the POT state (in PSMCT) or (Inactive) Awaiting Next Fix state (in PSMOO).
13.2.2.6 Wait for time fix (waitTimeFix)
A time fix is a fix type in which the receiver will ensure that the time is accurate and confirmed towithin the limits set in UBX-CFG-NAV5. Enabling the waitTimeFix option will force the receiver tostay in Acquisition state until the time is known to within the configured limits then it willtransition to Tracking state. Enabling waitTimeFix will delay the transition from Acquisition state
to Tracking state by at least two extra seconds, thus, this should be taken into account (seeAcquisition Timeout). It is necessary to enable waitTimeFix in timing products.
The quality of the position fixes can also be configured by setting the limits in the message UBXCFG-NAV5. Setting harder limits in UBX-CFG-NAV5 will typically prolong the time in Acquisition
state. Thus, ensuring sufficient time is given to the receiver at start-up (when externallycontrolled) is necessary (see Acquisition Timeout Logic). When internally controlled, the receivercan make good judgement on the time needed in Acquisition state and no further adjustments will
be needed.
13.2.2.7 Maximum Startup State Duration (maxStartupStateDur)(only supported in protocol versions 17+).
The maxStartupStateDur is the maximum time that the receiver will spend in Startup state (i.e.,
Acquisition state). If the receiver is unable to acquire a valid position fix within this maximum time,
it will transition to (Inactive) Awaiting Next Search state (if doNotEnterOff is disabled).
Subsequently, the receiver will attempt to acquire another position fix according to the search
period (see Update period (updatePeriod) and search period (searchPeriod)). If
maxStartupStateDur is set to zero, the receiver will autonomously determine the maximum timeto spend in Acquisition state. Note that shorter settings (below about 45s) will degrade an
unaided receiver's ability to collect new Ephemeris data at low signal levels (see section Satellite

UBX-13003221 - R17

Early Production Information

Page 61 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

data download).
13.2.2.8 Do not enter '(Inactive) Awaiting Next Search' state when no fix (doNotEnterOff)
If this option is enabled, the receiver acts differently in case it can't get a fix: instead of entering(Inactive) Awaiting Next Search state, it keeps attempting to acquire a position fix. In other words,
the receiver will never be in (Inactive) Awaiting Next Search state and therefore searchPeriod andminAcqTime will be ignored.
13.2.2.9 Update RTC (updateRTC) and Ephemeris (updateEPH)
To maintain the ability of a fast start-up, the receiver needs to calibrate its RTC and update its
ephemeris data on a regular basis. This can be ensured by activating the update RTC and update
Ephemeris option. The RTC is calibrated every 5 minutes and the ephemeris data is updated
approximately every 30 minutes. See section Satellite data download for more information.
13.2.2.10 EXTINT pin control
The operation of PSM can be externally controlled using either EXTINT0 or EXTINT1 pin. This
external control allows the user to decide when to wake up the receiver to obtain a fix and when toforce the receiver into sleep/backup mode to save power. Operating the receiver externallythrough the EXTINT pins will override internal functions that coincide with that specific operation.
The choice of which pin to use can be configured through the extintSelect feature in UBX-CFG-PM2.
Only one pin can be selected at a time but it is sufficient to perform all the required tasks.
If the Force-ON (extintWake) feature in UBX-CFG-PM2 is enabled, the receiver will not enter Inactive
states for as long as the configured EXTINT pin (EXTINT0 or EXTINT1) is at 'high' level. The
receiver will therefore always be in Acquisition/Tracking state in PSMOO or in
Acquisition/Tracking/POT state in PSMCT. When the pin level changes to 'low' the receiver willcontinue with its configured behavior.
If the Force-OFF (extintBackup) feature in UBX-CFG-PM2 is enabled, the receiver will enter Inactive
states for as long as the configured EXTINT pin is set to 'low' until the next wake up event. Any
wake-up event can wake up the receiver even while the EXTINT pin is set to 'low' (see Wake up).
However, if the pin stay at 'low' state, the receiver will only wake up for the time needed to read theconfiguration pin settings then it will enter the Inactive state again.
If both Force-ON and Force-OFF features are enabled at the same time, the receiver PSM
operation will be completely in user control. Setting 'high' on the configured EXTINT pin will wakeup the receiver to get a position fix and setting 'low' will put the receiver into sleep/backup mode.
13.2.2.11 Grid offset (gridOffset)
Once the receiver has a valid time, the update grid is aligned to the start of the week of thereference time standard (midnight between Saturday and Sunday). Before having a valid time, theupdate grid is unaligned. A grid offset shifts the update grid with respect to the start of the weekof the reference time standard. An example of usage can be found in section Use grid offset.
The grid offset is not used in cyclic tracking operation.

UBX-13003221 - R17

Early Production Information

Page 62 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

13.2.2.12 Optimization target
In cyclic tracking operation, the behavior of the receiver can be tuned even more closely to theapplication's need by choosing an appropriate optimization target.
In protocol version 23.01 two optimization targets are available:• Performance: The receiver achieves a good GNSS performance while keeping the power
consumption low.
• Power save: The receiver might sacrifice GNSS performance in favor of a reduced power
consumption.
13.2.3 Features
13.2.3.1 Communication
When PSM is enabled, communication with the receiver (e.g. UBX message to disable PSM)
requires particular attention. This is because the receiver may be in Inactive state and therefore
unable to receive any message through its interfaces. To ensure that the configuration messages
are processed by the receiver, even while in Inactive state, the following steps need to be taken:• Send a dummy sequence of 0xFF (one byte is sufficient) to the receiver's UART interface. This
will wake up the receiver if it is in Inactive state. If the receiver is not in Inactive state, thesequence will be ignored.
• Send the configuration message about half a second after the dummy sequence. If the interval
between the dummy sequence and the configuration message is too short, the receiver may not
yet be ready. If the interval is too long, the receiver may return to Inactive state before theconfiguration message was received. It is therefore important to check for a UBX-ACK-ACK reply
from the receiver to confirm that the configuration message was received.
• Send the configuration save message immediately after the configuration message.
Similarly, when configuring the receiver for PSMOO (and PSMCT when doNotEnterOff is disabled),
ensure that the configurations are saved. If they are not saved the receiver will enter backup mode
and when it wakes up again, it would have lost the configurations and even forgets it was in powersave mode. This can be avoided by using the UBX-CFG-CFG message (see Receiver Configuration
for details). When operating PSM from u-Center and setting the receiver to Power Save Mode in
UBX-CFG-RXM, check the save configuration box. u-Center will then send a UBX-CFG-CFG message
after the UBX-CFG-RXM to save the configurations.
13.2.3.2 Wake up
The receiver can be woken up by generating an edge on one of the following pins:• rising or falling edge on one of the EXTINT pins
• rising or falling edge on the RXD1 pin• rising or falling edge on the SPI CS pin• rising edge on NRESET pin
All wake-up signals are interpreted as a position request, where the receiver wakes up and tries toobtain a position fix. Wake-up signals have no effect if the receiver is already in Acquisition,
Tracking or POT state.

UBX-13003221 - R17

Early Production Information

Page 63 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

13.2.3.3 Behavior while USB host connected
As long as the receiver is connected to a USB host, it will not enter the lowest possible powerstate. This is because it must retain a small level of CPU activity to avoid breaching requirementsof the USB specification. The drawback, however, is that power consumption is higher.
Wake up by pin/UART is possible even if the receiver is connected to a USB host. In thiscase the state of the pin must be changed for a duration longer than one millisecond.
13.2.3.4 Cooperation with the AssistNow Autonomous feature
If both PSM and AssistNow Autonomous features are enabled, the receiver won't enter (Inactive)
Awaiting Next Fix state as long as AssistNow Autonomous carries out calculations. This preventslosing data from unfinished calculations and, in the end, reduces the total extra power needed for
AssistNow Autonomous. The delay before entering (Inactive) Awaiting Next Fix state, if any, will bein the range of several seconds, rarely more than 20 seconds.
Only entering (Inactive) Awaiting Next Fix state is affected by AssistNow Autonomous. In otherwords: in cyclic tracking operation, AssistNow Autonomous will not interfere with the PSM (apartfrom the increased power consumption).
Enabling the AssistNow Autonomous feature will lead to increased power consumption
while prediction is calculated. The main goal of PSM is to reduce the overall power
consumption. Therefore for each application special care must be taken to judge
whether AssistNow Autonomous is beneficial to the overall power consumption or not.
13.2.4 Examples
13.2.4.1 Use Grid Offset
Scenario: Get a position fix once a day at a fixed time. If the position fix cannot be obtained try
again every two hours.
Solution: First set the update period to 24*3600s and the search period to 2*3600s. Now aposition fix is obtained every 24 hours and if the position fix fails retrials are scheduled in two hourintervals. As the update grid is aligned to midnight Saturday/Sunday reference time standard, theposition fixes happen at midnight reference time standard. By setting the grid offset to 12*3600s
the position fixes are shifted to once a day at noon reference time standard. If the position fix atnoon fails, retrials take place every two hours, the first at 14:00reference time standard. Upon
successfully acquiring a position fix the next fix attempt is scheduled for noon the following day.
13.2.4.2 User controlled position fix
Scenario: Get a position fix on request.
Solution: Set updatePeriod and searchPeriod to zero. Set extintSelect to the desired EXTINT pin
to be used. Enable the extintWake and extintBackup features.
13.2.4.3 Use update periods of 30 minutes
Scenario: Get a position fix once every 30 minutes and acquire a fix needed for timing products
Solution: Set mode of operation to PSMOO. Set updatePeriod to 1800 seconds. Set the search
period to 120 seconds. Enable waitTimeFix feature.

UBX-13003221 - R17

Early Production Information

Page 64 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

13.3 Peak current settings
The peak current during acquisition can be reduced by activating the corresponding option in UBXCFG-PM2. A peak current reduction will result in longer start-up times of the receiver.
This setting is independent of the activated mode (Continuous or Power Save Mode).

13.4 Power On/Off commandWith message UBX-RXM-PMREQ the receiver can be forced to enter Inactive state (in Continuousand Power Save Mode). It will stay in Inactive state for the time specified in the message or until it
is woken up by an EXTINT or activity on the RXD1, SPI CS, or NRESET pin.
Sending the message UBX-RXM-PMREQ while the receiver is in Power Save Mode will
overrule PSM and force the receiver to enter Inactive state. It will stay in Inactive state
until woken up. After wake-up the receiver continues working in Power Save Mode asconfigured.

13.5 EXTINT pin control when Power Save Mode is not active
The receiver can be forced OFF also when the Power Save Mode is not active. This works the same
way as EXTINT pin control in Power Save Mode. Just as in Power Save Mode, this feature has to beenabled and configured using UBX-CFG-PM2

13.6 Measurement and navigation rate with Power Save ModeIn Continuous Mode, measurement and navigation rate is configured using UBX-CFG-RATE. In
Power Save Mode however, measurement and navigation rate can differ from the configured rates
as follows:• Cyclic Operation: When in state Power Optimized Tracking, the measurement and navigation
rate is determined by the updatePeriod configured in UBX-CFG-PM2. The receiver can however
switch to Tracking state (e.g. to download data). When in Tracking state, the measurement andnavigation rate is as configured with UBX-CFG-RATE. Note: When the receiver is no longer able toproduce position fixes, it can switch from Cyclic Operation to ON/OFF Operation (if this is notdisabled with the doNotEnterOff switch in UBX-CFG-PM2). In that case the remarks below are
relevant.
• ON/OFF Operation: ( in protocol versions less than 18) when in state Acquisition, themeasurement and navigation rate is fixed to 2Hz. All NMEA (and UBX) messages that are
output upon a navigation fix are also output with a rate of 2Hz. This must be considered whenchoosing the baud rate of a receiver that uses Power Save Mode! Note that a receiver mightstay in Acquisition state for quite some time (can be tens of seconds under weak signal
conditions). When the receiver eventually switches to Tracking state, the measurement andnavigation rate will be as configured with UBX-CFG-RATE. However, ( in protocol versions 18+)
the measurement and navigation rate will be as configured with UBX-CFG-RATE in all active
states.

13.7 Power Mode Setup(Not supported in protocol versions less than 18).
In order to simplify the power saving configuration of the receiver in typical circumstances, a setof predefined setups can be selected using the message UBX-CFG-PMS.

UBX-13003221 - R17

Early Production Information

Page 65 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Selecting one of the available setups (listed below) is the equivalent of using a combination of theconfiguration messages with appropriate parameters that impact the power consumption of thereceiver.
Valid Power Mode Setup in UBX-CFG-PMS
Setup Name

Description

Full Power
Balanced
Aggressive 1Hz

No compromises on power saves
Power savings without performance degradation
Best power saving setup (1Hz rate). This corresponds to Super-E mode
performance setting.
Excellent power saving setup (2Hz rate)
Good power saving setup (4Hz rate)
ON OFF mode setup

Aggressive 2Hz
Aggressive 4Hz
Interval

u-blox recommends using these predefined settings, except where users have very specific powersaving requirements.
Note that polling UBX-CFG-PMS will return the setup only if the full configuration is consistent
with one of the predefined Power Mode Setups.
In 4Hz mode, when running a flash firmware, it is recommended to run with a subset of
GNSS systems, to avoid system overload.
Using UBX-CFG-PMS to set Super-E mode 1, 2, 4Hz navigation rates sets 180 s
minAcqTime instead the default 300 s in protocol version 23.01. 300 s is recommended
for the best performance.

14 Forcing a Receiver Reset
Typically, in GNSS receivers, one distinguishes between cold, warm, and hot starts, depending on
the type of valid information the receiver has at the time of the restart.
• Cold start In cold start mode, the receiver has no information from the last position (e.g. time,
velocity, frequency etc.) at startup. Therefore, the receiver must search the full time andfrequency space, and all possible satellite numbers. If a satellite signal is found, it is tracked to
decode the ephemeris (18-36 seconds under strong signal conditions), whereas the otherchannels continue to search satellites. Once there is a sufficient number of satellites with valid
ephemeris, the receiver can calculate position and velocity data. Other GNSS receiver
manufacturers call this startup mode Factory Startup.
• Warm start In warm start mode, the receiver has approximate information for time, position,and coarse satellite position data (Almanac). In this mode, after power-up, the receiver normallyneeds to download ephemeris before it can calculate position and velocity data. As theephemeris data usually is outdated after 4 hours, the receiver will typically start with a Warm
start if it has been powered down for more than 4 hours. In this scenario, several augmentations
are possible. See the section on Multi-GNSS Assistance.
• Hot start In hot start mode, the receiver was powered down only for a short time (4 hours orless), so that its ephemeris is still valid. Since the receiver doesn't need to download ephemeris
again, this is the fastest startup method.
In the UBX-CFG-RST message, one can force the receiver to reset and clear data, in order to see theeffects of maintaining/losing such data between restarts. For this, the CFG-RST message offers
the navBbrMask field, where hot, warm and cold starts can be initiated, and also other

UBX-13003221 - R17

Early Production Information

Page 66 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

combinations thereof.
Data stored in flash memory is not cleared by any of the options provided by UBX-CFGRST. So, for example, if valid AssistNow Offline data stored in the flash it is likely to havean impact on a "cold start".
The Reset Type can also be specified. This is not related to GNSS, but to the way the software
restarts the system.
• Hardware Reset uses the on-chip Watchdog, in order to electrically reset the chip. This is animmediate, asynchronous reset. No Stop events are generated. This is equivalent to pull the
Reset signal of the receiver to ground.
• Controlled Software Reset terminates all running processes in an orderly manner and, once thesystem is idle, restarts operation, reloads its configuration and starts to acquire and track
GNSS satellites.
• Controlled Software Reset (GNSS only) only restarts the GNSS tasks, without reinitializing thefull system or reloading any stored configuration.
• Controlled GNSS Stop stops all GNSS tasks. The receiver will not be restarted, but will stop any
GNSS related processing.
• Controlled GNSS Start starts all GNSS tasks.

15 Receiver Status Monitoring
Messages in the UBX class UBX-MON are used to report the status of the parts of the embedded
computer system that are not GNSS specific.
The main purposes are• Hardware and Software Versions, using UBX-MON-VER. See also the chapter decoding the output
of UBX-MON-VER• Status of the Communications Input/Output system• Status of various Hardware Sections with UBX-MON-HW

15.1 Input/Output system
The I/O system is a GNSS-internal layer where all data input- and output capabilities (such as
UART, DDC, SPI, USB) of the GNSS receiver are combined. Each communications task has buffers
assigned, where data is queued. For data originating at the receiver, to be communicated over one
or multiple communications queues, the message UBX-MON-TXBUF can be used. This message
shows the current and maximum buffer usage, as well as error conditions.
If the amount of data configured is too much for a certain port's bandwidth (e.g. all UBX
messages output on a UART port with a baud rate of 9600), the buffer will fill up. Oncethe buffer space is exceeded, new messages to be sent will be dropped. For details see
section Serial Communication Ports Description
Inbound data to the GNSS receiver is placed in buffers. Usage of these buffers is shown with themessage UBX-MON-RXBUF. Further, as data is then decoded within the receiver (e.g. to separate
UBX and NMEA data), the UBX-MON-MSGPP can be used. This message shows (for each port andprotocol) how many messages were successfully received. It also shows (for each port) how many
bytes were discarded because they were not in any of the supported protocol framings.
The following table shows the port numbers used. Note that any numbers not listed are reserved
for future use.
UBX-13003221 - R17

Early Production Information

Page 67 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Port Number assignment
Port #

01
3
4Electrical Interface

DDC (I²C compatible)
UART 1
USB
SPI

Protocol numbers range from 0-7. All numbers not listed are reserved.
Protocol Number assignment
Protocol #0
1
2

Protocol NameUBX Protocol
NMEA Protocol
RTCM Protocol

15.2 Jamming/Interference Indicator
The field jamInd of the UBX-MON-HW message can be used as an indicator for continuous wave
(narrowband) jammers/interference only. The interpretation of the value depends on theapplication. It is necessary to run the receiver in an unjammed environment to determine anappropriate value for the unjammed case. If the value rises significantly above this threshold, thisindicates that a continuous wave jammer is present.
This indicator is always enabled.
The indicator is reporting any currently detected narrowband interference over all currently
configured signal bands

15.3 Jamming/Interference Monitor (ITFM)
The field jammingState of the UBX-MON-HW message can be used as an indicator for both
broadband and continuous wave (CW) jammers/interference. It is independent of the (CW only)
jamming indicator described in Jamming/Interference Indicator above.
This monitor reports whether jamming has been detected or suspected by the receiver. The
receiver monitors the background noise and looks for significant changes. Normally, with nointerference detected, it will report 'OK'. If the receiver detects that the noise has risen above a
preset threshold, the receiver reports 'Warning'. If in addition, there is no current valid fix, thereceiver reports 'Critical'.
The monitor has four states as shown in the following table:
Jamming/Interference monitor reported states
Value

Reported

Description

state

0
1
2
3

Unknown Jamming/interference monitor not enabled, uninitialized
or antenna disconnectedOK
no interference detected
Warning
position ok but interference is visible (above thethresholds)
Criticalno reliable position fix and interference is visible (above
the thresholds); interference is probable reason why
there is no fix

UBX-13003221 - R17

Early Production Information

Page 68 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The monitor is disabled by default. The monitor is enabled by sending an appropriate UBX-CFGITFM message with the enable bit set. In this message it is also possible to specify the thresholds
at which broadband and CW jamming are reported. These thresholds should be interpreted as thedB level above 'normal'. It is also possible to specify whether the receiver expects an active or
passive antenna.
The monitor algorithm relies on comparing the currently measured spectrum with areference from when a good fix was obtained. Thus the monitor will only function when
the receiver has had at least one (good) first fix, and will report 'Unknown' before thistime.
Jamming/Interference monitor is not supported in Power Save Mode (PSM) ON/OFF
mode.
The monitor is reporting any currently detected interference over all currently configured signal
bands

16 Spoofing Detection(Note: this feature is not supported in protocol versions less than 18).

16.1 Introduction
Spoofing is the process whereby someone tries to forge a GNSS signal with the intention offooling the receiver into calculating a different user position than the true one.
The spoofing detection feature monitors the GNSS signals for suspicious patterns indicating thatthe receiver is being spoofed. A flag in UBX-NAV-STATUS alerts the user to potential spoofing.

16.2 Scope
The spoofing detection feature monitors suspicious changes in the GNSS signal indicatingexternal manipulation. Therefore the detection is only successful when the signal is genuine firstand when the transition to the spoofed signal is being observed directly. When a receiver isstarted up to a spoofed signal the detection algorithms will be unable to recognize the spoofing.
Also, the algorithms rely on availability of signals from multiple GNSS; the detection does not workin single GNSS mode.

17 Signal Attenuation Compensation(not supported in protocol versions less than 19).
In normal operating conditions, low signal strength indicates likely contamination by multipath.
The receiver trusts such signals less in order to preserve the quality of the position solution inpoor 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 thiscase, the signal attenuation compensation feature can be used to restore normal performance.
There are three possible modes:• Disabled: no signal attenuation compensation is performed• Automatic: the receiver automatically estimates and compensates for the signal attenuation• Configured: the receiver compensates for the signal attenuation based on a configured value
These modes can be selected using UBX-CFG-NAVX5. In the case of the "configured" mode, theuser should input the maximum C/N0 observed in a clear-sky environment, excluding any outliers

UBX-13003221 - R17

Early Production Information

Page 69 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualor unusually high values. The configured value can have a large impact on the receiver
performance, so should be chosen carefully.

18 Remote Inventory
18.1 Description
The Remote Inventory enables storing user-defined data in the non-volatile memory of thereceiver. The data can be either binary or a string of ASCII characters. In the second case, it will be
output at startup after the boot screen.

18.2 Usage• The contents of the Remote Inventory can be set and polled with the message UBX-CFG-RINV.
Refer to the message specification for a detailed description.
• If the contents of the Remote Inventory are polled without having been set before, the default
configuration (see table below) is output.
Default configuration
Parameter

Value

flags
data

0x00
"Notice: no data saved!"
As with all configuration changes, these must be saved in order to be made permanent.
Make sure to save the section RINV before resetting or switching off the receiver. For
more information about saving a configuration, see section Configuration Concept.

19 Time pulse
For protocol versions less than 18, functionality of the time pulse has not beencharacterized when only BeiDou is enabled.
The time pulse feature is not available for protocol versions 23-23.01.

19.1 Introduction
u-blox receivers include a time pulse function providing clock pulses with configurable durationand frequency. The time pulse function can be configured using the UBX-CFG-TP5 message. The
UBX-TIM-TP message provides time information for the next pulse, time source and thequantization error of the output pin.

UBX-13003221 - R17

Early Production Information

Page 70 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

19.2 Recommendations• The time pulse can be aligned to a wide variety of GNSS times or to variants of UTC derived fromthem (see the section on time bases). However, it is strongly recommended that the choice oftime base is aligned with the available GNSS signals (so to produce GPS time or UTC(USNO),
ensure GPS signals are available, and for GLONASS time or UTC(SU) ensure the presence
GLONASS signals). This will involve coordinating that the setting of UBX-CFG-GNSS with the
choice of time pulse time base.
• For best time pulse performance it is recommended to disable the SBAS subsystem.
• When using time pulse for precision timing applications it is recommended to calibrate theantenna cable delay against a reference-timing source.
• Care needs to be given to the cable delay settings in the receiver configuration.
• In order to get the best timing accuracy with the antenna, a fixed and accurate position isneeded.
• If relative time accuracy between multiple receivers is required, do not mix receivers of different
product families. If this is required, the receivers must be calibrated accordingly, by setting
cable delay and user delay.
• The recommended configuration when using the UBX-TIM-TP message is to set both themeasurement rate (UBX-CFG-RATE) and the time pulse frequency (UBX-CFG-TP5) to 1Hz.
Since the rate of UBX-TIM-TP is bound to the measurement rate, more than one UBXTIM-TP message can appear between two pulses if the measurement rate is set larger
than the time pulse frequency. In this case all UBX-TIM-TP messages in between a time
pulse T1 and T2 belong to T2 and the lastUBX-TIM-TP before T2 reports the mostaccurate quantization error. In general, if the navigation solution rate and time pulse rate
are configured to different values, there will not be a single UBX-TIM-TP message foreach time pulse.
The sequential order of the signal present at the TIMEPULSE pin and the respective output
message for the simple case of 1 pulse per second (1PPS) and a one second navigation update rateis shown in the following figure.

UBX-13003221 - R17

Early Production Information

Page 71 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

19.3 GNSS time bases
GNSS receivers must handle a variety of different time bases as each GNSS has its own reference
system time. What is more, although each GNSS provides a model for converting their systemtime into UTC, they all support a slightly different variant of UTC. So, for example, GPS supports avariant of UTC as defined by the US National Observatory, while BeiDou uses UTC from the
National Time Service Center, China (NTSC). While the different UTC variants are normally closelyaligned, they can differ by as much as a few hundreds of nanoseconds.
Although u-blox receivers can combine a variety of different GNSS times internally, the user mustchoose a single type of GNSS time and, separately, a single type of UTC for input (on EXTINTs)
and output (via the Time Pulse) and the parameters reported in corresponding messages.
For protocol versions 16 or greater, the UBX-CFG-TP5 message allows the user to choose between
any of the supported GNSS (GPS, GLONASS, BeiDou, etc) times and UTC. Also, the UBX-CFG-NAV5
message allows the user to select which variant of UTC the receiver should use. This includes an"automatic" option which causes the receiver to select an appropriate UTC version itself, based on
the GNSS configuration, using, in order of preference, USNO if GPS is enabled, SU if GLONASS isenabled, NTSC if BeiDou is enabled and, finally, European if Galileo is enabled.
Note that for protocol versions prior to 16, no choice of UTC variant is supported and the UBX-CFGTP5 message only allows the user to choose between GPS and UTC as the time system thegenerated time pulse will be aligned to.
The receiver will assume that the input time pulse uses the same GNSS time base as specified forthe output using UBX-CFG-TP5. So if the user selects GLONASS time for time pulse output, any
time pulse input must also be aligned to GLONASS time (or to the separately chosen variant of
UTC). Where UTC is selected for time pulse output, any GNSS time pulse input will be assumed to
be aligned to GPS time.
u-blox receivers allow users to choose independently GNSS signals used in the receiver(using UBX-CFG-GNSS) and the input/output time base (using UBX-CFG-TP5). For
example it is possible to instruct the receiver to use GPS and GLONASS satellite signals
to generate BeiDou time. This practice will compromise time-pulse accuracy if thereceiver cannot measure the timing difference between the constellations directly and is
not recommended.
The information that allows GNSS times to be converted to the associated UTC times isonly transmitted by the GNSS at relatively infrequent periods. For example GPStransmits UTC(USNO) information only once every 12.5 minutes. Therefore, if a TimeUBX-13003221 - R17

Early Production Information

Page 72 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Pulse is configured to use a variant of UTC time, after a cold start, substantial delays
before the receiver has sufficient information to start outputing the Time Pulse can be
expected.

19.4 Time pulse configuration
u-blox receivers provide one or two TIMEPULSE pins (dependent on product variant) delivering atime pulse (TP) signal with a configurable pulse period, pulse length and polarity (rising or fallingedge). Check the product data sheet for detailed specification of configurable values.
It is possible to define different signal behavior (i.e. output frequency and pulse length) dependingon whether or not the receiver is locked to a reliable time source. Time pulse signals can be
configured using the UBX proprietary message UBX-CFG-TP5.

19.5 Configuring time pulse with UBX-CFG-TP5
The UBX message UBX-CFG-TP5 can be used to change the time pulse settings, and includes thefollowing parameters defining the pulse:• time pulse index - Index of time pulse output pin to be configured. If a product only has one time
pulse output it is typically configurable with index 0. Exceptions to this include LEA-M8F,
M8030-KT-FT and NEO-M8L. Please refer to specific product documentation.
• antenna cable delay - Signal delay due to the cable between antenna and receiver.
• RF group delay - Signal delay in the RF module of the receiver (read-only).
• pulse frequency/period - Frequency or period time of the pulse when locked mode is notconfigured or active.
• pulse frequency/period lock - Frequency or period time of the pulse, as soon as receiver has
calculated a valid time from a received signal. Only used if the corresponding flag is set to use
another setting in locked mode.
• pulse length/ratio - Length or duty cycle of the generated pulse, either specifies a time or ratio
for the pulse to be on/off.
• pulse length/ratio lock - Length or duty cycle of the generated pulse, as soon as receiver has
calculated a valid time from a received signal. Only used if the corresponding flag is set to use
another setting in locked mode.
• user delay - The cable delay from the receiver to the user device plus signal delay of any user
application.
• active - time pulse will be active if this bit is set.
• lock to gps freq - Use frequency gained from GPS signal information rather than local
oscillator's frequency if flag is set.
• lock to gnss freq - Use frequency gained from GNSS signal information rather than local
oscillator's frequency if flag is set.
• locked other setting - If this bit is set, as soon as the receiver can calculate a valid time, thealternative setting is used. This mode can be used for example to disable time pulse if time is
not locked, or indicate lock with different duty cycles.
• is frequency - Interpret the 'Frequency/Period' field as frequency rather than period if flag is set.
• is length - Interpret the 'Length/Ratio' field as length rather than ratio if flag is set.
• align to TOW - If this bit is set, pulses are aligned to the top of a second.

UBX-13003221 - R17

Early Production Information

Page 73 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• polarity - If set, the first edge of the pulse is a rising edge (Pulse Mode: Rising).
• grid UTC/GPS - Selection between UTC (0) or GPS (1) timegrid. Also effects the time output by
UBX-TIM-TP message.
• grid UTC/GNSS - Selection between UTC (0), GPS (1), GLONASS (2) and Beidou (3) timegrid.
Also effects the time output by UBX-TIM-TP message.
The maximum pulse length can't exceed the pulse period.
Time pulse settings shall be chosen in such a way, that neither the high nor the low
period of the output is less than 50 ns (except when disabling it completely), otherwise
pulses can be lost.
The maximum frequency of the second time pulse pin (TIMEPULSE2) is limited to 1kHz
for protocol versions less than 18unless using a Timing product variant.
19.5.1 Example 1
The example below shows the 1PPS TP signal generated on the time pulse output according to thespecific parameters of the UBX-CFG-TP5 message:• tpIdx = 0• freqPeriod = 1 s• pulseLenRatio = 100 ms• active = 1• lockGpsFreq = lockGnssFreq = 1• isLength = 1• alignToTow = 1• polarity = 1• gridUtcGps = gridUtcGnss = 1
The 1 Hz output is maintained whether or not the receiver is locked to GPS time. The alignment to
TOW can only be maintained when GPS time is locked.

19.5.2 Example 2This example only works with a Timing product variant or for protocol versions greater than 17.
The following example shows a 10 MHz TP signal generated on the TIMEPULSE2 output when thereceiver is locked to GPS time. Without the lock to GPS time no frequency is output.

UBX-13003221 - R17

Early Production Information

Page 74 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• tpIdx = 1• freqPeriod = 1 Hz
• pulseLenRatio = 0• freqPeriodLock = 10 MHz• pulseLenRatioLock = 50%• active = 1• lockGpsFreq = lockGnssFreq = 1• lockedOtherSet = 1• isFreq = 1• alignToTow = 1• polarity = 1• gridUtcGps = gridUtcGnss = 1

20 Timemark
The receiver can be used to provide an accurate measurement of the time at which a pulse was
detected on the external interrupt pin. The reference time can be chosen by setting the timesource parameter to UTC, GPS, GLONASS, BeiDou, Galileo or local time in the UBX-CFG-TP5
configuration message. The UTC standard can be set in the UBX-CFG-NAV5 configuration
message. The delay figures defined with UBX-CFG-TP5 are also applied to the results output in the
UBX-TIM-TM2 message.
A UBX-TIM-TM2 message is output at the next epoch if• the UBX-TIM-TM2 message is enabled• a rising or falling edge was triggered since last epoch on one of the EXTINT channels
The UBX-TIM-TM2 messages include time of the last timemark, new rising/falling edge indicator,
time source, validity, number of marks and a quantization error. The timemark is triggered
continuously.
Only the last rising and falling edge detected between two epochs is reported since theoutput rate of the UBX-TIM-TM2 message corresponds to the measurement rate
configured with UBX-CFG-RATE (see Figure below).

UBX-13003221 - R17

Early Production Information

Page 75 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

21 Odometer
21.1 Introduction
The odometer provides information on travelled ground distance (in meter) using solely the
position and Doppler-based velocity of the navigation solution. For each computed travelled
distance since the last odometer reset, the odometer estimates a 1-sigma accuracy value. The
total cumulative ground distance is maintained and saved in the BBR memory.
The odometer feature is disabled by default. It can be enabled using the UBX-CFG-ODO
message.

21.2 Odometer Output
The odometer output is published in the UBX-NAV-ODO message. This message contains thefollowing elements:• Ground distance since last reset (distance field): this distance is defined as the total cumulated
distance in meters since the last time the odometer was reset (see section Resetting the
Odometer);• Ground distance accuracy (distanceStd field): this quantity is defined as the 1-sigma accuracy
estimate (in meters) associated to the Ground distance since last reset value;• Total cumulative ground distance (totalDistance field): this quantity is defined as the total
cumulated distance in meters since the last time the receiver was cold started (see section
Resetting the Odometer).
If logging is enabled, then the odometer's ground distance since last reset value will be included in

UBX-13003221 - R17

Early Production Information

Page 76 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

the logged position data (see section Logging).

21.3 Odometer Configuration
The odometer can be enabled/disabled by setting the appropriate flag in UBX-CFG-ODO (flags
field). The algorithm behaviour can be optimized by setting up a profile (odoCfg field)
representative of the context in which the receiver is operated. The implemented profiles together
with their meanings are listed below:• Running: the algorithm is optimized for typical dynamics encountered while running, i.e theDoppler-based velocity solution is assumed to be of lower quality;• Cycling: the algorithm is optimized for typical dynamics encountered while cycling;• Swimming: the algorithm is optimized for very slow and smooth trajectories typicallyencountered while swimming;• Car: the algorithm assumes that good Doppler measurements are available (i.e. the antenna issubject to low vibrations) and is optimized for typical dynamics encountered by cars.
The odometer can only be reliably operated in a swimming context if satellite signals areavailable and the antenna is not immersed.

21.4 Resetting the Odometer
The odometer outputs (see UBX-NAV-ODO message) can be reset by the following means:• Ground distance since last reset (distance field): by sending a UBX-NAV-RESETODO message;• Ground distance accuracy (distanceStd field): by sending a UBX-NAV-RESETODO message;• Total cumulative ground distance (totalDistance): by a cold start of the receiver (this erases the
BBR memory);

22 Logging
22.1 Introduction
The logging feature allows position fixes and arbitrary byte strings from the host to be logged in
flash memory attached to the receiver. Logging of position fixes happens independently of thehost system, and can continue while the host is powered down.
The following tables list all the logging related messages:
Logging control and configuration messages
Message

Description

UBX-LOG-CREATEUBX-LOG-ERASEUBX-CFG-LOGFILTERUBX-LOG-INFOUBX-LOG-STRING

Creates a log file and activates the logging subsystem
Erases a log file and deactivates the logging subsystem
Used to start/stop recording and set/get the logging configuration
Provides information about the logging system
Enables a host process to write a string of bytes to the log file

Logging retrieval messages
Message

Description

UBX-LOG-RETRIEVEUBX-LOG-RETRIEVEPOS

Starts the log retrieval process
A position log entry returned by the receiver

UBX-13003221 - R17

Early Production Information

Page 77 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Logging retrieval messages continued
Message

Description

UBX-LOGOdometer position data
RETRIEVEPOSEXTRAUBX-LOG-RETRIEVESTRING A byte string log entry returned by the receiver
UBX-LOG-FINDTIME
Finds the index of the first entry <= given time

22.2 Setting the logging system up
An empty log can be created using the UBX-LOG-CREATE message and a log can be deleted with
the UBX-LOG-ERASE message. The logging system will only be running if a log is in existence, somost logging messages will be rejected with an UBX-ACK-NAK message if there is no log present.
Only one log can be created at any one time so an UBX-ACK-NAK message will be returned if a log
already exists. The message specifies the maximum size of the log in bytes (with some pre-set
values provided). Both the logging subsystem and the receiver file-store have implementation
overheads, so total space available for log entries will be somewhat smaller than the size
specified.
UBX-LOG-CREATE also allows the log to be specified as a circular log. If the log is circular, thenwhen it fills up, a set of older log entries will be deleted and the space freed up used for new log
entries. By contrast, if a non-circular log becomes full then new entries which don't fit will berejected. UBX-LOG-CREATE also causes the logging system to start up so that further logging
messages can be processed. The logging system will start up automatically on power-up if there isa log in existence. The log will remain in the receiver until specifically erased using the UBX-LOGERASE message.
UBX-CFG-LOGFILTER controls whether logging of entries is currently enabled and selects position
fix messages for logging. These configuration settings will be saved if the configuration is saved
to flash. If this is done, then entry logging will continue on power-up in the same manner that it did
before power-down.
The top level active/inactive states of the logging subsystem.

22.3 Information about the log
The receiver can be polled for a UBX-LOG-INFO message which will give information about the log.
This will include the maximum size that the log can grow to (which, due to overheads, will besmaller than that requested in UBX-LOG-CREATE) and the amount of log space currently occupied.
It will also report the number of entries currently in the log together with the time and date of thenewest and oldest messages which have a valid time stamp.
Log entries are compressed and have housekeeping information associated with them, so theactual space occupied by log messages may be difficult to predict. The minimum size for a
UBX-13003221 - R17

Early Production Information

Page 78 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

position fix entry is 9 bytes and the maximum 24 bytes, the typical size is 10 or 11 bytes. If theodometer is enabled then this will use at least another three bytes per fix.
Each log also has a fixed overhead which is dependent on the log type. The approximate size of
this overhead is shown in the following table.
Log overhead size
Log type

Overheadcircularnon-circular

Up to 40 kB
Up to 8 kB

The number of entries that can be logged in any given flash size can be estimated as follows:
Approx. number of entries = (flash size available for logging - log
overhead)/typical entry size
For example, if 1500 kB of flash is available for logging (after other flash usage such as thefirmware image is taken into account) a non-circular log would be able to contain approximately
139000 entries ((1500*1024)-(8*1024))/11 = 138891.

22.4 Recording
The UBX-CFG-LOGFILTER message specifies the conditions under which entries are recorded.
Nothing will be recorded if recording is disabled, otherwise position fix and UBX-LOG-STRING
entries can be recorded. When recording is enabled an entry will also be created from each UBXLOG-STRING message. These will be timestamped if the receiver has current knowledge of time.
The UBX-CFG-LOGFILTER message has several values which can be used to select position fix
entries for logging. If all of these values are zero, then all position fixes will be logged (subject to a
maximum rate of 1Hz). A position is logged if any of the thresholds are exceeded. If a threshold is
set to zero it is ignored. In addition the position difference and current speed thresholds also havea minimum time threshold.
Position fixes are only recorded if a valid fix is obtained - failed and invalid fixes are not recorded.
Position fixes are compressed to economise on the amount of flash space used. In order toimprove the compression, the fix values are rounded to improve their compression. This meansthat the values returned by the logging system may differ slightly from any which are gathered inreal time.
In On/Off Power Save Mode it is possible to configure the logging system so that only one fix isrecorded for each on period. This will be recorded immediately before the receiver powers off andwill be the best fix seen during the on period (in this case, "best" is defined as being the fix with thelowest horizontal accuracy figure).
The recorded data for a fix comprises :• The time and date of the fix recorded to a precision of one second• Latitude and longitude to a precision of one millionth of a degree. Depending on position on
Earth this is a precision in the order of 0.1m
• Altitude (height above mean sea level) to a precision of 0.1m. Entries with an altitude lower than
-470m (lower than the lowest point on earth) or higher than 20,000m may not be recorded in thelog.
• Ground speed to a precision of 1cm/s• The fix type (only successful fix types, since these are the only ones recorded)

UBX-13003221 - R17

Early Production Information

Page 79 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• The number of satellites used in the fix is recorded, but there is a maximum count which can berecorded. If the actual count exceeds this maximum count then the maximum count will berecorded. If a log entry is retrieved with a satellite count equal to the maximum this means thatvalue or more. The maximum count is 51. (The maximum count is 19 inprotocol versions lessthan 24)• A horizontal accuracy estimate is recorded to give an indication of fix quality. This is anapproximate compressed representation of the accuracy as determined by the fix process. Any
accuracy less than 0.7m will be recorded as 0.7m and any value above 1km will be recorded as
1km. Within these limits, the recorded accuracy will always be greater than the fix accuracy
number (by up to 40%)
• Heading to a precision of one degree• Odometer distance data (if odometer is enabled)
The states of the active logging subsystem

22.5 Retrieval
UBX-LOG-RETRIEVE starts the process which allows the receiver to output log entries. Log
recording must be stopped using UBX-CFG-LOGFILTER before this can be done. UBX-LOG-INFO
may be helpful to a host system in order to understand the current log status before retrieval isstarted.
Once retrieval has started, one message will be output from the receiver for each log entry
requested. Sending any logging message to the receiver during retrieval will cause the retrieval tostop before the message is processed.
To maximise the speed of transfer it is recommended that a high communications data rate isused and GNSS processing is stopped during the transfer (see UBX-CFG-RST)UBX-LOG-RETRIEVE can specify a start-entry index and entry-count. The maximum number of
entries that can be returned in response to a single UBX-LOG-RETRIEVE message is 256. If more
entries than this are required the message will need to be sent multiple times with different
startEntry indices.

UBX-13003221 - R17

Early Production Information

Page 80 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The receiver will send a UBX-LOG-RETRIEVEPOS message for each position fix log entry and a UBXLOG-RETRIEVESTRING message for each string log entry. If the odometer was enabled at the time
a position was logged, then a UBX-LOG-RETRIEVEPOSEXTRA will also be sent. Messages will besent in the order in which they were logged, so UBX-LOG-RETRIEVEPOS and UBX-LOGRETRIEVESTRING messages may be interspersed in the message stream.
The UBX-LOG-FINDTIME message can be used to search a log for the index of the first entry lessthan or equal to the given time. This index can then be used with the UBX-LOG-RETRIEVE message
to provide time-based retrieval of log entries.

22.6 Command message acknowledgement
Some log operations may take a long time to execute because of the time taken to write to flash
memory. The time for some operations may be unpredictable since the number and timing of
flash operations may vary. In order to allow host software to synchronise to these delays logging
messages will always produce a response. This will be UBX-ACK-NAK in case of error, otherwise UBXACK-ACK unless there is some other defined response to the message.
It is possible to send a small number of logging commands without waiting for acknowledgement,
since there is a command queue, but this risks confusion between the acknowledgements for thecommands. Also a command queue overflow would result in commands being lost.

23 Data Batching(Note: this functionality is supported only in protocol versions 23.01).

23.1 Introduction
The data batching feature allows position fixes to be stored in the RAM of the receiver to be
retrieved later in one batch. Batching of position fixes happens independently of the host system,
and can continue while the host is powered down.
The following tables list all the batching related messages:
Batching control and configuration messages
Message

Description

UBX-CFG-BATCHUBX-MON-BATCH

Used to enable and configure the batching feature
Provides information about the buffer fill level and dropped data due
to overrun

Batch retrieval messages
Message

Description

UBX-LOG-RETRIEVEBATCHUBX-LOG-BATCH

Starts the batch retrieval process
A batch entry returned by the receiver

23.2 Setting up the data batching
Data batching is disabled per default and it has to be configured before use via UBX-CFG-BATCH.
The feature must be enabled and the buffer size must be set to greater than 0. It is possible to set
up a PIO as a flag that indicates when the buffer is close to filling up. The fill level when this PIO isasserted can be set by the user separately from the buffer size. The notification fill level must not
be larger than the buffer size.
If the host does not retrieve the batched fixes before the buffer fills up the oldest fix will be
UBX-13003221 - R17

Early Production Information

Page 81 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

dropped and replaced with the newest.
The RAM available in the chip limits the size of the buffer. To make the best use of the available
space users can select what data they want to batch. When batching is enabled a basic set ofdata is stored and the configuration flags extraPvt and extraOdo can be used to store moredetailed information about the position fixes. Doing so reduces the number of fixes that can bebatched.
The receiver will reject configuration if it cannot allocate the required buffer memory. To ensure
robust operation of the receiver the following limits are enforced:
Maximum number of batched epochs
extraPvt

extraOdo

0
0
1
1

0
1
0
1

Maximum number of epochs

300
221
156
132

It is recommended to disable all periodic output messages when using batching. This
improves system robustness and also helps ensure that the output of batched data is
not delayed by other messages.
The buffer size is set up in terms of navigation epochs. This means that the time thatcan be covered with a certain buffer depends on the navigation rate. This rate can be set
separately for full power operation via UBX-CFG-RATE and for power save mode via theupdatePeriod in UBX-CFG-PM2.
Data batching settings should not be re-configured while retrieving data from the buffer.

23.3 Retrieval
UBX-LOG-RETRIEVEBATCH starts the process which allows the receiver to output batch entries.
Batching must not be stopped for readout; all batched data is lost when the feature is disabled.
Batched fixes are always retrieved starting with the oldest fix in the buffer and progressing
towards newer ones. There is no way to skip certain fixes during retrieval.
When a UBX-LOG-RETRIEVEBATCH message is sent the receiver transmits all batched fixes. It is
recommended to send a retrieval request with sendMonFirst set. This way the receiver will send a
UBX-MON-BATCH message first that contains the number of fixes in the batching buffer. This
information can be used to detect when the u-blox receiver finished sending data.
Once retrieval has started, the receiver will first send UBX-MON-BATCH if sendMonFirst option was
selected in the UBX-LOG-RETRIEVEBATCH. After that, it will send UBX-LOG-BATCH messages withthe batched fixes.
To maximise the speed of transfer it is recommended that a high communications data rate isused.
The receiver will discard retrieval request while processing a previous UBX-LOGRETRIEVEBATCH message.
The receiver does not acknowledge the reception of UBX-LOG-RETRIEVEBATCH; theresponse that the host should expect are the reply messages.

UBX-13003221 - R17

Early Production Information

Page 82 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

24 Geofencing(Note: this feature is not supported in protocol versions less than 18).

24.1 Introduction

The geofencing feature allows for the configuration of up to four circular areas (geofences) on the
Earth's surface. The receiver will then evaluate for each of these areas whether the current
position lies within the area or not and signal the state via UBX messaging and PIO toggling.

24.2 Interface
Geofencing can be configured using the UBX-CFG-GEOFENCE message. The geofence evaluation is
active whenever there is at least one geofence configured.
The current state of each geofence plus the combined state is output in UBX-NAV-GEOFENCE withevery navigation epoch.
Additionally the user can configure the receiver to output the combined geofence state on aphysical pin.

24.3 Geofence state evaluation
With every navigation epoch the receiver will evaluate the current solution's position versus theconfigured geofences. There are three possible outcomes for each geofence:• Inside - The position is inside the geofence with the configured confidence level• Outside - The position lies outside of the geofence with the configured confidence level• Unknown - There is no valid position solution or the position uncertainty does not allow for
unambiguous state evaluation
The position solution uncertainty (standard deviation) is multiplied with the configured
confidence sigma level number and taken into account when evaluating the geofence state (redcircle in figure below).

The combined state for all geofences is evaluated as the combination (logical OR) of all geofences:• Inside - The position lies inside of at least one geofence• Outside - The position lies outside of all geofences• Unknown - All remaining states

UBX-13003221 - R17

Early Production Information

Page 83 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

24.4 Using a PIO for Geofence State Output
This feature can be used for example for waking up a sleeping host when a defined geofence
condition is reached. The receiver will toggle the assigned pin according to the combined geofence
state. Due to hardware restrictions the unknown state will always be represented as HIGH. If thereceiver is in software backup or in a reset, the pin will go to HIGH accordingly. The meaning of the
LOW state can be configured using UBX-CFG-GEOFENCE.

25 Time Mode Configuration
This feature is only available with Timing, FTS or High Precision GNSS (HPG) productsThis section relates to the configuration message UBX-CFG-TMODE2 (for Timing or FTS products)
and to the configuration message UBX-CFG-TMODE3 (for HPG products).

25.1 Introduction
Time Mode is a special receiver mode where the position of the receiver is known and fixed andonly the time is calculated using all available satellites. This mode allows for maximum time
accuracy, for single-SV solutions, and also for using the receiver as a stationary reference station.

25.2 Fixed Position
In order to use the Time Mode, the receiver's position must be known as exactly as possible. Either
the user already knows and enters the position, or it is determined using Survey-in. Errors in the
fixed position will translate into time errors depending on the satellite constellation.
For Timing products, as a rule of thumb the position should be known with an accuracy of better
than 1 m for a timing accuracy in the order of nanoseconds. If an accuracy is required only in theorder of microseconds, a position accuracy of roughly 300 m is sufficient.
For HPG products, errors in the reference station position will directly translate into rover position
errors. The reference station position accuracy should therefore be at least as good as the desired
rover absolute position accuracy.

25.3 Survey-in
Survey-in is the procedure that is carried out prior to using Time Mode. It determines a stationary
receiver's position by building a weighted mean of all valid 3D position solutions.
Two requirements for stopping the procedure must be specified:• The minimum observation time defines a minimum amount of observation time regardless of
the actual number of valid fixes that were used for the position calculation. Reasonable values
range from one day for high accuracy requirements to a few minutes for coarse position
determination.
• The required 3D position standard deviation defines a limit on the spread of positions that
contribute to the calculated mean. As the position error translates into a time error when using
Time Mode (see above), one should carefully evaluate the time accuracy requirements andchoose an appropriate value.
Survey-in ends, when both requirements are met. After Survey-in has finished successfully, thereceiver will automatically enter fixed position Time Mode.
The Survey-in status can queried using the UBX-TIM-SVIN message for Timing or FTS products or

UBX-13003221 - R17

Early Production Information

Page 84 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

the UBX-NAV-SVIN message for HPG products.
The "Standard Deviation" parameter defines uncertainty of the manually provided "True
Position" set of parameters. This uncertainty directly affects the accuracy of the
timepulse. This is to prevent an error that would otherwise be present in the timepulse
because of the initially inaccurate position (assumed to be correct by the receiver)without users being aware of it. The "3D accuracy" parameter in "Fixed Position" as wellas the "Position accuracy limit" in "Survey-in" affect the produced time information andthe timepulse in the same way. Please note that the availability of the position accuracy
does not mitigate the error in the timepulse but only accounts for it when calculating theresulting time accuracy.
Once a survey-in has been started, its progress is saved in non-volatile memory, andhence continues over events such as a reset, receiver restart, or change of satellite
constellation. If a survey-in position is required using data only for a particular receiverconfiguration, then any on-going survey-in should be stopped by either a UBX-CFGTMODE2 or a UBX-CFG-TMODE3 message with the timeMode field set to 0, then thereceiver configured as required, and then a new UBX-CFG-TMODE2 or UBX-CFG-TMODE3
message sent with the new survey-in parameters.

26 Time & Frequency Sync (FTS)
The features described in this section are only available with the FTS products

26.1 Introduction
An FTS configured receiver provides an accurate, low phase-noise reference frequency as well asphase reference pulse (typically at one pulse per second). An FTS receiver also implements
automatic hold-over capability based on a stable VCTCXO in modules and the customer's choiceof reference oscillator in chip-based designs. It offers generic interfaces for external sources ofsynchronization (suitable for external OCXOs, IEEE1588 or Synchronous Ethernet). The receiver is
optimized for stationary applications and delivers excellent GNSS sensitivity in conjunction withassistance data.
In the rest of this description the following terminology will be used:• Disciplined oscillator: an oscillator whose frequency is corrected by a more stable frequency
reference, such as a GNSS system.
• Internal oscillator: the mandatory disciplined oscillator which is used as the reference frequency
for the GNSS receiver subsystem. The output from this oscillator is also available to theapplication as an output from the module.
• External oscillator: an optional oscillator, disciplined by the receiver, either via I2C DAC or via
UBX messages handle by a host.
• Source: a source of frequency and/or phase synchronization either measured by the receiver
based on direct hardware input or an offset estimated by an external timing sub-system withrespect to the receiver output. Sources are handled according to related estimates of
uncertainty delivered by the application or (for oscillators) configurable models provided by thereceiver.
• Holdover: periods when GNSS measurements of sufficient quality to maintain time/frequency
are not available.

UBX-13003221 - R17

Early Production Information

Page 85 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

In all FTS related messages the above sources are indexed as follows:
Synchronization source indexing
SourceIndex

Internal oscillator
GNSS
EXTINT0 (external input)
EXTINT1 (external input)
Internal oscillator measured by thehostExternal oscillator measured by the
host

0
1
2
3
4
5

The following table lists FTS related messages:
FTS message summary
Message

Description

UBX-CFG-SMGR
UBX-CFG-ESRCUBX-CFG-DOSCUBX-CFG-TP5UBX-CFG-NAV5
UBX-MON-SMGR
UBX-TIM-DOSC

Synchronization manager configuration
External source configuration
Disciplined oscillator configuration
Configures the output pulse parameters
Configures which variant of UTC is used by the receiver
SMGR monitoring message
Message containing disciplining command for external oscillators
controlled through the hostMessage allowing the host to directly control the module's
oscillators
Message containing information about the preceding time-pulse
output by the receiver
Message containing measurements of phase/frequency inputs
Oscillator calibration command and result report
Information about latest frequency change to an oscillator

UBX-TIM-HOC
UBX-TIM-TOS
UBX-TIM-SMEASUBX-TIM-VCOCALUBX-TIM-FCHG

The remainder of this chapter describes some typical use cases, introduces the Synchronization
Manager (SMGR) functionality unique to FTS products and describes the use of related
messages.

26.2 Example use cases
In this section some typical use cases are described.
26.2.1 Stand-alone synchronization system

UBX-13003221 - R17

Early Production Information

Page 86 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

In this example, the FTS device provides a stand-alone synchronization sub-system in the context
of, say, a small cell. The module's internal 30.72MHz VCTCXO is disciplined by the module andprovides the frequency reference to the platform. The module provides a PPS signal tosynchronize the platform's physical layer. A 1PPS (or frequency) input to the module provides
frequency and/or phase information from host timing sub-systems such as PTP or Sync-E. In theabsence of phase information from GNSS or any other source, the module relies on the VCTCXO
for synchronization holdover, augmented by any reliable source of frequency control. In theabsence of frequency control, the holdover performance is determined entirely by the VCTCXO.
In some applications holdover performance will be enhanced by using an external stable (but notnecessarily accurate) frequency reference.
26.2.2 Oscillator control via host

UBX-13003221 - R17

Early Production Information

Page 87 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The frequency offset of the external oscillator is measured by the FTS device and communicatedto the host which can then make any corrections necessary. The FTS device also generates a PPS
phase reference internally (with no guarantee of coherence with the external oscillator). Duringholdover, the phase of 1PPS signal is maintained using either the primary reference oscillator or
the 1PPS_In signal, according to their respective uncertainty.
26.2.3 Oscillator control via directly-connected DAC

In this use case, the FTS device disciplines an external oscillator via an external DAC. Duringholdover the input to the external DAC is frozen and the phase of the time pulse output ismaintained by the primary reference oscillator, but only guaranteed to be fully coherent with theinternal oscillator. The FTS receiver can also be commanded to perform a one-off calibration of
the tuning slope of external oscillator if necessary.
26.2.4 External (coherent) PPS

UBX-13003221 - R17

Early Production Information

Page 88 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

In this use case, the system PPS is generated by an external device from the output of the primaryreference oscillator. The FTS receiver measures the phase of this PPS input against GNSS time or
the best available source. Any small phase corrections necessary can be made by the receiver via
adjustments to the oscillator frequency or directly by the host to the PPS generator (e.g. toaccelerate removal of large phase errors). During holdover the DAC input is frozen.

26.3 Synchronization Manager Concept
The Synchronization Manager (SMGR) assumes the frequency and phase control functions in FTS
configured devices. The SMGR uses internal and external phase and frequency measurements toderive the disciplining values (necessary frequency changes) and to assess the quality(uncertainty) of the time pulse signal and the frequency outputs. The SMGR considers thefollowing synchronization sources:• The GNSS solutions• Internal oscillator• Up to two external signals: frequency or time pulse (e.g. 1PPS) reference signals on EXTINT0
and/or EXTINT1• Externally conducted measurements, from which the results are sent to the receiver throughone of the host interfaces
Each measurement provides frequency offset and/or phase information along with an estimate of
the uncertainty of each. The SMGR functional block diagram is given below:

UBX-13003221 - R17

Early Production Information

Page 89 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The user has the option to configure how the SMGR considers the external signals, e.g. time orfrequency source, disciplined or not, etc... The user must also configure the uncertainty of thesignals along with their nominal characteristics. One of the external signals may be configured as
the feedback path of a disciplined external oscillator.
The SMGR can operate in frequency locked or in phase locked mode. In frequency locked mode thetarget of the SMGR is to eliminate frequency error. In phase locked mode the elimination of timeerror is the goal; this may lead to intentional deviation from the correct oscillator frequency. The
correction rate in both of these modes is subject to configurable limits (see UBX-CFG-SMGR). The
SMGR runs periodically (typically once a second). Its operation consists of the following stages
each time it is executed:• Choose the best source to be the reference, given the characteristics (phase noise and stability)of each of the sources and the uncertainty of their measurements.
• Calculate the phase and/or frequency errors as well as their uncertainty for each of thedisciplined oscillators with respect to the reference source.
• Calculate correction for disciplined oscillators; time and/or frequency corrections are limited tothe configured limits.
• Map frequency adjustment to physical output.
The SMGR runs periodically and retrieves the most recent measurements for each source alongwith the estimates about their respective uncertainty. The relative phase and/or frequency errorsof disciplined oscillators with respect to the reference are calculated from incoming
measurements and used to discipline them. The decision-making process as such does notdepend on decisions made previously, however it does rely on the estimated uncertainty for eachsource, which is determined by comparing predicted and measured values over some moderate
period of time. The SMGR only uses a single reference source at any one time. It does not combine
measurements from different sources in any way. If the selected reference provides a time error
measurement then a phase locked loop is possible, otherwise the receiver automatically enters
frequency lock even if configured to maintain a phase lock.
In some cases the host software might choose to drive an oscillator directly. This may be useful

UBX-13003221 - R17

Early Production Information

Page 90 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

where a large timing error has accumulated (e.g. after a long period of holdover) and normal
operation would prevent the error being corrected swiftly. In this case, the host can deliberately
steer the oscillator to correct timing in large steps as configured maximum phase and frequencychange limits are not applied to adjustments commanded by the host. Another use of the direct
host-driven steering may be the calibration of other parts of the system. Use UBX-TIM-HOC
message for this functionality.
If the time error is so large that its correction would take prohibitively long even with maximum
frequency offset of the oscillator the receiver can be switched to non-coherent time pulse output
mode. In this case the sync manager is temporarily reconfigured to allow time pulse intervals thatare not coherent with the frequency output, i.e. there are more or less than the nominal number ofcycles between two pulses. The user may optionally specify a limit on time adjustments. The
output mode can be set to coherent again once the time error is sufficiently small.
A SMGR summary status is provided by UBX-MON-SMGR message.
The SMGR runs at the navigation rate set by UBX-CFG-RATE. For FTS configured
devices, it is not recommended to use navigation rates higher than 1Hz.

26.4 Oscillator and source specification
For correct operation, the frequency, phase and stability characteristics of all sources anddisciplined oscillators must be described. External synchronization sources are configured withUBX-CFG-ESRC and disciplined oscillators with UBX-CFG-DOSC. The models (short and long term
stability behavior) specified by these messages provide the SMGR with the knowledge necessary
to its decision making.
The user must also configure the method (coherent or non-coherent) used for frequency
adjustment, the maximum frequency adjustment and other parameters contained in UBX-CFGDOSC.
It is assumed that an external voltage-controlled oscillator has a constant ratio of relative
frequency change to control voltage change. The oscillator is therefore characterized by two
metrics: an offset (control voltage for nominal frequency) and a gain (relative frequency change
per control step). Each of these parameters are known along with their uncertainty. It is assumed
that the oscillator control gain is stable over time but its offset may change significantly withaging. Because of the drift of the offset, its saved value is regularly updated in the model. The
gain, on the other hand, is only updated on demand by the host application by re-configuration orcalibration. For the measurement of the gain a special auto-calibration is available, described in
the calibration section.
External oscillator stability (frequency changes) is described by four parameters (see UBX-CFGDOSC):• changes with temperature: withTemp is the maximum deviation limit from the nominal
frequency at the reference temperature over the supported temperature range (in ppb) andtimeToTemp (in s) which is a period after which the maximum deviation limit is reached.
• aging: maxDevLifeTime is the maximum deviation from the nominal frequency (in ppb) andwithAge is the oscillator stability with age (in ppb/year).

UBX-13003221 - R17

Early Production Information

Page 91 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

26.5 Calibration
Prior to disciplining an oscillator, the SMGR must have an accurate knowledge of the controlled
oscillator's frequency control gain and initial frequency offset (oscillator gains may differ
significantly from unit to unit and batch to batch, largely as a result of different crystal Q). The
receiver provides a slope measurement utility to aid the calibration process.
The calibration utility is a special mode where all disciplining operations are suspended andtherefore all disciplined oscillators, internal or external, cease to produce usable outputs. It takes
place in response to a specific request (UBX-TIM-VCOCAL message) from the host to do so for aparticular oscillator and only one oscillator can be calibrated at a time. During this phase, the
SMGR forces large frequency variations by changing the input of the digital to analogue
conversion device whose output is driving the oscillator. Several frequency measurements are
performed and a gain is estimated.

Calibration parameters must be configured or the calibration utility called before disciplining
operation is possible. Once calibrated, the calibStatus flag in UBX-CFG-DOSC is set. The
calibration utility can be re-triggered at any time by issuing the appropriate command through the
UBX-TIM-VCOCAL message (not recommended during normal operation). An ongoing calibration
process can be aborted using the same message with the appropriate flags. It can also be
bypassed if the calibStatus flag in the UBX-CFG-DOSC message is set to 1 (oscillator is calibrated
independently with results saved using the UBX-CFG-DOSC message).
In order to enter the calibration mode it is required that:• A stable frequency source is available for the duration of the calibration. This source may be a
GNSS solution or a frequency signal on an EXTINT pin.
• The oscillator subject to calibration is configured through the UBX-CFG-DOSC message(including an initial estimate of gain) and available for the duration of the process.
For an external oscillator it is also assumed that the useful range of the input is covered by theoutput of the DAC and that the relation frequency versus DAC input is linear. Once the calibration
operation is complete the receiver will issue a UBX message to indicate that the SMGR is reverting
to normal operation and to report the results of the calibration. A default for the internal oscillator
is available in the firmware.
Note that it is important that only the chosen frequency source is enabled during the calibration
process and that it remains stable throughout the calibration period; otherwise incorrect
oscillator measurements will be made and this will lead to miscalibration and poor subsequent
operation of the receiver.

UBX-13003221 - R17

Early Production Information

Page 92 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

26.6 FTS device Output and Top Of Second (TOS) message
The outputs available from an FTS device can be one or all of the following:• A disciplined frequency source at the same frequency as the internal oscillator.
• A 1PPS or an even second signal (other similar rates are possible) coherent with the internal
oscillator, configured by UBX-CFG-TP5.
• Messages reporting measurement results (for example for a host disciplined external
oscillator).
• A UBX-TIM-TOS message which describes the current condition (accuracy, coherent or noncoherent, etc...) of the frequency and PPS outputs.
• DAC command for disciplined external oscillators.
The top of second (TOS) message is a summary of the FTS device's status. It is output shortly
after each time pulse and so will normally be aligned to the second of the reference time (ifavailable). To guarantee that this message is output as the first message after the time pulse asystem of time slot reservation is provided for all communication interfaces towards the host. For
more information on this mechanism please refer to the description of TX time slots
Users of the FTS variant are expected to use the UBX-TIM-TOS message to obtain key
parameters for each time pulse. The UBX-TIM-TP message is only supported forcompatibility with timing receivers and is not guaranteed to provide the mostappropriate information in all FTS use cases.
The time pulse of an FTS device is generated differently from that of other u-blox receivers.
FTS products support two modes of time pulse generation: "coherent" and "non-coherent" pulses.
"Coherent" pulse generation means that the number of clock cycles between two pulses is always
the same. When in "non-coherent" pulse mode the receiver may change the number of clock cycles
between two pulses if it can thus reduce the phase error of the time pulse. The receiver can be
configured (using UBX-CFG-SMGR) to operate in either of these modes or to switch from "noncoherent" to coherent mode after initial frequency and phase error has been eliminated.
It can be useful to instruct the receiver to enter the "non-coherent" pulse mode during startup or
while recovering from holdover; it reduces the time necessary for phase convergence. After thephase error is reduced the host can instruct the FTS receiver to switch back to "coherent" mode
again.
The UBX-TIM-TOS message, when enabled, indicates the actual mode of pulse generation.
Depending on the time pulse generation mode, the time pulse can be forced to be phase aligned tothe oscillators. In coherent output mode the phase offset of the oscillator at the rising edge of thetime pulse is defined by the phaseOffset field of UBX-CFG-DOSC. In "non-coherent" mode thisconstraint is ignored.
The phase offset is handled differently for both oscillators. Whereas phase lock between
the internal oscillator and the time pulse is guaranteed by hardware, in the case of theexternal oscillator the lock is achieved by software and that lock is therefore the lockbehavior is expected to be different.
The frequency, shape and offset of the time pulse can be configured with the UBX-CFG-TP5
message. Some of the fields are interpreted differently by FTS devices compared to other u-blox
receivers. Among others the lockGnssFreq flag is ignored and the time pulse is always aligned tothe best synchronization source. Furthermore, switching between the two time pulse frequency
and length parameters is not governed by GNSS alone but by the condition selected in the

UBX-13003221 - R17

Early Production Information

Page 93 of 407

u-blox 8 / u-blox M8 Receiver Description - ManualsyncMode field.
Two delay parameters can be configured using UBX-CFG-TP5, antCableDelay anduserConfigDelay. In an FTS product care should be taken what delays are attributed towhich of the delay terms. The antenna cable delay is only relevant when the receiver isfollowing GNSS as reference; the user configurable delay is applied regardless of theactive reference signal.
In current FTS products only TIMEPULSE 2 can be used for pulse generation.
Additionally, just 0.5 Hz, 1 Hz and 2 Hz time pulse output is supported by current FTS
products. Other output frequencies may be configured with UBX-CFG-TP5 but are notguaranteed to work properly.

26.7 Message transmission time slot reservations on host interfaces
The firmware provides three message transmission time slots that are aligned to the time pulse
output of the receiver. No message is scheduled for transmission in the first slot after the leadingedge of the time pulse. The second slot is reserved for the UBX-TIM-TOS message and the third
slot is used for outputting other messages. However, any message transmission that was started
will be finished before a new message is started.
The time slots can be enabled and configured using UBX-CFG-TXSLOT.
When the reference time pulse is disabled or runs at a high frequency it may happen
that many or all outgoing messages are lost. Therefore the time slot mechanism should
be configured to match the time pulse behavior or disabled altogether.
This mechanism only controls when a message transmission may start and does not guaranteethat the message transmission will finish before the end of the corresponding slot. Therefore theend of the last slot should be configured such that the longest enabled message can still betransmitted before the period starts when the receiver must not transmit messages.
The timing of the actual message output is also dependent on the communicationinterface and its clocking. On the slave interfaces (DDC and SPI) the host must provide
clock in all time slots for this feature to work.
26.7.1 Example setup
Following is an example scenario. The receiver is set up to output a time pulse at a 1 Hz rate.
Suppose that the following requirements are given for system integration:• The TOS message should be output 10 to 50 ms after the time pulse.
• No other message should be output from the leading edge of the time pulse until 50 ms after
the time pulse.
• The longest enabled message takes up to 100 ms to transmit through the chosen interface withthe configured speed.
Then the time slots are enabled and the three slots are configured to end 10, 50 and 900 ms after
the pulse respectively. The following figure indicates time pulses with upwards pointing arrows.
Slot 0 (the first one active immediately after the time pulse) is active and thus blocks thetransmission of new messages from 100 ms before the time pulse until 10 ms after it. Time slot 1,
i.e. the time between 10 and 50 ms after the pulse, is reserved for the top-of-second message. Allother messages are output in slot 2.

UBX-13003221 - R17

Early Production Information

Page 94 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

27 RTK Mode Configuration
This feature is only available with the High Precision GNSS products
u-blox RTK technology introduces the concept of a reference station and a rover. Using the
RTCM3 protocol, the reference station sends corrections to the rover via a communication linkenabling the rover to compute its position relative to the reference with high accuracy.
In the high precision GNSS context, the terms reference station and base station can beused interchangeably.
The distance between the reference station and the rover is called baseline length.
The reference station can provide correction to several rovers but the rover cannot
concurrently process corrections from several reference stations.
The remainder of this chapter describes how to configure the reference station and the rover.
More details about the RTCM3 protocol can be found in the RTCM3 section.

27.1 Reference Station Mode Configuration
Reference Station Mode is a special receiver mode where the receiver uses measurements from allavailable satellites to broadcast corrections. Configuring a stationary reference station is done in
two steps:• The receiver must be set in Time Mode using the configuration steps described in the Time
Mode Configuration section.
• The RTCM3 correction stream must be configured following the rules detailed in the RTCM3
Configuration section. Each RTCM message must be individually enabled using UBX-CFG-MSG.
By default the reference station will begin operation in standard GNSS mode without any
RTCM output. Messages for observations will be streamed as soon as they are
configured for output. However messages for the reference station position will only be
output when both the reference station is in fixed position mode, and the message isconfigured for output. As explained in the Time Mode Configuration section, this modecan be directly configured or reached at the end of a successful survey-in.
The rover will need to have received both reference station observation messages andreference station position messages in order to attempt ambiguity fixes.
When the reference station is in Time Mode, some error checking is performed on theentered, or surveyed-in, fixed position. If the result of these checks indicates that the
fixed position may be incorrect, then a UBX-INF-WARNING message will be sent, with thetext "Reference Station position seems incorrect".

UBX-13003221 - R17

Early Production Information

Page 95 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

27.2 Rover Mode Configuration
The RTK rover can be configured to work in either of these two differential modes using UBX-CFGDGNSS:• RTK fixed: In this mode, the rover will attempt to fix ambiguities whenever possible.
• RTK float: In this mode, the rover will estimate the ambiguities as float but will make noattempts at fixing them.
The time after which old RTCM data will be discarded can be specified using the dgnssTimeout
field in UBX-CFG-NAV5.
By default the rover will begin operation in RTK fixed mode. Upon receiving an RTCM3
correction stream on any of its communication interfaces, the rover will parse the data,
apply the correction and, if possible, fix ambiguities. In absence of correction data or if
the correction data times out, the rover will operate in standard GNSS mode.
The time needed to resolve the ambiguity is affected by the baseline length as well as bymultipath and satellite visibility at both rover and reference station.

27.3 Moving Baseline RTK Configuration
The moving baseline (MB) RTK mode differs from the standard RTK mode in that it does not
require the reference to be stationary at a known location. In MB RTK mode, both the reference
station and rover receivers can move while computing a centimeter-level accurate 3D vector
between them. This is ideal for applications where the relative position offset between two moving
vehicles is required such as, for example, the follow-me feature on a UAV.
For the sake of conciseness, in the moving baseline RTK context, the reference station
and rover receivers are referred to as MB reference and MB rover, respectively.
27.3.1 MB Reference Configuration
Configuring a receiver to operate in MB reference mode is done in two steps:• The receiver must be set in Time Mode disabled using the configuration message UBX-CFGTMODE3.
• The RTCM3 correction stream must be configured following the rules detailed in the RTCM3
Configuration section. Each RTCM message must be individually enabled using UBX-CFG-MSG.
If the MB reference moves, then its position changes over time. To ensure that the baseline is as
accurate as possible:• The MB reference position must be sent for each epoch the MB reference observations are sent.
• The MB reference and rover must use the same navigation update rate.
27.3.2 MB Rover Configuration
As in the standard RTK mode, it is possible to configure the MB rover to operate in RTK fixed or
RTK float using the UBX-CFG-DGNSS message.
By default the MB rover will begin operation in RTK fixed mode.
As discussed in the Moving Baseline Expected Performance section, RTCM corrections
can only be extrapolated over a few seconds when both reference and rover receivers are
moving. Therefore, any dgnssTimeout value configured using the UBX-CFG-NAV5
message will be ignored by the MB rover.

UBX-13003221 - R17

Early Production Information

Page 96 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

27.3.3 Expected Performance
While the MB RTK solution aims at estimating the relative position with centimeter-levelaccuracy, the absolute position of each receiver is expected to be known with a standard GNSS
accuracy of a few meters. Additionally, the performance of the MB RTK solution is limited by thefollowing:• A moving reference receiver typically experiences worse GNSS tracking than a static reference
receiver in an open-sky environment and therefore the MB RTK performance may be degraded.
• The MB rover can only compute an optimal MB RTK solution if the time-matched RTCM
observation and position messages are received within a predefined time limit. The MB rover will
wait up to 700 ms for messages before falling back to an extrapolated MB RTK solution. The MB
rover will extrapolate the MB reference observations and/or position for up to 3 s before fallingback to standard GNSS operation.
• The achievable update rate of the MB RTK solution is limited by the communication link latency.
As a rule of thumb, the communication link latency should be about half the desired navigation
update period. If it exceeds 700 ms, the MB rover will not be able to compute an MB RTK
solution, even at 1 Hz.
• Since the MB rover must wait for time-matched RTCM corrections from the MB RTK reference
to compute its position, the overall latency of the MB RTK solution will be the sum of thecommunication link latency plus the MB RTK computation time.
When falling back to standard GNSS operation, the MB rover will automatically adjust
the accuracy and status flag information contained in the messages listed in the
RTCM3 Output section.
Upon recovering the RTCM correction stream, the MB rover will automatically try torevert to MB RTK operation.

28 Automotive Dead Reckoning (ADR)
This feature is only available with the ADR products.

28.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.
ADR solutions use the messages of the External Sensor Fusion (ESF) class.

28.2 ADR System Configuration
28.2.1 Enabling/Disabling Fusion Filter
The ADR fusion filter can be turned-off by means of the useAdr bit in the UBX-CFG-NAVX5
configuration message. If fusion is turned-off, the receiver outputs a GNSS-only solution.
28.2.2 Recommended Configuration
For an optimum ADR navigation performance, the recommended general configuration is thefollowing:• Navigation Rate: the standard navigation solution update rate of 1 Hz (seeUBX-CFG-RATE
UBX-13003221 - R17

Early Production Information

Page 97 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

message) is recommended. The wheel tick quantization error is a limiting factor when using
high frequency updates. This means that navigation rates higher than 1 Hz may result in lower
position accuracies.
It is advised to re-consider enabled messages and features (e.g logging) at higher
navigation rates to meet CPU load, memory and interface bandwidth constraints (Validin protocol versions 19.2)

28.3 Operation
This section describes how the ADR receiver operates.
28.3.1 Fusion Filter Modes
The fusion filter operates in different modes which are output in the UBX-ESF-STATUS message.
More details about each fusion mode are given in the sequel.
28.3.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 coldstart or a filter resetin 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) are flagged as 0: NOT CALIBRATED and the navigation solution output duringinitialization is based on GNSS solely.
Note that initialization phase requires good GNSS signal conditions as well as periods during
which vehicle is stationary and moving (including turns). Once all required initialization steps areachieved, fusion mode is triggered and the calibration phase begins.
28.3.1.2 Fusion Mode
Once initialization phase is achieved, the receiver enters navigation mode. The receiver is in fusionmode if the fusionMode field in the UBX-ESF-STATUS message is set on 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 (used bit set). This is
the case when the sensor calibration status (calibStatus) is flagged as 1:CALIBRATING. As soon
as the calibration reached a status where optimal fusion performance can be expected, the sensor
calibration status is flagged as 2/3:CALIBRATED.
28.3.1.3 Suspended Fusion Mode
Sensor fusion can be temporarily suspended in cases where no fused solution should/can becomputed. The receiver is in the temporarily disabled fusion mode if the fusionMode field in the
UBX-ESF-STATUS message is set on 2:SUSPENDED. In this case, the receiver computes a GNSSonly solution.
28.3.1.4 Disabled Fusion Mode
Sensor fusion can be permanently switched-off in cases where recurrent fusion failures happen or
user turned-off manually fusion. The receiver is in the permanently disabled fusion mode if thefusionMode field in the UBX-ESF-STATUS message is set on 3:DISABLED. In such a case, thereceiver computes a GNSS-only solution.
Fusion is permanently disabled in the following cases:

UBX-13003221 - R17

Early Production Information

Page 98 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• If the fusion filter was manually turned-off by the user (useAdr bit in the UBX-CFG-NAVX5
message is not set).
• If the fusion filter encountered too many errors.
28.3.2 Accelerated Initialization and Calibration Procedure
This section describes how to perform fast initialization and calibration of the ADR receiver for the
purpose of evaluation.
The duration of the initialization phase mostly depends on the quality of the GNSS signals and the
dynamics encountered by the vehicle. Therefore the car should be driven to an open and flat area
like an empty open-sky parking area for example. The initialization and calibration drive should
contain phases where the car is stopped during a few minutes (with engine turned-on), phases
where the car is doing normal left and right turns and phases where speed is above 30 km/h undergood GNSS reception conditions.
Once initialization is completed, the fusionMode field in the UBX-ESF-STATUS message switches
to 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 directly impacting the navigation solution quality.
Note that the calibration status (calibStatus in UBX-ESF-STATUS message) 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 re-calibrating the sensors.
28.3.3 Navigation Output
28.3.3.1 Local-level North-East-Down (NED) Frame
The local-level frame is a geodetic frame with following features:• The origin (O) is a point on the Earth 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.
The frame is referred to as North-East-Down (NED) since its axes are aligned with the North, Eastand Down directions.
28.3.3.2 Vehicle-Frame
The vehicle-frame is a right-handed 3D Cartesian frame rigidly connected with the vehicle and isused to determine the attitude of the vehicle with respect to the local-level frame. It has thefollowing features:• The origin (O) is the VRP in protocol versions less than 19.2, otherwise, is the origin of the IMU
instrumental frame;• 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.

UBX-13003221 - R17

Early Production Information

Page 99 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

28.3.3.3 Vehicle Position and Velocity Output
The position and velocity information is output in several messages like UBX-NAV-PVT for
example. In protocol versions less than 19.2, position and velocity computed by the ADR
navigation filter are referenced to the VRP. For protocol versions 19.2+, position and velocity arereferenced to the origin of the IMU instrumental frame.
28.3.3.4 Vehicle Attitude Output(Only supported in protocol versions 19+).
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 as vehicle attitude and are illustrated in the figure below:

UBX-13003221 - R17

Early Production Information

Page 100 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

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-13003221 - R17

Early Production Information

Page 101 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

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.
Roll angle estimation only supported in protocol versions 19.2+.
28.3.3.5 Vehicle Dynamics Output(Only supported in protocol versions 19+).
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. It's 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 thefusion 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.
28.3.4 Sensor Data Types
The supported sensor data types are:Definition of Data Types
Type

Description

Unit

Format of the 24 data bits

0
1..4
5

none, data field contains no data
reserved
z-axis gyroscope angular rate

deg/s *2^-12signedUBX-13003221 - R17

Early Production Information

Page 102 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Definition of Data Types continued
Type

Description

6

front-left wheel ticks

Unit Format of the 24 data bits

7

front-right wheel ticks

8

rear-left wheel ticks

9

rear-right wheel ticks

10

single tick (speed tick)

11
12

speed
gyroscope temperature

13
14
16
17
18

y-axis gyroscope angular rate
x-axis gyroscope angular rate
x-axis accelerometer specific force
y-axis accelerometer specific force
z-axis accelerometer specific force

Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
m/s * 1e-3
signeddeg Celsius * 1e- signed
2
deg/s *2^-12signeddeg/s *2^-12signedm/s^2 *2^-10signedm/s^2 *2^-10signedm/s^2 *2^-10signed

28.3.5 Raw Sensor Data Output(This feature is not supported in protocol versions less than 15.01).
Some u-blox module products contain inertial sensors (IMU) that are directly connected to the
GNSS and cannot be directly accessed from outside the module. The UBX-ESF-RAW message canbe used to access raw measurements of these sensors. A variable number of data fields may be
used in a single message and these can contain different types of measurements. The type ofeach measurement is specified in the dataType field. The possible data types are x, y and z-axis
measurements on gyroscope or accelerometer and gyroscope temperature measurements as
described in the ESF Measurement Data section. One UBX-ESF-RAW message can contain multiple
samples from the same sensor. The user can separate and order these using the time tags
attached to each of the measurements.
UBX-13003221 - R17

Early Production Information

Page 103 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The measurements are made at a fixed rate. The sampling rate or other sensor configuration
options can not be changed.
To turn on this feature the UBX-ESF-RAW message must be enabled using UBX-CFG-MSG. If nonzero rate is selected the message will be output but the selected rate does not otherwise have an
influence at the rate of the messages.
Turning on this feature does not disable sensor fusion in the receiver. To use an externalfusion algorithm consider disabling the automotive dead reckoning mode using UBXCFG-NAVX5.
28.3.6 Receiver Startup and Shutdown
Continuous dead reckoning is possible over receiver restarts if the following conditions are true:• The vehicle is not moved while the receiver is off
During periods of external sensor data unavailability the receiver switches to GNSS-only
navigation if the last sensor information indicated the vehicle was moving.

29 Untethered Dead Reckoning (UDR)
This feature is only available with the UDR products.

29.1 Introduction
u-blox solution for Untethered Dead Reckoning (UDR) allows improved navigation performance inplaces with GNSS-denied conditions as well as during short GNSS outages. UDR is based on
Sensor Fusion Dead Reckoning (SFDR) technology, which integrates an Inertial Navigation
System (INS) with GNSS measurements. The INS integrates angular rates and specific forces
sensed by an Inertial Measurement Unit (IMU). The INS computes position, velocity and attitudechanges and can, once initialized, provide accurate navigation information. However, an inertialonly navigation solution would degrade quickly with time due to the errors corrupting the IMU
observations. The integration of the INS with GNSS measurements bounds these time-growing
errors by calibrating the INS. The resulting integrated INS/GNSS filter, called fusion filter below,
has the following advantages compared to standalone GNSS positioning:• Improved navigation performance in GNSS-denied conditions: errors caused by multipath or
weak signal conditions are mitigated though the aid brought by the IMU.
• Navigation solution during short GNSS-outages: the INS bridges short GNSS gaps which might
be caused by tunnels or parking garages.
UDR solution uses the messages of the External Sensor Fusion (ESF) class.

29.2 UDR System Configuration(These features are not supported in protocol versions less than 19).
29.2.1 Enabling/Disabling Fusion Filter
The UDR fusion filter can be turned-off by means of the useAdr bit in the UBX-CFG-NAVX5
configuration message. If fusion is turned-off, the receiver outputs a GNSS-only solution.

UBX-13003221 - R17

Early Production Information

Page 104 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

29.2.2 Recommended Configuration
For an optimum navigation performance, the recommended general configuration is the following:• Navigation Rate: the standard navigation solution update rate of 1 Hz (seeUBX-CFG-RATE
message) is recommended.
It is advised to re-consider enabled messages and features (e.g logging) at higher
navigation rates to meet CPU load, memory and interface bandwidth constraints (Validin protocol versions 19.2)

29.3 Operation
This section describes how the UDR receiver operates.
29.3.1 Fusion Filter Modes
The fusion filter operates in different modes which are output in the UBX-ESF-STATUS message.
More details about each fusion mode are given in the sequel.
29.3.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 coldstart or a filter resetin 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) are flagged as 0: NOT CALIBRATED and the navigation solution output duringinitialization is based on GNSS solely.
Note that initialization phase requires good GNSS signal conditions as well as periods during
which vehicle is stationary and moving (including turns). Once all required initialization steps areachieved, fusion mode is triggered and the calibration phase begins.
29.3.1.2 Fusion Mode
Once initialization phase is achieved, the receiver enters navigation mode. The receiver is in fusionmode if the fusionMode field in the UBX-ESF-STATUS message is set on 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 (used bit set). This is
the case when the sensor calibration status (calibStatus) is flagged as 1:CALIBRATING. As soon
as the calibration reached a status where optimal fusion performance can be expected, the sensor
calibration status is flagged as 2/3:CALIBRATED.
29.3.1.3 Suspended Fusion Mode
Sensor fusion can be temporarily suspended in cases where no fused solution should/can becomputed. The receiver is in the temporarily disabled fusion mode if the fusionMode field in the
UBX-ESF-STATUS message is set on 2:SUSPENDED. In this case, the receiver computes a GNSSonly solution.
29.3.1.4 Disabled Fusion Mode
Sensor fusion can be permanently switched-off in cases where recurrent fusion failures happen or
user turned-off manually fusion. The receiver is in the permanently disabled fusion mode if thefusionMode field in the UBX-ESF-STATUS message is set on 3:DISABLED. In such a case, thereceiver computes a GNSS-only solution.

UBX-13003221 - R17

Early Production Information

Page 105 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Fusion is permanently disabled in the following cases:• If the fusion filter was manually turned-off by the user (useAdr bit in the UBX-CFG-NAVX5
message is not set).
• If the fusion filter encountered too many errors.
29.3.2 Accelerated Initialization and Calibration Procedure
This section describes how to perform fast initialization and calibration of the UDR receiver for the
purpose of evaluation.
The duration of the initialization phase mostly depends on the quality of the GNSS signals and the
dynamics encountered by the vehicle. Therefore the car should be driven to an open and flat area
like an empty open-sky parking area for example. The initialization and calibration drive should
contain phases where the car is stopped during a few minutes (with engine turned-on), phases
where the car is doing normal left and right turns and phases where speed is above 30 km/h undergood GNSS reception conditions.
Once initialization is completed, the fusionMode field in the UBX-ESF-STATUS message switches
to 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 improving the navigation solution quality.
Note that the calibration status (calibStatus in UBX-ESF-STATUS message) 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 re-calibrating the sensors.
29.3.3 Navigation Output(Only supported in protocol versions 19+).
29.3.3.1 Local-level North-East-Down (NED) Frame
The local-level frame is a geodetic frame with following features:• The origin (O) is a point on the Earth 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.
The frame is referred to as North-East-Down (NED) since its axes are aligned with the North, Eastand Down directions.
29.3.3.2 Body-Frame
The body-frame is a right-handed 3D Cartesian frame rigidly connected with the vehicle and isused to determine the attitude of the vehicle with respect to the local-level frame. It has thefollowing features:• The origin (O) is the origin of the IMU instrumental frame;• 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.

UBX-13003221 - R17

Early Production Information

Page 106 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

29.3.3.3 Vehicle Position and Velocity Output
The position and velocity information is output in several messages like UBX-NAV-PVT for
example. The position computed by the UDR navigation filter is referenced to the origin (O) of thebody-frame.
29.3.3.4 Vehicle Attitude Output
The transformation between the body-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 as vehicle attitude and are illustrated in the figure below:

UBX-13003221 - R17

Early Production Information

Page 107 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

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-13003221 - R17

Early Production Information

Page 108 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

The vehicle attitude is output in the UBX-NAV-ATT message. The message provides all three
angles together with their accuracy estimates. Note that since no backwards motion informationis measured, no heading of motion information is output in the UBX-NAV-PVT message (heading ofvehicle is provided in a separate field within the same message).
29.3.3.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. It's accuracy is directly dependent on the filter attitude
estimation accuracy.
Compensated vehicle dynamics information is output with respect to the body-frame.
29.3.4 Sensor Data Types
The supported sensor data types are:Definition of Data Types
Type

Description

0
1..4
5
6

none, data field contains no data
reserved
z-axis gyroscope angular rate
front-left wheel ticks

UBX-13003221 - R17

Unit

Format of the 24 data bits

deg/s *2^-12signedBits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)

Early Production Information

Page 109 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Definition of Data Types continued
Type

Description

7

front-right wheel ticks

Unit Format of the 24 data bits

8

rear-left wheel ticks

9

rear-right wheel ticks

10

single tick (speed tick)

11
12

speed
gyroscope temperature

13
14
16
17
18

y-axis gyroscope angular rate
x-axis gyroscope angular rate
x-axis accelerometer specific force
y-axis accelerometer specific force
z-axis accelerometer specific force

Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
Bits 0-22: unsigned
tick value. Bit 23:
direction indicator(0=forward,
1=backward)
m/s * 1e-3
signeddeg Celsius * 1e- signed
2
deg/s *2^-12signeddeg/s *2^-12signedm/s^2 *2^-10signedm/s^2 *2^-10signedm/s^2 *2^-10signed

29.3.5 Raw Sensor Data Output(This feature is not supported in protocol versions less than 15.01).
Some u-blox module products contain inertial sensors (IMU) that are directly connected to the
GNSS and cannot be directly accessed from outside the module. The UBX-ESF-RAW message canbe used to access raw measurements of these sensors. A variable number of data fields may be
used in a single message and these can contain different types of measurements. The type ofeach measurement is specified in the dataType field. The possible data types are x, y and z-axis
measurements on gyroscope or accelerometer and gyroscope temperature measurements as
described in the ESF Measurement Data section. One UBX-ESF-RAW message can contain multiple
samples from the same sensor. The user can separate and order these using the time tags
attached to each of the measurements.
The measurements are made at a fixed rate. The sampling rate or other sensor configuration
options can not be changed.
To turn on this feature the UBX-ESF-RAW message must be enabled using UBX-CFG-MSG. If nonzero rate is selected the message will be output but the selected rate does not otherwise have an

UBX-13003221 - R17

Early Production Information

Page 110 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

influence at the rate of the messages.
Turning on this feature does not disable sensor fusion in the receiver. To use an externalfusion algorithm consider disabling the automotive dead reckoning mode using UBXCFG-NAVX5.
29.3.6 Receiver Startup and Shutdown
Continuous dead reckoning is possible over receiver restarts if the following conditions are true:• The vehicle is not moved while the receiver is off
During periods of external sensor data unavailability the receiver switches to GNSS-only
navigation if the last sensor information indicated the vehicle was moving.

30 High Navigation Rate (HNR)
This feature is only available with the ADR products.
This feature is only available with the UDR products.

30.1 Introduction
u-blox DR solutions allow a low latency position and velocity to be output at up to 30 Hz. The
maximum GNSS rate is 2 Hz. Sensors measurements are used to propagate the solution at thehigher rate between GNSS epochs.
The high navigation rate solution is output using the UBX-HNR-PVT message for firmwares using
protocol version 19+.

30.2 Configuration
The high navigation rate output can be configured using the UBX-CFG-HNR message.
If a high navigation rate has been configured with UBX-CFG-HNR then the number ofenabled output messages must be adjusted to keep within the maximum throughput of
the interface used.

UBX-13003221 - R17

Early Production Information

Page 111 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Interface Description
31 NMEA Protocol
31.1 Protocol Overview
31.1.1 Message Format
NMEA messages sent by the GNSS receiver are based on NMEA 0183 Version 4.10. The following
picture shows the structure of a NMEA protocol message.

For further information on the NMEA Standard, refer to NMEA 0183 Standard For Interfacing
Marine Electronic Devices, Version 4.10, June, 2012. Seehttp://www.nmea.org/ for ordering
instructions.
The NMEA standard allows for proprietary, manufacturer-specific messages to be added. These
shall be marked with a manufacturer mnemonic. The mnemonic assigned to u-blox is UBX and isused for all non-standard messages. These proprietary NMEA messages therefore have theaddress field set to PUBX. The first data field in a PUBX message identifies the message number
with two digits.
31.1.2 Talker ID
One of the ways the NMEA standard differentiates between GNSS is by using a two-lettermessage identifier, the 'Talker ID'. The specific Talker ID used by a u-blox receiver will depend on
the device model and system configuration. The table below shows the Talker ID that will be usedfor various GNSS configurations.

UBX-13003221 - R17

Early Production Information

Page 112 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

NMEA Talker IDs
Configured GNSS

Talker ID

GPS, SBAS, QZSSGLONASS
Galileo
BeiDouAny combination of GNSS

GP
GL
GA
GB*
GN

*This is a u-blox extension to the NMEA 4.10 standard. Only NMEA 4.11 defines the GB talker ID.
See also Extended Configuration in Protocol Configuration.
31.1.3 Protocol Configuration
The NMEA protocol on u-blox receivers can be configured to the need of customer applications
using UBX-CFG-NMEA. For backwards compatibility various versions of this message aresupported, however, any new users should use the version that is not marked as deprecated.
There are four NMEA standards supported. The default NMEA version is 4.10. Alternatively
versions 4.00, 2.3, and 2.1 can be enabled (for details on how this affects the output refer tosection Position Fix Flags in NMEA Mode).
Customers using BeiDou and/or Galileo are recommended to select NMEA version 4.10,
as earlier versions have no support for these two GNSS.
Customers using High Precision GNSS (HPG) products are recommended to select
NMEA version 4.10, as earlier versions do no support the Float RTK (F) and Real Time
Kinematic (R) mode indicator flags in all messages.
NMEA defines satellite numbering systems for some, but not all GNSS (this is partly dependent
on the NMEA version). Satellite numbers for unsupported GNSS can be configured using UBXCFG-NMEA. Unknown satellite numbers are always reported as a null NMEA field (i.e. an empty
string).
The NMEA specification indicates that the GGA message is GPS specific. However, u-blox
receivers support the output of a GGA message for each of the Talker IDs.
NMEA filtering flags
Parameter

Description

Position filtering

Enable positions from failed or invalid fixes to be reported (with the "V" status
flag to indicate that the data is not valid).
Enable positions from invalid fixes to be reported (with the "V" status flag toindicate that the data is not valid).
Enable the receiver's best knowledge of time to be output, even though it
might be wrong.
Enable the receiver's best knowledge of date to be output, even though it
might be wrong.
Restrict output to GPS satellites only.
Permit course over ground (COG) to be reported even when it would otherwise
be frozen.

Valid position
filteringTime filtering
Date filtering
GPS-only filtering
Track filtering

NMEA flags
Parameter

UBX-13003221 - R17

Description

Early Production Information

Page 113 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

NMEA flags continued
Parameter

Description

Compatibility
Mode

Some older NMEA applications expect the NMEA output to be formatted in a
specific way, for example, they will only work if the latitude and longitude haveexactly four digits behind the decimal point. u-blox receivers offer acompatibility mode to support these legacy applications.
u-blox receivers use a sophisticated signal quality detection scheme, in orderto produce the best possible position output. This algorithm considers all SV
measurements, and may eventually decide to only use a subset thereof, if it
improves the overall position accuracy. If Consideration mode is enabled, allsatellites, which were considered for navigation, are communicated as being
used for the position determination. If Consideration Mode is disabled, only
those satellites which after the consideration step remained in the position
output are marked as being used.
Enabling this mode will limit the NMEA sentence length to a maximum of 82
characters.
Enabling this mode increases precision of the position output. Latitude andlongitude then have seven digits after the decimal point, and altitude has
three digits after the decimal point. Note: The High Precision Mode cannot be
set in conjunction with either Compatibility Mode or Limit82 Mode.

Consideration
Mode

Limit82 ModeHigh Precision
Mode

Extended configuration
OptionDescription

GNSS to filter
Satellite
numbering
Main Talker ID

Filters satellites based on their GNSS
This field configures the display of satellites that do not have an NMEAdefined value. Note: this does not apply to satellites with an unknown ID.
By default the main Talker ID (i.e. the Talker ID used for all messages otherthan GSV) is determined by the GNSS assignment of the receiver's channels(see UBX-CFG-GNSS). This field enables the main Talker ID to be overridden.
By default the Talker ID for GSV messages is GNSS specific (as defined by
NMEA). This field enables the GSV Talker ID to be overridden.
By default the Talker ID for BeiDou is 'GB'. This field enables the BeiDou Talker
ID to be overridden.

GSV Talker ID
BDS Talker ID

Extra fields in NMEA 4.10 and above
Message

Extra fields

GBS
GNS
GRS
GSA
GSV
RMC

systemId, signalId
navStatus
systemId, signalId
systemId
signalId
navStatus

31.1.4 Satellite Numbering
The NMEA protocol (V4.10) identifies GNSS satellites with a one digit system ID and a two digit
satellite number. u-blox receivers support this method in their NMEA output when "strict" SV
numbering is selected.

UBX-13003221 - R17

Early Production Information

Page 114 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

In most cases this is the default setting, but can be checked or set using UBX-CFG-NMEA.
In order to support QZSS within current receivers and prepare for support of other systems (e.g.
Galileo) in future receivers, an "extended" SV numbering scheme can be enabled (using UBX-CFGNMEA).
This uses the NMEA-defined numbers where possible, but adds other number ranges to support
other GNSS. Note however that these non-standard extensions require 3 digit numbers, which
may not be supported by some NMEA parsing software. For example QZSS satellites are reported
using numbers in the range 193 to 197.
See Satellite Numbering for a complete list of satellite numbers.
GLONASS satellites can be tracked before they have been identified. In NMEA output,
such unknown satellite numbers are always reported as a null field (i.e. an empty string).
31.1.5 Latitude and Longitude Format
According to the NMEA Standard, Latitude and Longitude are output in the format Degrees,
Minutes and (Decimal) Fractions of Minutes. To convert to Degrees and Fractions of Degrees, or
Degrees, Minutes, Seconds and Fractions of seconds, the 'Minutes' and 'Fractional Minutes' parts
need to be converted. In other words: If the GPS Receiver reports a Latitude of 4717.112671 North
and Longitude of 00833.914843 East, this is
Latitude 47 Degrees, 17.112671 Minutes
Longitude 8 Degrees, 33.914843 Minutes
or
Latitude 47 Degrees, 17 Minutes, 6.76026 Seconds
Longitude 8 Degrees, 33 Minutes, 54.89058 Seconds
or
Latitude 47.28521118 Degrees
Longitude 8.56524738 Degrees
31.1.6 Position Fix Flags
This section shows how u-blox implements the NMEA protocol and the conditions determining
how flags are set.
Flags in NMEA 4.10 and above
NMEA Message
Field

GLL, RMC

GGA

GLL, VTG

RMC, GNS

statusquality

posModeposModeNo position fix (at power-up, after losing satellite lock)

V

0

N

N

GNSS fix, but user limits exceeded

V

0

N

N

Dead reckoning fix, but user limits exceeded

V

6

E

E

Dead reckoning fix

A

6

E

E

RTK float

A

5

D

F

RTK fixed

A

4

D

R

2D GNSS fix

A

1/2

A/D

A/D

3D GNSS fix

A

1/2

A/D

A/D

Combined GNSS/dead reckoning fix

A

1/2

A/D

A/D

See below (1)See below

See below

See below

(2)

(3)

(3)

UBX-13003221 - R17

Early Production Information

Page 115 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual(1) Possible values forstatus: V = Data invalid, A = Data valid(2) Possible values for quality: 0 = No fix, 1 = Autonomous GNSS fix, 2 = Differential GNSS fix, 4 =RTK fixed, 5 = RTK float, 6 = Estimated/Dead reckoning fix(3) Possible values for posMode: N = No fix, E = Estimated/Dead reckoning fix, A = Autonomous
GNSS fix, D = Differential GNSS fix, F = RTK float, R = RTK fixed
Flags in NMEA 2.3 and above
NMEA Message

GLL, RMC

GGA

GSA

GLL, VTG,

statusqualitynavModeposModeNo position fix (at power-up, after losing satellite lock)

V

0

1

N

GNSS fix, but user limits exceeded

V

0

1

N

Dead reckoning fix, but user limits exceeded

V

6

2

E

Dead reckoning fix

A

6

2

E

2D GNSS fix

A

1/2

2

A/D

3D GNSS fix

A

1/2

3

A/D

Combined GNSS/dead reckoning fix

A

1/2

3

A/D

See below (1)See below

See below

See below

(2)

(3)

(4)

RMC, GNS
Field(1) Possible values forstatus: V = Data invalid, A = Data valid(2) Possible values for quality: 0 = No fix, 1 = Autonomous GNSS fix, 2 = Differential GNSS fix, 4 =RTK fixed, 5 = RTK float, 6 = Estimated/Dead reckoning fix(3) Possible values for navMode: 1 = No fix, 2 = 2D fix, 3 = 3D fix(4) Possible values for posMode: N = No fix, E = Estimated/Dead reckoning fix, A = Autonomous
GNSS fix, D = Differential GNSS fix, F = RTK float, R = RTK fixed
Flags in NMEA 2.1 and below
The flags in NMEA 2.1 and below are the same as NMEA 2.3 and above but with the following
differences:• The posMode field is not output for GLL, RMC and VTG messages (each message has one fieldless).
• The GGA quality field is set to 1 (instead of 6) for both types of dead reckoning fix.
31.1.7 Multi-GNSS Considerations
Many applications which process NMEA messages assume that only a single GNSS is active.
However, when multiple GNSS are configured, the NMEA specification requires the output tochange in the following ways:
NMEA output for Multi-GNSS
ChangeDescription

Main Talker ID
GSV Talker IDs

The main Talker ID will be 'GN' (e.g. instead of 'GP' for a GPS receiver)
The GSV message reports the signal strength of the visible
satellites. However, the Talker ID it uses is specific to the GNSS it isreporting information for, so for a multi-GNSS receiver it will not be
the same as the main Talker ID. (e.g. other messages will be using
the 'GN' Talker ID but the GSV message will use GNSS-specificTalker IDs)

UBX-13003221 - R17

Early Production Information

Page 116 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

NMEA output for Multi-GNSS continued
ChangeDescription

Multiple GSA and GRS
Messages

Multiple GSA and GRS messages are output for each fix, one foreach GNSS. This may confuse applications which assume they are
output only once per position fix (as is the case for a single GNSS
receiver).

31.1.8 Output of Invalid/Unknown Data
By default the receiver will not output invalid data. In such cases, it will output empty fields.
A valid position fix is reported as follows:$GPGLL,4717.11634,N,00833.91297,E,124923.00,A,A*6E
An invalid position fix (but time valid) is reported as follows:$GPGLL,,,,,124924.00,V,N*42
If Time is unknown (e.g. during a cold-start):$GPGLL,,,,,,V,N*64
Note:
An exception from the above default are dead reckoning fixes, which are also output
when invalid (user limits exceeded).
Differing from the NMEA standard, u-blox reports valid dead reckoning fixes with user
limits met (not exceeded) as valid (A) instead of invalid (V).
Output of invalid data marked with the 'Invalid/Valid' Flags can be enabled using the UBX
protocol message UBX-CFG-NMEA.
31.1.9 Messages Overview
When configuring NMEA messages using the UBX protocol message UBX-CFG-MSG, the Class/Ids
shown in the table shall be used.
Page Mnemonic

Cls/ID

Description

NMEA Standard Messages

Standard Messages

119

DTM

0xF0 0x0A

Datum Reference

120

GBQ

0xF0 0x44

Poll a standard message (if the current Talker ID is GB)

120

GBS

0xF0 0x09

GNSS Satellite Fault Detection

121

GGA

0xF0 0x00

Global positioning system fix data

123

GLL

0xF0 0x01

Latitude and longitude, with time of position fix and status

124

GLQ

0xF0 0x43

Poll a standard message (if the current Talker ID is GL)

124

GNQ

0xF0 0x42

Poll a standard message (if the current Talker ID is GN)

125

GNS

0xF0 0x0D

GNSS fix data

126

GPQ

0xF0 0x40

Poll a standard message (if the current Talker ID is GP)

127

GRS

0xF0 0x06

GNSS Range Residuals

128

GSA

0xF0 0x02

GNSS DOP and Active Satellites

129

GST

0xF0 0x07

GNSS Pseudo Range Error Statistics

130

GSV

0xF0 0x03

GNSS Satellites in View

131

RMC

0xF0 0x04

Recommended Minimum data

UBX-13003221 - R17

Early Production Information

Page 117 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

NMEA Messages Overview continued
Page Mnemonic

Cls/ID

Description

132

TXT

0xF0 0x41

Text Transmission

133

VLW

0xF0 0x0F

Dual ground/water distance

134

VTG

0xF0 0x05

Course over ground and Ground speed

135

ZDA

0xF0 0x08

Time and Date

NMEA PUBX Messages

Proprietary Messages

136

CONFIG

0xF1 0x41

Set Protocols and Baudrate

137

POSITION

0xF1 0x00

Lat/Long Position Data

138

RATE

0xF1 0x40

Set NMEA message output rate

139

SVSTATUS

0xF1 0x03

Satellite Status

140

TIME

0xF1 0x04

Time of Day and Clock Information

UBX-13003221 - R17

Early Production Information

Page 118 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2 Standard Messages
Standard Messages: i.e. Messages as defined in the NMEA Standard.
31.2.1 DTM
31.2.1.1 Datum Reference
Message

DTM

Description

Datum ReferenceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message gives the difference between the current datum and the reference
datum.
The current datum defaults to WGS84.
The reference datum cannot be changed and is always set to WGS84.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x0A

11

Message Structure:$xxDTM,datum,subDatum,lat,NS,lon,EW,alt,refDatum*cs<CR><LF>

Example:$GPDTM,W84,,0.0,N,0.0,E,0.0,W84*6F$GPDTM,999,,0.08,N,0.07,E,-47.7,W84*1C
Field Name

Unit

FormatExampleDescription

DTM Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
Local datum code: W84 = WGS84, P90 =PZ90 (supported in protocol versions greaterthan 19.1), 999 = user defined
A null field
Offset in Latitude
North/South indicator
Offset in Longitude
East/West indicator
Offset in altitude
Reference datum code: W84 (WGS 84, fixed
field)
Checksum
Carriage return and line feed

No.

0

xxDTM

-

string$GPDTM

1

datum

-

string

W84

2
3
4
5
6
7
8

subDatum
lat
NS
lon
EW
alt
refDatumstringmin numericcharactermin numericcharacterm
numeric
string

0.08
S
0.07
E
-2.8
W84

9
10

cs
<CR><LF>-

UBX-13003221 - R17

hexadecimal *67
character-

Early Production Information

Page 119 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.2 GBQ
31.2.2.1 Poll a standard message (if the current Talker ID is GB)
Message

GBQ

Description

Poll a standard message (if the current Talker ID is GB)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Polls a standard NMEA message if the current Talker ID is GB

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x44

4Message Structure:$xxGBQ,msgId*cs<CR><LF>

Example:$EIGBQ,RMC*28
Field Name

Unit

FormatExampleDescription$EIGBQ

GBQ Message ID (xx = Talker ID of the device
requesting the poll)
Message ID of the message to be polled
Checksum
Carriage return and line feed

No.

0

xxGBQ

-

string

1
2
3

msgId
cs
<CR><LF>-

string
RMC
hexadecimal *28
character-

31.2.3 GBS
31.2.3.1 GNSS Satellite Fault Detection
Message

GBS

Description

GNSS Satellite Fault Detection

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message outputs the results of the Receiver Autonomous Integrity
Monitoring Algorithm (RAIM).
• The fields errLat, errLon and errAlt output the standard deviation of theposition calculation, using all satellites which pass the RAIM test successfully.
• The fields errLat, errLon and errAlt are only output if the RAIM process
passed successfully (i.e. no or successful edits happened). These fields arenever output if 4 or fewer satellites are used for the navigation calculation(because, in such cases, integrity can not be determined by the receiverautonomously).
• The fields prob, bias and stdev are only output if at least one satellite failed in
the RAIM test.
If more than one satellites fail the RAIM test, only the information for the worst
satellite is output in this message.
ID for CFG-MSG

UBX-13003221 - R17

Number of fields

Early Production Information

Page 120 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Message Info

0xF0 0x09

13

Message Structure:$xxGBS,time,errLat,errLon,errAlt,svid,prob,bias,stddev,systemId,signalId*cs<CR><LF>

Example:$GPGBS,235503.00,1.6,1.4,3.2,,,,,,*40$GPGBS,235458.00,1.4,1.3,3.1,03,,-21.4,3.8,1,0*5B
Field Name

Unit

FormatExampleDescription

GBS Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
UTC time to which this RAIM sentence
belongs, see note on UTC representation
Expected error in latitude
Expected error in longitude
Expected error in altitude
Satellite ID of most likely failed satellite
Probability of missed detection: null (notsupported, fixed field)
Estimated bias of most likely failed satellite (apriori residual)
Standard deviation of estimated bias
NMEA defined GNSS System ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
NMEA defined GNSS Signal ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
Checksum
Carriage return and line feed

No.

0

xxGBS

-

string$GPGBS1time-hhmmss.ss

235503.00

2
3
4
5
6

errLaterrLonerrAlt
svid
prob

m
m
m
-

numeric
numeric
numeric
numeric
numeric

1.6
1.4
3.2
03
-

7

bias

m

numeric

-21.4

8
9

stddevsystemIdm-numeric
numeric

3.8
110

signalId-

numeric

0

11
12

cs
<CR><LF>-

hexadecimal *5Bcharacter-

31.2.4 GGA
31.2.4.1 Global positioning system fix data
Message

GGA

Description

Global positioning system fix data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The output of this message is dependent on the currently selected datum(default: WGS84). The NMEA specification indicates that the GGA message is
GPS specific. However, when the receiver is configured for multi-GNSS, theGGA message contents will be generated from the multi-GNSS solution. For
multi-GNSS use, it is recommended that the NMEA-GNS message is usedinstead.
Time and position, together with GPS fixing related data (number of satellites in

UBX-13003221 - R17

Early Production Information

Page 121 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

use, and the resulting HDOP, age of differential data if in use, etc.).
Message Info

ID for CFG-MSG

Number of fields

0xF0 0x00

17

Message Structure:$xxGGA,time,lat,NS,lon,EW,quality,numSV,HDOP,alt,altUnit,sep,sepUnit,diffAge,diffStation*cs<CR><LF>

Example:$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,08,1.01,499.6,M,48.0,M,,*5B
Field Name

Unit

FormatExamplestring$GPGGA

Description

No.

0

xxGGA

-

1
2

time
lat

-

3
4

NS
lon

-

5
6

EW
quality

-

7
8
9
10
11

numSV
HDOP
alt
altUnit
sep

m
m

12
13

sepUnit
diffAges

14

diffStation
cs<CR><LF>-

15
16

UBX-13003221 - R17-

GGA Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
hhmmss.ss 092725.00
UTC time, see note on UTC representation
ddmm.
4717.11399 Latitude (degrees & minutes), see format
mmmmm
description
characterN
North/South indicator
dddmm.
00833.91590 Longitude (degrees & minutes), see format
mmmmm
description
characterE
East/West indicatordigit
1
Quality indicator for position fix, see position
fix flags description
numeric
08
Number of satellites used (range: 0-12)
numeric
1.01
Horizontal Dilution of Precision
numeric
499.6
Altitude above mean sea level
character
M
Altitude units: M (meters, fixed field)
numeric
48.0
Geoid separation: difference between ellipsoidand mean sea level
characterM
Geoid separation units: M (meters, fixed field)
numeric
Age of differential corrections (null when
DGPS is not used)numeric
ID of station providing differential corrections(null when DGPS is not used)hexadecimal *5B
Checksumcharacter
Carriage return and line feed

Early Production Information

Page 122 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.5 GLL
31.2.5.1 Latitude and longitude, with time of position fix and status
Message

GLL

Description

Latitude and longitude, with time of position fix and status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The output of this message is dependent on the currently selected datum(default: WGS84)-

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x01

10

Message Structure:$xxGLL,lat,NS,lon,EW,time,status,posMode*cs<CR><LF>

Example:$GPGLL,4717.11364,N,00833.91565,E,092321.00,A,A*60
Field Name

Unit

FormatExamplestring$GPGLL

Description

No.

0

xxGLL

-

1

lat

-

2
3

NS
lon

-

4
5
6

EW
time
status-7

posMode-8
9

cs<CR><LF>-

UBX-13003221 - R17

GLL Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
ddmm.
4717.11364 Latitude (degrees & minutes), see format
mmmmm
description
characterN
North/South indicator
dddmm.
00833.91565 Longitude (degrees & minutes), see format
mmmmm
description
characterE
East/West indicatorhhmmss.ss 092321.00
UTC time, see note on UTC representation
character
A
Data validity status, see position fix flags
description
character
A
Positioning mode, see position fix flags
description (only available in NMEA 2.3 andlater)
hexadecimal *60
Checksumcharacter
Carriage return and line feed

Early Production Information

Page 123 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.6 GLQ
31.2.6.1 Poll a standard message (if the current Talker ID is GL)
Message

GLQ

Description

Poll a standard message (if the current Talker ID is GL)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Polls a standard NMEA message if the current Talker ID is GL

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x43

4Message Structure:$xxGLQ,msgId*cs<CR><LF>

Example:$EIGLQ,RMC*3A
Field Name

Unit

FormatExampleDescription$EIGLQ

GLQ Message ID (xx = Talker ID of the device
requesting the poll)
Message ID of the message to be polled
Checksum
Carriage return and line feed

No.

0

xxGLQ

-

string

1
2
3

msgId
cs
<CR><LF>-

string
RMC
hexadecimal *3A
character-

31.2.7 GNQ
31.2.7.1 Poll a standard message (if the current Talker ID is GN)
Message

GNQ

Description

Poll a standard message (if the current Talker ID is GN)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Polls a standard NMEA message if the current Talker ID is GN

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x42

4

Message Structure:$xxGNQ,msgId*cs<CR><LF>

Example:$EIGNQ,RMC*3A
Field Name

Unit

FormatExampleDescription$EIGNQ

GNQ Message ID (xx = Talker ID of the device
requesting the poll)
Message ID of the message to be polled
Checksum

No.

0

xxGNQ

-

string

1
2

msgId
cs

-

string
RMC
hexadecimal *3A

UBX-13003221 - R17

Early Production Information

Page 124 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GNQ continued
Field Name

Unit

FormatExampleDescription-

character-

Carriage return and line feedNo.

3

<CR><LF>

31.2.8 GNS
31.2.8.1 GNSS fix data
Message

GNS

Description

GNSS fix data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The output of this message is dependent on the currently selected datum(default: WGS84)
Time and position, together with GNSS fixing related data (number of satellites
in use, and the resulting HDOP, age of differential data if in use, etc.).

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x0D

16

Message Structure:$xxGNS,time,lat,NS,lon,EW,posMode,numSV,HDOP,alt,sep,diffAge,diffStation,navStatus*cs<CR><LF>

Example:$GNGNS,103600.01,5114.51176,N,00012.29380,W,ANNN,07,1.18,111.5,45.6,,,V*00$GNGNS,122310.2,3722.425671,N,12258.856215,W,DAAA,14,0.9,1005.543,6.5,,,V*0E$GPGNS,122310.2,,,,,,07,,,,5.2,23,V*02
Field Name

Unit

FormatExample$GPGNS

Description

No.

0

xxGNS

-

string

1
2

time
lat

-

3
4

NS
lon

-

5
6

EW
posMode-hhmmss.ss
ddmm.
mmmmm
character
dddmm.
mmmmm
charactercharacter

7
8
9
10

numSV
HDOP
alt
sep

m
m

numeric
numeric
numeric
numeric

UBX-13003221 - R17

GNS Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
091547.00
UTC time, see note on UTC representation
5114.50897 Latitude (degrees & minutes), see format
description
N
North/South indicator
00012.28663 Longitude (degrees & minutes), see format
description
E
East/West indicator
AAAA
Positioning mode, see position fix flags
description. First character for GPS, second
character for GLONASS, Third character for
Galileo, Fourth character for BeiDou
10
Number of satellites used (range: 0-99)
0.83
Horizontal Dilution of Precision
111.1
Altitude above mean sea level
45.6
Geoid separation: difference between ellipsoidand mean sea level

Early Production Information

Page 125 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GNS continued
Field Name

Unit

FormatExampleDescription

Age of differential corrections (null when
DGPS is not used)
ID of station providing differential corrections(null when DGPS is not used)
Navigational status indicator: V (Equipment is
not providing navigational status information,
fixed field, only available in NMEA 4.10 andlater)
Checksum
Carriage return and line feed

No.

11

diffAges

numeric-

12

diffStation
navStatus-

numeric--

characterV

cs<CR><LF>-

hexadecimal *71
character
-

13

14
15

31.2.9 GPQ
31.2.9.1 Poll a standard message (if the current Talker ID is GP)
Message

GPQ

Description

Poll a standard message (if the current Talker ID is GP)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Polls a standard NMEA message if the current Talker ID is GP

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x40

4Message Structure:$xxGPQ,msgId*cs<CR><LF>

Example:$EIGPQ,RMC*3A
Field Name

Unit

FormatExampleDescription$EIGPQ

GPQ Message ID (xx = Talker ID of the device
requesting the poll)
Message ID of the message to be polled
Checksum
Carriage return and line feed

No.

0

xxGPQ

-

string

1
2
3

msgId
cs
<CR><LF>-

string
RMC
hexadecimal *3A
character-

UBX-13003221 - R17

Early Production Information

Page 126 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.10 GRS
31.2.10.1 GNSS Range Residuals
Message

GRS

Description

GNSS Range Residuals

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This messages relates to associated GGA and GSA messages.
If less than 12 SVs are available, the remaining fields are output empty. If morethan 12 SVs are used, only the residuals of the first 12 SVs are output, in order toremain consistent with the NMEA standard.
In a multi-GNSS system this message will be output multiple times, once foreach GNSS.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x06

19

Message Structure:$xxGRS,time,mode{,residual},systemId,signalId*cs<CR><LF>

Example:$GNGRS,104148.00,1,2.6,2.2,-1.6,-1.1,-1.7,-1.5,5.8,1.7,,,,,1,1*52$GNGRS,104148.00,1,,0.0,2.5,0.0,,2.8,,,,,,,1,5*52
Field Name

Unit

FormatExampleDescription

GRS Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
UTC time of associated position fix, see noteon UTC representation
Computation method used:
1 = Residuals were recomputed after theGGA
position was computed (fixed)

No.

0

xxGRS

-

string$GPGRS1time-hhmmss.ss

082632.00

2

mode

-

digit

1

Start of repeated block (12 times)

3 + residual
1*Nmnumeric

0.54

Range residuals for SVs used in navigation.
The SV order matches the order from the
GSA sentence
NMEA defined GNSS System ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
NMEA defined GNSS Signal ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
Checksum
Carriage return and line feed

End of repeated block15

systemId-

numeric

1

16

signalId-

numeric

0

17
18

cs
<CR><LF>-

hexadecimal *70
character-

UBX-13003221 - R17

Early Production Information

Page 127 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.11 GSA
31.2.11.1 GNSS DOP and Active Satellites
Message

GSA

Description

GNSS DOP and Active Satellites

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The GNSS receiver operating mode, satellites used for navigation, and DOP
values.
• If less than 12 SVs are used for navigation, the remaining fields are left empty.
If more than 12 SVs are used for navigation, only the IDs of the first 12 are
output.
• The SV numbers (fields 'svid') are in the range of 1 to 32 for GPS satellites, and
33 to 64 for SBAS satellites (33 = SBAS PRN 120, 34 = SBAS PRN 121, and soon)
In a multi-GNSS system this message will be output multiple times, once foreach GNSS.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x02

21

Message Structure:$xxGSA,opMode,navMode{,svid},PDOP,HDOP,VDOP,systemId*cs<CR><LF>

Example:$GPGSA,A,3,23,29,07,08,09,18,26,28,,,,,1.94,1.18,1.54,1*0D
Field Name

Unit

FormatExampleDescription

GSA Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
Operation mode:
M = Manually set to operate in 2D or 3D mode
A = Automatically switching between 2D or
3D modeNavigation mode, see position fix flags
description

No.

0

xxGSA

-

string$GPGSA

1

opMode-characterA

2

navMode

-

digit

3

Start of repeated block (12 times)

3 + svid
1*N-

numeric

29

Satellite number

1.94
1.18
1.54
1

Position dilution of precision
Horizontal dilution of precision
Vertical dilution of precision
NMEA defined GNSS System ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
ChecksumEnd of repeated block

15
16
17
18

PDOP
HDOP
VDOP
systemId-

numeric
numeric
numeric
numeric

19

cs-

hexadecimal *0D

UBX-13003221 - R17

Early Production Information

Page 128 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GSA continued
Field Name

Unit

FormatExampleDescription-

character-

Carriage return and line feed

No.

20

<CR><LF>

31.2.12 GST
31.2.12.1 GNSS Pseudo Range Error Statistics
Message

GST

Description

GNSS Pseudo Range Error Statistics

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message reports statistical information on the quality of the position
solution.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x07

11

Message Structure:$xxGST,time,rangeRms,stdMajor,stdMinor,orient,stdLat,stdLong,stdAlt*cs<CR><LF>

Example:$GPGST,082356.00,1.8,,,,1.7,1.3,2.2*7E
Field Name

Unit

FormatExampleDescription

GST Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
UTC time of associated position fix, see noteon UTC representation
RMS value of the standard deviation of therangesStandard deviation of semi-major axis (onlysupported in ADR 4.10 and later)
Standard deviation of semi-minor axis (onlysupported in ADR 4.10 and later)
Orientation of semi-major axis (onlysupported in ADR 4.10 and later)
Standard deviation of latitude error
Standard deviation of longitude error
Standard deviation of altitude error
Checksum
Carriage return and line feed

No.

0

xxGST

-

string$GPGST1time-hhmmss.ss

082356.00

2

rangeRmsmnumeric

1.8

3

stdMajormnumeric-4

stdMinorm

numeric-

5

orientdeg numeric

-

6
7
8
9
10

stdLatstdLong
stdAltcs<CR><LF>

m
m
m
-

1.7
1.3
2.2
*7E
-

UBX-13003221 - R17

numeric
numeric
numeric
hexadecimal
character

Early Production Information

Page 129 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.2.13 GSV
31.2.13.1 GNSS Satellites in View
Message

GSV

Description

GNSS Satellites in View

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The number of satellites in view, together with each SV ID, elevation azimuth,and signal strength (C/No) value. Only four satellite details are transmitted in
one message.
In a multi-GNSS system sets of GSV messages will be output multiple times,
one set for each GNSS.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x03

8..16

Message Structure:$xxGSV,numMsg,msgNum,numSV{,svid,elv,az,cno},signalId*cs<CR><LF>

Example:$GPGSV,3,1,09,09,,,17,10,,,40,12,,,49,13,,,35,1*6F$GPGSV,3,2,09,15,,,44,17,,,45,19,,,44,24,,,50,1*64$GPGSV,3,3,09,25,,,40,1*6E$GPGSV,1,1,03,12,,,42,24,,,47,32,,,37,5*66$GAGSV,1,1,00,2*76
Field Name

Unit

FormatExampleDescription

GSV Message ID (xx = GSV Talker ID, see
NMEA Talker IDs table). Talker ID GN shall not
be usedNumber of messages, total number of GSV
messages being output (range: 1-9)
Number of this message (range: 1-numMsg)
Number of known satellites in view regarding
both the talker ID and the signalId

No.

0

xxGSV

-

string$GPGSV1

numMsg

-

digit

3

2
3

msgNum
numSV

-

digit
numeric

1
10Start of repeated block (1..4 times)

4+
4*N
5+
4*N
6+
4*N
7+
4*N

svid

-

numeric

23

Satellite ID

elv

deg numeric38

Elevation (range: 0-90)

az

deg numeric

230

Azimuth (range: 0-359)

cno

dB
Hz

44

Signal strength (C/N0, range: 0-99), null when
not tracking

numeric

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 130 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

GSV continued
Field Name

Unit

FormatExampleDescription

0

No.

5..
16

signalId-

numeric

6..
16
7..
16

cs

-

hexadecimal *7F

NMEA defined GNSS Signal ID, see Signal
Identifiers table (only available in NMEA 4.10
and later)
Checksum<CR><LF>-

character

Carriage return and line feed-

31.2.14 RMC
31.2.14.1 Recommended Minimum data
Message

RMC

Description

Recommended Minimum data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The output of this message is dependent on the currently selected datum(default: WGS84)
The recommended minimum sentence defined by NMEA for GNSS system data.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x04

16

Message Structure:$xxRMC,time,status,lat,NS,lon,EW,spd,cog,date,mv,mvEW,posMode,navStatus*cs<CR><LF>

Example:$GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A,V*57
Field Name

Unit

FormatExample$GPRMC

Description

No.

0

xxRMC

-

string1
2

time
status-hhmmss.ss
character

3

lat

-

4
5

NS
lon

6
7

EW
spd

8

cog

UBX-13003221 - R17

ddmm.
mmmmm
character
dddmm.
mmmmm
characterkno numericts
deg numericrees

RMC Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
083559.00
UTC time, see note on UTC representation
A
Data validity status, see position fix flags
description
4717.11437 Latitude (degrees & minutes), see format
description
N
North/South indicator
00833.91522 Longitude (degrees & minutes), see format
description
E
East/West indicator
0.004
Speed over ground77.52

Course over ground

Early Production Information

Page 131 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

RMC continued
Field Name

Unit

FormatExampleDescription

ddmmyy091202

Date in day, month, year format, see note on
UTC representation
Magnetic variation value. Only supported in
ADR 4.10 and later

No.

9

date

-

10

mv

-

11

mvEW

deg numericreescharacter

12

posMode-characterA

13

navStatus-character

V

14
15

cs
<CR><LF>-

hexadecimal *57
character--

Magnetic variation E/W indicator. Only
supported in ADR 4.10 and later
Mode Indicator, see position fix flags
description (only available in NMEA 2.3 andlater)
Navigational status indicator: V (Equipment is
not providing navigational status information,
fixed field, only available in NMEA 4.10 andlater)
Checksum
Carriage return and line feed

31.2.15 TXT
31.2.15.1 Text Transmission
Message

TXT

Description

Text Transmission

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment-

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x41

7

Message Structure:$xxTXT,numMsg,msgNum,msgType,text*cs<CR><LF>

Example:$GPTXT,01,01,02,u-blox ag - www.u-blox.com*50$GPTXT,01,01,02,ANTARIS ATR0620 HW 00000040*67
Field Name

Unit

FormatExampleDescription

TXT Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
Total number of messages in thistransmission (range: 1-99)
Message number in this transmission (range:
1-numMsg)

No.

0

xxTXT

-

string$GPTXT1

numMsg-numeric

01

2

msgNum-numeric

01

UBX-13003221 - R17

Early Production Information

Page 132 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

TXT continued
Field Name

Unit

FormatExampleDescription

02

Text identifier (u-blox receivers specify thetype of the message with this number):
00: Error
01: Warning
02: Notice
07: UserAny ASCII textNo.

3

msgType-numeric

4

text

-

string5
6

cs<CR><LF>-

www.u-blox.
com
hexadecimal *67
character-

Checksum
Carriage return and line feed

31.2.16 VLW
31.2.16.1 Dual ground/water distance
Message

VLW

Description

Dual ground/water distanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The distance traveled, relative to the water and over the ground. This message
relates to the Odometer functionality.
Contrarily to the NMEA standard, if NMEA 2.1 or 2.3 are configured, thesentence will additionally contain tgd, tgdUnit, gd and gdUnit fields.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x0F

11

Message Structure:$xxVLW,twd,twdUnit,wd,wdUnit,tgd,tgdUnit,gd,gdUnit*cs<CR><LF>

Example:$GPVLW,,N,,N,15.8,N,1.2,N*06
Field Name

Unit

FormatExampleDescription

string$GPVLW

VLW Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
Total cumulative water distance: null (fixed
field)
Total cumulative water distance units: N(nautical miles, fixed field)
Water distance since reset: null (fixed field)
Water distance since reset units: N (nautical
miles, fixed field)
Total cumulative ground distance (onlyavailable in NMEA 4.00 and later)

No.

0

xxVLW

-

1

twd

nmi numeric-2

twdUnit-character

N

3
4

wd
wdUnitnmi numericcharacter

N

5

tgd

nmi numeric

15.8

UBX-13003221 - R17

Early Production Information

Page 133 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

VLW continued
Field Name

Unit

FormatExampleDescription

characterN

Total cumulative ground distance units: N(nautical miles, fixed field, only available in
NMEA 4.00 and later)
Ground distance since reset (only available in
NMEA 4.00 and later)
Ground distance since reset units: N (nautical
miles, fixed field, only available in NMEA 4.00
and later)
Checksum
Carriage return and line feedNo.

6

tgdUnit-

7gd

nmi numeric

1.2

8

gdUnit-character

N

9
10

cs
<CR><LF>-

hexadecimal *06
character-

31.2.17 VTG
31.2.17.1 Course over ground and Ground speed
Message

VTG

Description

Course over ground and Ground speed

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

Velocity is given as Course over Ground (COG) and Speed over Ground (SOG).

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x05

12

Message Structure:$xxVTG,cogt,cogtUnit,cogm,cogmUnit,sogn,sognUnit,sogk,sogkUnit,posMode*cs<CR><LF>

Example:$GPVTG,77.52,T,,M,0.004,N,0.008,K,A*06
Field Name

Unit

FormatExampleDescription

VTG Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
Course over ground (true)

No.

0

xxVTG

-

string$GPVTG

1

cogt

77.52

2

cogtUnit

deg numericreescharacter

3

cogm

-

4

cogmUnit

deg numericreescharacter

5

sogn

0.004

6

sognUnit

kno numerictscharacterCourse over ground units: M (degrees
magnetic, fixed field)
Speed over groundN

Speed over ground units: N (knots, fixed field)

UBX-13003221 - R17

T

M

Course over ground units: T (degrees true,
fixed field)
Course over ground (magnetic). Only
supported in ADR 4.10 and above

Early Production Information

Page 134 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

VTG continued
Field Name

Unit

FormatExampleDescription

0.008

Speed over groundK
A

Speed over ground units: K (kilometers perhour, fixed field)
Mode Indicator, see position fix flags
description (only available in NMEA 2.3 andlater)
Checksum
Carriage return and line feed

No.

7

sogk

8

sogkUnit

km/ numerichcharacter9

posMode-character

10
11

cs
<CR><LF>-

hexadecimal *06
character-

31.2.18 ZDA
31.2.18.1 Time and Date
Message

ZDA

Description

Time and DateFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

UTC, day, month, year and local time zone.

Message Info

ID for CFG-MSG

Number of fields

0xF0 0x08

9Message Structure:$xxZDA,time,day,month,year,ltzh,ltzn*cs<CR><LF>

Example:$GPZDA,082710.00,16,09,2002,00,00*64
Field Name

Unit

FormatExampleDescription

No.

0

xxZDA

-

string$GPZDA

1
2
3

time
day
month

hhmmss.ss
ddmm082710.00
16
09

4

year

yyyy

2002

UTC year

5
6
7
8

ltzh
ltzn
cs
<CR><LF>

day
mo
nth
yea
r
-

ZDA Message ID (xx = current Talker ID, see
NMEA Talker IDs table)
UTC Time, see note on UTC representation
UTC day (range: 1-31)
UTC month (range: 1-12)xx
zz
hexadecimal
character

00
00
*64
-

Local time zone hours: 00 (fixed field)
Local time zone minutes: 00 (fixed field)
Checksum
Carriage return and line feed

UBX-13003221 - R17

Early Production Information

Page 135 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.3 PUBX Messages
Proprietary Messages: i.e. Messages defined by u-blox.
31.3.1 CONFIG (PUBX,41)
31.3.1.1 Set Protocols and Baudrate
Message

CONFIG

Description

Set Protocols and Baudrate

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Set

Comment-

Message Info

ID for CFG-MSG

Number of fields

0xF1 0x41

9Message Structure:$PUBX,41,portId,inProto,outProto,baudrate,autobauding*cs<CR><LF>

Example:$PUBX,41,1,0007,0003,19200,0*25
Field Name

Unit

FormatExampleDescription

Message ID, UBX protocol header, proprietary
sentence
Proprietary message identifier
ID of communication port. For a list of port IDs
see Serial Communication Ports Description.
Input protocol mask. Bitmask, specifying
which protocols(s) are allowed for input. For
details see corresponding field in UBX-CFGPRT.
Output protocol mask. Bitmask, specifying
which protocols(s) are allowed for input. For
details see corresponding field in UBX-CFGPRT.
Baudrate

No.

0

$PUBX

-

string

$PUBX

1
2

msgId
portId-numeric
numeric

41
1

3

inProto-hexadecimal 0007

4

outProto-

hexadecimal 0003

5

baudrate

6

autobauding
cs<CR><LF>

bits numeric/s
numeric

7
8

UBX-13003221 - R17

-

19200
0

hexadecimal *25
character-

Autobauding: 1=enable, 0=disable (notsupported on u-blox 5, set to 0)
Checksum
Carriage return and line feed

Early Production Information

Page 136 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

31.3.2 POSITION (PUBX,00)
31.3.2.1 Lat/Long Position Data
Message

POSITION

Description

Lat/Long Position Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The output of this message is dependent on the currently selected datum(default: WGS84)
This message contains position solution data. The datum selection may bechanged using the message UBX-CFG-DAT.

Message Info

ID for CFG-MSG

Number of fields

0xF1 0x00

23

Message Structure:$PUBX,00,time,lat,NS,long,EW,altRef,navStat,hAcc,vAcc,SOG,COG,vVel,diffAge,HDOP,VDOP,TDOP,numSvs,reserved,DR,*cs<CR><LF>

Example:$PUBX,00,081350.00,4717.113210,N,00833.915187,E,546.589,G3,2.1,2.0,0.007,77.52,0.007,,0.92,1.19,0.7
7,9,0,0*5F
Field Name

Unit

FormatExample$PUBX

Description

No.

0

$PUBX

-

string

1
2
3

msgId
time
lat

-

4
5

NS
long

-

6
7
8

EW
altRefnavStatm-

numeric
hhmmss.ss
ddmm.
mmmmm
character
dddmm.
mmmmm
characternumeric
string

9
10

hAcc
vAcc

m
m

numeric
numeric

UBX-13003221 - R17

Message ID, UBX protocol header, proprietary
sentence00
Proprietary message identifier: 00
081350.00
UTC time, see note on UTC representation
4717.113210 Latitude (degrees & minutes), see format
description
N
North/South Indicator
00833.
Longitude (degrees & minutes), see format
915187
description
E
East/West indicator
546.589
Altitude above user datum ellipsoid.
G3
Navigation Status:
NF = No Fix
DR = Dead reckoning only solution
G2 = Stand alone 2D solution
G3 = Stand alone 3D solution
D2 = Differential 2D solution
D3 = Differential 3D solution
RK = Combined GPS + dead reckoning
solution
TT = Time only solution
2.1
Horizontal accuracy estimate.
2.0
Vertical accuracy estimate.
Early Production Information

Page 137 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

POSITION continued
Field Name

Unit

FormatExampleDescription

0.007

Speed over ground

77.52
0.007
-

Course over ground
Vertical velocity (positive downwards)
Age of differential corrections (blank when
DGPS is not used)
HDOP, Horizontal Dilution of Precision
VDOP, Vertical Dilution of Precision
TDOP, Time Dilution of Precision
Number of satellites used in the navigation
solution
Reserved, always set to 0
DR usedChecksum
Carriage return and line feed

No.

11

SOG

12
13
14

COG
vVel
diffAge

km/ numerichdeg numericm/s numerics
numeric

15
16
17
18

HDOP
VDOP
TDOP
numSvs-numeric
numeric
numeric
numeric

0.92
1.19
0.77
9

19
20
21
22

reservedDR
cs<CR><LF>-

numeric
numeric
hexadecimal
character

0
0
*5B
-

31.3.3 RATE (PUBX,40)
31.3.3.1 Set NMEA message output rate
Message

RATE

Description

Set NMEA message output rate

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Set

Comment

Set/Get message rate configuration (s) to/from the receiver.
• Send rate is relative to the event a message is registered on. For example, if
the rate of a navigation message is set to 2, the message is sent every second
navigation solution.

Message Info

ID for CFG-MSG

Number of fields

0xF1 0x40

11Message Structure:$PUBX,40,msgId,rddc,rus1,rus2,rusb,rspi,reserved*cs<CR><LF>

Example:$PUBX,40,GLL,1,0,0,0,0,0*5D
Field Name

Unit

FormatExampleDescription

Message ID, UBX protocol header, proprietary
sentence
Proprietary message identifier
NMEA message identifier

No.

0

$PUBX

-

string

$PUBX

1
2

ID
msgId

-

numeric
string40
GLL

UBX-13003221 - R17

Early Production Information

Page 138 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

RATE continued
Field Name

Unit

FormatExampleDescription

output rate on DDC
0 disables that message from being output
on this port
1 means that this message is output every
epoch
output rate on USART 1
0 disables that message from being output
on this port
1 means that this message is output every
epoch
output rate on USART 2
0 disables that message from being output
on this port
1 means that this message is output every
epoch
output rate on USB
0 disables that message from being output
on this port
1 means that this message is output every
epoch
output rate on SPI
0 disables that message from being output
on this port
1 means that this message is output every
epoch
Reserved: always fill with 0
Checksum
Carriage return and line feed

No.

3

rddc

cycl numeric
es

1

4

rus1

cycl numeric
es

1

5

rus2

cycl numeric
es

1

6

rusb

cycl numeric
es

1

7

rspi

cycl numeric
es

1

8
9
10

reserved
cs<CR><LF>-

numeric0
hexadecimal *5Dcharacter-

31.3.4 SVSTATUS (PUBX,03)
31.3.4.1 Satellite Status
Message

SVSTATUS

Description

Satellite Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The PUBX,03 message contains satellite status information.

Message Info

ID for CFG-MSG

Number of fields

0xF1 0x03

5 + 6*n

Message Structure:$PUBX,03,GT{,sv,s,az,el,cno,lck},*cs<CR><LF>

Example:UBX-13003221 - R17

Early Production Information

Page 139 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual$PUBX,03,11,23,-,,,45,010,29,-,,,46,013,07,-,,,42,015,08,U,067,31,42,025,10,U,195,33,46,026,18,U,32
6,08,39,026,17,-,,,32,015,26,U,306,66,48,025,27,U,073,10,36,026,28,U,089,61,46,024,15,-,,,39,014*0D
Field Name

Unit

FormatExampleDescription

Message ID, UBX protocol header, proprietary
sentence
Proprietary message identifier: 03
Number of GNSS satellites tracked

No.

0

$PUBX

-

string

$PUBX

1
2

msgId
n

-

numeric
numeric

03
11

Start of repeated block (n times)

3 + sv
6*N
4+ s
6*N

-

numeric

23-

character

-

5+
6*N
6+
6*N
7+
6*N
8+
6*N

az

deg numeric-

Satellite ID according to UBX svId mapping(see Satellite Numbering)
Satellite status:- = Not used
U = Used in solutione = Ephemeris available, but not used fornavigation
Satellite azimuth (range: 0-359)

eldeg numeric-

Satellite elevation (range: 0-90)

cno

dB
Hz
s

numeric

45

numeric010

Signal strength (C/N0, range 0-99), blankwhen not tracking
Satellite carrier lock time (range: 0-64)
0: code lock only
64: lock for 64 seconds or more-hexadecimal *0D

Checksum-character

Carriage return and line feedlck

End of repeated block

3 + cs6*n
4 + <CR><LF>
6*n-

31.3.5 TIME (PUBX,04)
31.3.5.1 Time of Day and Clock Information
Message

TIME

Description

Time of Day and Clock Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment-

Message Info

ID for CFG-MSG

Number of fields

0xF1 0x04

12

Message Structure:$PUBX,04,time,date,utcTow,utcWk,leapSec,clkBias,clkDrift,tpGran,*cs<CR><LF>

Example:UBX-13003221 - R17

Early Production Information

Page 140 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual$PUBX,04,073731.00,091202,113851.00,1196,15D,1930035,-2660.664,43,*3C
Field Name

Unit

FormatExampleDescription

Message ID, UBX protocol header, proprietary
sentence
Proprietary message identifier: 04
UTC time, see note on UTC representation
UTC date, day, month, year format, see noteon UTC representation
UTC Time of Week
UTC week number, continues beyond 1023
Leap seconds
The number is marked with a D if the value isthe firmware default value. If the value is notmarked it has been received from a satellite.
Receiver clock bias
Receiver clock drift

No.

0

$PUBX

-

string

$PUBX

1
2
3

msgId
time
date

-

numeric
hhmmss.ss
ddmmyy04073731.00
0912024
5
6

utcTow
utcWk
leapSecssnumeric
113851.00
numeric
1196
numeric/text 15D7
8

clkBiasclkDriftnumeric
numeric

1930035-2660.664

9

tpGran

ns
ns/
s
ns

numeric

43

10
11

cs
<CR><LF>-

hexadecimal *3C
character-

UBX-13003221 - R17

Time Pulse Granularity, The quantization
error of the TIMEPULSE pin
Checksum
Carriage Return and Line Feed

Early Production Information

Page 141 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32 UBX Protocol
32.1 UBX Protocol Key Features
u-blox receivers support a u-blox proprietary protocol to communicate with a host computer. This
protocol has the following key features:• Compact - uses 8-bit Binary Data.
• Checksum Protected - uses a low-overhead checksum algorithm• Modular - uses a 2-stage message identifier (Class and Message ID)

32.2 UBX Frame Structure
The structure of a basic UBX Frame is shown in the following diagram.

• Every Frame starts with a 2-byte Preamble consisting of two synchronization characters: 0xB5
0x62.
• A 1-byteMessage Class field follows. A Class is a group of messages that are related to eachother.
• A 1-byteMessage ID field defines the message that is to follow.
• A 2-byte Length field follows. The length is defined as being that of the payload only. It does notinclude the Preamble, Message Class, Message ID, Length, or CRC fields. The number format of
the length field is a Little-Endian unsigned 16-bit integer.
• The Payload field contains a variable number of bytes.
• The two 1-byteCK_A and CK_B fields hold a 16-bit checksum whose calculation is defined below.
This concludes the Frame.

32.3 UBX Payload Definition Rules

UBX-13003221 - R17

Early Production Information

Page 142 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.3.1 Structure Packing
Values are placed in an order that structure packing is not a problem. This means that 2-bytevalues shall start on offsets which are a multiple of 2; 4-byte values shall start at a multiple of 4;
and so on.
32.3.2 Reserved Elements
Some messages contain reserved fields or bits to allow for future expansion. The contents ofthese elements should be ignored in output messages and must be set to zero in input messages.
Where a message is output and subsequently returned to the receiver as input message, reserved
elements can either be explicitly set to zero or left with whatever value they were output with.
32.3.3 Undefined Values
The description of some fields provide specific meanings for specific values. For example, the fieldgnssId appears in many UBX messages and uses 0 to indicate GPS, 1 for SBAS and so on (seeSatellite Numbering for details); however it is usually stored in a byte with far more possible values
than the handful currently defined. All such undefined values are reserved for future expansion
and therefore should not be used.
32.3.4 Message Naming
Referring to messages is done by adding the class name and a dash in front of the message name.
For example, the version information message is referred to as UBX-MON-VER. Referring tomessage fields or their values is done by adding a dot and the name, e.g. UBX-MON-VER.
swVersion.
32.3.5 Number Formats
All multi-byte values are ordered in Little Endian format, unless otherwise indicated.
All floating point values are transmitted in IEEE754 single or double precision.
Variable Type Definitions
Short

Type

Size

Comment

Min/Max

Resolution(Bytes)U1
RU1_3

Unsigned Char
Unsigned Char

1
1

I1
X1
U2
I2
X2
U4

Signed Char
Bitfield
Unsigned Short
Signed Short
Bitfield
Unsigned Long

1
1
2
2
2
4

I4

Signed Long

4

UBX-13003221 - R17

0..255
1
binary floating 0..(31*2^7) non- ~ 2^(Value >> 5)
point with 3 bit continuous
exponent, eeeb
bbbb, (Value &0x1F) << (Value>> 5)
2's complement -128 .. 127
1
n/a
n/a
0 .. 65535
12's complement -32768 .. 32767 1
n/a
n/a
0 ..
1
4'294'967'295
2's complement -2'147'483'648 .. 1
2'147'483'647

Early Production Information

Page 143 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Variable Type Definitions continued
Short

Type

Size

Comment Min/Max

Resolution(Bytes)X4
R4

Bitfield
4
IEEE 754 Single Precision 4R8IEEE 754 Double Precision 8

CH

ASCII / ISO 8859.1
Encodingn/a-1*2^+127 ..
2^+127-1*2^+1023 ..
2^+1023n/a~ Value * 2^-24~ Value * 2^-53

132.4 UBX Checksum
The checksum is calculated over the Message, starting and including the CLASS field, up until,
but excluding, the Checksum Field:

The checksum algorithm used is the 8-Bit Fletcher Algorithm, which is used in the TCP standard (RFC 1145). This algorithm works as follows:• Buffer[N] contains the data over which the checksum is to be calculated.
• The two CK_ values are 8-Bit unsigned integers, only! If implementing with larger-sized integer
values, make sure to mask both CK_A and CK_B with 0xFF after both operations in the loop.
CK_A = 0, CK_B = 0
For(I=0;I<N;I++){CK_A = CK_A + Buffer[I]CK_B = CK_B + CK_A}
• After the loop, the two U1 values contain the checksum, transmitted after the Message, whichconclude the Frame.

UBX-13003221 - R17

Early Production Information

Page 144 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.5 UBX Message Flow
There are certain features associated with the messages being sent back and forth:
32.5.1 Acknowledgement
When messages from the class CFG are sent to the receiver, the receiver will send an"acknowledge" (UBX-ACK-ACK) or a "not acknowledge" (UBX-ACK-NAK) message back to the sender,
depending on whether or not the message was processed correctly.
Some messages from other classes (e.g. LOG) also use the same acknowledgement mechanism.
32.5.2 Polling Mechanism
All messages that are output by the receiver in a periodic manner (i.e. messages in classes MON,NAV and RXM) and Get/Set type messages, such as the messages in the CFG class, can also bepolled.
The UBX protocol is designed so that messages can be polled by sending the message required to
the receiver but without a payload (or with just a single parameter that identifies the poll request).
The receiver then responds with the same message with the payload populated.

32.6 UBX Class IDs
A class is a grouping of messages which are related to each other. The following table lists all thecurrent message classes.
Name

Class

Description

NAV

0x01 Navigation Results Messages: Position, Speed, Time, Acceleration, Heading, DOP,
SVs used
RXM 0x02 Receiver Manager Messages: Satellite Status, RTC Status
INF
0x04 Information Messages: Printf-Style Messages, with IDs such as Error, Warning,
Notice
ACK 0x05 Ack/Nak Messages: Acknowledge or Reject messages to UBX-CFG input messages
CFG 0x06 Configuration Input Messages: Configure the receiver.
UPD 0x09 Firmware Update Messages: Memory/Flash erase/write, Reboot, Flash
identification, etc.
MON 0x0A Monitoring Messages: Communication Status, CPU Load, Stack Usage, Task
StatusAID
0x0B AssistNow Aiding Messages: Ephemeris, Almanac, other A-GPS data input
TIM 0x0D Timing Messages: Time Pulse Output, Time Mark Results
ESF 0x10 External Sensor Fusion Messages: External Sensor Measurements and Status
Information
MGA 0x13 Multiple GNSS Assistance Messages: Assistance data for various GNSS
LOG 0x21 Logging Messages: Log creation, deletion, info and retrieval
SEC 0x27 Security Feature Messages
HNR 0x28 High Rate Navigation Results Messages: High rate time, position, speed, heading
All remaining class IDs are reserved.

UBX-13003221 - R17

Early Production Information

Page 145 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.7 UBX Messages Overview
Page Mnemonic

Cls/ID

LengthUBX Class ACK

Type

Description

Ack/Nak Messages

152

ACK-ACK

0x05 0x01

2

OutputMessage Acknowledged

152

ACK-NAK

0x05 0x00

2

OutputMessage Not-Acknowledged

UBX Class AID

AssistNow Aiding Messages

153

AID-ALM

0x0B 0x30

0Poll Request

Poll GPS Aiding Almanac Data153

AID-ALM

0x0B 0x30

1

Poll Request

Poll GPS Aiding Almanac Data for a SV

154

AID-ALM

0x0B 0x30(8) or (40)

Input/Output

GPS Aiding Almanac Input/Output...

155

AID-AOP

0x0B 0x33

0Poll Request

Poll AssistNow Autonomous data, all...

155

AID-AOP

0x0B 0x33

1

Poll Request

Poll AssistNow Autonomous data, one...

156

AID-AOP

0x0B 0x33

68

Input/Output

AssistNow Autonomous data

157

AID-EPH

0x0B 0x31

0Poll Request

Poll GPS Aiding Ephemeris Data

157

AID-EPH

0x0B 0x31

1

Poll Request

Poll GPS Aiding Ephemeris Data for a SV

158

AID-EPH

0x0B 0x31(8) or (104)

Input/Output

GPS Aiding Ephemeris Input/Output...

159

AID-HUI

0x0B 0x02

0Poll Request

Poll GPS Health, UTC, ionosphere...

159

AID-HUI

0x0B 0x02

72

Input/Output

GPS Health, UTC and ionosphere...

161

AID-INI

0x0B 0x01

0Poll Request

Poll GPS Initial Aiding Data161

AID-INI

0x0B 0x01

48

Input/Output

Aiding position, time, frequency, clock...

UBX Class CFG

Configuration Input Messages

164

CFG-ANT

0x06 0x13

4

Get/SetAntenna Control Settings

165

CFG-BATCH

0x06 0x93

8

Get/SetGet/Set data batching configuration

166

CFG-CFG

0x06 0x09(12) or (13)CommandClear, Save and Load configurations

168

CFG-DAT

0x06 0x06

44

Set

Set User-defined Datum.

169

CFG-DAT

0x06 0x06

52

Get

The currently defined Datum

170

CFG-DGNSS

0x06 0x70

4

Get/SetDGNSS configuration

170

CFG-DOSC

0x06 0x61

4 + 32*numO... Get/Set

Disciplined oscillator configuration

172

CFG-ESRC

0x06 0x60

4 + 36*numS... Get/Set

External synchronization source...

174

CFG-GEOFENCE

0x06 0x69

8 + 12*numF... Get/Set

Geofencing configuration

175

CFG-GNSS

0x06 0x3E

4 + 8*numCo... Get/Set

GNSS system configuration

178

CFG-HNR

0x06 0x5C

4

Get/SetHigh Navigation Rate Settings

178

CFG-INF

0x06 0x02

1

Poll Request

Poll configuration for one protocol

179

CFG-INF

0x06 0x02

0 + 10*N

Get/SetInformation message configuration

180

CFG-ITFM

0x06 0x39

8

Get/SetJamming/Interference Monitor...

181

CFG-LOGFILTER

0x06 0x47

12

Get/SetData Logger Configuration

183

CFG-MSG0x06 0x01

2

Poll Request

Poll a message configuration

183

CFG-MSG0x06 0x01

8

Get/SetSet Message Rate(s)184

CFG-MSG0x06 0x01

3

Get/SetSet Message Rate

184

CFG-NAV50x06 0x24

36

Get/SetNavigation Engine Settings

UBX-13003221 - R17

Early Production Information

Page 146 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX Messages Overview continued
Page Mnemonic

Cls/ID

LengthType

Description

187

CFG-NAVX50x06 0x23

40

Get/SetNavigation Engine Expert Settings

189

CFG-NAVX50x06 0x23

40

Get/SetNavigation Engine Expert Settings

192

CFG-NAVX50x06 0x23

44

Get/SetNavigation Engine Expert Settings

194

CFG-NMEA

0x06 0x17

4

Get/SetNMEA protocol configuration...

196

CFG-NMEA

0x06 0x17

12

Get/SetNMEA protocol configuration V0...

198

CFG-NMEA

0x06 0x17

20

Get/SetExtended NMEA protocol configuration V1

201

CFG-ODO0x06 0x1E

20

Get/SetOdometer, Low-speed COG Engine...

202

CFG-PM2

0x06 0x3B

44

Get/SetExtended Power Management...

204

CFG-PM2

0x06 0x3B

48

Get/SetExtended Power Management...

206

CFG-PM2

0x06 0x3B

48

Get/SetExtended Power Management...

209

CFG-PMS

0x06 0x86

8

Get/SetPower Mode Setup

210

CFG-PRT

0x06 0x00

1

Poll Request

Polls the configuration for one I/O Port210

CFG-PRT

0x06 0x00

20

Get/SetPort Configuration for UART213

CFG-PRT

0x06 0x00

20

Get/SetPort Configuration for USB Port215

CFG-PRT

0x06 0x00

20

Get/SetPort Configuration for SPI Port218

CFG-PRT

0x06 0x00

20

Get/SetPort Configuration for DDC Port221

CFG-PWR

0x06 0x57

8Set

Put receiver in a defined power state.

221

CFG-RATE

0x06 0x08

6

Get/SetNavigation/Measurement Rate Settings

223

CFG-RINV

0x06 0x34

1 + 1*N

Get/SetContents of Remote Inventory223

CFG-RST

0x06 0x04

4CommandReset Receiver / Clear Backup Data...

225

CFG-RXM

0x06 0x11

2

Get/Set

RXM configuration

225

CFG-RXM

0x06 0x11

2

Get/Set

RXM configuration

226

CFG-SBAS

0x06 0x16

8

Get/Set

SBAS Configuration

228

CFG-SLAS

0x06 0x8D

4

Get/Set

SLAS Configuration

229

CFG-SMGR

0x06 0x62

20

Get/SetSynchronization manager configuration

232

CFG-TMODE2

0x06 0x3D

28

Get/SetTime Mode Settings 2233

CFG-TMODE3

0x06 0x71

40

Get/SetTime Mode Settings 3

235

CFG-TP50x06 0x31

0Poll Request

Poll Time Pulse Parameters for Time...

235

CFG-TP50x06 0x31

1

Poll Request

Poll Time Pulse Parameters

236

CFG-TP50x06 0x31

32

Get/SetTime Pulse Parameters

237

CFG-TP50x06 0x31

32

Get/SetTime Pulse Parameters

239

CFG-TXSLOT

0x06 0x53

16

Set

TX buffer time slots configuration

240

CFG-USB

0x06 0x1B

108

Get/SetUSB ConfigurationUBX Class ESF

External Sensor Fusion Messages

242

ESF-INS

0x10 0x15

36

243

ESF-MEAS

0x10 0x02(8 + 4*numM... Input/Output

External Sensor Fusion Measurements

245

ESF-RAW

0x10 0x03

4 + 8*N

Raw sensor measurements

246

ESF-STATUS

0x10 0x10

16 + 4*numS... Periodic/Polled

UBX-13003221 - R17

Periodic/Polled

Output

Early Production Information

Vehicle dynamics information

External Sensor Fusion (ESF) status...

Page 147 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX Messages Overview continued
Page Mnemonic

Cls/ID

LengthUBX Class HNR

TypeDescription

High Rate Navigation Results Messages

249

HNR-INS

0x28 0x02

36

Periodic/Polled

Vehicle dynamics information

250

HNR-PVT0x28 0x00

72

Periodic/Polled

High Rate Output of PVT Solution

UBX Class INF

Information Messages

253

INF-DEBUG

0x04 0x04

0 + 1*N

OutputASCII output with debug contents

253

INF-ERROR

0x04 0x00

0 + 1*N

OutputASCII output with error contents254

INF-NOTICE

0x04 0x02

0 + 1*N

OutputASCII output with informational contents254

INF-TEST

0x04 0x03

0 + 1*N

OutputASCII output with test contents

255

INF-WARNING

0x04 0x01

0 + 1*N

OutputASCII output with warning contents

UBX Class LOG

Logging Messages

256

LOG-BATCH

0x21 0x11

100

PolledBatched data

259

LOG-CREATE

0x21 0x07

8CommandCreate Log File260

LOG-ERASE

0x21 0x03

0CommandErase Logged Data260

LOG-FINDTIME

0x21 0x0E

12

Input

Find index of a log entry based on a...

261

LOG-FINDTIME

0x21 0x0E

8OutputResponse to FINDTIME request

262

LOG-INFO

0x21 0x08

0Poll Request

Poll for log information

262

LOG-INFO

0x21 0x08

48

OutputLog information

264

LOG-RETRIEVEBA... 0x21 0x10

4Command

Request batch data

265

LOG-RETRIEVEPO... 0x21 0x0f

32

OutputOdometer log entry265

LOG-RETRIEVEPOS 0x21 0x0b

40

OutputPosition fix log entry

266

LOG-RETRIEVEST... 0x21 0x0d

16 + 1*byteCo...Output

Byte string log entry

267

LOG-RETRIEVE

0x21 0x09

12

Command

Request log data

268

LOG-STRING

0x21 0x04

0 + 1*N

CommandStore arbitrary string in on-board flashUBX Class MGA

Multiple GNSS Assistance Messages

269

MGA-ACK-DATA00x13 0x60

8OutputMultiple GNSS Acknowledge message

270

MGA-ANO

0x13 0x20

76

Input

Multiple GNSS AssistNow Offline...

271

MGA-BDS-EPH

0x13 0x03

88

Input

BDS Ephemeris Assistance272

MGA-BDS-ALM

0x13 0x03

40

Input

BDS Almanac Assistance273

MGA-BDS-HEALTH 0x13 0x03

68

Input

BDS Health Assistance274

MGA-BDS-UTC

0x13 0x03

20

Input

BDS UTC Assistance274

MGA-BDS-IONO

0x13 0x03

16

Input

BDS Ionospheric Assistance

275

MGA-DBD

0x13 0x80

0Poll Request

Poll the Navigation Database

275

MGA-DBD

0x13 0x80

12 + 1*N

Input/Output

Navigation Database Dump Entry

276

MGA-FLASH-DATA 0x13 0x21

6 + 1*size

Input

Transfer MGA-ANO data block to flash

277

MGA-FLASH-STOP 0x13 0x21

2

Input

Finish flashing MGA-ANO data

277

MGA-FLASH-ACK

0x13 0x21

6OutputAcknowledge last FLASH-DATA or -STOP

278

MGA-GAL-EPH

0x13 0x02

76

Input

Galileo Ephemeris Assistance

280

MGA-GAL-ALM

0x13 0x02

32

Input

Galileo Almanac Assistance

UBX-13003221 - R17

Early Production Information

Page 148 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX Messages Overview continued
Page Mnemonic

Cls/ID

LengthType

Description

281

MGA-GAL-TIMEO...

0x13 0x02

12

Input

Galileo GPS time offset assistance

281

MGA-GAL-UTC

0x13 0x02

20

Input

Galileo UTC Assistance

282

MGA-GLO-EPH

0x13 0x06

48

Input

GLONASS Ephemeris Assistance

283

MGA-GLO-ALM

0x13 0x06

36

Input

GLONASS Almanac Assistance284

MGA-GLO-TIMEO... 0x13 0x06

20

Input

GLONASS Auxiliary Time Offset...

285

MGA-GPS-EPH

0x13 0x00

68

Input

GPS Ephemeris Assistance

287

MGA-GPS-ALM

0x13 0x00

36

Input

GPS Almanac Assistance

288

MGA-GPS-HEALTH 0x13 0x00

40

Input

GPS Health Assistance

288

MGA-GPS-UTC

0x13 0x00

20

Input

GPS UTC Assistance

289

MGA-GPS-IONO

0x13 0x00

16

Input

GPS Ionosphere Assistance290

MGA-INI-POS_XYZ

0x13 0x40

20

Input

Initial Position Assistance

291

MGA-INI-POS_LLH

0x13 0x40

20

Input

Initial Position Assistance

291

MGA-INI-TIME_UTC 0x13 0x40

24

Input

Initial Time Assistance293

MGA-INI-TIME_GN... 0x13 0x40

24

Input

Initial Time Assistance294

MGA-INI-CLKD

0x13 0x40

12

Input

Initial Clock Drift Assistance

295

MGA-INI-FREQ

0x13 0x40

12

Input

Initial Frequency Assistance

296

MGA-INI-EOP

0x13 0x40

72

Input

Earth Orientation Parameters Assistance296

MGA-QZSS-EPH

0x13 0x05

68

Input

QZSS Ephemeris Assistance

298

MGA-QZSS-ALM

0x13 0x05

36

Input

QZSS Almanac Assistance299

MGA-QZSS-HEAL... 0x13 0x05

12

Input

QZSS Health AssistanceUBX Class MON

Monitoring Messages

300

MON-BATCH

0x0A 0x32

12PolledData batching buffer status

301

MON-GNSS

0x0A 0x28

8PolledInformation message major GNSS...

303

MON-HW2

0x0A 0x0B

28

Periodic/Polled

Extended Hardware Status

304

MON-HW

0x0A 0x09

60

Periodic/Polled

Hardware Status

305

MON-IO

0x0A 0x02

0 + 20*N

Periodic/Polled

I/O Subsystem Status

306

MON-MSGPP

0x0A 0x06

120

Periodic/Polled

Message Parse and Process Status

306

MON-PATCH

0x0A 0x27

0Poll Request

Poll Request for installed patches

307

MON-PATCH

0x0A 0x27

4 + 16*nEntriesPolled

Output information about installed...

308

MON-RXBUF

0x0A 0x07

24

Periodic/Polled

Receiver Buffer Status

308

MON-RXR

0x0A 0x21

1

OutputReceiver Status Information

309

MON-SMGR

0x0A 0x2E

16

Periodic/Polled

Synchronization Manager Status

312

MON-TXBUF

0x0A 0x08

28

Periodic/Polled

Transmitter Buffer Status313

MON-VER

0x0A 0x04

0Poll Request

Poll Receiver/Software Version

313

MON-VER

0x0A 0x04

40 + 30*N

PolledReceiver/Software Version

UBX Class NAV

Navigation Results Messages

314

NAV-AOPSTATUS

0x01 0x60

16Periodic/Polled

AssistNow Autonomous Status

315

NAV-ATT

0x01 0x05

32

Periodic/Polled

Attitude Solution

UBX-13003221 - R17

Early Production Information

Page 149 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX Messages Overview continued
Page Mnemonic

Cls/ID

LengthType

Description

Periodic/Polled

Clock Solution

316

NAV-CLOCK

0x01 0x2220316

NAV-DGPS0x01 0x31

16 + 12*numChPeriodic/Polled

DGPS Data Used for NAV

317

NAV-DOP

0x01 0x04

18

Periodic/Polled

Dilution of precision318

NAV-EOE

0x01 0x61

4

Periodic

End Of Epoch

318

NAV-GEOFENCE

0x01 0x39

8 + 2*numFe... Periodic/Polled

Geofencing status319

NAV-HPPOSECEF

0x01 0x1328

Periodic/Polled

High Precision Position Solution in ECEF

320

NAV-HPPOSLLH

0x01 0x1436

Periodic/Polled

High Precision Geodetic Position Solution

321

NAV-ODO0x01 0x09

20

Periodic/Polled

Odometer Solution

322

NAV-ORB

0x01 0x34

8 + 6*numSv

Periodic/Polled

GNSS Orbit Database Info

325

NAV-POSECEF

0x01 0x01

20

Periodic/Polled

Position Solution in ECEF

325

NAV-POSLLH

0x01 0x02

28

Periodic/Polled

Geodetic Position Solution

326

NAV-PVT0x01 0x07

92

Periodic/Polled

Navigation Position Velocity Time...

329

NAV-RELPOSNED

0x01 0x3C

40

Periodic/Polled

Relative Positioning Information in...

331

NAV-RESETODO

0x01 0x10

0CommandReset odometer

331

NAV-SAT

0x01 0x35

8 + 12*numSvsPeriodic/Polled

Satellite Information

333

NAV-SBAS

0x01 0x32

12 + 12*cnt

Periodic/Polled

SBAS Status Data

334

NAV-SLAS

0x01 0x42

20 + 8*cnt

Periodic/Polled

QZSS L1S SLAS Status Data

336

NAV-SOL

0x01 0x06

52

Periodic/Polled

Navigation Solution Information

337

NAV-STATUS

0x01 0x03

16

Periodic/Polled

Receiver Navigation Status

340

NAV-SVINFO

0x01 0x30

8 + 12*numCh Periodic/Polled

Space Vehicle Information

342

NAV-SVIN

0x01 0x3B

40

Periodic/Polled

Survey-in data

343

NAV-TIMEBDS

0x01 0x24

20

Periodic/Polled

BDS Time Solution

344

NAV-TIMEGAL

0x01 0x25

20

Periodic/Polled

Galileo Time Solution

345

NAV-TIMEGLO

0x01 0x23

20

Periodic/Polled

GLO Time Solution

346

NAV-TIMEGPS

0x01 0x20

16

Periodic/Polled

GPS Time Solution

347

NAV-TIMELS

0x01 0x26

24

Periodic/Polled

Leap second event information

349

NAV-TIMEUTC

0x01 0x21

20

Periodic/Polled

UTC Time Solution350

NAV-VELECEF

0x01 0x1120

Periodic/Polled

Velocity Solution in ECEF

351

NAV-VELNED

0x01 0x1236

Periodic/Polled

Velocity Solution in NED

UBX Class RXM

Receiver Manager Messages

352

RXM-IMES

0x02 0x61

4 + 44*numTx Periodic/Polled

Indoor Messaging System Information

355

RXM-MEASX

0x02 0x14

44 + 24*num... Periodic/Polled

Satellite Measurements for RRLP

356

RXM-PMREQ

0x02 0x418Command

Requests a Power Management task

357

RXM-PMREQ

0x02 0x41

16Command

Requests a Power Management task

358

RXM-RAWX

0x02 0x15

16 + 32*num... Periodic/Polled

Multi-GNSS Raw Measurement Data

362

RXM-RAWX

0x02 0x15

16 + 32*num... Periodic/Polled

Multi-GNSS Raw Measurement Data365

RXM-RLM

0x02 0x59

16

OutputGalileo SAR Short-RLM report

366

RXM-RLM

0x02 0x59

28

OutputGalileo SAR Long-RLM report

UBX-13003221 - R17

Early Production Information

Page 150 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX Messages Overview continued
Page Mnemonic

Cls/ID

LengthType

Description

Output

RTCM input status

367

RXM-RTCM

0x02 0x32

8368

RXM-SFRBX

0x02 0x13

8 + 4*numW... Output

Broadcast Navigation Data Subframe

368

RXM-SFRBX

0x02 0x13

8 + 4*numW... Output

Broadcast Navigation Data Subframe

369

RXM-SVSI

0x02 0x20

8 + 6*numSVSV Status InfoUBX Class SEC
371

SEC-UNIQID

0x27 0x03

Periodic/Polled

Security Feature Messages
9

UBX Class TIM

OutputUnique Chip ID

Timing Messages

372

TIM-DOSC

0x0D 0x118OutputDisciplined oscillator control

372

TIM-FCHG

0x0D 0x16

32

Periodic/Polled

Oscillator frequency changed notification

373

TIM-HOC

0x0D 0x17

8

Input

Host oscillator control

374

TIM-SMEAS

0x0D 0x13

12 + 24*num... Input/Output

Source measurement

376

TIM-SVIN

0x0D 0x04

28

Periodic/Polled

Survey-in data

377

TIM-TM2

0x0D 0x03

28

Periodic/Polled

Time mark data

378

TIM-TOS0x0D 0x1256

Periodic

Time Pulse Time and Frequency Data380

TIM-TP

0x0D 0x01

16

Periodic/Polled

Time Pulse Timedata382

TIM-VCOCAL

0x0D 0x15

1Command

Stop calibration

382

TIM-VCOCAL

0x0D 0x15

12Command

VCO calibration extended command

384

TIM-VCOCAL

0x0D 0x15

12Periodic/Polled

Results of the calibration

384

TIM-VRFY

0x0D 0x06

20

Periodic/Polled

Sourced Time VerificationUBX Class UPD

Firmware Update Messages

386

UPD-SOS

0x09 0x14

0Poll Request

Poll Backup File Restore Status

386

UPD-SOS

0x09 0x14

4CommandCreate Backup File in Flash387

UPD-SOS

0x09 0x14

4CommandClear Backup in Flash387

UPD-SOS

0x09 0x148OutputBackup File Creation Acknowledge

388

UPD-SOS

0x09 0x148OutputSystem Restored from Backup

UBX-13003221 - R17

Early Production Information

Page 151 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.8 UBX-ACK (0x05)
Ack/Nak Messages: i.e. Acknowledge or Reject messages to UBX-CFG input messages.
Messages in the UBX-ACK class output the processing results to UBX-CFG and some othermessages.
32.8.1 UBX-ACK-ACK (0x05 0x01)
32.8.1.1 Message Acknowledged
MessageUBX-ACK-ACKDescription

Message Acknowledged

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

Output upon processing of an input message. ACK Message is sent as soon as
possible but at least within one second.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x05 0x01 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

clsID
msgID

-

Class ID of the Acknowledged Message
Message ID of the Acknowledged
Message

Format01

U1
U1

32.8.2 UBX-ACK-NAK (0x05 0x00)
32.8.2.1 Message Not-Acknowledged
MessageUBX-ACK-NAK

Description

Message Not-Acknowledged

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

Output upon processing of an input message. NAK Message is sent as soon as
possible but at least within one second.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x05 0x00 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Class ID of the Not-Acknowledged
Message
Message ID of the Not-Acknowledged
Message

Format

0

U1

-

clsID

-

1

U1

-

msgID

-

UBX-13003221 - R17

Early Production Information

Page 152 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9 UBX-AID (0x0B)
AssistNow Aiding Messages: i.e. Ephemeris, Almanac, other A-GPS data input.
Messages in the AID class are used to send GPS aiding data to the receiver.
32.9.1 UBX-AID-ALM (0x0B 0x30)
32.9.1.1 Poll GPS Aiding Almanac Data
MessageUBX-AID-ALM

Description

Poll GPS Aiding Almanac Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll GPS Aiding Data (Almanac) for all 32 SVs by sending this message to thereceiver without any payload. The receiver will return 32 messages of type AIDALM as defined below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x30 0

Checksumsee below CK_A CK_B

No payload

32.9.1.2 Poll GPS Aiding Almanac Data for a SV
MessageUBX-AID-ALM

Description

Poll GPS Aiding Almanac Data for a SV

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll GPS Aiding Data (Almanac) for an SV by sending this message to thereceiver. The receiver will return one message of type AID-ALM as defined below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x30 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

svid

-

SV ID for which the receiver shall return its
Almanac Data (Valid Range: 1 .. 32 or 51,
56, 63).

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 153 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.1.3 GPS Aiding Almanac Input/Output Message
MessageUBX-AID-ALM

Description

GPS Aiding Almanac Input/Output Message

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead• If the WEEK Value is 0, DWRD0 to DWRD7 are not sent as the Almanac is notavailable for the given SV. This may happen even if NAV-SVINFO and RXMSVSI are indicating almanac availability as the internal data may not represent
the content of an original broadcast almanac (or only parts thereof).
• DWORD0 to DWORD7 contain the 8 words following the Hand-Over Word (HOW ) from the GPS navigation message, either pages 1 to 24 of sub-frame 5or pages 2 to 10 of subframe 4. See IS-GPS-200 for a full description of thecontents of the Almanac pages.
• In DWORD0 to DWORD7, the parity bits have been removed, and the 24 bits ofdata are located in Bits 0 to 23. Bits 24 to 31 shall be ignored.
• Example: Parameter e (Eccentricity) from Almanac Subframe 4/5, Word 3, Bits
69-84 within the subframe can be found in DWRD0, Bits 15-0 whereas Bit 0 is
the LSB.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x30 (8) or (40)Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0

U4

-

svid

-

4

U4

-

week

-

SV ID for which thisAlmanac Data is (Valid Range: 1 .. 32 or 51,
56, 63).
Issue Date of Almanac (GPS week number)

-

dwrd

-

Almanac Words

Start of optional block

8

U4[8]

End of optional block

UBX-13003221 - R17

Early Production Information

Page 154 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.2 UBX-AID-AOP (0x0B 0x33)
32.9.2.1 Poll AssistNow Autonomous data, all satellites
MessageUBX-AID-AOP

Description

Poll AssistNow Autonomous data, all satellites

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll AssistNow Autonomous aiding data for all GPS satellites by sending thisempty message. The receiver will return an AID-AOP message (see definition
below) for each GPS satellite for which data is available.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x33 0

Checksumsee below CK_A CK_B

No payload

32.9.2.2 Poll AssistNow Autonomous data, one GPS satellite
MessageUBX-AID-AOP

Description

Poll AssistNow Autonomous data, one GPS satellite

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll the AssistNow Autonomous data for the specified GPS satellite. The
receiver will return a AID-AOP message (see definition below) if data is available
for the requested satellite.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x33 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

svid

-

GPS SV ID for which the data is requested(valid range: 1..32).

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 155 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.2.3 AssistNow Autonomous data
MessageUBX-AID-AOP

Description

AssistNow Autonomous data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
If enabled, this message is output at irregular intervals. It is output wheneverAssistNow Autonomous has produced new data for a satellite. Depending on theavailability of the optional data the receiver will output either version of themessage. If this message is polled using one of the two poll requests describedabove the receiver will send this message if AssistNow Autonomous data isavailable or the corresponding poll request message if no AssistNow
Autonomous data is available for each satellite (i.e. svid 1..32). At the user's
choice the optional data may be chopped from the payload of a previously polled
message when sending the message back to the receiver. Sending a valid AIDAOP message to the receiver will automatically enable the AssistNow
Autonomous feature on the receiver. See the section AssistNow Autonomous in
the receiver description for details on this feature.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x33 68

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

gnssIdsvId-reserved1
data-

GNSS identifier (see Satellite Numbering)
Satellite identifier (see Satellite
Numbering)Reservedassistance data

Format

0
1

U1
U1

2
4

U1[2] U1[64] -UBX-13003221 - R17

Early Production Information

Page 156 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.3 UBX-AID-EPH (0x0B 0x31)
32.9.3.1 Poll GPS Aiding Ephemeris Data
MessageUBX-AID-EPH

Description

Poll GPS Aiding Ephemeris Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll GPS Aiding Data (Ephemeris) for all 32 SVs by sending this message to thereceiver without any payload. The receiver will return 32 messages of type AIDEPH as defined below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x31 0

Checksumsee below CK_A CK_B

No payload

32.9.3.2 Poll GPS Aiding Ephemeris Data for a SV
MessageUBX-AID-EPH

Description

Poll GPS Aiding Ephemeris Data for a SV

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
Poll GPS Constellation Data (Ephemeris) for an SV by sending this message tothe receiver. The receiver will return one message of type AID-EPH as defined
below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x31 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

svid

-

SV ID for which the receiver shall return its
Ephemeris Data (Valid Range: 1 .. 32).

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 157 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.3.3 GPS Aiding Ephemeris Input/Output Message
MessageUBX-AID-EPH

Description

GPS Aiding Ephemeris Input/Output Message

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead• SF1D0 to SF3D7 is only sent if ephemeris is available for this SV. If not, thepayload may be reduced to 8 Bytes, or all bytes are set to zero, indicating that
this SV Number does not have valid ephemeris for the moment. This may
happen even if NAV-SVINFO and RXM-SVSI are indicating ephemeris
availability as the internal data may not represent the content of an original
broadcast ephemeris (or only parts thereof).
• SF1D0 to SF3D7 contain the 24 words following the Hand-Over Word ( HOW )from the GPS navigation message, subframes 1 to 3. The Truncated TOWCount is not valid and cannot be used. See IS-GPS-200 for a full description of
the contents of the Subframes.
• In SF1D0 to SF3D7, the parity bits have been removed, and the 24 bits of data
are located in Bits 0 to 23. Bits 24 to 31 shall be ignored.
• When polled, the data contained in this message does not represent the full
original ephemeris broadcast. Some fields that are irrelevant to u-blox
receivers may be missing. The week number in Subframe 1 has already been
modified to match the Time Of Ephemeris (TOE).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x31 (8) or (104)

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

SV ID for which this ephemeris data is(Valid Range: 1 .. 32).
Hand-Over Word of first Subframe. This isrequired if data is sent to the receiver.
0 indicates that no Ephemeris Data isfollowing.

Format

0

U4

-

svid

-

4

U4

-

how

-

-

sf1d
sf2d
sf3d

-

Start of optional block

8
40
72

U4[8]
U4[8]
U4[8]

Subframe 1 Words 3..10 (SF1D0..SF1D7)
Subframe 2 Words 3..10 (SF2D0..SF2D7)
Subframe 3 Words 3..10 (SF3D0..SF3D7)

End of optional block

UBX-13003221 - R17

Early Production Information

Page 158 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.4 UBX-AID-HUI (0x0B 0x02)
32.9.4.1 Poll GPS Health, UTC, ionosphere parameters
MessageUBX-AID-HUIDescription

Poll GPS Health, UTC, ionosphere parameters

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x02 0

Checksumsee below CK_A CK_B

No payload

32.9.4.2 GPS Health, UTC and ionosphere parameters
MessageUBX-AID-HUIDescription

GPS Health, UTC and ionosphere parameters

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
This message contains a health bit mask, UTC time and Klobuchar parameters.
For more information on these parameters, see the ICD-GPS-200
documentation.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x02 72

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Bitmask, every bit represenst a GPS SV (132). If the bit is set the SV is healthy.
UTC - parameter A0
UTC - parameter A1
UTC - reference time of week
UTC - reference week number
UTC - time difference due to leap seconds
before event
UTC - week number when next leap
second event occurs
UTC - day of week when next leap second
event occurs
UTC - time difference due to leap seconds
after event

Format0

X4-

health

-

4
12
20
24
26

R8
R8
I4
I2
I2

-

utcA0
utcA1
utcTOW
utcWNT
utcLS

-

28

I2

-

utcWNF

-

30

I2

-

utcDN

-

32

I2

-

utcLSF-UBX-13003221 - R17

Early Production Information

Page 159 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-AID-HUI continued
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format34

I2-

utcSpare

36
40

R4
R4

-

klobA0klobA1

44

R4-

klobA248

R4-

klobA3

52
56

R4
R4

-

klobB0klobB160

R4-klobB264

R4-klobB3

68

X4

-

flags

UTC - Spare to ensure structure is amultiple of 4 bytess
Klobuchar - alpha 0s/semi Klobuchar - alpha 1
circles/semi Klobuchar - alpha 2circle^2s/semi Klobuchar - alpha 3
circle^3s
Klobuchar - beta 0s/semi Klobuchar - beta 1
circles/semi Klobuchar - beta 2circle^2s/semi Klobuchar - beta 3circle^3
flags (see graphic below)

Bitfield flags
This graphic explains the bits of flags

Name

Description

healthValid
utcValid
klobValid

Healthmask field in this message is valid

UBX-13003221 - R17

UTC parameter fields in this message are valid
Klobuchar parameter fields in this message are valid

Early Production Information

Page 160 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.9.5 UBX-AID-INI (0x0B 0x01)
32.9.5.1 Poll GPS Initial Aiding Data
MessageUBX-AID-INI

Description

Poll GPS Initial Aiding Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x01 0

Checksumsee below CK_A CK_B

No payload

32.9.5.2 Aiding position, time, frequency, clock drift
MessageUBX-AID-INI

Description

Aiding position, time, frequency, clock drift

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

All UBX-AID messages are deprecated; use UBX-MGA messages instead
This message contains position, time and clock drift information. The position
can be input in either the ECEF X/Y/Z coordinate system or as lat/lon/height. The
time can either be input as inexact value via the standard communicationinterface, suffering from latency depending on the baud rate, or using hardware
time synchronization where an accurate time pulse is input on the externalinterrupts. It is also possible to supply hardware frequency aiding by connecting
a continuous signal to an external interrupt.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0B 0x01 48

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Descriptioncm_
WGS84 ECEF X coordinate or latitude,or_depending on flags below
deg*1e7cm_
WGS84 ECEF Y coordinate or longitude,or_depending on flags below
deg*1e7cm
WGS84 ECEF Z coordinate or altitude,
depending on flags below
cm
Position accuracy (stddev)

Format0

I4-

ecefXOrLat

4

I4

-

ecefYOrLon

8

I4

-

ecefZOrAlt

12

U4

-

posAccUBX-13003221 - R17

Early Production Information

Page 161 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-AID-INI continued
Byte Offset

Number

Scaling

Name

tmCfg

Unit

Description

Format

16

X2

-

18

U2

-

20

U4

-

24
28
32
36

I4
U4
U4
I4

-

40

U4

-

44

X4

-

-

Time mark configuration (see graphic
below)
wnoOrDate
week_ Actual week number oror_
yearSince2000/Month (YYMM),
yearM depending on flags below
onth
towOrTime
ms_
Actual time of week oror_
DayOfMonth/Hour/Minute/Second
dayHo (DDHHMMSS), depending on flags below
urMin
uteSe
c
towNs
ns
Fractional part of time of weektAccMsms
Milliseconds part of time accuracytAccNsns
Nanoseconds part of time accuracy
clkDOrFreq
ns/s_ Clock drift or frequency, depending onor_flags below
Hz*1e2
clkDAccOrFreq ns/s_ Accuracy of clock drift or frequency,Accor_ppb depending on flags below
flags
Bitmask with the following flags (seegraphic below)

Bitfield tmCfg
This graphic explains the bits of tmCfg

Name

Description

fEdge
tm1
f1

use falling edge (default rising)

UBX-13003221 - R17time mark on extint 1 (default extint 0)
frequency on extint 1 (default extint 0)

Early Production Information

Page 162 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

pos
time
clockDtp
clockF
lla
altInvprevTmutc

Position is valid

UBX-13003221 - R17

Time is valid
Clock drift data contains valid clock drift, must not be set together with clockF
Use time pulse
Clock drift data contains valid frequency, must not be set together with clockD
Position is given in lat/long/alt (default is ECEF)
Altitude is not valid, if lla was set
Use time mark received before AID-INI message (default uses mark received after message)
Time is given as UTC date/time (default is GPS wno/tow)

Early Production Information

Page 163 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10 UBX-CFG (0x06)
Configuration Input Messages: i.e. Configure the receiver..
Messages in the CFG class can be used to configure the receiver and poll current configuration
values. Any messages in the CFG class sent to the receiver are either acknowledged (withmessage UBX-ACK-ACK) if processed successfully or rejected (with message UBX-ACK-NAK) if
processing unsuccessfully.
32.10.1 UBX-CFG-ANT (0x06 0x13)
32.10.1.1 Antenna Control Settings
Message

UBX-CFG-ANT

Description

Antenna Control Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message allows the user to configure the antenna supervisor.
The antenna supervisor can be used to detect the status of an active antenna
and control it. It can be used to turn off the supply to the antenna in the event ofa short (for example) or to manage power consumption in Power Save Mode.
Refer to Antenna Supervisor Configuration and the relevant Integration manual(IM) for more information regarding the behavior of the antenna supervisor.
Refer to UBX-MON-HW for a description of the fields in the message used toobtain the status of the antenna.
Note that not all pins can be used for antenna supervisor operation, it isrecommended that you use the default pins, consult the Integration Manual if
you need to use other pins.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x13 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

flags
pins

-

Antenna Flag Mask (see graphic below)
Antenna Pin Configuration (see graphic
below)

Format02

X2
X2

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 164 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

svcs
scd
ocd
pdwnOnSCD
recoveryEnable Antenna Supply Voltage Control Signal
Enable Short Circuit Detection
Enable Open Circuit Detection
Power Down Antenna supply if Short Circuit is detected. (only in combination with Bit 1)
Enable automatic recovery from short state

Bitfield pins
This graphic explains the bits of pins

Name

Description

pinSwitch
pinSCD
pinOCD
reconfig

PIO-Pin used for switching antenna supply
PIO-Pin used for detecting a short in the antenna supply
PIO-Pin used for detecting open/not connected antenna
if set to one, and this command is sent to the receiver, the receiver will reconfigure the pins as
specified.

32.10.2 UBX-CFG-BATCH (0x06 0x93)
32.10.2.1 Get/Set data batching configuration
Message

UBX-CFG-BATCH

Description

Get/Set data batching configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 23.01

Type

Get/SetComment

Gets or sets the configuration for data batching.
See Data Batching for more information.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x93 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Flags (see graphic below)
Size of buffer in number of epochs to store
Buffer fill level that triggers PIO
notification, in number of epochs stored
PIO ID to use for buffer level notification
Reserved

Format

0
1
2
4

U1
X1
U2
U2

-

versionflags
bufSizenotifThrs

-

6
7

U1
U1

-

pioId
reserved1-

UBX-13003221 - R17

Early Production Information

Page 165 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

enableextraPvt

Enable data batching
Store extra PVT information
The fields iTOW, tAcc, numSV, hMSL, vAcc, velN, velE, velD, sAcc, headAcc and pDOP in UBX-LOGBATCH are only valid if this flag is set.
Store odometer data

extraOdo

The fields distance, totalDistance and distanceStd in UBX-LOG-BATCH are only valid if this flag isset.
Note: the odometer feature itself must also be enabled.

pioEnable
pioActiveLow

Enable PIO notification
PIO is active low

32.10.3 UBX-CFG-CFG (0x06 0x09)
32.10.3.1 Clear, Save and Load configurations
Message

UBX-CFG-CFG

Description

Clear, Save and Load configurations

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

See Receiver Configuration for a detailed description on how Receiver
Configuration should be used. The three masks are made up of individual bits,
each bit indicating the sub-section of all configurations on which thecorresponding action shall be carried out. The reserved bits in the masks must
be set to '0'. For detailed information refer to the Organization of theConfiguration Sections. Note that commands can be combined. The sequence ofexecution is Clear, Save, Load.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x09 (12) or (13)Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

clearMask-

Mask with configuration sub-sections toclear (i.e. load default configurations topermanent configurations in non-volatilememory) (see graphic below)

Format0

X4

UBX-13003221 - R17

Early Production Information

Page 166 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-CFG continued
Byte Offset

Number

Scaling

Name

Unit

Description

Mask with configuration sub-sections tosave (i.e. save current configurations to
non-volatile memory), see ID description ofclearMask
Mask with configuration sub-sections toload (i.e. load permanent configurations
from non-volatile memory to current
configurations), see ID description ofclearMask

Format4

X4-

saveMask

-

8

X4

-

loadMask--

deviceMask-

Start of optional block12

X1

Mask which selects the memory devices
for this command. (see graphic below)

End of optional block

Bitfield clearMask
This graphic explains the bits of clearMask

Name

Description

ioPortCommunications port settings. Modifying this sub-section results in an IO system reset. Because ofthis undefined data may be output for a short period of time after receiving the message.

msgConf
infMsgnavConf
rxmConf
senConf
rinvConf
antConflogConf
ftsConf

UBX-13003221 - R17

Message configuration
INF message configuration
Navigation configuration
Receiver Manager configuration
Sensor interface configuration (not supported in protocol versions less than 19)
Remote inventory configuration
Antenna configuration
Logging configuration
FTS configuration. Only applicable to the FTS product variant.

Early Production Information

Page 167 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield deviceMask
This graphic explains the bits of deviceMask

Name

Description

devBBRdevFlashdevEEPROM
devSpiFlash

Battery backed RAM
Flash
EEPROM
SPI Flash32.10.4 UBX-CFG-DAT (0x06 0x06)
32.10.4.1 Set User-defined Datum.
Message

UBX-CFG-DAT

Description

Set User-defined Datum.

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Set

Comment

For more information see the description of Geodetic Systems and Frames.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x06 44

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Semi-major Axis ( accepted range = 6,300,
000.0 to 6,500,000.0 meters ).
1.0 / Flattening ( accepted range is 0.0 to500.0 ).
X Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Y Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Z Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Rotation about the X Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Rotation about the Y Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Rotation about the Z Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Scale change ( accepted range is 0.0 to
50.0 parts per million ).

Format

0

R8

-

majA

m

8

R8

-

flat

-

16

R4

-

dX

m

20

R4

-

dY

m

24

R4

-

dZ

m

28

R4

-

rotX

s

32

R4

-

rotY

s

36

R4

-

rotZ

s

40

R4

-

scale

ppm

UBX-13003221 - R17

Early Production Information

Page 168 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.4.2 The currently defined Datum
Message

UBX-CFG-DAT

Description

The currently defined Datum

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get

Comment

Returns the parameters of the currently defined datum. If no user-defined
datum has been set, this will default to WGS84.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x06 52

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Datum Number: 0 = WGS84, 0xFFFF =user-defined
ASCII String: WGS84 or USER
Semi-major Axis ( accepted range = 6,300,
000.0 to 6,500,000.0 meters ).
1.0 / Flattening ( accepted range is 0.0 to500.0 ).
X Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Y Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Z Axis shift at the origin ( accepted range
is +/- 5000.0 meters ).
Rotation about the X Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Rotation about the Y Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Rotation about the Z Axis ( accepted
range is +/- 20.0 milli-arc seconds ).
Scale change ( accepted range is 0.0 to
50.0 parts per million ).

Format0

U2-

datumNum

-

2
8

CH[6]
R8

-

datumName
majA

m

16

R8

-

flat

-

24

R4

-

dX

m

28

R4

-

dY

m

32

R4

-

dZ

m

36

R4

-

rotX

s

40

R4

-

rotY

s

44

R4

-

rotZ

s

48

R4

-

scale

ppm

UBX-13003221 - R17

Early Production Information

Page 169 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.5 UBX-CFG-DGNSS (0x06 0x70)
32.10.5.1 DGNSS configuration
Message

UBX-CFG-DGNSS

Description

DGNSS configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20.01, 20.1, 20.2, 20.3, 22, 23 and 23.01(only with High Precision GNSS products)

Type

Get/SetComment

This message allows the user to configure the DGNSS configuration of thereceiver.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x70 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Specifies differential mode:
2: RTK float: No attempts are made to fix
ambiguities.
3: RTK fixed: Ambiguities are fixedwhenever possible.
Reserved

Format0

U1-

dgnssMode

-

1

U1[3]

-

reserved1-

32.10.6 UBX-CFG-DOSC (0x06 0x61)
32.10.6.1 Disciplined oscillator configuration
Message

UBX-CFG-DOSC

Description

Disciplined oscillator configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Get/SetComment

This message allows the characteristics of the internal or external oscillator to
be described to the receiver.
The gainVco and gainUncertainty parameters are normally set using thecalibration process initiated using UBX-TIM-VCOCAL.
The behavior of the system can be badly affected by setting the wrong values,
so customers are advised to only change these parameters with care.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x61 4 + 32*numOsc

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Number of oscillators to configure (affects
length of this message)
Reserved

Format

0
1

U1
U1

-

versionnumOsc

-

2

U1[2]

-

reserved1-

UBX-13003221 - R17

Early Production Information

Page 170 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-DOSC continued
Byte Offset

Number

Scaling

Name

Unit

Description

FormatStart of repeated block (numOsc times)

4 + 32*NU1-

5 + 32*N
6 + 32*N
8 + 32*N
12 + 32*N

U1
X2
U4
I4

2^-2
-

16 + 32*N

U4

2^-8

20 + 32*N

U4

2^-8

24 + 32*N

U2-

26 + 32*N
28 + 32*N

U1[2]
I4

2^-16

32 + 32*N

U1

2^-8

33 + 32*N

U1[3]

-

-

Id of oscillator.
0 - internal oscillator
1 - external oscillator
reserved2
Reservedflags
flags (see graphic below)
freqHzNominal frequency of source
phaseOffset
psIntended phase offset of the oscillator
relative to the leading edge of the time
pulse
withTemp
ppb
Oscillator stability limit over operating
temperature range (must be > 0)
withAge
ppb/ye Oscillator stability with age (must be > 0)
artimeToTemps
The minimum time that it could take for atemperature variation to move theoscillator frequency by 'withTemp' (mustbe > 0)reserved3
Reserved
gainVcoppb/ra Oscillator control gain/slope; change ofw LSB frequency per unit change in raw control
changegainUncertain Relative uncertainty (1 standard deviation)tyof oscillator control gain/slope
reserved4
Reserved
oscId

End of repeated block

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 171 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

isCalibrated
controlIf

1 if the oscillator gain is calibrated, 0 if not
Communication interface for oscillator control:
0: Custom DAC attached to receiver's I2C
1: Microchip MCP4726 (12 bit DAC) attached to receiver's I2C
2: TI DAC8571 (16 bit DAC) attached to receiver's I2C
13: 12 bit DAC attached to host
14: 14 bit DAC attached to host
15: 16 bit DAC attached to host
Note that for DACs attached to the host, the host must monitor UBX-TIM-DOSC messages and pass
the supplied raw values on to the DAC.

32.10.7 UBX-CFG-ESRC (0x06 0x60)
32.10.7.1 External synchronization source configuration
Message

UBX-CFG-ESRC

Description

External synchronization source configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Get/SetComment

External time or frequency source configuration. The stability of time andfrequency sources is described using different fields, see sourceType fielddocumentation.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x60 4 + 36*numSources

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Number of sources (affects length of thismessage)
Reserved

Format

0
1

U1
U1

-

versionnumSources

-

2

U1[2]

-

reserved1-

Start of repeated block (numSources times)

4 + 36*N

U1

UBX-13003221 - R17-

extInt-EXTINT index of this source (0 for
EXTINT0 and 1 for EXTINT1)

Early Production Information

Page 172 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-ESRC continued
Byte Offset

Number

Scaling

Name

Unit

sourceType

Description

Format5 + 36*NU1-

6 + 36*N
8 + 36*N
12 + 36*N
16 + 36*N

X2
U4
U1[4]
U4

2^-2
2^-8

20 + 36*N

U4

2^-8

24 + 36*N

U2-

26 + 36*N

U2-

28 + 36*N

I4-

32 + 36*N

U4-

36 + 36*N

U4

-

-

Source type:
0: none1: frequency source; use withTemp,
withAge, timeToTemp andmaxDevLifeTime to describe the stabilityof the source
2: time source; use offset,
offsetUncertainty and jitter fields todescribe the stability of the source
3: feedback from external oscillator;
stability data is taken from the external
oscillator's configuration
flags
Flags (see graphic below)
freqHzNominal frequency of source
reserved2
Reserved
withTemp
ppb
Oscillator stability limit over operating
temperature range (must be > 0)
Only used if sourceType is 1.
withAge
ppb/ye Oscillator stability with age (must be > 0)ar
Only used if sourceType is 1.
timeToTemps
The minimum time that it could take for atemperature variation to move theoscillator frequency by 'withTemp' (mustbe > 0)
Only used if sourceType is 1.
maxDevLifeTim ppb
Maximum frequency deviation duringelifetime (must be > 0)
Only used if sourceType is 1.
offsetns
Phase offset of signal
Only used if sourceType is 2.
offsetUncerta ns
Uncertainty of phase offset (one standard
inty
deviation)
Only used if sourceType is 2.
jitterns/sPhase jitter (must be > 0)
Only used if sourceType is 2.

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 173 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

polarity

Polarity of signal:
0: leading edge is rising edge
1: leading edge is falling edge
Time base of timing signal:

gnssUtc

0: GNSS - as specified in CFG-TP5 (or GPS if CFG-TP5 indicates UTC)
1: UTC
Only used if sourceType is 2.

32.10.8 UBX-CFG-GEOFENCE (0x06 0x69)
32.10.8.1 Geofencing configuration
Message

UBX-CFG-GEOFENCE

Description

Geofencing configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Get/SetComment

Gets or sets the geofencing configuration
See the Geofencing description for feature details.
If the receiver is sent a valid new configuration, it will respond with a UBX-ACKACK message and immediately change to the new configuration. Otherwise thereceiver will reject the request, by issuing a UBX-ACK-NAK and continuing
operation with the previous configuration.
Note that the acknowledge message does not indicate whether the PIO
configuration has been successfully applied (pin assigned), it only indicates the
successful configuration of the feature. The configured PIO must be previously
unoccupied for successful assignment.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x69 8 + 12*numFences

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionnumFences-Message version (=0x00 for this version)
Number of geofences contained in thismessage. Note that the receiver can only
store a limited number of geofences(currently 4).

Format0
1

U1
U1

UBX-13003221 - R17

Early Production Information

Page 174 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-GEOFENCE continued
Byte Offset

Number

Scaling

Name

Unit

Description

Format2

U1-

confLvl

-

3
4

U1[1]
U1

-

reserved1
pioEnabled

-

5

U1

-

pinPolarity

-

6
7

U1
U1[1]

-

pin
reserved2-

Required confidence level for stateevaluation. This value times the position's
standard deviation (sigma) defines theconfidence band.
0 = no confidence required
1 = 68%
2 = 95%
3 = 99.7%
4 = 99.99%
Reserved
1 = Enable PIO combined fence state
output, 0 = disable
PIO pin polarity. 0 = Low means inside, 1 =Low means outside. Unknown state isalways high.
PIO pin number
Reserved

deg
deg
m

Latitude of the geofence circle center
Longitude of the geofence circle center
Radius of the geofence circle

Start of repeated block (numFences times)

8 + 12*N
12 + 12*N
16 + 12*N

I4
I4
U4

1e-7
1e-7
1e-2

lat
lon
radiusEnd of repeated block32.10.9 UBX-CFG-GNSS (0x06 0x3E)
32.10.9.1 GNSS system configuration
Message

UBX-CFG-GNSS

Description

GNSS system configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Gets or sets the GNSS system channel sharing configuration.
If the receiver is sent a valid new configuration, it will respond with a UBX-ACKACK message and immediately change to the new configuration. Otherwise thereceiver will reject the request, by issuing a UBX-ACK-NAK and continuing
operation with the previous configuration.
Configuration requirements:• It is necessary for at least one major GNSS to be enabled, after applying the
new configuration to the current one.
• It is also required that at least 4 tracking channels are available to eachenabled major GNSS, i.e. maxTrkCh must have a minimum value of 4 for eachenabled major GNSS.
• The number of tracking channels in use must not exceed the number of

UBX-13003221 - R17

Early Production Information

Page 175 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

tracking channels available in hardware, and the sum of all reserved tracking
channels needs to be less than or equal to the number of tracking channels inuse.
Notes:• To avoid cross-correlation issues, it is recommended that GPS and QZSS are
always both enabled or both disabled.
• Polling this message returns the configuration of all supported GNSS, whether
enabled or not; it may also include GNSS unsupported by the particular
product, but in such cases the enable flag will always be unset.
• See section GNSS Configuration for a discussion of the use of this message.
• See section Satellite Numbering for a description of the GNSS IDs available.
• Configuration specific to the GNSS system can be done via other messages (e.
g. UBX-CFG-SBAS).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x3E 4 + 8*numConfigBlocks

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (=0 for this version)
Number of tracking channels available inhardware (read only)(Read only in protocol versions greaterthan 23) Number of tracking channels touse. Must be > 0, <= numTrkChHw. If
0xFF, then number of tracking channels to
use will be set to numTrkChHw.
Number of configuration blocks following

Format

0
1

U1
U1

-

msgVernumTrkChHw

-

2

U1

-

numTrkChUse

-

3

U1

-

numConfigBloc ks

Start of repeated block (numConfigBlocks times)

4 + 8*N

U1-

gnssId

-5 + 8*N

U1-

resTrkCh-

6 + 8*NU1-

maxTrkCh-

7 + 8*N
8 + 8*N

U1
X4-

reserved1
flags-

System identifier (see Satellite Numbering)(Read only in protocol versions greaterthan 23) Number of reserved (minimum)
tracking channels for this system.
(Read only in protocol versions greaterthan 23) Maximum number of tracking
channels used for this system. Must be >0, >= resTrkChn, <= numTrkChUse and <=maximum number of tracking channels
supported for this system.
Reserved
bitfield of flags. At least one signal must
be configured in every enabled system.
(see graphic below)

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 176 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

enablesigCfgMask

Enable this system
Signal configuration mask
When gnssId is 0 (GPS)* 0x01 = GPS L1C/A* 0x10 = GPS L2C
When gnssId is 1 (SBAS)* 0x01 = SBAS L1C/A
When gnssId is 2 (Galileo)* 0x01 = Galileo E1 (not supported inprotocol versions less than 18)* 0x20 = Galileo E5b
When gnssId is 3 (BeiDou)* 0x01 = BeiDou B1I* 0x10 = BeiDou B2I
When gnssId is 4 (IMES)* 0x01 = IMES L1
When gnssId is 5 (QZSS)* 0x01 = QZSS L1C/A* 0x04 = QZSS L1S* 0x10 = QZSS L2C
When gnssId is 6 (GLONASS)* 0x01 = GLONASS L1* 0x10 = GLONASS L2
When gnssId is 7 (IRNSS)* 0x01 = IRNSS L5A

UBX-13003221 - R17

Early Production Information

Page 177 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.10 UBX-CFG-HNR (0x06 0x5C)
32.10.10.1 High Navigation Rate Settings
Message

UBX-CFG-HNR

Description

High Navigation Rate Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15.01, 16 and 17(only with ADR products)• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Get/SetComment

The u-blox receivers support high rates of navigation update up to 30 Hz. The
navigation solution output UBX-NAV-HNR will not be aligned to the top of asecond.
• The update rate has a direct influence on the power consumption. The morefixes that are required, the more CPU power and communication resources are
required.
• For most applications a 1 Hz update rate would be sufficient.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x5C 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

highNavRate
reserved1

Hz-

Rate of navigation solution output
Reserved

Format

0
1

U1
U1[3]

32.10.11 UBX-CFG-INF (0x06 0x02)
32.10.11.1 Poll configuration for one protocol
Message

UBX-CFG-INF

Description

Poll configuration for one protocol

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x02 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

protocolID-

Protocol Identifier, identifying the output
protocol for this Poll Request. The
following are valid Protocol Identifiers:
0: UBX Protocol
1: NMEA Protocol
2-255: Reserved

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 178 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.11.2 Information message configuration
Message

UBX-CFG-INF

Description

Information message configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

The value of infMsgMask[x] below are that each bit represents one of the INF
class messages (Bit 0 for ERROR, Bit 1 for WARNING and so on.). For a complete
list, see the Message Class INF. Several configurations can be concatenated to
one input message. In this case the payload length can be a multiple of thenormal length. Output messages from the module contain only one
configuration unit. Note that I/O Ports 1 and 2 correspond to serial ports 1 and 2.
I/O port 0 is DDC. I/O port 3 is USB. I/O port 4 is SPI. I/O port 5 is reserved for
future use.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x02 0 + 10*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Protocol Identifier, identifying for which
protocol the configuration is set/get. The
following are valid Protocol Identifiers:
0: UBX Protocol
1: NMEA Protocol
2-255: Reserved
Reserved
A bit mask, saying which information
messages are enabled on each I/O port(see graphic below)

FormatStart of repeated block (N times)

N*10

U1

-

protocolID-

1 + 10*N
4 + 10*N

U1[3]
X1[6]

-

reserved1
infMsgMask-

End of repeated block

Bitfield infMsgMask
This graphic explains the bits of infMsgMask

UBX-13003221 - R17

Early Production Information

Page 179 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

ERROR
WARNINGNOTICETEST
DEBUG

enable ERROR
enable WARNING
enable NOTICE
enable TEST
enable DEBUG

32.10.12 UBX-CFG-ITFM (0x06 0x39)
32.10.12.1 Jamming/Interference Monitor configuration
Message

UBX-CFG-ITFM

Description

Jamming/Interference Monitor configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Configuration of Jamming/Interference monitor.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x39 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

interference config word. (see graphic
below)
extra settings for jamming/interferencemonitor (see graphic below)

Format0

X4-

config

-

4

X4

-

config2-

Bitfield config
This graphic explains the bits of config

UBX-13003221 - R17

Early Production Information

Page 180 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

bbThreshold
cwThresholdalgorithmBits
enableBroadband jamming detection threshold (unit = dB)
CW jamming detection threshold (unit = dB)
reserved algorithm settings - should be set to 0x16B156 in hex for correct settings
enable interference detection

Bitfield config2
This graphic explains the bits of config2

Name

Description

generalBits
antSetting
enable2

general settings - should be set to 0x31E in hex for correct setting
antennaSetting, 0=unknown, 1=passive, 2=active
Set to 1 to scan auxiliary bands (u-blox 8 / u-blox M8 only, otherwise ignored)

32.10.13 UBX-CFG-LOGFILTER (0x06 0x47)
32.10.13.1 Data Logger Configuration
Message

UBX-CFG-LOGFILTER

Description

Data Logger Configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message can be used to configure the data logger, i.e. to enable/disable thelog recording and to get/set the position entry filter settings.
Position entries can be filtered based on time difference, position difference or
current speed thresholds. Position and speed filtering also have a minimum timeinterval. A position is logged if any of the thresholds are exceeded. If a thresholdis set to zero it is ignored. The maximum rate of position logging is 1Hz.
The filter settings will be configured to the provided values only if the'applyAllFilterSettings' flag is set. This allows the recording to beenabled/disabled independently of configuring the filter settings.
It is supported to configure the data logger in the absence of a logging file. By
doing so, once the logging file is created, the data logger configuration will takeeffect immediately and logging recording and filtering will activate according to
the configuration.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x47 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

FormatUBX-13003221 - R17

Early Production Information

Page 181 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-LOGFILTER continued
Byte Offset

Number

Scaling

Name

Unit

Descriptions

The version of this message. Set to 1
Flags (see graphic below)
Minimum time interval between logged
positions (0 = not set). This is only appliedin combination with the speed and/or
position thresholds. If both minInterval
and timeThreshold are set, minIntervalmust be less than or equal to
timeThreshold.
If the time difference is greater than thethreshold then the position is logged (0 =not set).
If the current speed is greater than thethreshold then the position is logged (0 =not set). minInterval also applies
If the 3D position difference is greaterthan the threshold then the position islogged (0 = not set). minInterval also
applies

Format

0
1
2

U1
X1
U2

-

versionflags
minInterval

4

U2

-

timeThreshold s

6

U2

-

speedThreshol m/s
d

8

U4

-

positionThres m
hold

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 182 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

recordEnabled
psmOncePerWak
upEnabled
applyAllFilterSettings

1 = enable recording, 0 = disable recording
1 = enable recording only one single position per PSM on/off mode wake-up period, 0 = disable once
per wake-up
1 = apply all filter settings, 0 = only apply recordEnabled

32.10.14 UBX-CFG-MSG (0x06 0x01)
32.10.14.1 Poll a message configuration
Message

UBX-CFG-MSG

Description

Poll a message configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x01 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

msgClass
msgID-

Message Class
Message Identifier

Format0
1

U1
U1

32.10.14.2 Set Message Rate(s)Message

UBX-CFG-MSG

Description

Set Message Rate(s)FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Set/Get message rate configuration (s) to/from the receiver.
See also section How to change between protocols.
• Send rate is relative to the event a message is registered on. For example, if
the rate of a navigation message is set to 2, the message is sent every second
navigation solution. For configuring NMEA messages, the section NMEA
Messages Overview describes Class and Identifier numbers used.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x01 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

msgClass
msgID
rate

-

Message Class
Message Identifier
Send rate on I/O Port (6 Ports)

Format

0
1
2

U1
U1
U1[6]

UBX-13003221 - R17

Early Production Information

Page 183 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.14.3 Set Message Rate
Message

UBX-CFG-MSG

Description

Set Message Rate

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Set message rate configuration for the current port.
See also section How to change between protocols.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x01 3

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

msgClass
msgID
rate

-

Message Class
Message Identifier
Send rate on current Port

Format

0
1
2

U1
U1
U1

32.10.15 UBX-CFG-NAV5 (0x06 0x24)
32.10.15.1 Navigation Engine Settings
Message

UBX-CFG-NAV5

Description

Navigation Engine Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

See the Navigation Configuration Settings Description for a detailed descriptionof how these settings affect receiver operation.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x24 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

mask

-

Parameters Bitmask. Only the masked
parameters will be applied. (see graphic
below)

Format0

X2

UBX-13003221 - R17

Early Production Information

Page 184 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NAV5 continued
Byte Offset

Number

Scaling

Name

Unit

Description

Dynamic platform model:
0: portable
2: stationary
3: pedestrian
4: automotive
5: sea6: airborne with <1g acceleration
7: airborne with <2g acceleration
8: airborne with <4g acceleration
9: wrist worn watch (not supported inprotocol versions less than 18)
10: bike (supported inprotocol versions 19.
2)
Position Fixing Mode:
1: 2D only
2: 3D only
3: auto 2D/3D
Fixed altitude (mean sea level) for 2D fix
mode.
Fixed altitude variance for 2D mode.
Minimum Elevation for a GNSS satellite to
be used in NAV
Reserved
Position DOP Mask to use
Time DOP Mask to use
Position Accuracy Mask
Time Accuracy Mask
Static hold threshold

Format2

U1-

dynModel

-

3

U1

-

fixMode

-

4

I4

0.01

fixedAlt

m

8
12

U4
I1

0.0001 fixedAltVar
minElev

m^2
deg

13
14
16
18
20
22

U1
U2
U2
U2
U2
U1

0.1
0.1
-

s
m
m
cm/s

23
24

U1
U1

-

drLimit
pDop
tDop
pAcc
tAcc
staticHoldThreshdgnssTimeout
cnoThreshNumS
Vs

25

U1

-

cnoThresh

dBHz

26
28

U1[2]
U2

-

reserved1
staticHoldMax m
Dist

UBX-13003221 - R17s-

DGNSS timeout
Number of satellites required to have
C/N0 above cnoThresh for a fix to be
attempted
C/N0 threshold for deciding whether toattempt a fix
Reserved
Static hold distance threshold (before
quitting static hold)

Early Production Information

Page 185 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NAV5 continued
Byte Offset

Number

Scaling

Name

Unit

Description

UTC standard to be used:
0: Automatic; receiver selects based on
GNSS configuration (see GNSS timebases).
3: UTC as operated by the U.S. Naval
Observatory (USNO); derived from GPStime
6: UTC as operated by the former Soviet
Union; derived from GLONASS time
7: UTC as operated by the National Time
Service Center, China; derived from
BeiDou time(not supported in protocol versions lessthan 16).
Reserved

Format30

U1-

utcStandard

-

31

U1[5]

-

reserved2-

Bitfield mask
This graphic explains the bits of mask

Name

Description

dyn
minEl
posFixMode
drLim
posMask
timeMask
staticHoldMaskdgpsMask
cnoThresholdutc

Apply dynamic model settings
Apply minimum elevation settings
Apply fix mode settings
Reserved
Apply position mask settings
Apply time mask settings
Apply static hold settings
Apply DGPS settings.
Apply CNO threshold settings (cnoThresh, cnoThreshNumSVs).
Apply UTC settings.
(not supported in protocol versions less than 16).

UBX-13003221 - R17

Early Production Information

Page 186 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.16 UBX-CFG-NAVX5 (0x06 0x23)
32.10.16.1 Navigation Engine Expert Settings
Message

UBX-CFG-NAVX5

Description

Navigation Engine Expert Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16 and 17

Type

Get/SetComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x23 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
First parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Second parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Reserved
Minimum number of satellites fornavigation
Maximum number of satellites fornavigation
Minimum satellite signal level fornavigation
Reserved
1 = initial fix must be 3D
Reserved
1 = issue acknowledgements forassistance message input
GPS week rollover number; GPS weeknumbers will be set correctly from thisweek up to 1024 weeks after this week.
Setting this to 0 reverts to firmware
default.
Reserved
1 = use Precise Point Positioning (onlyavailable with the PPP product variant)
AssistNow Autonomous configuration(see graphic below)
Reserved

Format

0
2

U2
X2

-

version
mask1

-

4

X4

-

mask2

-

8
10

U1[2]
U1

-

reserved1
minSVs

#SVs

11

U1

-

maxSVs

#SVs

12

U1

-

minCNO

dBHz

13
14
15
17

U1
U1
U1[2]
U1

-

reserved2
iniFix3D
reserved3
ackAiding

-

18

U2

-

wknRollover

-

20
26

U1[6]
U1

-

reserved4
usePPP

-

27

U1

-

aopCfg

-

28

U1[2]

-

reserved5-

UBX-13003221 - R17

Early Production Information

Page 187 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NAVX5 continued
Byte Offset

Number

Scaling

Name

Unit

Description

Maximum acceptable (modeled)
AssistNow Autonomous orbit error (valid
range = 5..1000, or 0 = reset to firmware
default)
Reserved
Reserved
Only supported on certain products
Enable/disable ADR sensor fusion (if 0:
sensor fusion is disabled - if 1: sensor
fusion is enabled).

Format30

U2-

aopOrbMaxErr

m

32
36
39

U1[4]
U1[3]
U1

-

reserved6
reserved7
useAdr

-Bitfield mask1
This graphic explains the bits of mask1

Name

Description

minMaxminCnoinitial3dfix
wknRollackAidppp
aop

1 = apply min/max SVs settings
1 = apply minimum C/N0 setting
1 = apply initial 3D fix settings
1 = apply GPS weeknumber rollover settings
1 = apply assistance acknowledgement settings
1 = apply usePPP flag
1 = apply aopCfg (useAOP flag) and aopOrbMaxErr settings (AssistNow Autonomous)

Bitfield mask2
This graphic explains the bits of mask2

UBX-13003221 - R17

Early Production Information

Page 188 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

adr

Apply ADR sensor fusion on/off setting (useAdr flag)

Bitfield aopCfg
This graphic explains the bits of aopCfg

Name

Description

useAOP

1 = enableAssistNow Autonomous

32.10.16.2 Navigation Engine Expert Settings
Message

UBX-CFG-NAVX5

Description

Navigation Engine Expert Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Get/SetComment(Polling will send back a version 3 message in protocol versions 19.2).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x23 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (2 for this version)
First parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Second parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Reserved
Minimum number of satellites fornavigation
Maximum number of satellites fornavigation
Minimum satellite signal level fornavigation
Reserved
1 = initial fix must be 3D
Reserved

Format

0
2

U2
X2

-

version
mask1

-

4

X4

-

mask2

-

8
10

U1[2]
U1

-

reserved1
minSVs

#SVs

11

U1

-

maxSVs

#SVs

12

U1

-

minCNO

dBHz

13
14
15

U1
U1
U1[2]

-

reserved2
iniFix3D
reserved3-

UBX-13003221 - R17

Early Production Information

Page 189 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NAVX5 continued
Byte Offset

Number

Scaling

Name

Unit

Description

1 = issue acknowledgements forassistance message input
GPS week rollover number; GPS weeknumbers will be set correctly from thisweek up to 1024 weeks after this week.
Setting this to 0 reverts to firmware
default.
Only supported on certain products
Permanently attenuated signal
compensation (0 = disabled, 255 =automatic, 1..63 = maximum expected
C/N0 value)
Reserved
Reserved
Reserved
1 = use Precise Point Positioning (onlyavailable with the PPP product variant)
AssistNow Autonomous configuration(see graphic below)
Reserved
Maximum acceptable (modeled)
AssistNow Autonomous orbit error (valid
range = 5..1000, or 0 = reset to firmware
default)
Reserved
Reserved
Only supported on certain products
Enable/disable ADR/UDR sensor fusion (if0: sensor fusion is disabled - if 1: sensor
fusion is enabled).

Format17

U1-

ackAiding

-

18

U2

-

wknRollover

-

20

U1

-

sigAttenCompM dBHz
ode

21
22
24
26

U1
U1[2]
U1[2]
U1

-

reserved4
reserved5
reserved6
usePPP

-

27

U1

-

aopCfg

-

28
30

U1[2]
U2

-

reserved7
aopOrbMaxErr

m

32
36
39

U1[4]
U1[3]
U1

-

reserved8
reserved9
useAdr

-Bitfield mask1
This graphic explains the bits of mask1

UBX-13003221 - R17

Early Production Information

Page 190 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

minMaxminCnoinitial3dfix
wknRollackAidppp
aop

1 = apply min/max SVs settings
1 = apply minimum C/N0 setting
1 = apply initial 3D fix settings
1 = apply GPS weeknumber rollover settings
1 = apply assistance acknowledgement settings
1 = apply usePPP flag
1 = apply aopCfg (useAOP flag) and aopOrbMaxErr settings (AssistNow Autonomous)

Bitfield mask2
This graphic explains the bits of mask2

Name

Description

adr
sigAttenComp

Apply ADR/UDR sensor fusion on/off setting (useAdr flag)
Only supported on certain products
Apply signal attenuation compensation feature settings

Bitfield aopCfg
This graphic explains the bits of aopCfg

Name

Description

useAOP

1 = enableAssistNow Autonomous

UBX-13003221 - R17

Early Production Information

Page 191 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.16.3 Navigation Engine Expert Settings
Message

UBX-CFG-NAVX5

Description

Navigation Engine Expert Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 19.1 and 19.2

Type

Get/SetComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x23 44

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (3 for this version)
First parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Second parameters bitmask. Only the
flagged parameters will be applied,unused bits must be set to 0. (see graphic
below)
Reserved
Minimum number of satellites fornavigation
Maximum number of satellites fornavigation
Minimum satellite signal level fornavigation
Reserved
1 = initial fix must be 3D
Reserved
1 = issue acknowledgements forassistance message input
GPS week rollover number; GPS weeknumbers will be set correctly from thisweek up to 1024 weeks after this week.
Setting this to 0 reverts to firmware
default.
Only supported on certain products
Permanently attenuated signal
compensation (0 = disabled, 255 =automatic, 1..63 = maximum expected
C/N0 value)
Reserved
Reserved
Reserved

Format

0
2

U2
X2

-

version
mask1

-

4

X4

-

mask2

-

8
10

U1[2]
U1

-

reserved1
minSVs

#SVs

11

U1

-

maxSVs

#SVs

12

U1

-

minCNO

dBHz

13
14
15
17

U1
U1
U1[2]
U1

-

reserved2
iniFix3D
reserved3
ackAiding

-

18

U2

-

wknRollover

-

20

U1

-

sigAttenCompM dBHz
ode

21
22
24

U1
U1[2]
U1[2]

-

reserved4
reserved5
reserved6

UBX-13003221 - R17-

Early Production Information

Page 192 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NAVX5 continued
Byte Offset

Number

Scaling

Name

Unit

Description

1 = use Precise Point Positioning (onlyavailable with the PPP product variant)
AssistNow Autonomous configuration(see graphic below)
Reserved
Maximum acceptable (modeled)
AssistNow Autonomous orbit error (valid
range = 5..1000, or 0 = reset to firmware
default)
Reserved
Reserved
Only supported on certain products
Enable/disable ADR/UDR sensor fusion (if0: sensor fusion is disabled - if 1: sensor
fusion is enabled).
Reserved
Reserved

Format26

U1-

usePPP

-

27

U1

-

aopCfg

-

28
30

U1[2]
U2

-

reserved7
aopOrbMaxErr

m

32
36
39

U1[4]
U1[3]
U1

-

reserved8
reserved9
useAdr

-

40
42

U1[2]
U1[2]

-

reserved10
reserved11-

Bitfield mask1
This graphic explains the bits of mask1

Name

Description

minMaxminCnoinitial3dfix
wknRollackAidppp
aop

1 = apply min/max SVs settings

UBX-13003221 - R17

1 = apply minimum C/N0 setting
1 = apply initial 3D fix settings
1 = apply GPS weeknumber rollover settings
1 = apply assistance acknowledgement settings
1 = apply usePPP flag
1 = apply aopCfg (useAOP flag) and aopOrbMaxErr settings (AssistNow Autonomous)

Early Production Information

Page 193 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield mask2
This graphic explains the bits of mask2

Name

Description

adr
sigAttenComp

Apply ADR/UDR sensor fusion on/off setting (useAdr flag)
Only supported on certain products
Apply signal attenuation compensation feature settings

Bitfield aopCfg
This graphic explains the bits of aopCfg

Name

Description

useAOP

1 = enableAssistNow Autonomous

32.10.17 UBX-CFG-NMEA (0x06 0x17)
32.10.17.1 NMEA protocol configuration (deprecated)
Message

UBX-CFG-NMEA

Description

NMEA protocol configuration (deprecated)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message version is provided for backwards compatibility only. Use thelast version listed below instead (its fields are backwards compatible with thisversion, it just has extra fields defined).
Set/Get the NMEA protocol configuration. See section NMEA Protocol
Configuration for a detailed description of the configuration effects on NMEA
output.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x17 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

filter-filter flags (see graphic below)

Format0

X1

UBX-13003221 - R17

Early Production Information

Page 194 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NMEA continued
Byte Offset

Number

Scaling

Name

Unit

Description

0x23: NMEA version 2.3
0x21: NMEA version 2.1
Maximum Number of SVs to report per
TalkerId.
0: unlimited
8: 8 SVs
12: 12 SVs
16: 16 SVs
flags (see graphic below)

Format1

U1-

nmeaVersion

-

2

U1

-

numSV

-

3

X1

-

flags

-

Bitfield filter
This graphic explains the bits of filter

Name

Description

posFilt
mskPosFilt
timeFilt
dateFilt
gpsOnlyFilter
trackFilt

Enable position output for failed or invalid fixes
Enable position output for invalid fixes
Enable time output for invalid times
Enable date output for invalid dates
Restrict output to GPS satellites only
Enable COG output even if COG is frozen

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 195 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

compatenable compatibility mode.
This might be needed for certain applications when customer's NMEA parser expects a fixed numberof digits in position coordinates
enable considering mode.

consider32.10.17.2 NMEA protocol configuration V0 (deprecated)
Message

UBX-CFG-NMEA

Description

NMEA protocol configuration V0 (deprecated)

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message version is provided for backwards compatibility only. Use thelast version listed below instead (its fields are backwards compatible with thisversion, it just has extra fields defined).
Set/Get the NMEA protocol configuration. See section NMEA Protocol
Configuration for a detailed description of the configuration effects on NMEA
output.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x17 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

filter flags (see graphic below)
0x23: NMEA version 2.3
0x21: NMEA version 2.1
Maximum Number of SVs to report per
TalkerId.
0: unlimited
8: 8 SVs
12: 12 SVs
16: 16 SVs
flags (see graphic below)
Filters out satellites based on their GNSS.
If a bitfield is enabled, the corresponding
satellites will be not output. (see graphic
below)
Configures the display of satellites that do
not have an NMEA-defined value.
Note: this does not apply to satellites withan unknown ID.
0: Strict - Satellites are not output
1: Extended - Use proprietary numbering(see Satellite Numbering)Format

0
1

X1
U1

-

filter
nmeaVersion

-

2

U1

-

numSV

-

3
4

X1
X4

-

flags
gnssToFilter

-

8

U1

-

svNumbering-

UBX-13003221 - R17

Early Production Information

Page 196 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NMEA continued
Byte Offset

Number

Scaling

Name

Unit

Description

By default the main Talker ID (i.e. theTalker ID used for all messages other thanGSV) is determined by the GNSS
assignment of the receiver's channels (seeUBX-CFG-GNSS).
This field enables the main Talker ID to be
overridden.
0: Main Talker ID is not overridden
1: Set main Talker ID to 'GP'
2: Set main Talker ID to 'GL'
3: Set main Talker ID to 'GN'
4: Set main Talker ID to 'GA'
5: Set main Talker ID to 'GB'
By default the Talker ID for GSV messages
is GNSS specific (as defined by NMEA).
This field enables the GSV Talker ID to be
overridden.
0: Use GNSS specific Talker ID (as definedby NMEA)
1: Use the main Talker ID
Message version (set to 0 for this version)

Format9

U1-

mainTalkerId

-

10

U1

-

gsvTalkerId

-

11

U1

-

version-Bitfield filter
This graphic explains the bits of filter

Name

Description

posFilt
mskPosFilt
timeFilt
dateFilt
gpsOnlyFilter
trackFilt

Enable position output for failed or invalid fixes

UBX-13003221 - R17

Enable position output for invalid fixes
Enable time output for invalid times
Enable date output for invalid dates
Restrict output to GPS satellites only
Enable COG output even if COG is frozen

Early Production Information

Page 197 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

compatenable compatibility mode.
This might be needed for certain applications when customer's NMEA parser expects a fixed numberof digits in position coordinates
enable considering mode.

considerBitfield gnssToFilter
This graphic explains the bits of gnssToFilter

Name

Description

gps
sbas
qzss
glonass
beidouDisable reporting of GPS satellites
Disable reporting of SBAS satellites
Disable reporting of QZSS satellites
Disable reporting of GLONASS satellites
Disable reporting of BeiDou satellites

32.10.17.3 Extended NMEA protocol configuration V1
Message

UBX-CFG-NMEA

Description

Extended NMEA protocol configuration V1

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Set/Get the NMEA protocol configuration. See section NMEA Protocol
Configuration for a detailed description of the configuration effects on NMEA
output.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x17 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

filter-filter flags (see graphic below)

Format0

X1

UBX-13003221 - R17

Early Production Information

Page 198 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NMEA continued
Byte Offset

Number

Scaling

Name

Unit

Description

0x41: NMEA version 4.10
0x40: NMEA version 4.0
0x23: NMEA version 2.3
0x21: NMEA version 2.1
Maximum Number of SVs to report per
TalkerId.
0: unlimited
8: 8 SVs
12: 12 SVs
16: 16 SVs
flags (see graphic below)
Filters out satellites based on their GNSS.
If a bitfield is enabled, the corresponding
satellites will be not output. (see graphic
below)
Configures the display of satellites that do
not have an NMEA-defined value.
Note: this does not apply to satellites withan unknown ID.
0: Strict - Satellites are not output
1: Extended - Use proprietary numbering(see Satellite Numbering)
By default the main Talker ID (i.e. theTalker ID used for all messages other thanGSV) is determined by the GNSS
assignment of the receiver's channels (seeUBX-CFG-GNSS).
This field enables the main Talker ID to be
overridden.
0: Main Talker ID is not overridden
1: Set main Talker ID to 'GP'
2: Set main Talker ID to 'GL'
3: Set main Talker ID to 'GN'
4: Set main Talker ID to 'GA'
5: Set main Talker ID to 'GB'
By default the Talker ID for GSV messages
is GNSS specific (as defined by NMEA).
This field enables the GSV Talker ID to be
overridden.
0: Use GNSS specific Talker ID (as definedby NMEA)
1: Use the main Talker ID
Message version (set to 1 for this version)

Format1

U1-

nmeaVersion

-

2

U1

-

numSV

-

3
4

X1
X4

-

flags
gnssToFilter

-

8

U1

-

svNumbering

-

9

U1

-

mainTalkerId

-

10

U1

-

gsvTalkerId

-

11

U1

-

version-UBX-13003221 - R17

Early Production Information

Page 199 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-NMEA continued
Byte Offset

Number

Scaling

Name

Unit

Description

Sets the two characters that should be
used for the BeiDou Talker ID
If these are set to zero, the default BeiDou
TalkerId will be used
Reserved

Format

12

CH[2]

-

bdsTalkerId

-

14

U1[6]

-

reserved1-

Bitfield filter
This graphic explains the bits of filter

Name

Description

posFilt
mskPosFilt
timeFilt
dateFilt
gpsOnlyFilter
trackFilt

Enable position output for failed or invalid fixes
Enable position output for invalid fixes
Enable time output for invalid times
Enable date output for invalid dates
Restrict output to GPS satellites only
Enable COG output even if COG is frozen

Bitfield flags
This graphic explains the bits of flags

Name

Description

compatenable compatibility mode.
This might be needed for certain applications when customer's NMEA parser expects a fixed numberof digits in position coordinates

considerlimit82
highPrecenable considering mode.
enable strict limit to 82 characters maximum.
enable high precision mode.
This flag cannot be set in conjunction with either Compatibility Mode or Limit82 Mode.
(not supported in protocol versions less than 20.01)

UBX-13003221 - R17

Early Production Information

Page 200 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield gnssToFilter
This graphic explains the bits of gnssToFilter

Name

Description

gps
sbas
qzss
glonass
beidouDisable reporting of GPS satellites
Disable reporting of SBAS satellites
Disable reporting of QZSS satellites
Disable reporting of GLONASS satellites
Disable reporting of BeiDou satellites

32.10.18 UBX-CFG-ODO (0x06 0x1E)
32.10.18.1 Odometer, Low-speed COG Engine Settings
Message

UBX-CFG-ODO

Description

Odometer, Low-speed COG Engine Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This feature is not supported for the FTS product variant.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x1E 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Reserved
Odometer/Low-speed COG filter flags (seegraphic below)
Odometer filter settings (see graphic
below)
Reserved
Speed below which course-over-ground(COG) is computed with the low-speed
COG filter
Maximum acceptable position accuracy
for computing COG with the low-speed
COG filter
Reserved
Velocity low-pass filter level, range 0..255
COG low-pass filter level (at speed < 8m/s), range 0..255

Format

0
1
4

U1
U1[3]
U1

-

versionreserved1
flags

-

5

X1

-

odoCfg

-

6
12

U1[6]
U1

1e-1

reserved2
cogMaxSpeed

m/s

13

U1

-

cogMaxPosAcc

m

14
16
17

U1[2]
U1
U1

-

reserved3
velLpGain
cogLpGain-

UBX-13003221 - R17

Early Production Information

Page 201 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-ODO continued
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved4-

Reserved

Format18

U1[2]Bitfield flags
This graphic explains the bits of flags

Name

Description

useODO
useCOG
outLPVel
outLPCog

Odometer enabled flag
Low-speed COG filter enabled flag
Output low-pass filtered velocity flag
Output low-pass filtered heading (COG) flag

Bitfield odoCfg
This graphic explains the bits of odoCfg

Name

Description

profileProfile type (0=running, 1=cycling, 2=swimming, 3=car, 4=custom)

32.10.19 UBX-CFG-PM2 (0x06 0x3B)
32.10.19.1 Extended Power Management configuration
Message

UBX-CFG-PM2

Description

Extended Power Management configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This feature is not supported for either the ADR or FTS products.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x3B 44

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

FormatUBX-13003221 - R17

Early Production Information

Page 202 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PM2 continued
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0
1
2

U1
U1
U1

-

versionreserved1
maxStartupSta s
teDur

3
4

U1
X4

-

reserved2
flags

-

8

U4

-

updatePeriod

ms

12

U4

-

searchPeriod

ms

16
20
22
24

U4
U2
U2
U1[20] -gridOffset
onTimeminAcqTime
reserved3

ms
s
s
-

Message version (0x01 for this version)
Reserved
Maximum time to spend in Acquisition
state. If 0: bound disabled (seemaxStartupStateDur). (not supported inprotocol versions less than 17)
Reserved
PSM configuration flags (see graphic
below)
Position update period. If set to 0, thereceiver will never retry a fix and it will wait
for external events
Acquisition retry period if previously failed.
If set to 0, the receiver will never retry astartup
Grid offset relative to GPS start of week
Time to stay in Tracking state
minimal search time
Reserved

Bitfield flags
This graphic explains the bits of flags

Name

Description

extintSel

EXTINT Pin Select0 EXTINT0
1 EXTINT1

extintWake

EXTINT Pin Control
0 disabled
1 enabled, keep receiver awake as long as selected EXTINT pin is 'high'extintBackup

EXTINT Pin Control
0 disabled
1 enabled, force receiver into BACKUP mode when selected EXTINT pin is 'low'

UBX-13003221 - R17

Early Production Information

Page 203 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags Description continued
Name

Description

limitPeakCurr

Limit Peak Current
00 disabled
01 enabled, peak current is limited
10 reserved
11 reserved

waitTimeFix

Wait for Timefix (see waitTimeFix)
0 wait for normal fix ok before starting on time
1 wait for time fix ok before starting on time
Update Real Time Clock (see updateRTC)

updateRTC

0 Do not wake up to update RTC. RTC is updated during normal on-time.
1 Update RTC. The receiver adds extra wake-up cycles to update the RTC.
Update Ephemeris (see updateEPH)

updateEPH

0 Do not wake up to update Ephemeris data
1 Update Ephemeris. The receiver adds extra wake-up cycles to update the Ephemeris data

doNotEnterOff

Behavior of receiver in case of no fix (see doNotEnterOff)
0 receiver enters (Inactive) Awaiting Next Search state
1 receiver does not enter(Inactive) Awaiting Next Search state but keeps trying to acquire a fix
insteadMode of operation (see mode)mode

00 ON/OFF operation (PSMOO)
01 Cyclic tracking operation (PSMCT)
10 reserved
11 reserved

32.10.19.2 Extended Power Management configuration
Message

UBX-CFG-PM2

Description

Extended Power Management configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3
and 22Type

Get/SetComment

This feature is not supported for either the ADR or FTS products.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x3B 48

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

version-Message version (0x02 for this version)
Note: the message version number is thesame as for protocol version 23.01; please
select correct message version based on
the protocol version supported by yourfirmware.

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 204 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PM2 continued
Byte Offset

Number

Scaling

Name

Unit

Description

Format

1
2

U1
U1

-

reserved1
maxStartupSta s
teDur

3
4

U1
X4

-

reserved2
flags

-

8

U4

-

updatePeriod

ms

12

U4

-

searchPeriod

ms

16
20
22
24
44

U4
U2
U2
U1[20] U4-

gridOffset
onTimeminAcqTime
reserved3
extintInactiv
ityMs

ms
s
s
ms

Reserved
Maximum time to spend in Acquisition
state. If 0: bound disabled (seemaxStartupStateDur). (not supported inprotocol versions less than 17)
Reserved
PSM configuration flags (see graphic
below)
Position update period. If set to 0, thereceiver will never retry a fix and it will wait
for external events
Acquisition retry period if previously failed.
If set to 0, the receiver will never retry astartup
Grid offset relative to GPS start of week
Time to stay in Tracking state
minimal search time
Reserved
inactivity time out on EXTINT pint if
enabled

Bitfield flags
This graphic explains the bits of flags

Name

Description

extintSel

EXTINT Pin Select0 EXTINT0
1 EXTINT1

extintWake

EXTINT Pin Control
0 disabled
1 enabled, keep receiver awake as long as selected EXTINT pin is 'high'extintBackup

EXTINT Pin Control
0 disabled
1 enabled, force receiver into BACKUP mode when selected EXTINT pin is 'low'

extintInactive

EXTINT Pin Control
0 disabled
1 enabled, Force backup in case EXTINT Pin is inactive for time longer than extintIncactivityMs

UBX-13003221 - R17

Early Production Information

Page 205 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags Description continued
Name

Description

limitPeakCurr

Limit Peak Current
00 disabled
01 enabled, peak current is limited
10 reserved
11 reserved

waitTimeFix

Wait for Timefix (see waitTimeFix)
0 wait for normal fix ok before starting on time
1 wait for time fix ok before starting on time
Update Real Time Clock (see updateRTC)

updateRTC

0 Do not wake up to update RTC. RTC is updated during normal on-time.
1 Update RTC. The receiver adds extra wake-up cycles to update the RTC.
Update Ephemeris (see updateEPH)

updateEPH

0 Do not wake up to update Ephemeris data
1 Update Ephemeris. The receiver adds extra wake-up cycles to update the Ephemeris data

doNotEnterOff

Behavior of receiver in case of no fix (see doNotEnterOff)
0 receiver enters (Inactive) Awaiting Next Search state
1 receiver does not enter(Inactive) Awaiting Next Search state but keeps trying to acquire a fix
insteadMode of operation (see mode)mode

00 ON/OFF operation (PSMOO)
01 Cyclic tracking operation (PSMCT)
10 reserved
11 reserved

32.10.19.3 Extended Power Management configuration
Message

UBX-CFG-PM2

Description

Extended Power Management configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 23.01

Type

Get/SetComment

This feature is not supported for either the ADR or FTS products.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x3B 48

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x02 for this version)
Note: the message version number is thesame as for protocol versions 18 up to 22;
please select correct message version
based on the protocol version supported
by your firmware.
Reserved

Format0

U1-

version

-

1

U1

-

reserved1-

UBX-13003221 - R17

Early Production Information

Page 206 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PM2 continued
Byte Offset

Number

Scaling

Name

Unit

Description

Format2

U1-

maxStartupSta s
teDur

3
4

U1
X4

-

reserved2
flags

-

8

U4

-

updatePeriod

ms

12

U4

-

searchPeriod

ms

16

U4

-

gridOffset

ms

20

U2

-

onTime

s

22
24
44

U2
U1[20] U4-

minAcqTimes
reserved3
extintInactiv ms
ityMs

Maximum time to spend in Acquisition
state. If 0: bound disabled (seemaxStartupStateDur). (not supported inprotocol versions 23 to 23.01)
Reserved
PSM configuration flags (see graphic
below)
Position update period. If set to 0, thereceiver will never retry a fix and it will wait
for external events
Acquisition retry period if previously failed.
If set to 0, the receiver will never retry astartup (not supported in protocol
versions 23 to 23.01)
Grid offset relative to GPS start of week
(not supported in protocol versions 23 to
23.01)
Time to stay in Tracking state (notsupported in protocol versions 23 to 23.01)
minimal search time
Reserved
inactivity time out on EXTINT pint if
enabled

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 207 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

optTarget

Optimization Target
000 performance (default)
001 power save
010 reserved
011 reserved
100 reserved
101 reserved
110 reserved
111 reserved

extintSel

EXTINT Pin Select0 EXTINT0
1 EXTINT1

extintWake

EXTINT Pin Control
0 disabled
1 enabled, keep receiver awake as long as selected EXTINT pin is 'high'extintBackup

EXTINT Pin Control
0 disabled
1 enabled, force receiver into BACKUP mode when selected EXTINT pin is 'low'

extintInactive

EXTINT Pin Control
0 disabled
1 enabled, Force backup in case EXTINT Pin is inactive for time longer than extintIncactivityMs

limitPeakCurr

Limit Peak Current
00 disabled
01 enabled, peak current is limited
10 reserved
11 reserved

waitTimeFix

Wait for Timefix (see waitTimeFix)
0 wait for normal fix ok before starting on time
1 wait for time fix ok before starting on time(not supported in protocol versions 23 to 23.01).

updateRTC

Update Real Time Clock (see updateRTC)
0 Do not wake up to update RTC. RTC is updated during normal on-time.
1 Update RTC. The receiver adds extra wake-up cycles to update the RTC.
(not supported in protocol versions 23 to 23.01).

updateEPH

Update Ephemeris (see updateEPH)
0 Do not wake up to update Ephemeris data
1 Update Ephemeris. The receiver adds extra wake-up cycles to update the Ephemeris data

doNotEnterOff

Behavior of receiver in case of no fix (see doNotEnterOff)
0 receiver enters (Inactive) Awaiting Next Search state
1 receiver does not enter(Inactive) Awaiting Next Search state but keeps trying to acquire a fix
instead(not supported in protocol versions 23 to 23.01).

UBX-13003221 - R17

Early Production Information

Page 208 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags Description continued
Name

Description

mode

Mode of operation (see mode)
00 ON/OFF operation (PSMOO) (not supported in protocol versions 23 to 23.01)
01 Cyclic tracking operation (PSMCT)
10 reserved
11 reserved

32.10.20 UBX-CFG-PMS (0x06 0x86)
32.10.20.1 Power Mode Setup
Message

UBX-CFG-PMS

Description

Power Mode Setup

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 22, 23 and 23.01

Type

Get/SetComment

Using UBX-CFG-PMS to set Super-E mode 1, 2, 4Hz navigation rates sets 180 s
minAcqTime instead the default 300 s in protocol version 23.01.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x86 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0
1

U1
U1

-

versionpowerSetupVal ue

2

U2

-

period

s

4

U2

-

onTime

s

6

U1[2]

-

reserved1-

UBX-13003221 - R17

Message version (0x00 for this version)
Power setup value
0x00 -> Full power
0x01 -> Balanced
0x02 -> Interval
0x03 -> Aggressive with 1Hz
0x04 -> Aggressive with 2Hz
0x05 -> Aggressive with 4Hz
0xFF -> Invalid (only when polling)
Position update period and search period.
Recommended minimum period is 10s,
although the receiver accepts any value
bigger than 5s.
Only valid when powerSetupValueset toInterval, otherwise must be set to '0'.
Duration of the ON phase, must be smaller
than the period.
Only valid when powerSetupValue set toInterval, otherwise must be set to '0'.
Reserved

Early Production Information

Page 209 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.21 UBX-CFG-PRT (0x06 0x00)
32.10.21.1 Polls the configuration for one I/O Port
Message

UBX-CFG-PRT

Description

Polls the configuration for one I/O Port

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Sending this message with a port ID as payload results in having the receiver
return the configuration for the specified port.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x00 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

PortID-Port Identifier Number (see the otherversions of CFG-PRT for valid values)

Format0U132.10.21.2 Port Configuration for UART
Message

UBX-CFG-PRT

Description

Port Configuration for UART

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Several configurations can be concatenated to one input message. In this casethe payload length can be a multiple of the normal length (see the other versionsof CFG-PRT). Output messages from the module contain only one configuration
unit.
Note that this message can affect baud rate and other transmission
parameters. Because there may be messages queued for transmission there
may be uncertainty about which protocol applies to such messages. In addition amessage currently in transmission may be corrupted by a protocol change. Hostdata reception parameters may have to be changed to be able to receive future
messages, including the acknowledge message resulting from the CFG-PRT
message.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x00 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Port Identifier Number (see Integration
Manual for valid UART port IDs)
Reserved

Format0

U1-

portID

-

1

U1

-

reserved1-

UBX-13003221 - R17

Early Production Information

Page 210 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PRT continued
Byte Offset

Number

Scaling

Name

Unit

Description

TX ready PIN configuration (see graphic
below)A bit mask describing the UART mode(see graphic below)
Baud rate in bits/second
A mask describing which input protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port. (seegraphic below)
A mask describing which output protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port. (seegraphic below)
Flags bit mask (see graphic below)
Reserved

Format2

X2-

txReady

-

4

X4

-

mode

-

8
12

U4
X2

-

baudRate
inProtoMask

Bits/s
-

14

X2

-

outProtoMask

-

16
18

X2
U1[2]

-

flags
reserved2-

Bitfield txReady
This graphic explains the bits of txReady

Name

DescriptionenpolEnable TX ready feature for this port
Polarity0 High-active
1 Low-active

pin
thres

PIO to be used (must not be in use already by another function)
Threshold
The given threshold is multiplied by 8 bytes.
The TX ready PIN goes active after >= thres*8 bytes are pending for the port and going inactive after
the last pending bytes have been written to hardware (0-4 bytes before end of stream).
0x000 no threshold
0x001 8byte
0x002 16byte...
0x1FE 4080byte
0x1FF 4088byte

UBX-13003221 - R17

Early Production Information

Page 211 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield modeThis graphic explains the bits of mode

Name

Description

charLenCharacter Length
00 5bit (not supported)
01 6bit (not supported)
10 7bit (supported only with parity)
11 8bitparity000 Even Parity
001 Odd Parity
10X No Parity
X1X Reserved

nStopBits

Number of Stop Bits
00 1 Stop Bit
01 1.5 Stop Bit
10 2 Stop Bit
11 0.5 Stop Bit

Bitfield inProtoMask
This graphic explains the bits of inProtoMask

Name

Description

inUbx
inNmeainRtcminRtcm3

UBX protocol
NMEA protocol
RTCM2 protocol
RTCM3 protocol (not supported in protocol versions less than 20)

Bitfield outProtoMask
This graphic explains the bits of outProtoMask

UBX-13003221 - R17

Early Production Information

Page 212 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

outUbxoutNmea
outRtcm3

UBX protocol
NMEA protocol
RTCM3 protocol (not supported in protocol versions less than 20)

Bitfield flags
This graphic explains the bits of flags

Name

Description

extendedTxTim
eout

Extended TX timeout: if set, the port will timeout if allocated TX memory >=4 kB and no activity for 1.
5s. If not set the port will timeout if no activity for 1.5s regardless on the amount of allocated TX
memory.

32.10.21.3 Port Configuration for USB Port
Message

UBX-CFG-PRT

Description

Port Configuration for USB Port

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Several configurations can be concatenated to one input message. In this casethe payload length can be a multiple of the normal length (see the other versionsof CFG-PRT). Output messages from the module contain only one configuration
unit.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x00 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Port Identifier Number (= 3 for USB port)
Reserved
TX ready PIN configuration (see graphic
below)
Reserved

Format

0
1
2

U1
U1
X2

-

portID
reserved1
txReady

-

4

U1[8]

-

reserved2-

UBX-13003221 - R17

Early Production Information

Page 213 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PRT continued
Byte Offset

Number

Scaling

Name

Unit

Description

A mask describing which input protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port. (seegraphic below)
A mask describing which output protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port. (seegraphic below)
Reserved
Reserved

Format12

X2-

inProtoMask

-

14

X2

-

outProtoMask

-

16
18

U1[2]
U1[2]

-

reserved3
reserved4-

Bitfield txReady
This graphic explains the bits of txReady

Name

DescriptionenpolEnable TX ready feature for this port
Polarity0 High-active
1 Low-active

pin
thres

PIO to be used (must not be in use already by another function)
Threshold
The given threshold is multiplied by 8 bytes.
The TX ready PIN goes active after >= thres*8 bytes are pending for the port and going inactive after
the last pending bytes have been written to hardware (0-4 bytes before end of stream).
0x000 no threshold
0x001 8byte
0x002 16byte...
0x1FE 4080byte
0x1FF 4088byte

UBX-13003221 - R17

Early Production Information

Page 214 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield inProtoMask
This graphic explains the bits of inProtoMask

Name

Description

inUbx
inNmeainRtcminRtcm3

UBX protocol
NMEA protocol
RTCM2 protocol
RTCM3 protocol (not supported in protocol versions less than 20)

Bitfield outProtoMask
This graphic explains the bits of outProtoMask

Name

Description

outUbxoutNmea
outRtcm3

UBX protocol
NMEA protocol
RTCM3 protocol (not supported in protocol versions less than 20)

32.10.21.4 Port Configuration for SPI Port
Message

UBX-CFG-PRT

Description

Port Configuration for SPI Port

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Several configurations can be concatenated to one input message. In this casethe payload length can be a multiple of the normal length (see the other versionsof CFG-PRT). Output messages from the module contain only one configuration
unit.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x00 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

portID
reserved1-

Port Identifier Number (= 4 for SPI port)
Reserved

Format0
1

U1
U1

UBX-13003221 - R17

Early Production Information

Page 215 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PRT continued
Byte Offset

Number

Scaling

Name

Unit

Description

TX ready PIN configuration (see graphic
below)SPI Mode Flags (see graphic below)
Reserved
A mask describing which input protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port.
(The bitfield inRtcm3 is not supported inprotocol versions less than 20) (seegraphic below)
A mask describing which output protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port.
(The bitfield outRtcm3 is not supported inprotocol versions less than 20) (seegraphic below)
Flags bit mask (see graphic below)
Reserved

Format2

X2-

txReady

-

4
8
12

X4
U1[4]
X2

-

mode
reserved2
inProtoMask

-

14

X2

-

outProtoMask

-

16
18

X2
U1[2]

-

flags
reserved3-

Bitfield txReady
This graphic explains the bits of txReady

Name

DescriptionenpolEnable TX ready feature for this port
Polarity0 High-active
1 Low-activepin

UBX-13003221 - R17

PIO to be used (must not be in use already by another function)

Early Production Information

Page 216 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield txReady Description continued
Name

Description

thres

Threshold
The given threshold is multiplied by 8 bytes.
The TX ready PIN goes active after >= thres*8 bytes are pending for the port and going inactive after
the last pending bytes have been written to hardware (0-4 bytes before end of stream).
0x000 no threshold
0x001 8byte
0x002 16byte...
0x1FE 4080byte
0x1FF 4088byte

Bitfield modeThis graphic explains the bits of mode

Name

Description

spiMode00 SPI Mode 0: CPOL = 0, CPHA = 0
01 SPI Mode 1: CPOL = 0, CPHA = 1
10 SPI Mode 2: CPOL = 1, CPHA = 0
11 SPI Mode 3: CPOL = 1, CPHA = 1

ffCnt

Number of bytes containing 0xFF to receive before switching off reception. Range: 0(mechanismoff)-63

Bitfield inProtoMask
This graphic explains the bits of inProtoMask

Bitfield outProtoMask
This graphic explains the bits of outProtoMask

UBX-13003221 - R17

Early Production Information

Page 217 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

extendedTxTim
eout

Extended TX timeout: if set, the port will timeout if allocated TX memory >=4 kB and no activity for 1.
5s.

32.10.21.5 Port Configuration for DDC Port
Message

UBX-CFG-PRT

Description

Port Configuration for DDC Port

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

Several configurations can be concatenated to one input message. In this casethe payload length can be a multiple of the normal length (see the other versionsof CFG-PRT). Output messages from the module contain only one configuration
unit.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x00 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Port Identifier Number (= 0 for DDC port)
Reserved
TX ready PIN configuration (see graphic
below)
DDC Mode Flags (see graphic below)
Reserved
A mask describing which input protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port.
(The bitfield inRtcm3 is not supported inprotocol versions less than 20) (seegraphic below)

Format

0
1
2

U1
U1
X2

-

portID
reserved1
txReady

-

4
8
12

X4
U1[4]
X2

-

mode
reserved2
inProtoMask-

UBX-13003221 - R17

Early Production Information

Page 218 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-PRT continued
Byte Offset

Number

Scaling

Name

Unit

Description

A mask describing which output protocols
are active.
Each bit of this mask is used for a
protocol. Through that, multiple protocols
can be defined on a single port.
(The bitfield outRtcm3 is not supported inprotocol versions less than 20) (seegraphic below)
Flags bit mask (see graphic below)
Reserved

Format14

X2-

outProtoMask

-

16
18

X2
U1[2]

-

flags
reserved3-

Bitfield txReady
This graphic explains the bits of txReady

Name

DescriptionenpolEnable TX ready feature for this port
Polarity0 High-active
1 Low-active

pin
thres

PIO to be used (must not be in use already by another function)
Threshold
The given threshold is multiplied by 8 bytes.
The TX ready PIN goes active after >= thres*8 bytes are pending for the port and going inactive after
the last pending bytes have been written to hardware (0-4 bytes before end of stream).
0x000 no threshold
0x001 8byte
0x002 16byte...
0x1FE 4080byte
0x1FF 4088byte

UBX-13003221 - R17

Early Production Information

Page 219 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield modeThis graphic explains the bits of mode

Name

Description

slaveAddr

Slave address
Range: 0x07 < slaveAddr < 0x78. Bit 0 must be 0

Bitfield inProtoMask
This graphic explains the bits of inProtoMask

Bitfield outProtoMask
This graphic explains the bits of outProtoMask

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 220 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

extendedTxTim
eout

Extended TX timeout: if set, the port will timeout if allocated TX memory >=4 kB and no activity for 1.
5s.

32.10.22 UBX-CFG-PWR (0x06 0x57)
32.10.22.1 Put receiver in a defined power state.
Message

UBX-CFG-PWR

Description

Put receiver in a defined power state.

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Set

Comment

This message is deprecated in protocol versions greater than 17. UseUBX-CFGRST for GNSS start/stop and UBX-RXM-PMREQ for software backup.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x57 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionreserved1
state-

Message version (1 for this version)
Reserved
Enter system state
0x52554E20: GNSS running
0x53544F50: GNSS stopped
0x42434B50: Software Backup. USB
interface will be disabled, other wakeup
source is needed.

Format

0
1
4

U1
U1[3]
U4

32.10.23 UBX-CFG-RATE (0x06 0x08)
32.10.23.1 Navigation/Measurement Rate Settings
Message

UBX-CFG-RATE

Description

Navigation/Measurement Rate Settings

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message allows the user to alter the rate at which navigation solutions (andthe measurements that they depend on) are generated by the receiver. The
calculation of the navigation solution will always be aligned to the top of asecond zero (first second of the week) of the configured reference time system.
(Navigation period is an integer multiple of the measurement period in protocol
versions greater than 17)• Each measurement triggers the measurements generation and raw data
output.
• The navRate value defines that every nth measurement triggers a navigation

UBX-13003221 - R17

Early Production Information

Page 221 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualepoch.
• The update rate has a direct influence on the power consumption. The morefixes that are required, the more CPU power and communication resources are
required.
• For most applications a 1 Hz update rate would be sufficient.
• When using Power Save Mode, measurement and navigation rate can differ
from the values configured here.
• See Measurement and navigation rate with Power Save Mode for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x08 6

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format0

U2-

measRate2

U2-

navRate4

U2-

timeRef

UBX-13003221 - R17

The elapsed time between GNSS
measurements, which defines the rate, e.
g. 100ms => 10Hz, 1000ms => 1Hz,
10000ms => 0.1Hz. Measurement rateshould be greater than or equal to 25 ms.
(Measurement rate should be greaterthan or equal to 50 ms in protocol versions
less than 24)
cycles The ratio between the number ofmeasurements and the number ofnavigation solutions, e.g. 5 means fivemeasurements for every navigation
solution. Maximum value is 127. (Thisparameter is ignored and the navRate is
fixed to 1 inprotocol versions less than 18)
The time system to which measurements
are aligned:
0: UTC time
1: GPS time
2: GLONASS time (not supported inprotocol versions less than 18)
3: BeiDou time (not supported in protocol
versions less than 18)
4: Galileo time (not supported in protocol
versions less than 18)

Early Production Information

Page 222 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.24 UBX-CFG-RINV (0x06 0x34)
32.10.24.1 Contents of Remote Inventory
Message

UBX-CFG-RINV

Description

Contents of Remote Inventory

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

If N is greater than 30, the excess bytes are discarded.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x34 1 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

flags

-

Flags (see graphic below)

data

-

Data to store/stored in Remote Inventory.

Format0

X1

Start of repeated block (N times)

1 + 1*NU1-

End of repeated block

Bitfield flags
This graphic explains the bits of flags

Name

Description

dump
binaryDump data at startup. Does not work if flag binary is set.
Data is binary.

32.10.25 UBX-CFG-RST (0x06 0x04)
32.10.25.1 Reset Receiver / Clear Backup Data Structures
Message

UBX-CFG-RST

Description

Reset Receiver / Clear Backup Data Structures

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

Don't expect this message to be acknowledged by the receiver.
• Newer FW version won't acknowledge this message at all.
• Older FW version will acknowledge this message but the acknowledge may not
be sent completely before the receiver is reset.
HeaderMessage Structure

UBX-13003221 - R17

Class ID

Length (Bytes)

0xB5 0x62 0x06 0x04 4
Early Production Information

PayloadChecksumsee below CK_A CK_B

Page 223 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

BBR Sections to clear. The following
Special Sets apply:
0x0000 Hot start
0x0001 Warm start
0xFFFF Cold start (see graphic below)
Reset Type0x00 - Hardware reset (Watchdog)
immediately
0x01 - Controlled Software reset
0x02 - Controlled Software reset (GNSS
only)
0x04 - Hardware reset (Watchdog) after
shutdown
0x08 - Controlled GNSS stop
0x09 - Controlled GNSS start
Reserved

Format0

X2-

navBbrMask

-

2

U1

-

resetMode

-

3

U1

-

reserved1-

Bitfield navBbrMask
This graphic explains the bits of navBbrMask

Name

Description

ephalm
health
klob
pos
clkd
osc
utc
rtc
aop

Ephemeris

UBX-13003221 - R17

Almanac
Health
Klobuchar parameters
Position
Clock Drift
Oscillator Parameter
UTC Correction + GPS Leap Seconds Parameters
RTC
Autonomous Orbit Parameters

Early Production Information

Page 224 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.26 UBX-CFG-RXM (0x06 0x11)
32.10.26.1 RXM configuration
Message

UBX-CFG-RXM

Description

RXM configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16 and 17

Type

Get/SetComment

For a detailed description see section Power Management.
Note that Power Save Mode cannot be selected when the receiver is configured
to process GLONASS signals (using UBX-CFG-GNSS).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x11 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved1
lpMode-Reserved
Low Power Mode
0: Continuous Mode
1: Power Save Mode
4: Continuous Mode
Note that for receivers with protocol
versions larger or equal to 14, both Low
Power Mode settings 0 and 4 configure
the receiver to Continuous Mode.

Format0
1

U1
U1

32.10.26.2 RXM configuration
Message

UBX-CFG-RXM

Description

RXM configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Get/SetComment

For a detailed description see section Power Management.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x11 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved1
lpMode-Reserved
Low Power Mode
0: Continuous Mode
1: Power Save Mode
4: Continuous Mode

Format0
1

U1
U1

UBX-13003221 - R17

Early Production Information

Page 225 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.27 UBX-CFG-SBAS (0x06 0x16)
32.10.27.1 SBAS Configuration
Message

UBX-CFG-SBAS

Description

SBAS Configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

This message configures the SBAS receiver subsystem (i.e. WAAS, EGNOS,
MSAS). See the SBAS Configuration Settings Description for a detailed
description of how these settings affect receiver operation.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x16 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

SBAS Mode (see graphic below)
SBAS Usage (see graphic below)
Maximum Number of SBAS prioritized
tracking channels (valid range: 0 - 3) touse (obsolete and superseded by UBXCFG-GNSS in protocol versions 14+).
Continuation of scanmode bitmask below(see graphic below)
Which SBAS PRN numbers to search for(Bitmask)
If all Bits are set to zero, auto-scan (i.e. allvalid PRNs) are searched.
Every bit corresponds to a PRN number(see graphic below)

Format

0
1
2

X1
X1
U1

-

mode
usage
maxSBAS

-

3

X1

-

scanmode2

-

4

X4

-

scanmode1-

Bitfield modeThis graphic explains the bits of mode

UBX-13003221 - R17

Early Production Information

Page 226 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

enabled

SBAS Enabled (1) / Disabled (0) - This field is deprecated; useUBX-CFG-GNSS to enable/disable SBAS
operation

test

SBAS Testbed: Use data anyhow (1) / Ignore data when in Test Mode (SBAS Msg 0)

Bitfield usage
This graphic explains the bits of usage

Name

Description

range
diffCorr
integrity

Use SBAS GEOs as a ranging source (for navigation)
Use SBAS Differential Corrections
Use SBAS Integrity Information

Bitfield scanmode2
This graphic explains the bits of scanmode2

Bitfield scanmode1
This graphic explains the bits of scanmode1

UBX-13003221 - R17

Early Production Information

Page 227 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.28 UBX-CFG-SLAS (0x06 0x8D)
32.10.28.1 SLAS Configuration
Message

UBX-CFG-SLAS

Description

SLAS Configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 19.2(only with ADR or UDR products)

Type

Get/SetComment

This message configures the QZSS SLAS (Sub-meter Level Augmentation
System). See the SLAS Configuration Settings Description for a detailed
description of how these settings affect receiver operation.
To apply SLAS corrections, QZSS operation and L1S signal tracking must be
enabled see UBX-CFG-GNSS
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x8D 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

mode
reserved1-

SLAS Mode (see graphic below)
Reserved

Format

0
1

X1
U1[3]

Bitfield modeThis graphic explains the bits of mode

Name

Description

enabledtest

Apply QZSS SLAS DGNSS corrections: Enabled (1) / Disabled (0)Use QZSS SLAS data when in test mode (SLAS msg 0): Use data anyhow (1) / Ignore data when in
Test Mode (0)raimRaim out measurements that are not corrected by QZSS SLAS, if at least 5 measurements arecorrected: Enabled (1) / Disabled (0)UBX-13003221 - R17

Early Production Information

Page 228 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.29 UBX-CFG-SMGR (0x06 0x62)
32.10.29.1 Synchronization manager configuration
Message

UBX-CFG-SMGR

Description

Synchronization manager configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Get/SetComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x62 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

Message version (0 for this version)
Minimum number of GNSS fixes before wecommit to use it as a source
Maximum frequency change rate during
disciplining. Must not exceed 30ppb/s
Maximum phase correction rate incoherent time pulse mode.
For maximum phase correction rate incorrective time pulse mode see
maxSlewRate.
Note that in coherent time pulse mode
phase correction is achieved by intentionalfrequency offset. Allowing for a highphase correction rate can result in large
intentional frequency offset. Must notexceed 100ns/s
Reserved
Limit of possible deviation from nominal
before UBX-TIM-TOS indicates thatfrequency is out of tolerance
Limit of possible deviation from nominal
before UBX-TIM-TOS indicates that time
pulse is out of tolerance
Sync manager message configuration(see graphic below)

Format

0
1

U1
U1

-

versionminGNSSFix

2

U2

-

4

U2

-

maxFreqChange ppb/s
Rate
maxPhaseCorrR ns/s
ate

6
8

U1[2]
U2

-

reserved1
freqTolerance ppb

10

U2

-

timeTolerance ns

12

X2

-

messageCfg

UBX-13003221 - R17-

Early Production Information

Page 229 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-SMGR continued
Byte Offset

Number

Scaling

Name

Unit

Description

Maximum slew rate, the maximum timecorrection that shall be applied between
locked pulses in corrective time pulse
mode.
To have no limit on the slew rate, set theflag disableMaxSlewRate to 1
For maximum phase correction rate incoherent time pulse mode see
maxPhaseCorrRate.
Flags (see graphic below)

Format14

U2-

maxSlewRate

us/s

16

X4

-

flags

-

Bitfield messageCfg
This graphic explains the bits of messageCfg

Name

Description

measInternal
measGNSS
measEXTINT0
measEXTINT1

1 = report the estimated offset of the internal oscillator based on the oscillator model
1 = report the internal oscillator's offset relative to GNSS
1 = report the internal oscillator's offset relative to the source on EXTINT0
1 = report the internal oscillator's offset relative to the source on EXTINT1

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 230 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

disableInternaldisableExtern
alpreferenceMode

1 = disable disciplining of the internal oscillator
1 = disable disciplining of the external oscillator
Reference selection preference
0 - best frequency accuracy
1 - best phase accuracy

enableGNSS
enableEXTINT0
enableEXTINT1
enableHostMea
sInt

1 = enable use of GNSS as synchronization source
1 = enable use of EXTINT0 as synchronization source
1 = enable use of EXTINT1 as synchronization source
1 = enable use of host measurements on the internal oscillator as synchronization source
Measurements made by the host must be sent to the receiver using a UBX-TIM-SMEAS-DATA0
message.

enableHostMea
sExt

1 = enable use of host measurements on the external oscillator as synchronization source
Measurements made by the host must be sent to the receiver using a UBX-TIM-SMEAS-DATA0
message.

useAnyFix

0 - use over-determined navigation solutions only
1 - use any fix

disableMaxSle
wRate

0 - use the value in the field maxSlewRate for maximum time correction in corrective time pulsemode
1 - don't use the value in the field maxSlewRate

issueFreqWarn
ing
issueTimeWarn
ing
TPCoherent

1 = issue a warning (viaUBX-TIM-TOS flag) when frequency uncertainty exceeds freqTolerance
1 = issue a warning (viaUBX-TIM-TOS flag) when time uncertainty exceeds timeTolerance
Control time pulse coherency
0 - Coherent pulses. Time phase offsets will be corrected gradually by varying the GNSS oscillator
rate within frequency tolerance limits. There will always be the correct number of GNSS oscillator
cycles between time pulses. Given tight limits this may take a long time
1 - Non-coherent pulses. In this mode the receiver will correct time phase offsets as quickly asallowed by the specified maximum slew rate, in which case there may not be the expected number of
GNSS oscillator cycles between time pulses.
2 - Post-initialization coherent pulses. The receiver will run in non-coherent mode as described above
until the pulse timing has been corrected and PLL is active on the internal oscillator, but will thenswitch to coherent pulse mode.

disableOffset

UBX-13003221 - R17

1 = disable automatic storage of oscillator offset

Early Production Information

Page 231 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.30 UBX-CFG-TMODE2 (0x06 0x3D)
32.10.30.1 Time Mode Settings 2
Message

UBX-CFG-TMODE2

Description

Time Mode Settings 2

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync or Time
Sync products)

Type

Get/SetComment

This message is available only for timing receivers
See the Time Mode Description for details. This message replaces thedeprecated UBX-CFG-TMODE message.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x3D 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Time Transfer Mode:
0 Disabled
1 Survey In
2 Fixed Mode (true position information
required)
3-255 Reserved
Reserved
Time mode flags (see graphic below)
WGS84 ECEF X coordinate or latitude,
depending on flags above

Format0

U1-

timeMode

-

1
2
4

U1
X2
I4

-

reserved1
flags
ecefXOrLat

8

I4

-

ecefYOrLon

12

I4

-

ecefZOrAlt

16
20
24

U4
U4
U4

-

fixedPosAcc
svinMinDur
svinAccLimitcm_
or_deg*1e7cm_
WGS84 ECEF Y coordinate or longitude,or_depending on flags above
deg*1e7cm
WGS84 ECEF Z coordinate or altitude,
depending on flags abovemm
Fixed position 3D accuracys
Survey-in minimum durationmm
Survey-in position accuracy limit

UBX-13003221 - R17

Early Production Information

Page 232 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

DescriptionllaaltInv

Position is given in LAT/LON/ALT (default is ECEF)
Altitude is not valid, in case lla was set

32.10.31 UBX-CFG-TMODE3 (0x06 0x71)
32.10.31.1 Time Mode Settings 3
Message

UBX-CFG-TMODE3

Description

Time Mode Settings 3

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20, 20.01, 20.1, 20.2 and 20.3(only withHigh Precision GNSS products)

Type

Get/SetComment

Configures the receiver to be in Time Mode. The position referred to in thismessage is that of the Antenna Reference Point (ARP).
See the Time Mode Description for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x71 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reserved
Receiver mode flags (see graphic below)cm_
WGS84 ECEF X coordinate (or latitude) ofor_
the ARP position, depending on flags
deg*1e- above
7cm_
WGS84 ECEF Y coordinate (or longitude)or_of the ARP position, depending on flags
deg*1e- above
7cm
WGS84 ECEF Z coordinate (or altitude) of
the ARP position, depending on flags
above

Format

0
1
2
4

U1
U1
X2
I4

-

versionreserved1
flags
ecefXOrLat

8

I4

-

ecefYOrLon

12

I4

-

ecefZOrAlt

UBX-13003221 - R17

Early Production Information

Page 233 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-TMODE3 continued
Byte Offset

Number

Scaling

Name

Unit

Description

0.1_
High-precision WGS84 ECEF X coordinate
mm_(or latitude) of the ARP position,or_depending on flags above. Must be in thedeg*1e- range -99..+99.
9The precise WGS84 ECEF X coordinate inunits of cm, or the precise WGS84 ECEF
latitude in units of 1e-7 degrees, is given by
ecefXOrLat + (ecefXOrLatHP * 1e-2)
0.1_
High-precision WGS84 ECEF Y coordinate
mm_(or longitude) of the ARP position,or_depending on flags above. Must be in thedeg*1e- range -99..+99.
9The precise WGS84 ECEF Y coordinate inunits of cm, or the precise WGS84 ECEF
longitude in units of 1e-7 degrees, is given
byecefYOrLon + (ecefYOrLonHP * 1e-2)
0.1_
High-precision WGS84 ECEF Z coordinate
mm(or altitude) of the ARP position,
depending on flags above. Must be in therange -99..+99.
The precise WGS84 ECEF Z coordinate, or
altitude coordinate, in units of cm is given
byecefZOrAlt + (ecefZOrAltHP * 1e-2)
Reserved
0.1_
Fixed position 3D accuracymmsSurvey-in minimum duration
0.1_
Survey-in position accuracy limitmmReserved

Format16

I1-

ecefXOrLatHP

17

I1

-

ecefYOrLonHP

18

I1

-

ecefZOrAltHP

19
20

U1
U4

-

reserved2
fixedPosAcc

24
28

U4
U4

-

svinMinDur
svinAccLimit

32

U1[8]

-

reserved3

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 234 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

mode

Receiver Mode:
0 Disabled
1 Survey In
2 Fixed Mode (true ARP position information required)
3-255 Reserved
Position is given in LAT/LON/ALT (default is ECEF)

lla32.10.32 UBX-CFG-TP5 (0x06 0x31)
32.10.32.1 Poll Time Pulse Parameters for Time Pulse 0
Message

UBX-CFG-TP5

Description

Poll Time Pulse Parameters for Time Pulse 0

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3 and 22

Type

Poll Request

Comment

Sending this (empty / no-payload) message to the receiver results in the receiver
returning a message of type UBX-CFG-TP5 with a payload as defined below for
timepulse 0.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x31 0

Checksumsee below CK_A CK_B

No payload

32.10.32.2 Poll Time Pulse Parameters
Message

UBX-CFG-TP5

Description

Poll Time Pulse Parameters

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3 and 22

Type

Poll Request

Comment

Sending this message to the receiver results in the receiver returning a message
of type UBX-CFG-TP5 with a payload as defined below for the specified time
pulse.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x31 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

tpIdx

-

Time pulse selection (0 = TIMEPULSE, 1 =TIMEPULSE2)

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 235 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.10.32.3 Time Pulse Parameters
Message

UBX-CFG-TP5

Description

Time Pulse Parameters

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 15

Type

Get/SetComment

This message is used to get/set time pulse parameters. For more information
see section Time pulse.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x31 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0

U1

-

tpIdx

Time pulse selection (0 = TIMEPULSE, 1 =TIMEPULSE2)
Message version (0x00 for this version)
Reservedns
Antenna cable delayns
RF group delay
Hz_or_ Frequency or period time, depending on
ussetting of bit 'isFreq'
Hz_or_ Frequency or period time when locked tous
GPS time, only used if 'lockedOtherSet' is
set
us_or_ Pulse length or duty cycle, depending on
2^-32 'isLength'
us_or_ Pulse length or duty cycle when locked to2^-32 GPS time, only used if 'lockedOtherSet' issetns
User configurable time pulse delay

1
2
4
6
8

U1
U1[2]
I2
I2
U4

-

versionreserved1
antCableDelay
rfGroupDelay
freqPeriod

12

U4

-

freqPeriodLoc
k

16

U4

-

pulseLenRatio

20

U4

-

pulseLenRatio
Lock

24

I4

-

28

X4

-

userConfigDel
ay
flags
-

Configuration flags (see graphic below)

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 236 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

activelockGpsFreq
lockedOtherSet

if set enable time pulse; if pin assigned to another function, other function takes precedence
if set synchronize time pulse to GPS as soon as GPS time is valid, otherwise use local clock
if set use 'freqPeriodLock' and 'pulseLenRatioLock' as soon as GPS time is valid and 'freqPeriod' and'pulseLenRatio' if GPS time is invalid,
if flag is cleared 'freqPeriod' and 'pulseLenRatio' used regardless of GPS time
if set 'freqPeriodLock' and 'freqPeriod' interpreted as frequency, otherwise interpreted as period

isFreqisLength

if set 'pulseLenRatioLock' and 'pulseLenRatio' interpreted as pulse length, otherwise interpreted as
duty cyclealign pulse to top of second (period time must be integer fraction of 1s)alignToTow
polarity

pulse polarity:
0 = falling edge at top of second
1 = rising edge at top of second
timegrid to use:

gridUtcGps

0 = UTC
1 = GPS

32.10.32.4 Time Pulse Parameters
Message

UBX-CFG-TP5

Description

Time Pulse Parameters

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3 and 22

Type

Get/SetComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x31 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0

U1

-

tpIdx

1
2
4
6
8

U1
U1[2]
I2
I2
U4

-

versionreserved1
antCableDelay
rfGroupDelay
freqPeriod

12

U4

-

freqPeriodLoc
k

16

U4

-

pulseLenRatio

20

U4

-

pulseLenRatio
Lock

UBX-13003221 - R17

Time pulse selection (0 = TIMEPULSE, 1 =TIMEPULSE2)
Message version (0x01 for this version)
Reservedns
Antenna cable delayns
RF group delay
Hz_or_ Frequency or period time, depending on
ussetting of bit 'isFreq'
Hz_or_ Frequency or period time when locked tous
GNSS time, only used if 'lockedOtherSet'
is setus_or_ Pulse length or duty cycle, depending on
2^-32 'isLength'
us_or_ Pulse length or duty cycle when locked to2^-32 GNSS time, only used if 'lockedOtherSet'
is set

Early Production Information

Page 237 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-TP5 continued
Byte Offset

Number

Scaling

Name

Unit

userConfigDel ns
ay
flags
-

Description

Format

24

I4

-

28

X4

-

User configurable time pulse delay
Configuration flags (see graphic below)

Bitfield flags
This graphic explains the bits of flags

Name

Description

activeIf set enable time pulse; if pin assigned to another function, other function takes precedence.
Must be set for FTS variant.

lockGnssFreq

If set synchronize time pulse to GNSS as soon as GNSS time is valid. If not set, or before GNSS time
is valid use local clock.
This flag is ignored by the FTS product variant; in this case the receiver always locks to the best
available time/frequency reference (which is not necessarily GNSS).

lockedOtherSet

If set the receiver switches between the timepulse settings given by 'freqPeriodLocked' &'pulseLenLocked' and those given by 'freqPeriod' & 'pulseLen'. The 'Locked' settings are used where
the receiver has an accurate sense of time. For non-FTS products, this occurs when GNSS solution
with a reliable time is available, but for FTS products the setting syncMode field governs behavior. In
all cases, the receiver only uses 'freqPeriod' & 'pulseLen' when the flag is unset.

isFreqisLength

If set 'freqPeriodLock' and 'freqPeriod' are interpreted as frequency, otherwise interpreted as period.
If set 'pulseLenRatioLock' and 'pulseLenRatio' interpreted as pulse length, otherwise interpreted as
duty cycle.

alignToTow

Align pulse to top of second (period time must be integer fraction of 1s).
Also set 'lockGnssFreq' to use this feature.
This flag is ignored by the FTS product variant; it is assumed to be always set (as is lockGnssFreq).
Set maxSlewRate and maxPhaseCorrRate fields of UBX-CFG-SMGR to 0 to disable alignment.

polarity

Pulse polarity:
0: falling edge at top of second
1: rising edge at top of second

UBX-13003221 - R17

Early Production Information

Page 238 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags Description continued
Name

Description

gridUtcGnss

Timegrid to use:
0: UTC
1: GPS
2: GLONASS
3: BeiDou
4: Galileo (not supported in protocol versions less than 18)
This flag is only relevant if 'lockGnssFreq' and 'alignToTow' are set.
Note that configured GNSS time is estimated by the receiver if locked to any GNSS system. If thereceiver has a valid GNSS fix it will attempt to steer the TP to the specified time grid even if thespecified time is not based on information from the constellation's satellites. To ensure timing based
purely on a given GNSS, restrict the supported constellations in UBX-CFG-GNSS.
Sync Manager lock mode to use:

syncMode

0: switch to 'freqPeriodLock' and 'pulseLenRatioLock' as soon as Sync Manager has an accuratetime, never switch back to 'freqPeriod' and 'pulseLenRatio'
1: switch to 'freqPeriodLock' and 'pulseLenRatioLock' as soon as Sync Manager has an accuratetime, and switch back to 'freqPeriod' and 'pulseLenRatio' as soon as time gets inaccurateThis field is only relevant for the FTS product variant.
This field is only relevant if the flag 'lockedOtherSet' is set.

32.10.33 UBX-CFG-TXSLOT (0x06 0x53)
32.10.33.1 TX buffer time slots configuration
Message

UBX-CFG-TXSLOT

Description

TX buffer time slots configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Set

Comment

This message configures how transmit time slots are defined for the receiverinterfaces. These time slots are relative to the chosen time pulse. A receiver that
supports this message offers 3 time slots: nr. 0, 1 and 2. These time pulses
follow each other and their associated priorities decrease in this order. The endof each can be specified in this message, the beginning is when the circularly
previous slot ends (i.e. slot 0 starts when slot 2 finishes).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x53 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Bitfield of ports for which the slots areenabled. (see graphic below)
Reference timepulse source
0 - Timepulse
1 - Timepulse 2

Format

0
1

U1
X1

-

versionenable

-

2

U1

-

refTp

-

UBX-13003221 - R17

Early Production Information

Page 239 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-TXSLOT continued
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved1-

Reservedend-

End of timeslot in milliseconds after time
pulse

Format3

U1

Start of repeated block (3 times)

4 + 4*NU4-

End of repeated block

Bitfield enable
This graphic explains the bits of enable

Name

Description

DDC
UART1
UART2
USB
SPI

DDC/I2CUART 1UART 2USB
SPI

32.10.34 UBX-CFG-USB (0x06 0x1B)
32.10.34.1 USB Configuration
Message

UBX-CFG-USB

Description

USB Configuration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Get/SetComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x06 0x1B 108

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Vendor ID. This field shall only be set toregistered Vendor IDs. Changing this fieldrequires special Host drivers.
Product ID. Changing this field requires
special Host drivers.
Reserved
Reserved

Format0

U2-

vendorID

-

2

U2

-

productID

-

4
6

U1[2]
U1[2]

-

reserved1
reserved2-

UBX-13003221 - R17

Early Production Information

Page 240 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-CFG-USB continued
Byte Offset

Number

Scaling

Name

Unit

powerConsumpt mA
ion
flags
-

Description

Format

8

U2

-

10

X2

-

12

CH[32 ]
CH[32 ]
CH[32 ]

44
76

vendorString-

productString serialNumber-

Power consumed by the device
various configuration flags (see graphic
below)
String containing the vendor name. 32
ASCII bytes including 0-termination.
String containing the product name. 32
ASCII bytes including 0-termination.
String containing the serial number. 32
ASCII bytes including 0-termination.
Changing the String fields requires special
Host drivers.

Bitfield flags
This graphic explains the bits of flags

Name

Description

reEnumpowerMode

force re-enumeration

UBX-13003221 - R17

self-powered (1), bus-powered (0)Early Production Information

Page 241 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.11 UBX-ESF (0x10)
External Sensor Fusion Messages: i.e. External Sensor Measurements and Status Information.
Messages in the ESF class are used to output external sensor fusion information from thereceiver.
32.11.1 UBX-ESF-INS (0x10 0x15)
32.11.1.1 Vehicle dynamics information
Message

UBX-ESF-INS

Description

Vehicle dynamics information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Periodic/Polled

Comment

This message outputs information about the vehicle dynamics.
For ADR products (in protocol versions less than 19.2), the output dynamics
information (angular rates and accelerations) is expressed with respect to thevehicle-frame. More information can be found in the ADR Navigation Output
section.
For ADR products, the output dynamics information (angular rates andaccelerations) is expressed with respect to the vehicle-frame. More information
can be found in the ADR Navigation Output section.
For UDR products, the output dynamics information (angular rates andaccelerations) are expressed with respect to the body-frame. More information
can be found in the UDR Navigation Output section.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x10 0x15 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Bitfield (see graphic below)
Reserved
GPS time of week of the navigation epoch.
See the description of iTOW for details.
Compensated x-axis angular rate.
Compensated y-axis angular rate.
Compensated z-axis angular rate.
Compensated x-axis acceleration (gravityfree).
Compensated y-axis acceleration (gravityfree).
Compensated z-axis acceleration (gravityfree).

Format

0
4
8

U4
U1[4]
U4

-

bitfield0
reserved1
iTOW

ms

12
16
20
24

I4
I4
I4
I4

1e-3
1e-3
1e-3
1e-2

xAngRateyAngRatezAngRate
xAccel

deg/s
deg/s
deg/s
m/s²

28

I4

1e-2

yAccel

m/s²

32

I4

1e-2

zAccelm/s²

UBX-13003221 - R17

Early Production Information

Page 242 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield bitfield0
This graphic explains the bits of bitfield0

Name

Description

versionxAngRateValidyAngRateValidzAngRateValidxAccelValidyAccelValidzAccelValid

Message version (1 for this version).
Compensated x-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated y-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated z-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated x-axis acceleration data validity flag (0: not valid, 1: valid).
Compensated y-axis acceleration data validity flag (0: not valid, 1: valid).
Compensated z-axis acceleration data validity flag (0: not valid, 1: valid).

32.11.2 UBX-ESF-MEAS (0x10 0x02)
32.11.2.1 External Sensor Fusion Measurements
Message

UBX-ESF-MEAS

Description

External Sensor Fusion Measurements

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15.01, 16 and 17(only with ADR products)• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Input/Output

Comment

Possible data types for the data field are described in the ESF Measurement
Data section.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x10 0x02

Payload(8 + 4*numMeas) or (12 +4*numMeas)

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format0

U4-

timeTag

-

4

X2

-

flags

-

6

U2

-

id

-

Time tag of measurement generated byexternal sensor
Flags. Set all unused bits to zero. (seegraphic below)
Identification number of data provider-

data (see graphic below)

Start of repeated block (numMeas times)

8 + 4*N

X4

-

data

End of repeated block
Start of optional block

UBX-13003221 - R17

Early Production Information

Page 243 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-ESF-MEAS continued
Byte Offset

Number

Scaling

Name

Unit

Description-

calibTtag

ms

Receiver local time calibrated.
This field must not be supplied whencalibTtagValid is set to 0.

Format8+U4
4*numMeas
End of optional block

Bitfield flags
This graphic explains the bits of flags

Name

Description

timeMarkSent
timeMarkEdge
calibTtagVali
dnumMeasTime mark signal was supplied just prior to sending this message: 0 = none, 1 = on Ext0, 2 = on Ext1
Trigger on rising (0) or falling (1) edge of time mark signal
Calibration time tag available. Always set to zero.
Number of measurements contained in this message (optional, can be obtained from message size)

Bitfield data
This graphic explains the bits of data

Name

Description

dataField
dataType

Data

UBX-13003221 - R17

Type of data (0 = no data; 1..63 = data type)

Early Production Information

Page 244 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.11.3 UBX-ESF-RAW (0x10 0x03)
32.11.3.1 Raw sensor measurements
Message

UBX-ESF-RAW

Description

Raw sensor measurements

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15.01, 16 and 17(only with ADR products)• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

OutputComment

The message contains measurements from the active inertial sensors
connected to the GNSS chip. Possible data types for the data field areaccelerometer, gyroscope and temperature readings as described in the ESF
Measurement Data section.
Note that the rate selected in UBX-CFG-MSG is not respected. If a positive rate is
selected then all raw measurements will be output.
See also Raw Sensor Measurement Data.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x10 0x03 4 + 8*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved1-

Reserved
data
Same as in UBX-ESF-MEAS (see graphic
below)
sensor time tag

Format0

U1[4]Start of repeated block (N times)

4 + 8*N

X4

-

data

-

8 + 8*N

U4

-

sTtag

-

End of repeated block

Bitfield data
This graphic explains the bits of data

UBX-13003221 - R17

Early Production Information

Page 245 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

dataField
dataType

data
type of data (0 = no data; 1..255 = data type)32.11.4 UBX-ESF-STATUS (0x10 0x10)
32.11.4.1 External Sensor Fusion (ESF) status information
Message

UBX-ESF-STATUS

Description

External Sensor Fusion (ESF) status information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15.01, 16 and 17(only with ADR products)• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Periodic/Polled

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x10 0x10 16 + 4*numSens

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0

U4

-

iTOW

ms

4
5
12

U1
U1[7]
U1

-

versionreserved1
fusionMode

-

13
15

U1[2]
U1

-

reserved2
numSens-

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (2 for this version)
Reserved
Fusion mode:
0: Initialization mode: receiver is
initializing some unknown values requiredfor doing sensor fusion
1: Fusion mode: GNSS and sensor data areused for navigation solution computation
2: Suspended fusion mode: sensor fusion
is temporarily disabled due to e.g. invalid
sensor data or detected ferry
3: Disabled fusion mode: sensor fusion ispermanently disabled until receiver resetdue e.g. to sensor error
More details can be found in the Fusion
Modes section.
Reserved
Number of sensors

Hz-

Sensor status, part 1 (seegraphic below)
Sensor status, part 2 (see graphic below)
Observation frequency
Sensor faults (see graphic below)

Start of repeated block (numSens times)

16 + 4*N
17 + 4*N
18 + 4*N
19 + 4*N

X1
X1
U1
X1

-

sensStatus1
sensStatus2
freq
faultsEnd of repeated block

UBX-13003221 - R17

Early Production Information

Page 246 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield sensStatus1
This graphic explains the bits of sensStatus1

Name

Description

type
used
ready

Sensor data type. Data types are defined in the Sensor Data Types section.
If set, sensor data is used for the current sensor fusion solution.
If set, sensor is set up (configuration is available or not required) but not used for computing thecurrent sensor fusion solution.

Bitfield sensStatus2
This graphic explains the bits of sensStatus2

Name

Description

calibStatus

00: Sensor is not calibrated
01: Sensor is calibrating
10/11: Sensor is calibrated
Good dead reckoning performance is only possible when all used sensors are calibrated. Dependingon the quality of the GNSS signals and the sensor data, the sensors may take a longer time to getcalibrated.

timeStatus

00: No data
01: Reception of the first byte used to tag the measurement
10: Event input used to tag the measurement
11: Time tag provided with the data

Bitfield faults
This graphic explains the bits of faults

UBX-13003221 - R17

Early Production Information

Page 247 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

badMeasbadTTagmissingMeas
noisyMeas

Bad measurements detected

UBX-13003221 - R17

Bad measurement time-tags detected
Missing or time-misaligned measurements detected
High measurement noise-level detected

Early Production Information

Page 248 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.12 UBX-HNR (0x28)
High Rate Navigation Results Messages: i.e. High rate time, position, speed, heading.
Messages in the HNR class are used to output high rate navigation data for position, altitude,
velocity and their accuracies.
32.12.1 UBX-HNR-INS (0x28 0x02)
32.12.1.1 Vehicle dynamics information
MessageUBX-HNR-INS

Description

Vehicle dynamics information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3, 22,
23 and 23.01(only with ADR or UDR products)

Type

Periodic/Polled

Comment

This message outputs high rate information about vehicle dynamics computedby the Inertial Navigation System (INS) during ESF-based navigation.
For ADR products (in protocol versions less than 19.2), the output dynamics
information (angular rates and accelerations) is expressed with respect to thevehicle-frame. More information can be found in the ADR Navigation Output
section.
For UDR products, the output dynamics information (angular rates andaccelerations) is expressed with respect to the body-frame. More information
can be found in the UDR Navigation Output section.
For ADR products, the output dynamics information (angular rates andaccelerations) is expressed with respect to the vehicle-frame. More information
can be found in the ADR Navigation Output section.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x28 0x02 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Bitfield (see graphic below)
Reserved
GPS time of week of the HNR epoch.
Compensated x-axis angular rate.
Compensated y-axis angular rate.
Compensated z-axis angular rate.
Compensated x-axis acceleration (withgravity).
Compensated y-axis acceleration (withgravity).
Compensated z-axis acceleration (withgravity).

Format

0
4
8
12
16
20
24

X4
U1[4]
U4
I4
I4
I4
I4

1e-3
1e-3
1e-3
1e-2

bitfield0
reserved1
iTOW
xAngRateyAngRatezAngRate
xAccel

ms
deg/s
deg/s
deg/s
m/s²

28

I4

1e-2

yAccel

m/s²

32

I4

1e-2

zAccelm/s²

UBX-13003221 - R17

Early Production Information

Page 249 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield bitfield0
This graphic explains the bits of bitfield0

Name

Description

versionxAngRateValidyAngRateValidzAngRateValidxAccelValidyAccelValidzAccelValid

Message version (0 for this version).
Compensated x-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated y-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated z-axis angular rate data validity flag (0: not valid, 1: valid).
Compensated x-axis acceleration data validity flag (0: not valid, 1: valid).
Compensated y-axis acceleration data validity flag (0: not valid, 1: valid).
Compensated z-axis acceleration data validity flag (0: not valid, 1: valid).

32.12.2 UBX-HNR-PVT (0x28 0x00)
32.12.2.1 High Rate Output of PVT Solution
MessageUBX-HNR-PVT

Description

High Rate Output of PVT Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Periodic/Polled

Comment

Note that during a leap second there may be more (or less) than 60 seconds in aminute; see the description of leap seconds for details. This message provides
the position, velocity and time solution with high output rate.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x28 0x00 72

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

iTOW

4
6
7
8
9
10
11
12

U2
U1
U1
U1
U1
U1
X1
I4

-

year
month
day
hour
min
sec
valid
nano

UBX-13003221 - R17

GPS time of week of the navigation epoch.
See the description of iTOW for details.
yYear (UTC)month Month, range 1..12 (UTC)dDay of month, range 1..31 (UTC)hHour of day, range 0..23 (UTC)min
Minute of hour, range 0..59 (UTC)sSeconds of minute, range 0..60 (UTC)
Validity Flags (see graphic below)ns
Fraction of second, range -1e9 .. 1e9 (UTC)

Early Production Information

Page 250 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-HNR-PVT continued
Byte Offset

Number

Scaling

Name

Unit

Description

GPSfix Type, range 0..5
0x00 = No Fix
0x01 = Dead Reckoning only
0x02 = 2D-Fix
0x03 = 3D-Fix
0x04 = GPS + dead reckoning combined
0x05 = Time only fix
0x06..0xff: reserved
Fix Status Flags (see graphic below)
Reserved
Longitude
Latitude
Height above Ellipsoid
Height above mean sea level
Ground Speed (2-D)
Speed (3-D)
Heading of motion (2-D)
Heading of vehicle (2-D)
Horizontal accuracy
Vertical accuracy
Speed accuracy
Heading accuracy
Reserved

Format16

U1-

gpsFix

-

17
18
20
24
28
32
36
40
44
48
52
56
60
64
68

X1
U1[2]
I4
I4
I4
I4
I4
I4
I4
I4
U4
U4
U4
U4
U1[4]

1e-7
1e-7
1e-5
1e-5
1e-5
-

flags
reserved1
lon
latheighthMSLgSpeedspeed
headMot
headVeh
hAcc
vAcc
sAcc
headAcc
reserved2

deg
deg
mm
mm
mm/s
mm/s
deg
deg
mm
mm
mm/s
deg
-

Bitfield valid
This graphic explains the bits of valid

UBX-13003221 - R17

Early Production Information

Page 251 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

validDatevalidTimefullyResolved

1 = Valid UTC Date (seeIntegration manual Time Validity section for details)
1 = Valid UTC Time of Day (seeIntegration manual Time Validity section for details)
1 = UTC Time of Day has been fully resolved (no seconds uncertainty)

Bitfield flags
This graphic explains the bits of flags

Name

Description

GPSfixOK
DiffSoln
WKNSETTOWSET
headVehValid>1 = Fix within limits (e.g. DOP & accuracy)

UBX-13003221 - R17

1 = DGPS used
1 = Valid GPS week number
1 = Valid GPS time of week (iTOW & fTOW)
Heading of vehicle is valid

Early Production Information

Page 252 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.13 UBX-INF (0x04)
Information Messages: i.e. Printf-Style Messages, with IDs such as Error, Warning, Notice.
Messages in the INF class are used to output strings in a printf style from the firmware orapplication code. All INF messages have an associated type to indicate the kind of message.
32.13.1 UBX-INF-DEBUG (0x04 0x04)
32.13.1.1 ASCII output with debug contents
Message

UBX-INF-DEBUG

Description

ASCII output with debug contents

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message has a variable length payload, representing an ASCII string.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x04 0x04 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

str-

ASCII Character

FormatStart of repeated block (N times)

N*1

CH

-

End of repeated block32.13.2 UBX-INF-ERROR (0x04 0x00)
32.13.2.1 ASCII output with error contents
Message

UBX-INF-ERROR

Description

ASCII output with error contents

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message has a variable length payload, representing an ASCII string.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x04 0x00 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

str-

ASCII Character

FormatStart of repeated block (N times)

N*1

CH

-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 253 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.13.3 UBX-INF-NOTICE (0x04 0x02)
32.13.3.1 ASCII output with informational contents
Message

UBX-INF-NOTICE

Description

ASCII output with informational contents

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message has a variable length payload, representing an ASCII string.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x04 0x02 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

str-

ASCII Character

FormatStart of repeated block (N times)

N*1

CH

-

End of repeated block32.13.4 UBX-INF-TEST (0x04 0x03)
32.13.4.1 ASCII output with test contents
Message

UBX-INF-TEST

Description

ASCII output with test contents

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message has a variable length payload, representing an ASCII string.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x04 0x03 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

str-

ASCII Character

FormatStart of repeated block (N times)

N*1

CH

-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 254 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.13.5 UBX-INF-WARNING (0x04 0x01)
32.13.5.1 ASCII output with warning contents
Message

UBX-INF-WARNING

Description

ASCII output with warning contents

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message has a variable length payload, representing an ASCII string.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x04 0x01 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

str-

ASCII Character

FormatStart of repeated block (N times)

N*1

CH

-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 255 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.14 UBX-LOG (0x21)
Logging Messages: i.e. Log creation, deletion, info and retrieval.
Messages in the LOG class are used to configure and report status information of the logging andbatching features.
32.14.1 UBX-LOG-BATCH (0x21 0x11)
32.14.1.1 Batched data
Message

UBX-LOG-BATCH

Description

Batched data

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 23.01

Type

PolledComment

Note that during a leap second there may be more (or less) than 60 seconds ina minute; see the description of leap seconds for details.
This message combines position, velocity and time solution, including accuracy
figures.
The output of this message can be requested via UBX-LOG-RETRIEVEBATCH.
The content of this message is influenced by UBX-CFG-BATCH. Depending on theflags extraPvt and extraOdo some of the fields in this message may not bevalid. This validity information is also indicated in this message via flags of thesame name.
See Data Batching for more information.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x11 100

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0
1
2

U1
X1
U2

-

versioncontentValid
msgCnt

4

U4

-

iTOW

8
10
11
12
13
14
15
16

U2
U1
U1
U1
U1
U1
X1
U4

-

year
month
day
hour
min
sec
valid
tAcc

20

I4

-

fracSec

UBX-13003221 - R17

Message version (0x00 for this version)
Content validity flags (see graphic below)
Message counter; increments for eachsent UBX-LOG-BATCH message.
ms
GPS time of week of the navigation epoch.
See the description of iTOW for details.
Only valid if extraPvt is set.
yYear (UTC)month Month, range 1..12 (UTC)dDay of month, range 1..31 (UTC)hHour of day, range 0..23 (UTC)min
Minute of hour, range 0..59 (UTC)sSeconds of minute, range 0..60 (UTC)
Validity flags (see graphic below)
nsTime accuracy estimate (UTC)
Only valid if extraPvt is set.
ns
Fraction of second, range -1e9 .. 1e9 (UTC)

Early Production Information

Page 256 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-LOG-BATCH continued
Byte Offset

Number

Scaling

Name

Unit

Description

GNSSfix Type:0: no fix
2: 2D-fix
3: 3D-fix
Fix status flags (see graphic below)
Additional flags
Number of satellites used in Nav Solution
Only valid if extraPvt is set.
Longitude
Latitude
Height above ellipsoid
Height above mean sea level
Only valid if extraPvt is set.
Horizontal accuracy estimate
Vertical accuracy estimate
Only valid if extraPvt is set.
NED north velocity
Only valid if extraPvt is set.
NED east velocity
Only valid if extraPvt is set.
NED down velocity
Only valid if extraPvt is set.
Ground Speed (2-D)
Heading of motion (2-D)
Speed accuracy estimate
Only valid if extraPvt is set.
Heading accuracy estimate
Only valid if extraPvt is set.
Position DOP
Only valid if extraPvt is set.
Reserved
Ground distance since last reset
Only valid if extraOdo is set.
Total cumulative ground distance
Only valid if extraOdo is set.
Ground distance accuracy (1-sigma)
Only valid if extraOdo is set.
Reserved

Format24

U1-

fixType

-

25
26
27

X1
X1
U1

-

flags
flags2
numSV

-

28
32
36
40

I4
I4
I4
I4

1e-7
1e-7
-

lon
lat
height
hMSL

deg
deg
mm
mm

44
48

U4
U4

-

hAcc
vAcc

mm
mm

52

I4

-

velN

mm/s

56

I4

-

velE

mm/s

60

I4

-

velD

mm/s

64
68
72

I4
I4
U4

1e-5
-

gSpeedheadMot
sAcc

mm/s
deg
mm/s

76

U4

1e-5

headAcc

deg

80

U2

0.01

pDOP

-

82
84

U1[2]
U4

-

reserved1
distance

m

88

U4

-

totalDistance m

92

U4

-

distanceStd

m

96

U1[4]

-

reserved2-

UBX-13003221 - R17

Early Production Information

Page 257 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield contentValid
This graphic explains the bits of contentValid

Name

Description

extraPvt

Store extra PVT information
The fields iTOW, tAcc, numSV, hMSL, vAcc, velN, velE, velD, sAcc, headAcc and pDOP are only valid if
this flag is set.

extraOdo

Store odometer data
The fields distance, totalDistance and distanceStd are only valid if this flag is set.
Note: the odometer feature itself must also be enabled.

Bitfield valid
This graphic explains the bits of valid

Name

Description

validDatevalidTime

1 = valid UTC Date (seeTime Validity section for details)
1 = valid UTC Time of Day (seeTime Validity section for details)

Bitfield flags
This graphic explains the bits of flags

UBX-13003221 - R17

Early Production Information

Page 258 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

gnssFixOK
diffSoln
psmState

1 = valid fix (i.e within DOP & accuracy masks)
1 = differential corrections were appliedPower Save Mode state (see Power Management):
0: PSM is not active
1: Enabled (an intermediate state before Acquisition state
2: Acquisition
3: Tracking
4: Power Optimized Tracking
5: Inactive

32.14.2 UBX-LOG-CREATE (0x21 0x07)
32.14.2.1 Create Log File
Message

UBX-LOG-CREATE

Description

Create Log File

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

This message is used to create an initial logging file and activate the logging
subsystem.
UBX-ACK-ACK or UBX-ACK-NAK are returned to indicate success or failure.
This message does not handle activation of recording or filtering of log entries(see UBX-CFG-LOGFILTER).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x07 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

The version of this message. Set to 0
Config flags (see graphic below)
Reserved
Indicates the size of the log:
0 (maximum safe size): Ensures thatlogging will not be interrupted and enoughspace will be left available for all otheruses of the filestore
1 (minimum size):
2 (user defined): See 'userDefinedSize'
below
Sets the maximum amount of space in thefilestore that can be used by the logging
task.
This field is only applicable if logSize is set
to user defined.

Format

0
1
2
3

U1
X1
U1
U1

-

versionlogCfgreserved1
logSize4

U4-

userDefinedSi bytesze

UBX-13003221 - R17

Early Production Information

Page 259 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield logCfg
This graphic explains the bits of logCfg

Name

Description

circularLog is circular (new entries overwrite old ones in a full log) if this bit set

32.14.3 UBX-LOG-ERASE (0x21 0x03)
32.14.3.1 Erase Logged Data
Message

UBX-LOG-ERASE

Description

Erase Logged Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

This message deactivates the logging system and erases all logged data.
UBX-ACK-ACK or UBX-ACK-NAK are returned to indicate success or failure.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x21 0x03 0

PayloadChecksumsee below CK_A CK_B

No payload

32.14.4 UBX-LOG-FINDTIME (0x21 0x0E)
32.14.4.1 Find index of a log entry based on a given time
Message

UBX-LOG-FINDTIME

Description

Find index of a log entry based on a given timeFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message can be used for a time-based search of a log. It can find the index
of the first log entry with time equal to the given time, otherwise the index of themost recent entry with time less than the given time. This index can then be
used with the UBX-LOG-RETRIEVE message to provide time-based retrieval oflog entries.
Searching a log is effective for a given time later than the base date (January
1st, 2004). Searching a log for a given time earlier than the base date will resultin an 'entry not found' response. (Searching a log for a given time earlier than thebase date will result in a UBX-ACK-NAK message in protocol versions less than18)
Searching a log for a given time greater than the last recorded entry's time will
return the index of the last recorded entry. (If the logging has stopped due tolack of file space, such a search will result in a UBX-ACK-NAK message in

UBX-13003221 - R17

Early Production Information

Page 260 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

protocol versions less than 18)
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x0E 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versiontype
reserved1
year
month
day
hour
minutesecondreserved2-

Message version (=0 for this version)
Message type, 0 for request
Reserved
Year (1-65635) of UTC timeMonth (1-12) of UTC time
Day (1-31) of UTC time
Hour (0-23) of UTC time
Minute (0-59) of UTC time
Second (0-60) of UTC time
Reserved

Format

0
1
2
4
6
7
8
9
10
11

U1
U1
U1[2]
U2
U1
U1
U1
U1
U1
U1

32.14.4.2 Response to FINDTIME request
Message

UBX-LOG-FINDTIME

Description

Response to FINDTIME request

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x0E 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versiontype
reserved1
entryNumber-

Message version (=1 for this version)
Message type, 1 for response
Reserved
Index of the first log entry with time =given time, otherwise index of the mostrecent entry with time < given time. If
0xFFFFFFFF, no log entry found with time<= given time. The indexing of log entries
is zero based.

Format

0
1
2
4

U1
U1
U1[2]
U4

UBX-13003221 - R17

Early Production Information

Page 261 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.14.5 UBX-LOG-INFO (0x21 0x08)
32.14.5.1 Poll for log information
Message

UBX-LOG-INFO

Description

Poll for log information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Upon sending of this message, the receiver returns UBX-LOG-INFO as defined
below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x08 0

Checksumsee below CK_A CK_B

No payload

32.14.5.2 Log information
Message

UBX-LOG-INFO

Description

Log information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message is used to report information about the logging subsystem.
Note:• The reported maximum log size will be smaller than that originally specified in
LOG-CREATE due to logging and filestore implementation overheads.
• Log entries are compressed in a variable length fashion, so it may be difficult
to predict log space usage with any precision.
• There may be times when the receiver does not have an accurate time (e.g. if
the week number is not yet known), in which case some entries will not have atimestamp. This may result in the oldest/newest entry time values not taking
account of these entries.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x08 48

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

versionreserved1
filestoreCapa
city
reserved2
currentMaxLog
SizecurrentLogSiz
e

bytes

The version of this message. Set to 1
Reserved
The capacity of the filestore

bytes

Reserved
The maximum size the current log isallowed to grow to
Approximate amount of space in log
currently occupied

Format

0
1
4

U1
U1[3]
U4

-

8
16

U1[8]
U4

-

20

U4

-

UBX-13003221 - R17

bytes

Early Production Information

Page 262 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-LOG-INFO continued
Byte Offset

Number

Scaling

Name

Unit

Description

Number of entries in the log.
Note: for circular logs this value will
decrease when a group of entries isdeleted to make space for new ones.
Oldest entry UTC year (1-65635) or zero if
there are no entries with known time
Oldest month (1-12)
Oldest day (1-31)
Oldest hour (0-23)
Oldest minute (0-59)
Oldest second (0-60)
Reserved
Newest year (1-65635) or zero if there are
no entries with known time
Newest month (1-12)
Newest day (1-31)
Newest hour (0-23)
Newest minute (0-59)
Newest second (0-60)
Reserved
Log status flags (see graphic below)
Reserved

Format24

U4-

entryCount

-

28

U2

-

oldestYear

-

30
31
32
33
34
35
36

U1
U1
U1
U1
U1
U1
U2

-

oldestMontholdestDay
oldestHour
oldestMinute
oldestSecond
reserved3
newestYear

-

38
39
40
41
42
43
44
45

U1
U1
U1
U1
U1
U1
X1
U1[3]

-

newestMonthnewestDay
newestHour
newestMinutenewestSecond
reserved4
statusreserved5-

Bitfield status
This graphic explains the bits of status

Name

Description

recordinginactive
circularLog entry recording is currently turned on

UBX-13003221 - R17

Logging system not active - no log present
The current log is circular

Early Production Information

Page 263 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.14.6 UBX-LOG-RETRIEVEBATCH (0x21 0x10)
32.14.6.1 Request batch data
Message

UBX-LOG-RETRIEVEBATCH

Description

Request batch data

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 23.01

Type

CommandComment

This message is used to request batched data.
Batch entries are returned in chronological order, using one UBX-LOG-BATCH pernavigation epoch.
The speed of transfer can be maximized by using a high data rate.
See Data Batching for more information.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x10 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionflags
reserved1-

Message version (0x00 for this version)
Flags (see graphic below)
Reserved

Format

0
1
2

U1
X1
U1[2]

Bitfield flags
This graphic explains the bits of flags

Name

Description

sendMonFirst

Send UBX-MON-BATCH message before sending the UBX-LOG-BATCH message(s).

UBX-13003221 - R17

Early Production Information

Page 264 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.14.7 UBX-LOG-RETRIEVEPOSEXTRA (0x21 0x0f)
32.14.7.1 Odometer log entry
Message

UBX-LOG-RETRIEVEPOSEXTRA

Description

Odometer log entry

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message is used to report an odometer log entry
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x0f 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

The index of this log entry
The version of this message. Set to 0
Reserved
Year (1-65635) of UTC time. Will be zero iftime not known
Month (1-12) of UTC time
Day (1-31) of UTC time
Hour (0-23) of UTC time
Minute (0-59) of UTC time
Second (0-60) of UTC time
Reserved
Odometer distance traveled since the lasttime the odometer was reset by a UBXNAV-RESETODO
Reserved

Format

0
4
5
6

U4
U1
U1
U2

-

entryIndex
versionreserved1
year

-

8
9
10
11
12
13
16

U1
U1
U1
U1
U1
U1[3]
U4

-

month
day
hour
minutesecondreserved2
distance-20

U1[12] -reserved3-

32.14.8 UBX-LOG-RETRIEVEPOS (0x21 0x0b)
32.14.8.1 Position fix log entry
Message

UBX-LOG-RETRIEVEPOS

Description

Position fix log entry

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message is used to report a position fix log entry
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x0b 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

entryIndex-

The index of this log entry

Format0

U4

UBX-13003221 - R17

Early Production Information

Page 265 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-LOG-RETRIEVEPOS continued
Byte Offset

Number

Scaling

Name

Unit

Description

Longitude
Latitude
Height above mean sea level
Horizontal accuracy estimate
Ground speed (2-D)
Heading
The version of this message. Set to 0
Fix type:
0x01: Dead Reckoning only
0x02: 2D-Fix
0x03: 3D-Fix
0x04: GNSS + Dead Reckoning combined
Year (1-65635) of UTC timeMonth (1-12) of UTC time
Day (1-31) of UTC time
Hour (0-23) of UTC time
Minute (0-59) of UTC time
Second (0-60) of UTC time
Reserved
Number of satellites used in the position
fix
Reserved

Format

4
8
12
16
20
24
28
29

I4
I4
I4
U4
U4
U4
U1
U1

1e-7
1e-7
1e-5
-

lon
lat
hMSL
hAcc
gSpeedheading
versionfixType

deg
deg
mm
mm
mm/s
deg
-

30
32
33
34
35
36
37
38

U2
U1
U1
U1
U1
U1
U1
U1

-

year
month
day
hour
minutesecondreserved1
numSV

-

39

U1

-

reserved2-

32.14.9 UBX-LOG-RETRIEVESTRING (0x21 0x0d)
32.14.9.1 Byte string log entry
Message

UBX-LOG-RETRIEVESTRING

Description

Byte string log entry

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message is used to report a byte string log entry
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x0d 16 + 1*byteCount

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

The index of this log entry
The version of this message. Set to 0
Reserved
Year (1-65635) of UTC time. Will be zero iftime not known
Month (1-12) of UTC time

Format

0
4
5
6

U4
U1
U1
U2

-

entryIndex
versionreserved1
year

-

8

U1

-

month

-

UBX-13003221 - R17

Early Production Information

Page 266 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-LOG-RETRIEVESTRING continued
Byte Offset

Number

Scaling

Name

Unit

Description

-

day
hour
minutesecondreserved2
byteCount-

Day (1-31) of UTC time
Hour (0-23) of UTC time
Minute (0-59) of UTC time
Second (0-60) of UTC time
Reserved
Size of string in bytes-

The bytes of the string

Format

9
10
11
12
13
14

U1
U1
U1
U1
U1
U2

Start of repeated block (byteCount times)

16 + 1*N

U1

-

bytes

End of repeated block32.14.10 UBX-LOG-RETRIEVE (0x21 0x09)
32.14.10.1 Request log data
Message

UBX-LOG-RETRIEVE

Description

Request log data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

This message is used to request logged data (log recording must first be
disabled, see UBX-CFG-LOGFILTER).
Log entries are returned in chronological order, using the messages UBX-LOGRETRIEVEPOS and UBX-LOG-RETRIEVESTRING. If the odometer was enabled at
the time a position was logged, then message UBX-LOG-RETRIEVEPOSEXTRA will
also be used. The maximum number of entries that can be returned in response
to a single UBX-LOG-RETRIEVE message is 256. If more entries than this are
required the message will need to be sent multiple times with different
startNumbers. The retrieve will be stopped if any UBX-LOG message is received.
The speed of transfer can be maximized by using a high data rate andtemporarily stopping the GPS processing (see UBX-CFG-RST).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x09 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

startNumber-

Index of first log entry to be transferred. If
it is larger than the index of the lastavailable log entry, then the first log entry
to be transferred is the last available log
entry. The indexing of log entries is zero
based.

Format0

U4

UBX-13003221 - R17

Early Production Information

Page 267 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-LOG-RETRIEVE continued
Byte Offset

Number

Scaling

Name

Unit

Description

Number of log entries to transfer in total
including the first entry to be transferred.
If it is larger than the log entries available
starting from the first entry to betransferred, then only the available log
entries are transferred followed by a UBXACK-NAK. The maximum is 256.
The version of this message. Set to 0.
Reserved

Format4

U4-entryCount

-

8
9

U1
U1[3]

-

versionreserved1-

32.14.11 UBX-LOG-STRING (0x21 0x04)
32.14.11.1 Store arbitrary string in on-board flash
Message

UBX-LOG-STRING

Description

Store arbitrary string in on-board flash

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

This message can be used to store an arbitrary byte string in the on-board flash
memory. The maximum length that can be stored is 256 bytes.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x21 0x04 0 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

bytes

-

The string of bytes to be logged(maximum 256)

FormatStart of repeated block (N times)

N*1

U1

-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 268 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15 UBX-MGA (0x13)
Multiple GNSS Assistance Messages: i.e. Assistance data for various GNSS.
Messages in the MGA class are used for GNSS aiding information from and to the receiver.
32.15.1 UBX-MGA-ACK (0x13 0x60)
32.15.1.1 UBX-MGA-ACK-DATA0
Message

UBX-MGA-ACK-DATA0

Description

Multiple GNSS Acknowledge message

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message is sent by a u-blox receiver to acknowledge the receipt of anassistance message.
Acknowledgments are enabled by setting the ackAiding parameter in the UBXCFG-NAVX5 message.
See the description of flow control for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x60 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Type of acknowledgment:
0: The message was not used by thereceiver (see infoCode field for anindication of why)
1: The message was accepted for use by
the receiver (the infoCode field will be 0)
Message version (0x00 for this version)
Provides greater information on what thereceiver chose to do with the message
contents:
0: The receiver accepted the data
1: The receiver doesn't know the time so
can't use the data (To resolve this a UBXMGA-INI-TIME_UTC message should be
supplied first)
2: The message version is not supportedby the receiver
3: The message size does not match themessage version
4: The message data could not be stored
to the database
5: The receiver is not ready to use themessage data
6: The message type is unknown

Format

0

U1

-

type

-

1
2

U1
U1

-

versioninfoCode-

UBX-13003221 - R17

Early Production Information

Page 269 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-ACK continued
Byte Offset

Number

Scaling

Name

Unit

-

msgId
msgPayloadSta rt

Description

Format

3
4

U1
U1[4]

UBX message ID of the ack'ed message
The first 4 bytes of the ack'ed message's
payload32.15.2 UBX-MGA-ANO (0x13 0x20)
32.15.2.1 Multiple GNSS AssistNow Offline Assistance
Message

UBX-MGA-ANO

Description

Multiple GNSS AssistNow Offline AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message is created by the AssistNow Offline service to deliver AssistNow
Offline assistance to the receiver. See the description of AssistNow Offline fordetails.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x20 76

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

typeversionsvId-

gnssId
year
month
day
reserved1
data
reserved2-

Message type (0x00 for this type)Message version (0x00 for this version)
Satellite identifier (see Satellite
Numbering)
GNSS identifier (see Satellite Numbering)years since the year 2000
month (1..12)
day (1..31)
Reservedassistance data
Reserved

Format

0
1
2

U1
U1
U1

3
4
5
6
7
8
72

U1
U1
U1
U1
U1
U1[64] U1[4] -UBX-13003221 - R17

Early Production Information

Page 270 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.3 UBX-MGA-BDS (0x13 0x03)
32.15.3.1 UBX-MGA-BDS-EPH
Message

UBX-MGA-BDS-EPH

Description

BDS Ephemeris AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of BeiDou ephemeris assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x03 88

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0
1
2

U1
U1
U1

-

type
version
svId

3
4
5
6
8
12
16
20
22
23
24
28
32
36

U1
U1
U1
I2
I4
I4
U4
I2
U1
U1
U4
U4
U4
I4

2^-66
2^-50
2^-33
2^3
0.1
2^3
2^-19
2^-33
2^-31

reserved1
SatH1
IODC
a2
a1
a0
toc
TGD1
URAI
IODE
toe
sqrtA
e
omega

40

I2

2^-43

Deltan

42

I2

2^-43

IDOT

44

I4

2^-31

M0

48

I4

2^-31

Omega0UBX-13003221 - R17

Message type (0x01 for this type)Message version (0x00 for this version)
BDS satellite identifier (see Satellite
Numbering)Reserved
Autonomous satellite Health flag
Issue of Data, Clocks/s^2 Time polynomial coefficient 2
s/sTime polynomial coefficient 1sTime polynomial coefficient 0s
Clock data reference timens
Equipment Group Delay Differential
User Range Accuracy Index
Issue of Data, Ephemeriss
Ephemeris reference timem^0.5 Square root of semi-major axis
Eccentricity
semi- Argument of perigee
circlessemi- Mean motion difference from computed
circles value/ssemi- Rate of inclination angle
circles/ssemi- Mean anomaly at reference time
circlessemi- Longitude of ascending node of orbital of
circles plane computed according to reference
time

Early Production Information

Page 271 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-BDS continued
Byte Offset

Number

Scaling

Name

Unit

Description

semicircles/ssemicircles
semicircles
semicirclesmRate of right ascension

Format

52

I4

2^-43

OmegaDot

56

I4

2^-31

i0

60

I4

2^-31

Cuc

64

I4

2^-31

Cus

68

I4

2^-6

Crc

72

I4

2^-6

Crs

76

I4

2^-31

Cic

80

I4

2^-31

Cis

84

U1[4]

-

reserved2

Inclination angle at reference time

Amplitude of cosine harmonic correction
term to the argument of latitude
Amplitude of sine harmonic correction
term to the argument of latitude
Amplitude of cosine harmonic correction
term to the orbit radiusm
Amplitude of sine harmonic correction
term to the orbit radiussemi- Amplitude of cosine harmonic correction
circles term to the angle of inclination
semi- Amplitude of sine harmonic correction
circles term to the angle of inclination
Reserved

32.15.3.2 UBX-MGA-BDS-ALM
Message

UBX-MGA-BDS-ALM

Description

BDS Almanac AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of BeiDou almanac assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x03 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0
1
2

U1
U1
U1

-

type
version
svId

3
4
5
6

U1
U1
U1
I2

2^12
2^-19

reserved1
Wna
toa
deltaI

8

U4

2^-11

sqrtA

UBX-13003221 - R17

Message type (0x02 for this version)
Message version (0x00 for this version)
BeiDou satellite identifier (see Satellite
Numbering)Reserved
week Almanac Week Numbers
Almanac reference timesemi- Almanac correction of orbit reference
circles inclination at reference timem^0.5 Almanac square root of semi-major axis

Early Production Information

Page 272 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-BDS continued
Byte Offset

Number

Scaling

Name

Unit

Description

semicircles
semicircles
semicircles

Almanac eccentricity
Almanac argument of perigee

Format

12
16

U4
I4

2^-21
2^-23

e
omega

20

I4

2^-23

M0

24

I4

2^-23

Omega0

28

I4

2^-38

omegaDot

32
34
36

I2
I2
U1[4]

2^-20
2^-38
-

a0
a1
reserved2

Almanac mean anomaly at reference time
Almanac longitude of ascending node oforbit plane at computed according toreference time
Almanac rate of right ascension

semicircles/ss
Almanac satellite clock biass/sAlmanac satellite clock rate
Reserved

32.15.3.3 UBX-MGA-BDS-HEALTH
Message

UBX-MGA-BDS-HEALTH

Description

BDS Health AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of BeiDou health assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x03 68

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x04 for this type)Message version (0x00 for this version)
Reserved
Each two-byte value represents a BDS SV(1-30). The 9 LSBs of each byte containthe 9 bit health code from subframe 5
pages 7,8 of the D1 message, and from
subframe 5 pages 35,36 of the D1
message.
Reserved

Format

0
1
2
4

U1
U1
U1[2] U2[30] -typeversionreserved1
healthCode

-

64

U1[4]

reserved2-

UBX-13003221 - R17-

Early Production Information

Page 273 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.3.4 UBX-MGA-BDS-UTC
Message

UBX-MGA-BDS-UTC

Description

BDS UTC AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of BeiDou UTC assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x03 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x05 for this type)Message version (0x00 for this version)
Reserved
BDT clock bias relative to UTC
BDT clock rate relative to UTC
Delta time due to leap seconds before the
new leap second effective
Reserved
BeiDou week number of reception of thisUTC parameter set (8 bit truncated)
Week number of the new leap second
Day number of the new leap second
Delta time due to leap seconds after the
new leap second effective
Reserved

Format

0
1
2
4
8
12

U1
U1
U1[2]
I4
I4
I1

2^-30
2^-50
-

type
versionreserved1
a0UTC
a1UTC
dtLS

s
s/s
s

13
14

U1[1]
U1

-

reserved2
wnRec

week

15
16
17

U1
U1
I1

-

wnLSF
dN
dtLSF

week
day
s

18

U1[2]

-

reserved3-

32.15.3.5 UBX-MGA-BDS-IONO
Message

UBX-MGA-BDS-IONO

Description

BDS Ionospheric AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of BeiDou ionospheric assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x03 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

type

-

Message type (0x06 for this type)

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 274 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-BDS continued
Byte Offset

Number

Scaling

Name

Unit

Description

2^-30
2^-27
2^-24
2^-24
2^11
2^14
2^16
2^16
-

versionreserved1
alpha0alpha1alpha2alpha3
beta0
beta1
beta2
beta3
reserved2ss/pi
s/pi^2s/pi^3ss/pi
s/pi^2s/pi^3-Message version (0x00 for this version)
Reserved
Ionospheric parameter alpha0
Ionospheric parameter alpha1
Ionospheric parameter alpha2
Ionospheric parameter alpha3
Ionospheric parameter beta0
Ionospheric parameter beta1
Ionospheric parameter beta2
Ionospheric parameter beta3
Reserved

Format

1
2
4
5
6
7
8
9
10
11
12

U1
U1[2]
I1
I1
I1
I1
I1
I1
I1
I1
U1[4]

32.15.4 UBX-MGA-DBD (0x13 0x80)
32.15.4.1 Poll the Navigation Database
Message

UBX-MGA-DBD

Description

Poll the Navigation Database

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Poll the whole navigation data base. The receiver will send all available data fromits internal database. The receiver will indicate the finish of the transmission
with a UBX-MGA-ACK. The msgPayloadStart field of the UBX-MGA-ACK message
will contain a U4 representing the number of UBX-MGA-DBD-DATA* messages
sent.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x13 0x80 0

PayloadChecksumsee below CK_A CK_B

No payload

32.15.4.2 Navigation Database Dump Entry
Message

UBX-MGA-DBD

Description

Navigation Database Dump Entry

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input/Output

Comment

UBX-MGA-DBD messages are only intended to be sent back to the same
receiver that generated them.
Navigation database entry. The data fields are firmware specific. Transmissionof this type of message will be acknowledged by UBX-MGA-ACK messages, if
acknowledgment has been enabled.
See the description of flow control for details.
The maximum payload size for firmware 2.01 onwards is 164 bytes (which makes

UBX-13003221 - R17

Early Production Information

Page 275 of 407

u-blox 8 / u-blox M8 Receiver Description - Manualthe maximum message size 172 bytes).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x80 12 + 1*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

reserved1-

Reserveddata-

fw specific data

Format0

U1[12] -Start of repeated block (N times)

12 + 1*NU1-End of repeated block32.15.5 UBX-MGA-FLASH (0x13 0x21)
32.15.5.1 UBX-MGA-FLASH-DATA
Message

UBX-MGA-FLASH-DATA

Description

Transfer MGA-ANO data block to flash

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message is used to transfer a block of MGA-ANO data from host to thereceiver. Upon reception of this message, the receiver will write the payload data
to its internal non-volatile memory (flash). Also, on reception of the first MGAFLASH-DATA message, the receiver will erase the flash allocated to storing any
existing MGA-ANO data. The payload can be up to 512 bytes. Payloads larger
than this would exceed the receiver's internal buffering capabilities. The receiverwill ACK/NACK this message using the message alternatives given below. The
host shall wait for an acknowledge message before sending the next data block.
See Flash-based AssistNow Offline for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x21 6 + 1*size

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0
1
2

U1
U1
U2

-

type
versionsequence

-

4

U2

-

size

-

Message type (0x01 for this type)Message version (0x00 for this version)
Message sequence number, starting at 0
and increamenting by 1 for each MGAFLASH-DATA message sent.
Payload size in bytes.

data

-

Payload data.

Start of repeated block (size times)

6 + 1*NU1-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 276 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.5.2 UBX-MGA-FLASH-STOP
Message

UBX-MGA-FLASH-STOP

Description

Finish flashing MGA-ANO data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message is used to tell the receiver that there are no more MGA-FLASH
type 1 messages coming, and that it can do any final internal operations needed
to commit the data to flash as a background activity. A UBX-MGA-ACK message
will be sent at the end of this process. Note that there may be a delay of several
seconds before the UBX-MGA-ACK for this message is sent because of the time
taken for this processing. See Flash-based AssistNow Offline for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x21 2

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

typeversion-Message type (0x02 for this type)Message version (0x00 for this version)

Format0
1

U1
U1

32.15.5.3 UBX-MGA-FLASH-ACK
Message

UBX-MGA-FLASH-ACK

Description

Acknowledge last FLASH-DATA or -STOP

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

This message reports an ACK/NACK to the host for the last MGA-FLASH type 1
or type 2 message message received. See Flash-based AssistNow Offline fordetails.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x21 6

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

typeversionack-

Message type (0x03 for this type)Message version (0x00 for this version)
Acknowledgment type. 0 - ACK: Message
received and written to flash. 1 - NACK:
Problem with last message, retransmission required (this only happens
while acknowledging a UBX-MGA_FLASH_DATA message). 2 - NACK: problem withlast message, give up.

Format

0
1
2

U1
U1
U1

UBX-13003221 - R17

Early Production Information

Page 277 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-FLASH continued
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved1
sequence-

Reserved
If acknowledging a UBX-MGA-FLASHDATA message this is the Message
sequence number being ack'ed. If
acknowledging a UBX-MGA-FLASH-STOP
message it will be set to 0xffff.

Format3
4U1
U2

32.15.6 UBX-MGA-GAL (0x13 0x02)
32.15.6.1 UBX-MGA-GAL-EPH
Message

UBX-MGA-GAL-EPH

Description

Galileo Ephemeris AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of Galileo ephemeris assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x02 76

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0
1
2

U1
U1
U1

-

type
version
svId

3
4

U1
U2

-

reserved1
iodNav

6

I2

2^-43

deltaN

8

I4

2^-31

m0

12
16
20

U4
U4
I4

2^-33
2^-19
2^-31

e
sqrtA
omega0

24

I4

2^-31

i0

28

I4

2^-31

omega

UBX-13003221 - R17

Message type (0x01 for this type)Message version (0x00 for this version)
Galileo Satellite identifier (see Satellite
Numbering)Reserved
Ephemeris and clock correction Issue ofDatasemi- Mean motion difference from computed
circles value/ssemi- Mean anomaly at reference time
circles
Eccentricitym^0.5 Square root of the semi-major axis
semi- Longitude of ascending node of orbital
circles plane at weekly epochsemi- Inclination angle at reference time
circlessemi- Argument of perigee
circles

Early Production Information

Page 278 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GAL continued
Byte Offset

Number

Scaling

Name

Unit

Description

semicircles/ssemicircles/sradians

Rate of change of right ascension

Format

32

I4

2^-43

omegaDot

36

I2

2^-43

iDot

38

I2

2^-29

cuc

40

I2

2^-29

cus

42

I2

2^-5

44

I2

2^-5

46

I2

2^-29

48

I2

2^-29

50
52
56
60

U2
I4
I4
I1

60
2^-34
2^-46
2^-59

61

U1

-

62

U2

60

64
66
68
69

I2
U1[2]
U1
U1

-

70
71

U1
U1

-

72

U1[4]

-

UBX-13003221 - R17

Rate of change of inclination angle

Amplitude of the cosine harmoniccorrection term to the argument oflatitude
Amplitude of the sine harmonic correction
term to the argument of latitude
Amplitude of the cosine harmoniccorrection term to the orbit radius
Amplitude of the sine harmonic correction
term to the orbit radius
Amplitude of the cosine harmoniccorrection term to the angle of inclination
Amplitude of the sine harmonic correction
term to the angle of inclination
Ephemeris reference time
SV clock bias correction coefficient
SV clock drift correction coefficient
SV clock drift rate correction coefficientradians
crc
radians
crs
radians
cic
radianscisradian
s
toe
s
af0
s
af1
s/s
af2
s/s
squaredsisaIndexE1E5 Signal-In-Space Accuracy index for dualbfrequency E1-E5b
tocs
Clock correction data reference Time ofWeek
bgdE1E5b
E1-E5b Broadcast Group Delay
reserved2
Reserved
healthE1B
E1-B Signal Health Status
dataValidityE E1-B Data Validity Status
1B
healthE5b
E5b Signal Health Status
dataValidityE E5b Data Validity Status5breserved3
Reserved

Early Production Information

Page 279 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.6.2 UBX-MGA-GAL-ALM
Message

UBX-MGA-GAL-ALM

Description

Galileo Almanac AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of Galileo almanac assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x02 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format

0
1
2

U1
U1
U1

-

type
version
svId

3
4
5
6
8

U1
U1
U1
U2
I2

600
2^-9

reserved1
ioda
almWNatoa
deltaSqrtA

10
12

U2
I2

2^-16
2^-14

e
deltaI

14

I2

2^-15

omega0

16

I2

2^-33

omegaDot

18

I2

2^-15

omega

20

I2

2^-15

m0

22
24
26
27
28

I2
I2
U1
U1
U1[4]

2^-19
2^-38
-

af0
af1
healthE1B
healthE5b
reserved2

UBX-13003221 - R17

Message type (0x02 for this type)Message version (0x00 for this version)
Galileo Satellite identifier (see Satellite
Numbering)Reserved
Almanac Issue of Data
week Almanac reference week numbers
Almanac reference timem^0.5 Difference with respect to the square rootof the nominal semi-major axis (29 600
km)
Eccentricity
semi- Inclination at reference time relative to i0
circles = 56 degreesemi- Longitude of ascending node of orbital
circles plane at weekly epochsemi- Rate of change of right ascension
circles/ssemi- Argument of perigee
circlessemi- Satellite mean anomaly at reference time
circless
Satellite clock correction bias 'truncated's/s
Satellite clock correction linear 'truncated'
Satellite E1-B signal health status
Satellite E5b signal health status
Reserved

Early Production Information

Page 280 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.6.3 UBX-MGA-GAL-TIMEOFFSET
Message

UBX-MGA-GAL-TIMEOFFSET

Description

Galileo GPS time offset assistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of Galileo time to GPS time offset.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x02 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

s

Description

Format

0
1
2
4

U1
U1
U1[2]
I2

2^-35

type
versionreserved1
a0G

6
8
9
10

I2
U1
U1
U1[2]

2^-51
3600
-

a1G
t0G
wn0G
reserved2

Message type (0x03 for this type)Message version (0x00 for this version)
Reserved
Constant term of the polynomial
describing the offset
s/sRate of change of the offsets
DReference time for GGTO data
weeks Week Number of GGTO reference
Reserved

32.15.6.4 UBX-MGA-GAL-UTC
Message

UBX-MGA-GAL-UTC

Description

Galileo UTC AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of Galileo UTC assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x02 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

2^-30
2^-50
-

type
versionreserved1
a0
a1
dtLS

s
s/s
s

Message type (0x05 for this type)Message version (0x00 for this version)
Reserved
First parameter of UTC polynomial
Second parameter of UTC polynomial
Delta time due to current leap seconds

Format

0
1
2
4
8
12

U1
U1
U1[2]
I4
I4
I1

UBX-13003221 - R17

Early Production Information

Page 281 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GAL continued
Byte Offset

Number

Scaling

Name

Unit

s

Description

Format

13

U1

3600

tot

14

U1

-

wnt

15

U1

-

wnLSF

16

U1

-

dN

17
18

I1
U1[2]

-

dTLSF
reserved2

UTC parameters reference time of week
(Galileo time)
weeks UTC parameters reference week number(the 8 bit WNt field)
weeks Week number at the end of which the
future leap second becomes effective (the8 bit WNLSF field)days
Day number at the end of which the future
leap second becomes effectives
Delta time due to future leap seconds
Reserved

32.15.7 UBX-MGA-GLO (0x13 0x06)
32.15.7.1 UBX-MGA-GLO-EPH
Message

UBX-MGA-GLO-EPH

Description

GLONASS Ephemeris AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GLONASS ephemeris assistance to areceiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x06 48

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x01 for this type)Message version (0x00 for this version)
GLONASS Satellite identifier (see Satellite
Numbering)Reserved
User range accuracy
Health flag from string 2
Type of GLONASS satellite (1 indicates
GLONASS-M)
Carrier frequency number of navigation RF
signal, Range=(-7 .. 6), -128 for unknown
X component of the SV position in PZ-90.
02 coordinate System
Y component of the SV position in PZ-90.
02 coordinate System

Format

0
1
2

U1
U1
U1

-

type
version
svId

-

3
4
5
6

U1
U1
U1
U1

-

reserved1
FT
B
M

-

7

I1

-

H

-

8

I4

2^-11

x

km

12

I4

2^-11

y

km

UBX-13003221 - R17

Early Production Information

Page 282 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GLO continued
Byte Offset

Number

Scaling

Name

Unit

km

Description

Format

16

I4

2^-11

z

20

I4

2^-20

dx

24

I4

2^-20

dy

28

I4

2^-20

dz

32

I1

2^-30

ddx

33

I1

2^-30

ddy

34

I1

2^-30

ddz

35

U1

15

tb

36
38
39
40
44

I2
U1
I1
I4
U1[4]

2^-40
2^-30
2^-30
-

gamma
E
deltaTautau
reserved2

Z component of the SV position in PZ-90.
02 coordinate System
km/s
X component of the SV velocity in PZ-90.
02 coordinate System
km/s
Y component of the SV velocity in PZ-90.
02 coordinate System
km/s
Z component of the SV velocity in PZ-90.
02 coordinate System
km/s^ X component of the SV acceleration in PZ2
90.02 coordinate System
km/s^ Y component of the SV acceleration in PZ2
90.02 coordinate System
km/s^ Z component of the SV acceleration in PZ2
90.02 coordinate Systemminut Index of a time interval within current day
esaccording to UTC(SU)
Relative carrier frequency deviation
days
Ephemeris data age indicatorsTime difference between L2 and L1 bands
SV clock bias
Reserved

32.15.7.2 UBX-MGA-GLO-ALM
Message

UBX-MGA-GLO-ALM

Description

GLONASS Almanac AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GLONASS almanac assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x06 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x02 for this type)Message version (0x00 for this version)
GLONASS Satellite identifier (see Satellite
Numbering)Reserved

Format

0
1
2

U1
U1
U1

-

type
version
svId

-

3

U1

-

reserved1-

UBX-13003221 - R17

Early Production Information

Page 283 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GLO continued
Byte Offset

Number

Scaling

Name

Unit

days

Description

Format

4

U2

-

N

6

U1

-

M

7

U1

-

C

8
10
12

I2
U2
I4

2^-18
2^-20
2^-20

tau
epsilonlambda

16

I4

2^-20

deltaI

20
24

U4
I4

2^-5
2^-9

tLambdadeltaT

28

I1

2^-14

deltaDT

29

I1

-

H

30
32

I2
U1[4]

-

omega
reserved2

Reference calender day number ofalmanac within the four-year period (fromstring 5)
Type of GLONASS satellite (1 indicates
GLONASS-M)
Unhealthy flag at instant of almanac
upload (1 indicates operability of satellite)s
Coarse time correction to GLONASS time
Eccentricity
semi- Longitude of the first (within the N-day)circles ascending node of satellite orbit in PC-90.
02 coordinate systemsemi- Correction to the mean value of inclination
circlessTime of the first ascending node passage
s/orbit Correction to the mean value of Draconianalperiod
periods/orbit Rate of change of Draconian periodalperiod^2
Carrier frequency number of navigation RF
signal, Range=(-7 .. 6)
Argument of perigee
Reserved

32.15.7.3 UBX-MGA-GLO-TIMEOFFSET
Message

UBX-MGA-GLO-TIMEOFFSET

Description

GLONASS Auxiliary Time Offset AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of auxiliary GLONASS assistance (including the
GLONASS time offsets to other GNSS systems) to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x06 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

type

-

Message type (0x03 for this type)

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 284 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GLO continued
Byte Offset

Number

Scaling

Name

Unit

days

Description

Format

1
2

U1
U2

-

version
N

4
8

I4
I4

2^-27
2^-31

tauC
tauGps

12
14
16

I2
I2
U1[4]

2^-10
2^-16
-

B1
B2
reserved1

Message version (0x00 for this version)
Reference calendar day number within thefour-year period of almanac (from string 5)sTime scale correction to UTC(SU) times
Correction to GPS time relative to
GLONASS times
Coefficient to determine delta UT1
s/msd Rate of change of delta UT1Reserved

32.15.8 UBX-MGA-GPS (0x13 0x00)
32.15.8.1 UBX-MGA-GPS-EPH
Message

UBX-MGA-GPS-EPH

Description

GPS Ephemeris AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GPS ephemeris assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x00 68

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x01 for this type)Message version (0x00 for this version)
GPS Satellite identifier (see Satellite
Numbering)Reserved
Fit interval flag
URA index
SV healthGroup delay differential
IODC
Clock data reference time
Reserved
Time polynomial coefficient 2

Format

0
1
2

U1
U1
U1

-

type
version
svId

-

3
4
5
6
7
8
10
12
13

U1
U1
U1
U1
I1
U2
U2
U1
I1

2^-31
2^4
2^-55

reserved1
fitIntervaluraIndexsvHealth
tgd
iodc
toc
reserved2
af2

14
16
20

I2
I4
I2

2^-43
2^-31
2^-5

af1
af0
crs

s
s
s/s
squareds/sTime polynomial coefficient 1sTime polynomial coefficient 0m
Crs

UBX-13003221 - R17

Early Production Information

Page 285 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GPS continued
Byte Offset

Number

Scaling

Name

Unit

Description

semicircles/ssemicircles
radiansradiansm^0.5s
radians
semicircles
radiansmMean motion difference from computed
value

Format

22

I2

2^-43

deltaN

24

I4

2^-31

m0

28

I2

2^-29

cuc

30

I2

2^-29

cus

32
36
40
42

U4
U4
U2
I2

2^-33
2^-19
2^4
2^-29

e
sqrtA
toe
cic

44

I4

2^-31

omega0

48

I2

2^-29

cis

50

I2

2^-5

crc

52

I4

2^-31

i0

56

I4

2^-31

omega

60

I4

2^-43

omegaDot

64

I2

2^-43

idot

66

U1[2]

-

reserved3

UBX-13003221 - R17

semicircles
semicircles
semicircles/ssemicircles/s-Mean anomaly at reference time
Amplitude of cosine harmonic correction
term to argument of latitude
Amplitude of sine harmonic correction
term to argument of latitude
Eccentricity
Square root of the semi-major axis
Reference time of ephemeris
Amplitude of cos harmonic correction
term to angle of inclination
Longitude of ascending node of orbit
plane at weekly epoch
Amplitude of sine harmonic correction
term to angle of inclination
Amplitude of cosine harmonic correction
term to orbit radius
Inclination angle at reference time
Argument of perigee
Rate of right ascension

Rate of inclination angle

Reserved

Early Production Information

Page 286 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.8.2 UBX-MGA-GPS-ALM
Message

UBX-MGA-GPS-ALM

Description

GPS Almanac AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GPS almanac assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x00 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x02 for this type)Message version (0x00 for this version)
GPS Satellite identifier (see Satellite
Numbering)
SV health information
Eccentricity
Reference week number of almanac (the 8
bit WNa field)
Reference time of almanac
Delta inclination angle at reference time

Format

0
1
2

U1
U1
U1

-

type
version
svId

-

3
4
6

U1
U2
U1

2^-21
-

svHealthe
almWNa

week

7
8

U1
I2

2^12
2^-19

toa
deltaI

10

I2

2^-38

omegaDot

12
16

U4
I4

2^-11
2^-23

sqrtA
omega0

20

I4

2^-23

omega

24

I4

2^-23

m0

28
30
32

I2
I2
U1[4]

2^-20
2^-38
-

af0
af1
reserved1ssemicircles
semicircles/sm^0.5
semicircles
semicircles
semicirclesss/s-

UBX-13003221 - R17

Rate of right ascension

Square root of the semi-major axis
Longitude of ascending node of orbit
plane
Argument of perigee
Mean anomaly at reference time
Time polynomial coefficient 0 (8 MSBs)
Time polynomial coefficient 1
Reserved

Early Production Information

Page 287 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.8.3 UBX-MGA-GPS-HEALTH
Message

UBX-MGA-GPS-HEALTH

Description

GPS Health AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GPS health assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x00 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x04 for this type)Message version (0x00 for this version)
Reserved
Each byte represents a GPS SV (1-32). The
6 LSBs of each byte contains the 6 bit
health code from subframes 4/5 page 25.
Reserved

Format

0
1
2
4

U1
U1
U1[2] U1[32] -typeversionreserved1
healthCode

-

36

U1[4]

reserved2--

32.15.8.4 UBX-MGA-GPS-UTC
Message

UBX-MGA-GPS-UTC

Description

GPS UTC AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GPS UTC assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x00 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

2^-30
2^-50
2^12

type
versionreserved1
utcA0
utcA1
utcDtLS
utcTotss/sssMessage type (0x05 for this type)Message version (0x00 for this version)
Reserved
First parameter of UTC polynomial
Second parameter of UTC polynomial
Delta time due to current leap seconds
UTC parameters reference time of week
(GPS time)

Format

0
1
2
4
8
12
13

U1
U1
U1[2]
I4
I4
I1
U1

UBX-13003221 - R17

Early Production Information

Page 288 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GPS continued
Byte Offset

Number

Scaling

Name

Unit

Description

weeks UTC parameters reference week number(the 8 bit WNt field)
weeks Week number at the end of which the
future leap second becomes effective (the8 bit WNLSF field)days
Day number at the end of which the future
leap second becomes effectives
Delta time due to future leap seconds
Reserved

Format14

U1-

utcWNt15

U1-

utcWNlsf

16

U1

-

utcDn

17
18

I1
U1[2]

-

utcDtLSF
reserved2

32.15.8.5 UBX-MGA-GPS-IONO
Message

UBX-MGA-GPS-IONO

Description

GPS Ionosphere AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of GPS ionospheric assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x00 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x06 for this type)Message version (0x00 for this version)
Reserveds
Ionospheric parameter alpha0 [s]s/semi- Ionospheric parameter alpha1 [s/semicircle circle]s/(sem Ionospheric parameter alpha2 [s/semiicircle^2]circle^2)s/(sem Ionospheric parameter alpha3 [s/semiicircle^3]
circle^3)s
Ionospheric parameter beta0 [s]s/semi- Ionospheric parameter beta1 [s/semicircle circle]

Format

0
1
2
4
5

U1
U1
U1[2]
I1
I1

2^-30
2^-27

type
versionreserved1
ionoAlpha0
ionoAlpha1

6

I1

2^-24

ionoAlpha2

7

I1

2^-24

ionoAlpha3

8
9

I1
I1

2^11
2^14

ionoBeta0
ionoBeta1

UBX-13003221 - R17

Early Production Information

Page 289 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-GPS continued
Byte Offset

Number

Scaling

Name

Unit

Descriptions/(sem Ionospheric parameter beta2 [s/semiicircle^2]circle^2)s/(sem Ionospheric parameter beta3 [s/semiicircle^3]
circle^3)
Reserved

Format

10

I1

2^16

ionoBeta2

11

I1

2^16

ionoBeta3

12

U1[4]

-

reserved2

32.15.9 UBX-MGA-INI (0x13 0x40)
32.15.9.1 UBX-MGA-INI-POS_XYZ
Message

UBX-MGA-INI-POS_XYZ

Description

Initial Position AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying position assistance that is inaccurate by more than the specified
position accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of initial position assistance to a receiver incartesian ECEF coordinates. This message is equivalent to the UBX-MGA-INIPOS_LLH message, except for the coordinate system.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

typeversionreserved1
ecefX
ecefY
ecefZ
posAcc

cm
cm
cm
cm

Message type (0x00 for this type)Message version (0x00 for this version)
Reserved
WGS84 ECEF X coordinate
WGS84 ECEF Y coordinate
WGS84 ECEF Z coordinate
Position accuracy (stddev)

Format

0
1
2
4
8
12
16

U1
U1
U1[2]
I4
I4
I4
U4

UBX-13003221 - R17

Early Production Information

Page 290 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.9.2 UBX-MGA-INI-POS_LLH
Message

UBX-MGA-INI-POS_LLH

Description

Initial Position AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying position assistance that is inaccurate by more than the specified
position accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of initial position assistance to a receiver in
WGS84 lat/long/alt coordinates. This message is equivalent to the UBX-MGAINI-POS_XYZ message, except for the coordinate system.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

1e-7
1e-7
-

type
versionreserved1
lat
lon
alt
posAcc

deg
deg
cm
cm

Message type (0x01 for this type)Message version (0x00 for this version)
Reserved
WGS84 Latitude
WGS84 Longitude
WGS84 Altitude
Position accuracy (stddev)

Format

0
1
2
4
8
12
16

U1
U1
U1[2]
I4
I4
I4
U4

32.15.9.3 UBX-MGA-INI-TIME_UTC
Message

UBX-MGA-INI-TIME_UTC

Description

Initial Time AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying time assistance that is inaccurate by more than the specified time
accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of UTC time assistance to a receiver. Thismessage is equivalent to the UBX-MGA-INI-TIME_GNSS message, except for thetime base.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 24

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

type

-

Message type (0x10 for this type)

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 291 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-INI continued
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reference to be used to set time (seegraphic below)
Number of leap seconds since 1980 (or0x80 = -128 if unknown)
Year
Month, starting at 1
Day, starting at 1
Hour, from 0 to 23
Minute, from 0 to 59
Seconds, from 0 to 59
Reserved
Nanoseconds, from 0 to 999,999,999
Seconds part of time accuracy
Reserved
Nanoseconds part of time accuracy, from0 to 999,999,999

Format

1
2

U1
X1

-

version
ref

-

3

I1

-

leapSecs

s

4
6
7
8
9
10
11
12
16
18
20

U2
U1
U1
U1
U1
U1
U1
U4
U2
U1[2]
U4

-

year
month
day
hour
minutesecondreserved1
ns
tAccS
reserved2
tAccNssns
sns

Bitfield ref
This graphic explains the bits of ref

Name

Description

source0: none, i.e. on receipt of message (will be inaccurate!)
1: relative to pulse sent to EXTINT0
2: relative to pulse sent to EXTINT1
3-15: reserved

fall
last

UBX-13003221 - R17

use falling edge of EXTINT pulse (default rising) - only if source is EXTINT
use last EXTINT pulse (default next pulse) - only if source is EXTINT

Early Production Information

Page 292 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.9.4 UBX-MGA-INI-TIME_GNSS
Message

UBX-MGA-INI-TIME_GNSS

Description

Initial Time AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying time assistance that is inaccurate by more than the specified time
accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of time assistance to a receiver in a chosen
GNSS timebase. This message is equivalent to the UBX-MGA-INI-TIME_UTC
message, except for the time base.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 24

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x11 for this type)Message version (0x00 for this version)
Reference to be used to set time (seegraphic below)
Source of time information. Currently
supported:
0: GPS time
2: Galileo time
3: BeiDou time
6: GLONASS time: week = 834 + ((N41)*1461 + Nt)/7, tow = (((N4-1)*1461 + Nt) %7) * 86400 + tod
Reserved
GNSS week number
GNSS time of week
GNSS time of week, nanosecond part from0 to 999,999,999
Seconds part of time accuracy
Reserved
Nanoseconds part of time accuracy, from0 to 999,999,999

Format

0
1
2

U1
U1
X1

-

type
version
ref

-

3

U1

-

gnssId

-

4
6
8
12

U1[2]
U2
U4
U4

-

reserved1
week
tow
ns

s
ns

16
18
20

U2
U1[2]
U4

-

tAccS
reserved2
tAccNssns

UBX-13003221 - R17

Early Production Information

Page 293 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield ref
This graphic explains the bits of ref

Name

Description

source0: none, i.e. on receipt of message (will be inaccurate!)
1: relative to pulse sent to EXTINT0
2: relative to pulse sent to EXTINT1
3-15: reserved
use falling edge of EXTINT pulse (default rising) - only if source is EXTINT

fall
last

use last EXTINT pulse (default next pulse) - only if source is EXTINT

32.15.9.5 UBX-MGA-INI-CLKD
Message

UBX-MGA-INI-CLKD

Description

Initial Clock Drift AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying clock drift assistance that is inaccurate by more than the specified
accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of clock drift assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

typeversionreserved1
clkD
clkDAccns/s
ns/s

Message type (0x20 for this type)Message version (0x00 for this version)
Reserved
Clock drift
Clock drift accuracy

Format

0
1
2
4
8

U1
U1
U1[2]
I4
U4

UBX-13003221 - R17

Early Production Information

Page 294 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.9.6 UBX-MGA-INI-FREQ
Message

UBX-MGA-INI-FREQ

Description

Initial Frequency AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

Supplying external frequency assistance that is inaccurate by more than thespecified accuracy, may lead to substantially degraded receiver performance.
This message allows the delivery of external frequency assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

1e-2
-

type
versionreserved1
flags
freq
freqAccHz
ppb

Message type (0x21 for this type)Message version (0x00 for this version)
Reserved
Frequency reference (see graphic below)
Frequency
Frequency accuracy

Format

0
1
2
3
4
8

U1
U1
U1
X1
I4
U4

Bitfield flags
This graphic explains the bits of flags

Name

Description

source0: frequency available on EXTINT0
1: frequency available on EXTINT1
2-15: reserved

fall

UBX-13003221 - R17

use falling edge of EXTINT pulse (default rising)

Early Production Information

Page 295 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.15.9.7 UBX-MGA-INI-EOP
Message

UBX-MGA-INI-EOP

Description

Earth Orientation Parameters AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of new Earth Orientation Parameters (EOP) toa receiver to improve AssistNow Autonomous operation.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x40 72

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

d

Description

Format

0
1
2
4

U1
U1
U1[2]
U2

-

type
versionreserved1
d2kRef

6

U2-

d2kMax

8
12

I4
I4

2^-30
2^-30

xpP0
xpP1

16
20

I4
I4

2^-30
2^-30

ypP0
ypP1

24
28
32

I4
2^-25
I4
2^-30
U1[40] -

dUT1
ddUT1
reserved2

Message type (0x30 for this type)Message version (0x00 for this version)
Reservedreference time (days since 1.1.2000 12.00h
UTC)dexpiration time (days since 1.1.2000 12.00hUTC)arcsec x_p t^0 polynomial term (offset)
arcsec x_p t^1 polynomial term (drift)/darcsec y_p t^0 polynomial term (offset)
arcsec y_p t^1 polynomial term (drift)/dsdUT1 t^0 polynomial term (offset)
s/ddUT1 t^1 polynomial term (drift)
Reserved

32.15.10 UBX-MGA-QZSS (0x13 0x05)
32.15.10.1 UBX-MGA-QZSS-EPH
Message

UBX-MGA-QZSS-EPH

Description

QZSS Ephemeris AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of QZSS ephemeris assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x13 0x05 68

PayloadChecksumsee below CK_A CK_B

Payload Contents:

UBX-13003221 - R17

Early Production Information

Page 296 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-QZSS continued
Byte Offset

Number

Scaling

Name

Unit

Description

Scaling

Name

Unit

Description

Message type (0x01 for this type)Message version (0x00 for this version)
QZSS Satellite identifier (see Satellite
Numbering), Range 1-5
Reserved
Fit interval flag
URA index
SV healthGroup delay differential
IODC
Clock data reference time
Reserved
Time polynomial coefficient 2

FormatByte Offset

NumberFormat

0
1
2

U1
U1
U1

-

type
version
svId

-

3
4
5
6
7
8
10
12
13

U1
U1
U1
U1
I1
U2
U2
U1
I1

2^-31
2^4
2^-55

reserved1
fitIntervaluraIndexsvHealth
tgd
iodc
toc
reserved2
af2

14
16
20
22

I2
I4
I2
I2

2^-43
2^-31
2^-5
2^-43

af1
af0
crs
deltaN

24

I4

2^-31

m0

28

I2

2^-29

cuc

30

I2

2^-29

cus

32
36
40
42

U4
U4
U2
I2

2^-33
2^-19
2^4
2^-29

e
sqrtA
toe
cic

44

I4

2^-31

omega0

48

I2

2^-29

cis

50

I2

2^-5

crc

52

I4

2^-31

i0

56

I4

2^-31

omega

s
s
s/s
squareds/sTime polynomial coefficient 1sTime polynomial coefficient 0m
Crs
semi- Mean motion difference from computed
circles value/ssemi- Mean anomaly at reference time
circlesradian Amp of cosine harmonic corr term to argsof latradian Amp of sine harmonic corr term to arg ofslat
eccentricitym^0.5 Square root of the semi-major axis AsReference time of ephemeris
radian Amp of cos harmonic corr term to angle ofs
inclination
semi- Long of asc node of orbit plane at weekly
circles epoch
radian Amp of sine harmonic corr term to anglesof inclinationm
Amp of cosine harmonic corr term to orbit
radiussemi- Inclination angle at reference time
circlessemi- Argument of perigee
circles

UBX-13003221 - R17

Early Production Information

Page 297 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-QZSS continued
Byte Offset

Number

Scaling

Name

Unit

Description

semi- Rate of right ascension
circles/ssemi- Rate of inclination angle
circles/s
Reserved

Format

60

I4

2^-43

omegaDot

64

I2

2^-43

idot

66

U1[2]

-

reserved3

32.15.10.2 UBX-MGA-QZSS-ALM
Message

UBX-MGA-QZSS-ALM

Description

QZSS Almanac AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of QZSS almanac assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x05 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x02 for this type)Message version (0x00 for this version)
QZSS Satellite identifier (see Satellite
Numbering), Range 1-5
Almanac SV health information
Almanac eccentricity
Reference week number of almanac (the 8
bit WNa field)
Reference time of almanac
Delta inclination angle at reference time

Format

0
1
2

U1
U1
U1

-

type
version
svId

-

3
4
6

U1
U2
U1

2^-21
-

svHealthe
almWNa

week

7
8

U1
I2

2^12
2^-19

toa
deltaI

10

I2

2^-38

omegaDot

12

U4

2^-11

sqrtA

16

I4

2^-23

omega0

20

I4

2^-23

omega

s
semicircles
semi- Almanac rate of right ascension
circles/sm^0.5 Almanac square root of the semi-major
axis Asemi- Almanac long of asc node of orbit plane atcircles weekly
semi- Almanac argument of perigee
circles

UBX-13003221 - R17

Early Production Information

Page 298 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-MGA-QZSS continued
Byte Offset

Number

Scaling

Name

Unit

Description

semi- Almanac mean anomaly at reference time
circless
Almanac time polynomial coefficient 0 (8
MSBs)
s/s
Almanac time polynomial coefficient 1
Reserved

Format

24

I4

2^-23

m0

28

I2

2^-20

af0

30
32

I2
U1[4]

2^-38
-

af1
reserved1

32.15.10.3 UBX-MGA-QZSS-HEALTH
Message

UBX-MGA-QZSS-HEALTH

Description

QZSS Health AssistanceFirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Input

Comment

This message allows the delivery of QZSS health assistance to a receiver.
See the description of AssistNow Online for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x13 0x05 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (0x04 for this type)Message version (0x00 for this version)
Reserved
Each byte represents a QZSS SV (1-5). The
6 LSBs of each byte contains the 6 bit
health code from subframes 4/5, data ID =3, SV ID = 51
Reserved

Format

0
1
2
4

U1
U1
U1[2]
U1[5]

-

type
versionreserved1
healthCode

-

9

U1[3]

-

reserved2-

UBX-13003221 - R17

Early Production Information

Page 299 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16 UBX-MON (0x0A)
Monitoring Messages: i.e. Communication Status, CPU Load, Stack Usage, Task Status.
Messages in the MON class are used to report the receiver status, such as CPU load, stack usage,
I/O subsystem statistics etc.
32.16.1 UBX-MON-BATCH (0x0A 0x32)
32.16.1.1 Data batching buffer status
Message

UBX-MON-BATCH

Description

Data batching buffer status

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 23.01

Type

PolledComment

This message contains status information about the batching buffer.
It can be polled and it can also be sent by the receiver as a response to a UBXLOG-RETRIEVEBATCH message before the UBX-LOG-BATCH messages.
See Data Batching for more information.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x32 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reserved
Current buffer fill level, i.e. number of
epochs currently stored
Number of dropped epochs since startup
Note: changing the batching configuration
will reset this counter.
Number of dropped epochs since last
MON-BATCH message
The next retrieved UBX-LOG-BATCH will
have this msgCnt value.

Format

0
1
4

U1
U1[3]
U2

-

versionreserved1
fillLevel

-

6

U2

-

dropsAll

-

8

U2

-

dropsSinceMon -

10

U2

-

nextMsgCnt

UBX-13003221 - R17-

Early Production Information

Page 300 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.2 UBX-MON-GNSS (0x0A 0x28)
32.16.2.1 Information message major GNSS selection
Message

UBX-MON-GNSS

Description

Information message major GNSS selection

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

PolledComment

This message reports major GNSS selection. It does this by means of bit masks
in U1 fields. Each bit in a bit mask corresponds to one major GNSS.
Augmentation systems are not reported.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x28 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x01for this version)
A bit mask showing the major GNSS thatcan be supported by this receiver (seegraphic below)
A bit mask showing the default major
GNSS selection. If the default major GNSS
selection is currently configured in theefuse for this receiver, it takes precedence
over the default major GNSS selection
configured in the executing firmware ofthis receiver. (see graphic below)
A bit mask showing the current major
GNSS selection enabled for this receiver(see graphic below)
Maximum number of concurrent major
GNSS that can be supported by thisreceiver
Reserved

Format

0
1

U1
X1

-

versionsupported

-

2

X1

-

defaultGnss

-

3

X1

-

enabled

-

4

U1

-

simultaneous

-

5

U1[3]

-

reserved1-

Bitfield supported
This graphic explains the bits of supported

UBX-13003221 - R17

Early Production Information

Page 301 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

GPSSupGlonassSup
BeidouSup
GalileoSup

GPS is supported
GLONASS is supported
BeiDou is supported
Galileo is supported

Bitfield defaultGnss
This graphic explains the bits of defaultGnss

Name

Description

GPSDefGlonassDef
BeidouDef
GalileoDef

GPS is default-enabled
GLONASS is default-enabled
BeiDou is default-enabled
Galileo is default-enabled

Bitfield enabledThis graphic explains the bits of enabled

Name

Description

GPSEnaGlonassEna
BeidouEna
GalileoEna

GPS is enabled

UBX-13003221 - R17

GLONASS is enabled
BeiDou is enabled
Galileo is enabled

Early Production Information

Page 302 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.3 UBX-MON-HW2 (0x0A 0x0B)
32.16.3.1 Extended Hardware Status
Message

UBX-MON-HW2

Description

Extended Hardware Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Status of different aspects of the hardware such as Imbalance, Low-Level
Configuration and POST Results.
The first four parameters of this message represent the complex signal fromthe RF front end. The following rules of thumb apply:• The smaller the absolute value of the variable ofsI and ofsQ, the better.
• Ideally, the magnitude of the I-part (magI) and the Q-part (magQ) of thecomplex signal should be the same.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x0B 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Imbalance of I-part of complex signal,
scaled (-128 = max. negative imbalance,
127 = max. positive imbalance)
Magnitude of I-part of complex signal,
scaled (0 = no signal, 255 = max.
magnitude)
Imbalance of Q-part of complex signal,
scaled (-128 = max. negative imbalance,
127 = max. positive imbalance)
Magnitude of Q-part of complex signal,
scaled (0 = no signal, 255 = max.
magnitude)
Source of low-level configuration(114 = ROM, 111 = OTP, 112 = config pins,
102 = flash image)
Reserved
Low-level configuration (obsolete inprotocol versions greater than 15)
Reserved
POST status word
Reserved

Format

0

I1

-

ofsI

-

1

U1

-

magI

-

2

I1

-

ofsQ

-

3

U1

-

magQ

-

4

U1

-

cfgSource

-

5
8

U1[3]
U4

-

reserved1
lowLevCfg

-

12
20
24

U1[8]
U4
U1[4]

-

reserved2
postStatusreserved3-

UBX-13003221 - R17

Early Production Information

Page 303 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.4 UBX-MON-HW (0x0A 0x09)
32.16.4.1 Hardware Status
Message

UBX-MON-HW

Description

Hardware Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Status of different aspect of the hardware, such as Antenna, PIO/Peripheral
Pins, Noise Level, Automatic Gain Control (AGC)
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x09 60

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Mask of Pins Set as Peripheral/PIO
Mask of Pins Set as Bank A/B
Mask of Pins Set as Input/Output
Mask of Pins Value Low/High
Noise Level as measured by the GPS Core
AGC Monitor (counts SIGHI xor SIGLO,
range 0 to 8191)
Status of the Antenna Supervisor State
Machine (0=INIT, 1=DONTKNOW, 2=OK,
3=SHORT, 4=OPEN)
Current PowerStatus of Antenna (0=OFF,
1=ON, 2=DONTKNOW)
Flags (see graphic below)
Reserved
Mask of Pins that are used by the Virtual
Pin Manager
Array of Pin Mappings for each of the 17
Physical Pins
CW Jamming indicator, scaled (0 = no CW
jamming, 255 = strong CW jamming)
Reserved
Mask of Pins Value using the PIO Irq
Mask of Pins Value using the PIO Pull HighResistor
Mask of Pins Value using the PIO Pull Low
ResistorFormat

0
4
8
12
16
18

X4
X4
X4
X4
U2
U2

-

pinSelpinBank
pinDirpinValnoisePerMS
agcCnt

-

20

U1

-

aStatus

-

21

U1

-

aPower

-

22
23
24

X1
U1
X4

-

flags
reserved1
usedMask-

28

U1[17] -

VP

-

45

U1

-

jamInd

-

46
48
52

U1[2]
X4
X4

-

reserved2
pinIrq
pullH

-

56

X4

-

pullL

-

UBX-13003221 - R17

Early Production Information

Page 304 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

rtcCalib
safeBoot
jammingState

RTC is calibrated
safeBoot mode (0 = inactive, 1 = active)
output from Jamming/Interference Monitor (0 = unknown or feature disabled, 1 = ok - no significant
jamming, 2 = warning - interference visible but fix OK, 3 = critical - interference visible and no fix)
RTC xtal has been determined to be absent. (not supported in protocol versions less than 18)

xtalAbsent

32.16.5 UBX-MON-IO (0x0A 0x02)
32.16.5.1 I/O Subsystem Status
Message

UBX-MON-IO

Description

I/O Subsystem Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

The size of the message is determined by the number of ports 'N' the receiver
supports, i.e. on u-blox 5 the number of ports is 6.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x02 0 + 20*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Number of bytes ever received
Number of bytes ever sent
Number of 100ms timeslots with parity
errorsNumber of 100ms timeslots with framing
errorsNumber of 100ms timeslots with overrun
errorsNumber of 100ms timeslots with breakconditions
Reserved

FormatStart of repeated block (N times)

N*20
4 + 20*N
8 + 20*N

U4
U4
U2

-

rxBytestxBytesparityErrs

bytes
bytes
-

10 + 20*N

U2-

framingErrs-

12 + 20*N

U2-

overrunErrs-

14 + 20*N

U2-

breakCond-

16 + 20*N

U1[4]

-

reserved1-

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 305 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.6 UBX-MON-MSGPP (0x0A 0x06)
32.16.6.1 Message Parse and Process Status
Message

UBX-MON-MSGPP

Description

Message Parse and Process Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x06 120

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Number of successfully parsed messages
for each protocol on port0
Number of successfully parsed messages
for each protocol on port1
Number of successfully parsed messages
for each protocol on port2
Number of successfully parsed messages
for each protocol on port3
Number of successfully parsed messages
for each protocol on port4
Number of successfully parsed messages
for each protocol on port5
Number skipped bytes for each port

Format

0

U2[8]

-

msg1

msgs

16

U2[8]

-

msg2

msgs

32

U2[8]

-

msg3

msgs

48

U2[8]

-

msg4

msgs

64

U2[8]

-

msg5

msgs

80

U2[8]

-

msg6

msgs

96

U4[6]

-

skippedbytes

32.16.7 UBX-MON-PATCH (0x0A 0x27)
32.16.7.1 Poll Request for installed patches
Message

UBX-MON-PATCH

Description

Poll Request for installed patches

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x0A 0x27 0

PayloadChecksumsee below CK_A CK_B

No payload

UBX-13003221 - R17

Early Production Information

Page 306 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.7.2 Output information about installed patches.
Message

UBX-MON-PATCH

Description

Output information about installed patches.

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

PolledComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x27 4 + 16*nEntries

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionnEntries-

Type of the message. 0x1 for this one.
The number of patches that is output.

-

Additional information about the patch
not stated in the patch header. (seegraphic below)
The number of the comparator.

Format0
2

U2
U2

Start of repeated block (nEntries times)

4 + 16*N

X4-

patchInfo

8 + 16*NU4-

12 + 16*N

U4-comparatorNum ber
patchAddress -16 + 16*N

U4-

patchData-

The address that the targeted by thepatch.
The data that will be inserted at thepatchAddress.

End of repeated block

Bitfield patchInfo
This graphic explains the bits of patchInfo

Name

Description

activatedlocation

1: the patch is active. 0: otherwise.

UBX-13003221 - R17

Indicates where the patch is stored. 0: eFuse, 1: ROM, 2: BBR, 3: file system.

Early Production Information

Page 307 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.8 UBX-MON-RXBUF (0x0A 0x07)
32.16.8.1 Receiver Buffer Status
Message

UBX-MON-RXBUF

Description

Receiver Buffer Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x07 24

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Number of bytes pending in receiverbuffer for each target
Maximum usage receiver buffer during thelast sysmon period for each target
Maximum usage receiver buffer for eachtargetFormat

0

U2[6]

-

pending

bytes

12

U1[6]

-

usage

%

18

U1[6]

-

peakUsage%

32.16.9 UBX-MON-RXR (0x0A 0x21)
32.16.9.1 Receiver Status Information
Message

UBX-MON-RXR

Description

Receiver Status Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The receiver ready message is sent when the receiver changes from or to backup
mode.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x21 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

flags

-

Receiver status flags (see graphic below)

Format0

X1

UBX-13003221 - R17

Early Production Information

Page 308 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

awake

not in Backup mode

32.16.10 UBX-MON-SMGR (0x0A 0x2E)
32.16.10.1 Synchronization Manager Status
Message

UBX-MON-SMGR

Description

Synchronization Manager Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Periodic/Polled

Comment

This message reports the status of internal and external oscillators and sources
as well as whether GNSS is used for disciplining.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x2E 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Reserved
Time of the week
A bit mask, indicating the status of thelocal oscillator (see graphic below)
A bit mask, indicating the status of theexternal oscillator (see graphic below)
Disciplining source identifier:
0: internal oscillator
1: GNSS
2: EXTINT0
3: EXTINT1
4: internal oscillator measured by the host
5: external oscillator measured by the hostA bit mask, indicating the status of the
GNSS (see graphic below)
A bit mask, indicating the status of theexternal input 0 (see graphic below)
A bit mask, indicating the status of theexternal input 1 (seegraphic below)

Format

0
1
4
8

U1
U1[3]
U4
X2

-

versionreserved1
iTOW
intOsc

ms
-

10

X2

-

extOsc

-

12

U1

-

discSrc

-

13

X1

-

gnss

-

14

X1

-

extInt0

-

15

X1

-

extInt1-

UBX-13003221 - R17

Early Production Information

Page 309 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield intOsc
This graphic explains the bits of intOsc

Name

Description

intOscState

State of the oscillator:
0: autonomous operation
1: calibration ongoing
2: oscillator is steered by the host
3: idle state

intOscCalib
intOscDisc

1 = oscillator gain is calibrated
1 = signal is disciplined

Bitfield extOsc
This graphic explains the bits of extOsc

Name

Description

extOscState

State of the oscillator:
0: autonomous operation
1: calibration ongoing
2: oscillator is steered by the host
3: idle state

extOscCalib
extOscDisc

1 = oscillator gain is calibrated
1 = signal is disciplined

Bitfield gnss
This graphic explains the bits of gnss

UBX-13003221 - R17

Early Production Information

Page 310 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

gnssAvail

1 = GNSS is present

Bitfield extInt0
This graphic explains the bits of extInt0

Name

Description

extInt0Avail
extInt0Type

1 = signal present at this input
Source type:
0: frequency
1: timeextInt0FeedBa
ck

This source is used as feedback of the external oscillator

Bitfield extInt1
This graphic explains the bits of extInt1

Name

Description

extInt1Avail
extInt1Type

1 = signal present at this input
Source type:
0: frequency
1: timeextInt1FeedBa
ck

UBX-13003221 - R17

This source is used as feedback of the external oscillator

Early Production Information

Page 311 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.11 UBX-MON-TXBUF (0x0A 0x08)
32.16.11.1 Transmitter Buffer Status
Message

UBX-MON-TXBUF

Description

Transmitter Buffer Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x08 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Number of bytes pending in transmitter
buffer for each target
Maximum usage transmitter buffer during
the last sysmon period for each target
Maximum usage transmitter buffer foreach target
Maximum usage of transmitter buffer
during the last sysmon period for all
targets
Maximum usage of transmitter buffer for
all targets
Error bitmask (see graphic below)
Reserved

Format

0

U2[6]

-

pending

bytes

12

U1[6]

-

usage

%

18

U1[6]

-

peakUsage

%

24

U1

-

tUsage

%

25

U1

-

tPeakusage

%

26
27

X1
U1

-

errorsreserved1-

Bitfield errors
This graphic explains the bits of errors

Name

Description

limit
mem
alloc

Buffer limit of corresponding target reached

UBX-13003221 - R17

Memory Allocation error
Allocation error (TX buffer full)

Early Production Information

Page 312 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.16.12 UBX-MON-VER (0x0A 0x04)
32.16.12.1 Poll Receiver/Software Version
Message

UBX-MON-VER

Description

Poll Receiver/Software Version

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x04 0

Checksumsee below CK_A CK_B

No payload

32.16.12.2 Receiver/Software Version
Message

UBX-MON-VER

Description

Receiver/Software Version

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

PolledComment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0A 0x04 40 + 30*N

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

swVersion-

Zero-terminated Software Version String.

hwVersion-

Zero-terminated Hardware Version String

extension-

Extended software information strings.
A series of zero-terminated strings. Eachextension field is 30 characters long andcontains varying software information.
Not all extension fields may appear.
Example reported information can be: thesoftware version string of the underlying
ROM (when the receiver's firmware is
running from flash), the firmware version,
the supported protocol version, themodule identifier, the Flash Information
Structure (FIS) file information, thesupported major GNSS, the supported
augmentation systems.

Format030

CH[30 ]
CH[10] -Start of repeated block (N times)

40 + 30*N

CH[30 ]End of repeated block

UBX-13003221 - R17

Early Production Information

Page 313 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17 UBX-NAV (0x01)
Navigation Results Messages: i.e. Position, Speed, Time, Acceleration, Heading, DOP, SVs used.
Messages in the NAV class are used to output navigation data such as position, altitude andvelocity in a number of formats. Additionally, status flags and accuracy figures are output. The
messages are generated with the configured navigation/measurement rate.
32.17.1 UBX-NAV-AOPSTATUS (0x01 0x60)
32.17.1.1 AssistNow Autonomous Status
Message

UBX-NAV-AOPSTATUS

Description

AssistNow Autonomous Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message provides information on the status of the AssistNow Autonomous
subsystem on the receiver. For example, a host application can determine theoptimal time to shut down the receiver by monitoring the status field for asteady 0. See the chapter AssistNow Autonomous in the receiver description for
details on this feature.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x60 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
AssistNow Autonomous configuration(see graphic below)
AssistNow Autonomous subsystem is idle(0) or running (not 0)
Reserved

Format

0

U4

-

iTOW

ms

4

U1

-

aopCfg

-

5

U1

-

status-6

U1[10] -reserved1-

Bitfield aopCfg
This graphic explains the bits of aopCfg

UBX-13003221 - R17

Early Production Information

Page 314 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

useAOP

AOP enabled flag

32.17.2 UBX-NAV-ATT (0x01 0x05)
32.17.2.1 Attitude Solution
Message

UBX-NAV-ATT

Description

Attitude Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.3,
22, 23 and 23.01(only with ADR or UDR products)

Type

Periodic/Polled

Comment

This message outputs the attitude solution as roll, pitch and heading angles.
More details about vehicle attitude can be found in the Vehicle Attitude Output(ADR) section for ADR products.
More details about vehicle attitude can be found in the Vehicle Attitude Output(UDR) section for UDR products.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x05 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (0 for this version)
Reserved
Vehicle roll.
Vehicle pitch.
Vehicle heading.
Vehicle roll accuracy (if null, roll angle is
not available).
Vehicle pitch accuracy (if null, pitch angle
is not available).
Vehicle heading accuracy (if null, heading
angle is not available).

Format

0

U4

-

iTOW

ms

4
5
8
12
16
20

U1
U1[3]
I4
I4
I4
U4

1e-5
1e-5
1e-5
1e-5

versionreserved1
roll
pitch
headingaccRoll

deg
deg
deg
deg

24

U4

1e-5

accPitch

deg

28

U4

1e-5

accHeadingdeg

UBX-13003221 - R17

Early Production Information

Page 315 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.3 UBX-NAV-CLOCK (0x01 0x22)
32.17.3.1 Clock Solution
Message

UBX-NAV-CLOCK

Description

Clock Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x22 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Clock bias
Clock drift
Time accuracy estimate
Frequency accuracy estimate

Format

0

U4

-

iTOW

ms

4
8
12
16

I4
I4
U4
U4

-

clkB
clkD
tAcc
fAcc

ns
ns/s
ns
ps/s

32.17.4 UBX-NAV-DGPS (0x01 0x31)
32.17.4.1 DGPS Data Used for NAV
Message

UBX-NAV-DGPS

Description

DGPS Data Used for NAV

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message outputs the DGPS correction data that has been applied to thecurrent NAV Solution. See also the notes on the RTCM protocol.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x31 16 + 12*numCh

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Age of newest correction data
DGPS base station identifier
DGPS base station health status
Number of channels for which correction
data is following

Format

0

U4

-

iTOW

ms

4
8
10
12

I4
I2
I2
U1

-

age
baseIdbaseHealth
numCh

ms
-

UBX-13003221 - R17

Early Production Information

Page 316 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-DGPS continued
Byte Offset

Number

Scaling

Name

Unit

Description

DGPS correction type status:
0x00: none
0x01: PR+PRR correction
Reserved

Format13

U1-

status

-

14

U1[2]

-

reserved1-

Start of repeated block (numCh times)

16 + 12*N
17 + 12*N

U1
X1

-

svid
flags

-

18 + 12*N
20 + 12*N
24 + 12*N

U2
R4
R4

-

ageC
prc
prrc

ms
m
m/s

Satellite ID
Channel number and usage (see graphic
below)
Age of latest correction data
Pseudorange correction
Pseudorange rate correction

End of repeated block

Bitfield flags
This graphic explains the bits of flags

Name

Description

channelGPS channel number this SV is on. Channel numbers in the firmware greater than 15 are displayed ashaving channel number 15
1 = DGPS used for this SV

dgpsUsed

32.17.5 UBX-NAV-DOP (0x01 0x04)
32.17.5.1 Dilution of precision
Message

UBX-NAV-DOP

Description

Dilution of precision

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment• DOP values are dimensionless.
• All DOP values are scaled by a factor of 100. If the unit transmits a value of e.g.
156, the DOP value is 1.56.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x04 18

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

FormatUBX-13003221 - R17

Early Production Information

Page 317 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-DOP continued
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Geometric DOP
Position DOPTime DOP
Vertical DOP
Horizontal DOP
Northing DOP
Easting DOP

Format

0

U4

-

iTOW

ms

4
6
8
10
12
14
16

U2
U2
U2
U2
U2
U2
U2

0.01
0.01
0.01
0.01
0.01
0.01
0.01

gDOP
pDOP
tDOP
vDOP
hDOP
nDOP
eDOP

-

32.17.6 UBX-NAV-EOE (0x01 0x61)
32.17.6.1 End Of Epoch
Message

UBX-NAV-EOE

Description

End Of Epoch

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic

Comment

This message is intended to be used as a marker to collect all navigation
messages of an epoch. It is output after all enabled NAV class messages (except
UBX-NAV-HNR) and after all enabled NMEA messages.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x61 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

iTOW

ms

GPS time of week of the navigation epoch.
See the description of iTOW for details.

Format0U432.17.7 UBX-NAV-GEOFENCE (0x01 0x39)
32.17.7.1 Geofencing status
Message

UBX-NAV-GEOFENCE

Description

Geofencing status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message outputs the evaluated states of all configured geofences for thecurrent epoch's position.
See the Geofencing description for feature details.
HeaderMessage Structure

UBX-13003221 - R17

Class ID

Length (Bytes)

0xB5 0x62 0x01 0x39 8 + 2*numFences

Early Production Information

PayloadChecksumsee below CK_A CK_B

Page 318 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (0x00 for this version)
Geofencing status
0 - Geofencing not available or not reliable
1 - Geofencing active
Number of geofences
Combined (logical OR) state of all
geofences
0 - Unknown
1 - Inside
2 - Outside

Format

0

U4

-

iTOW

ms

4
5

U1
U1

-

versionstatus

-

6
7

U1
U1

-

numFences
combState-

Start of repeated block (numFences times)

8 + 2*N

U1

-

state

-

9 + 2*NU1[1]-reserved1-

Geofence state
0 - Unknown
1 - Inside
2 - Outside
Reserved

End of repeated block32.17.8 UBX-NAV-HPPOSECEF (0x01 0x13)
32.17.8.1 High Precision Position Solution in ECEF
Message

UBX-NAV-HPPOSECEF

Description

High Precision Position Solution in ECEF

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20.01, 20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x13 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Reserved
GPS time of week of the navigation epoch.
See the description of iTOW for details.
ECEF X coordinate
ECEF Y coordinate
ECEF Z coordinate

Format

0
1
4

U1
U1[3]
U4

-

versionreserved1
iTOW

ms

8
12
16

I4
I4
I4

-

ecefX
ecefY
ecefZ

cm
cm
cm

UBX-13003221 - R17

Early Production Information

Page 319 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-HPPOSECEF continued
Byte Offset

Number

Scaling

Name

Unit

Description

High precision component of ECEF X
coordinate. Must be in the range of -99..
+99. Precise coordinate in cm = ecefX +(ecefXHp * 1e-2).
High precision component of ECEF Y
coordinate. Must be in the range of -99..
+99. Precise coordinate in cm = ecefY +(ecefYHp * 1e-2).
High precision component of ECEF Z
coordinate. Must be in the range of -99..
+99. Precise coordinate in cm = ecefZ +(ecefZHp * 1e-2).
Reserved
Position Accuracy Estimate

Format

20

I1

0.1

ecefXHp

mm

21

I1

0.1

ecefYHp

mm

22

I1

0.1

ecefZHp

mm

23
24

U1
U4

0.1

reserved2
pAcc

mm32.17.9 UBX-NAV-HPPOSLLH (0x01 0x14)
32.17.9.1 High Precision Geodetic Position Solution
Message

UBX-NAV-HPPOSLLH

Description

High Precision Geodetic Position Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20.01, 20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
This message outputs the Geodetic position with high precision in the currently
selected ellipsoid. The default is the WGS84 Ellipsoid, but can be changed withthe message UBX-CFG-DAT.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x14 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Reserved
GPS time of week of the navigation epoch.
See the description of iTOW for details.
Longitude
Latitude
Height above ellipsoid.
Height above mean sea level

Format

0
1
4

U1
U1[3]
U4

-

versionreserved1
iTOW

ms

8
12
16
20

I4
I4
I4
I4

1e-7
1e-7
-

lon
lat
height
hMSL

deg
deg
mm
mm

UBX-13003221 - R17

Early Production Information

Page 320 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-HPPOSLLH continued
Byte Offset

Number

Scaling

Name

Unit

Description

High precision component of longitude.
Must be in the range -99..+99. Precise
longitude in deg * 1e-7 = lon + (lonHp * 1e2).
High precision component of latitude.
Must be in the range -99..+99. Precise
latitude in deg * 1e-7 = lat + (latHp * 1e-2).
High precision component of height above
ellipsoid. Must be in the range -9..+9.
Precise height in mm = height + (heightHp* 0.1).
High precision component of height above
mean sea level. Must be in range -9..+9.
Precise height in mm = hMSL + (hMSLHp *0.1)
Horizontal accuracy estimate
Vertical accuracy estimate

Format

24

I1

1e-9

lonHp

deg

25

I1

1e-9

latHp

deg

26

I1

0.1

heightHp

mm

27

I1

0.1

hMSLHp

mm

28
32

U4
U4

0.1
0.1

hAcc
vAcc

mm
mm

32.17.10 UBX-NAV-ODO (0x01 0x09)
32.17.10.1 Odometer Solution
Message

UBX-NAV-ODO

Description

Odometer Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message outputs the traveled distance since last reset (see UBX-NAVRESETODO) together with an associated estimated accuracy and the total
cumulated ground distance (can only be reset by a cold start of the receiver).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x09 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

DescriptionmsMessage version (0 for this version)
Reserved
GPS time of week of the navigation epoch.
See the description of iTOW for details.
Ground distance since last reset
Total cumulative ground distance
Ground distance accuracy (1-sigma)

Format

0
1
4

U1
U1[3]
U4

-

versionreserved1
iTOW

8
12
16

U4
U4
U4

-

distancem
totalDistance m
distanceStdm

UBX-13003221 - R17

Early Production Information

Page 321 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.11 UBX-NAV-ORB (0x01 0x34)
32.17.11.1 GNSS Orbit Database Info
Message

UBX-NAV-ORB

Description

GNSS Orbit Database Info

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Status of the GNSS orbit database knowledge.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x34 8 + 6*numSv

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (1, for this version)
Number of SVs in the database
Reserved

Format

0

U4

-

iTOW

ms

4
5
6

U1
U1
U1[2]

-

versionnumSv
reserved1-

Start of repeated block (numSv times)

8 + 6*N
9 + 6*N
10 + 6*N
11 + 6*N
12 + 6*N
13 + 6*N

U1
U1
X1
X1
X1
X1

-

gnssIdsvId
svFlagephalmotherOrb-

GNSS ID
Satellite ID
Information Flags (see graphic below)
Ephemeris data (see graphic below)
Almanac data (see graphic below)
Other orbit data available (see graphic
below)End of repeated block

Bitfield svFlag
This graphic explains the bits of svFlag

UBX-13003221 - R17

Early Production Information

Page 322 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

healthSV health:0: unknown
1: healthy
2: not healty

visibility

SV health:0: unknown
1: below horizon
2: above horizon
3: above elevation mask

Bitfield eph
This graphic explains the bits of eph

Name

Description

ephUsability

How long the receiver will be able to use the stored ephemeris data from now on:
31: The usability period is unknown
30: The usability period is more than 450 minutes
30 > n > 0: The usability period is between (n-1)*15 and n*15 minutes
0: Ephemeris can no longer be used

ephSource

0: not available
1: GNSS transmission
2: external aiding
3-7: other

Bitfield alm
This graphic explains the bits of alm

UBX-13003221 - R17

Early Production Information

Page 323 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

almUsability

How long the receiver will be able to use the stored almanac data from now on:
31: The usability period is unknown
30: The usability period is more than 30 days
30 > n > 0: The usability period is between n-1 and n days
0: Almanac can no longer be used

almSource

0: not available
1: GNSS transmission
2: external aiding
3-7: other

Bitfield otherOrb
This graphic explains the bits of otherOrb

Name

Description

anoAopUsability

How long the receiver will be able to use the orbit data from now on:
31: The usability period is unknown
30: The usability period is more than 30 days
30 > n > 0: The usability period is between n-1 and n days
0: Data can no longer be used

type

Type of orbit data:
0: No orbit data available
1: Assist now offline data
2: Assist now autonomous data
3-7: Other orbit data

UBX-13003221 - R17

Early Production Information

Page 324 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.12 UBX-NAV-POSECEF (0x01 0x01)
32.17.12.1 Position Solution in ECEF
Message

UBX-NAV-POSECEF

Description

Position Solution in ECEF

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x01 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
ECEF X coordinate
ECEF Y coordinate
ECEF Z coordinate
Position Accuracy Estimate

Format

0

U4

-

iTOW

ms

4
8
12
16

I4
I4
I4
U4

-

ecefX
ecefY
ecefZ
pAcc

cm
cm
cm
cm

32.17.13 UBX-NAV-POSLLH (0x01 0x02)
32.17.13.1 Geodetic Position Solution
Message

UBX-NAV-POSLLH

Description

Geodetic Position Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
This message outputs the Geodetic position in the currently selected ellipsoid.
The default is the WGS84 Ellipsoid, but can be changed with the message UBXCFG-DAT.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x02 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Longitude
Latitude
Height above ellipsoid

Format

0

U4

-

iTOW

ms

4
8
12

I4
I4
I4

1e-7
1e-7
-

lon
lat
heightdeg
deg
mm

UBX-13003221 - R17

Early Production Information

Page 325 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-POSLLH continued
Byte Offset

Number

Scaling

Name

Unit

Description

-

hMSL
hAcc
vAcc

mm
mm
mm

Height above mean sea level
Horizontal accuracy estimate
Vertical accuracy estimate

Format

16
20
24

I4
U4
U4

32.17.14 UBX-NAV-PVT (0x01 0x07)
32.17.14.1 Navigation Position Velocity Time Solution
Message

UBX-NAV-PVT

Description

Navigation Position Velocity Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Note that during a leap second there may be more or less than 60 seconds in aminute.
See the description of leap seconds for details.
This message combines position, velocity and time solution, including accuracy
figures
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x07 92

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

iTOW

4
6
7
8
9
10
11
12
16
20

U2
U1
U1
U1
U1
U1
X1
U4
I4
U1

-

year
month
day
hour
min
sec
valid
tAcc
nano
fixType

21
22
23

X1
X1
U1

-

flags
flags2
numSV

UBX-13003221 - R17

GPS time of week of the navigation epoch.
See the description of iTOW for details.
yYear (UTC)month Month, range 1..12 (UTC)dDay of month, range 1..31 (UTC)hHour of day, range 0..23 (UTC)min
Minute of hour, range 0..59 (UTC)sSeconds of minute, range 0..60 (UTC)
Validity flags (see graphic below)
nsTime accuracy estimate (UTC)ns
Fraction of second, range -1e9 .. 1e9 (UTC)
GNSSfix Type:0: no fix
1: dead reckoning only
2: 2D-fix
3: 3D-fix
4: GNSS + dead reckoning combined
5: time only fix
Fix status flags (see graphic below)
Additional flags (see graphic below)
Number of satellites used in Nav Solution

Early Production Information

Page 326 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-PVT continued
Byte Offset

Number

Scaling

Name

Unit

Description

Longitude
Latitude
Height above ellipsoid
Height above mean sea level
Horizontal accuracy estimate
Vertical accuracy estimate
NED north velocity
NED east velocity
NED down velocity
Ground Speed (2-D)
Heading of motion (2-D)
Speed accuracy estimate
Heading accuracy estimate (both motion
and vehicle)
Position DOP
Reserved
Heading of vehicle (2-D)
Magnetic declination
Magnetic declination accuracy

Format

24
28
32
36
40
44
48
52
56
60
64
68
72

I4
I4
I4
I4
U4
U4
I4
I4
I4
I4
I4
U4
U4

1e-7
1e-7
1e-5
1e-5

lon
lat
height
hMSL
hAcc
vAcc
velN
velE
velD
gSpeedheadMotsAcc
headAcc

deg
deg
mm
mm
mm
mm
mm/s
mm/s
mm/s
mm/s
deg
mm/s
deg

76
78
84
88
90

U2
U1[6]
I4
I2
U2

0.01
1e-5
1e-2
1e-2

pDOP
reserved1
headVehmagDecmagAcc

deg
deg
deg

Bitfield valid
This graphic explains the bits of valid

Name

Description

validDatevalidTimefullyResolved

1 = valid UTC Date (seeTime Validity section for details)
1 = valid UTC Time of Day (seeTime Validity section for details)
1 = UTC Time of Day has been fully resolved (no seconds uncertainty). Cannot be used to check iftime is completely solved.

validMag

UBX-13003221 - R17

1 = valid Magnetic declination

Early Production Information

Page 327 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

gnssFixOK
diffSoln
headVehValid
carrSoln

1 = valid fix (i.e within DOP & accuracy masks)
1 = differential corrections were applied
1 = heading of vehicle is valid
Carrier phase range solution status:
0: no carrier phase range solution
1: carrier phase range solution with floating ambiguities
2: carrier phase range solution with fixed ambiguities(not supported in protocol versions less than 20)

Bitfield flags2
This graphic explains the bits of flags2

Name

Description

confirmedAvai

1 = information about UTC Date and Time of Day validity confirmation is available (seeTime Validity
section for details)
This flag is only supported in Protocol Versions 19.00, 19.10, 20.10, 20.20, 20.30, 22.00, 23.00, 23.01,
27 and 28.

confirmedDate
confirmedTime

1 = UTC Date validity could be confirmed (seeTime Validity section for details)

UBX-13003221 - R17

Early Production Information

1 = UTC Time of Day could be confirmed (seeTime Validity section for details)

Page 328 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.15 UBX-NAV-RELPOSNED (0x01 0x3C)
32.17.15.1 Relative Positioning Information in NED frame
Message

UBX-NAV-RELPOSNED

Description

Relative Positioning Information in NED frame

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20, 20.01, 20.1, 20.2, 20.3, 22, 23 and 23.
01(only with High Precision GNSS products)

Type

Periodic/Polled

Comment

The NED frame is defined as the local topological system at the reference
station. The relative position vector components in this message, along with
their associated accuracies, are given in that local topological system
This message contains the relative position vector from the Reference Station
to the Rover, including accuracy figures, in the local topological system definedat the reference station
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x3C 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reserved
Reference Station ID. Must be in the range
0..4095
GPS time of week of the navigation epoch.
See the description of iTOW for details.
North component of relative position
vectorEast component of relative position vector
Down component of relative position
vectorHigh-precision North component ofrelative position vector.
Must be in the range -99 to +99.
The full North component of the relative
position vector, in units of cm, is given by
relPosN + (relPosHPN * 1e-2)
High-precision East component of relative
position vector.
Must be in the range -99 to +99.
The full East component of the relative
position vector, in units of cm, is given by
relPosE + (relPosHPE * 1e-2)

Format

0
1
2

U1
U1
U2

-

versionreserved1
refStationId

-

4

U4

-

iTOW

ms

8

I4

-

relPosN

cm

12
16

I4
I4

-

relPosE
relPosD

cm
cm

20

I1

0.1

relPosHPN

mm

21

I1

0.1

relPosHPE

mm

UBX-13003221 - R17

Early Production Information

Page 329 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-RELPOSNED continued
Byte Offset

Number

Scaling

Name

Unit

Description

High-precision Down component ofrelative position vector.
Must be in the range -99 to +99.
The full Down component of the relative
position vector, in units of cm, is given by
relPosD + (relPosHPD * 1e-2)
Reserved
Accuracy of relative position North
component
Accuracy of relative position East
component
Accuracy of relative position Down
component
Flags (see graphic below)

Format

22

I1

0.1

relPosHPD

mm

23
24

U1
U4

0.1

reserved2
accN

mm

28

U4

0.1

accE

mm

32

U4

0.1

accD

mm

36

X4

-

flags

-

Bitfield flags
This graphic explains the bits of flags

Name

Description

gnssFixOK
diffSoln
relPosValid
carrSoln

A valid fix (i.e within DOP & accuracy masks)
1 if differential corrections were applied
1 if relative position components and accuracies are valid
Carrier phase range solution status:
0 = no carrier phase range solution
1 = carrier phase range solution with floating ambiguities
2 = carrier phase range solution with fixed ambiguities

isMoving

1 if the receiver is operating in moving baseline mode (not supported inprotocol versions less than
20.3)

refPosMiss

1 if extrapolated reference position was used to compute moving baseline solution this epoch (notsupported in protocol versions less than 20.3)

refObsMiss

1 if extrapolated reference observations were used to compute moving baseline solution this epoch(not supported in protocol versions less than 20.3)

UBX-13003221 - R17

Early Production Information

Page 330 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.16 UBX-NAV-RESETODO (0x01 0x10)
32.17.16.1 Reset odometer
Message

UBX-NAV-RESETODO

Description

Reset odometer

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

This message resets the traveled distance computed by the odometer (see UBXNAV-ODO).
UBX-ACK-ACK or UBX-ACK-NAK are returned to indicate success or failure.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x10 0

Checksumsee below CK_A CK_B

No payload

32.17.17 UBX-NAV-SAT (0x01 0x35)
32.17.17.1 Satellite Information
Message

UBX-NAV-SAT

Description

Satellite Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message displays information about SVs which are either known to bevisible or currently tracked by the receiver. All signal related information
corresponds to the subset of signals specified in Signal Identifiers.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x35 8 + 12*numSvs

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (1 for this version)
Number of satellites
Reserved

Format

0

U4

-

iTOW

ms

4
5
6

U1
U1
U1[2]

-

versionnumSvsreserved1-

Start of repeated block (numSvs times)

8 + 12*N

U1-

gnssId

-9 + 12*N

U1

-

svId

-

10 + 12*N
11 + 12*N

U1
I1

-

cno
elev

dBHz
deg

UBX-13003221 - R17

GNSS identifier (see Satellite Numbering)for assignment
Satellite identifier (see Satellite
Numbering) for assignment
Carrier to noise ratio (signal strength)
Elevation (range: +/-90), unknown if out of
range

Early Production Information

Page 331 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-SAT continued
Byte Offset

Number

Scaling

Name

Unit

Description

Azimuth (range 0-360), unknown ifelevation is out of range
Pseudorange residual
Bitmask (see graphic below)

Format

12 + 12*N

I2

-

azim

deg

14 + 12*N
16 + 12*N

I2
X4

0.1
-

prRes
flags

m
-

End of repeated block

Bitfield flags
This graphic explains the bits of flags

Name

Description

qualityInd

Signal quality indicator:
0: no signal
1: searching signal
2: signal acquired
3: signal detected but unusable
4: code locked and time synchronized
5, 6, 7: code and carrier locked and time synchronized
Note: Since IMES signals are not time synchronized, a channel tracking an IMES signal can neverreach a quality indicator value of higher than 3.

svUsedhealth

1 = Signal in the subset specified inSignal Identifiers is currently being used for navigation
Signal health flag:
0: unknown
1: healthy
2: unhealthy

diffCorrsmoothed
orbitSource

1 = differential correction data is available for this SV
1 = carrier smoothed pseudorange used
Orbit source:
0: no orbit information is available for this SV
1: ephemeris is used
2: almanac is used
3: AssistNow Offline orbit is used
4: AssistNow Autonomous orbit is used
5, 6, 7: other orbit information is used

ephAvailalmAvail
anoAvail
aopAvail

UBX-13003221 - R17

1 = ephemeris is available for this SV
1 = almanac is available for this SV
1 = AssistNow Offline data is available for this SV
1 = AssistNow Autonomous data is available for this SV

Early Production Information

Page 332 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags Description continued
Name

Description

sbasCorrUsed
rtcmCorrUsed
slasCorrUsed
prCorrUsed
crCorrUsed
doCorrUsed

1 = SBAS corrections have been used for a signal in the subset specified inSignal Identifiers
1 = RTCM corrections have been used for a signal in the subset specified inSignal Identifiers
1 = QZSS SLAS corrections have been used for a signal in the subset specified inSignal Identifiers
1 = Pseudorange corrections have been used for a signal in the subset specified inSignal Identifiers
1 = Carrier range corrections have been used for a signal in the subset specified inSignal Identifiers
1 = Range rate (Doppler) corrections have been used for a signal in the subset specified inSignal
Identifiers

32.17.18 UBX-NAV-SBAS (0x01 0x32)
32.17.18.1 SBAS Status Data
Message

UBX-NAV-SBAS

Description

SBAS Status Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message outputs the status of the SBAS sub system
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x32 12 + 12*cnt

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0

U4

-

iTOW

ms

4

U1

-

geo

-

5

U1

-

mode

-

6

I1

-

sys

-

7

X1

-

service

-

8
9

U1
U1[3]

-

cnt
reserved1-

GPS time of week of the navigation epoch.
See the description of iTOW for details.
PRN Number of the GEO where correction
and integrity data is used from
SBAS Mode
0 Disabled
1 Enabled Integrity
3 Enabled Testmode
SBAS System (WAAS/EGNOS/...)-1 Unknown
0 WAAS
1 EGNOS
2 MSAS
3 GAGAN
16 GPSSBAS Services available (see graphic
below)
Number of SV data following
Reserved

svid
flags

-

SV ID
Flags for this SV

Start of repeated block (cnt times)

12 + 12*N
13 + 12*N

U1
U1

UBX-13003221 - R17-

Early Production Information

Page 333 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-SBAS continued
Byte Offset

Number

Scaling

Name

Unit

Description

Monitoring status
System (WAAS/EGNOS/...)
same as SYS
Services available
same as SERVICE
Reserved
Pseudo Range correction in [cm]Reserved
Ionosphere correction in [cm]Format14 + 12*N
15 + 12*N

U1
U1

-

udre
svSys

-

16 + 12*N

U1-

svService-

17 + 12*N
18 + 12*N
20 + 12*N
22 + 12*N

U1
I2
U1[2]
I2

-

reserved2
prc
reserved3
ic

cm
cm

End of repeated block

Bitfield service
This graphic explains the bits of service

Name

Description

Ranging
Corrections
Integrity
TestmodeBad

GEO may be used as ranging source
GEO is providing correction data
GEO is providing integrity
GEO is in test mode
Problem with signal or broadcast data indicated32.17.19 UBX-NAV-SLAS (0x01 0x42)
32.17.19.1 QZSS L1S SLAS Status Data
Message

UBX-NAV-SLAS

Description

QZSS L1S SLAS Status Data

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 19.2

Type

Periodic/Polled

Comment

This message outputs the status of the QZSS L1S SLAS sub system
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x42 20 + 8*cnt

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

iTOW

ms

GPS time of week of the navigation epoch.
See the description of iTOW for details.

Format0

U4

UBX-13003221 - R17

Early Production Information

Page 334 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-SLAS continued
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reserved
Longitude of the used ground monitoring
stationLatitude of the used ground monitoring
stationCode of the used ground monitoring
station according to the QZSS SLAS
Interface Specification, available fromqzss.go.jp/en/
Satellite identifier of the QZS/GEO whose
correction data is used (see Satellite
Numbering)
Flags regarding SLAS service (see graphic
below)
Number of pseudorange corrections
following

Format

4
5
8

U1
U1[3]
I4

1e-3

versionreserved1
gmsLon

deg

12

I4

1e-3

gmsLat

deg

16

U1

-

gmsCode

-

17

U1

-

qzssSvId

-

18

X1

-

serviceFlags

-

19

U1

-

cnt

-

Start of repeated block (cnt times)

20 + 8*N
21 + 8*N

U1
U1-

gnssIdsvId-

22 + 8*N
23 + 8*N
26 + 8*N

U1
U1[3]
I2

-

reserved2
reserved3
prc

cm

GNSS identifier (see Satellite Numbering)
Satellite identifier (see Satellite
Numbering)Reserved
Reserved
Pseudorange correction

End of repeated block

Bitfield serviceFlags
This graphic explains the bits of serviceFlags

UBX-13003221 - R17

Early Production Information

Page 335 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

gmsAvailable
qzssSvAvailab
letestMode

1 = Ground monitoring station available
1 = Correction providing QZSS SV available
1 = Currently used QZSS SV in test mode

32.17.20 UBX-NAV-SOL (0x01 0x06)
32.17.20.1 Navigation Solution Information
Message

UBX-NAV-SOL

Description

Navigation Solution Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message combines position, velocity and time solution in ECEF, including
accuracy figures.
This message has only been retained for backwards compatibility; users arerecommended to use the UBX-NAV-PVT message in preference.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x06 52

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

iTOW

4

I4

-

fTOW

8
10

I2
U1

-

week
gpsFix

11
12
16
20
24
28
32

X1
I4
I4
I4
U4
I4
I4

-

flags
ecefX
ecefY
ecefZ
pAcc
ecefVX
ecefVYUBX-13003221 - R17

GPS time of week of the navigation epoch.
See the description of iTOW for details.
ns
Fractional part of iTOW (range: +/500000).
The precise GPS time of week in seconds
is:(iTOW * 1e-3) + (fTOW * 1e-9)
weeks GPS week number of the navigation epoch
GPSfix Type, range 0..5
0x00 = No Fix
0x01 = Dead Reckoning only
0x02 = 2D-Fix
0x03 = 3D-Fix
0x04 = GPS + dead reckoning combined
0x05 = Time only fix
0x06..0xff: reserved
Fix Status Flags (see graphic below)cm
ECEF X coordinatecm
ECEF Y coordinatecm
ECEF Z coordinatecm
3D Position Accuracy Estimate
cm/s
ECEF X velocity
cm/s
ECEF Y velocity

Early Production Information

Page 336 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-SOL continued
Byte Offset

Number

Scaling

Name

Unit

Description

0.01-

ecefVZ
sAcc
pDOP
reserved1
numSV
reserved2

cm/s
cm/s
-

ECEF Z velocity
Speed Accuracy Estimate
Position DOP
Reserved
Number of SVs used in Nav Solution
Reserved

Format

36
40
44
46
47
48

I4
U4
U2
U1
U1
U1[4]

Bitfield flags
This graphic explains the bits of flags

Name

Description

GPSfixOK
DiffSoln
WKNSETTOWSET

1 = Fix within limits (e.g. DOP & accuracy)
1 = DGPS used
1 = Valid GPS week number (seeTime Validity section for details)
1 = Valid GPS time of week (iTOW & fTOW, seeTime Validity section for details)

32.17.21 UBX-NAV-STATUS (0x01 0x03)
32.17.21.1 Receiver Navigation Status
Message

UBX-NAV-STATUS

Description

Receiver Navigation Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x03 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

iTOW

ms

GPS time of week of the navigation epoch.
See the description of iTOW for details.

Format0

U4

UBX-13003221 - R17

Early Production Information

Page 337 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-STATUS continued
Byte Offset

Number

Scaling

Name

Unit

Description

GPSfix Type, this value does not qualify a
fix as valid and within the limits. See noteon flag gpsFixOk below.
0x00 = no fix
0x01 = dead reckoning only
0x02 = 2D-fix
0x03 = 3D-fix
0x04 = GPS + dead reckoning combined
0x05 = Time only fix
0x06..0xff = reserved
Navigation Status Flags (see graphic
below)Fix Status Information (see graphic below)
further information about navigation
output (see graphic below)
Time to first fix (millisecond time tag)
Milliseconds since Startup / Reset

Format4

U1-

gpsFix

-

5

X1

-

flags

-

6
7

X1
X1

-

fixStatflags2

-

8
12

U4
U4

-

ttff
msss

ms
ms

Bitfield flags
This graphic explains the bits of flags

Name

Description

gpsFixOk
diffSoln
wknSettowSet1 = position and velocity valid and within DOP and ACC Masks.
1 = differential corrections were applied
1 = Week Number valid (seeTime Validity section for details)
1 = Time of Week valid (seeTime Validity section for details)

Bitfield fixStat
This graphic explains the bits of fixStat

UBX-13003221 - R17

Early Production Information

Page 338 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

diffCorr
mapMatching

1 = differential corrections available
map matching status:
00: none
01: valid but not used, i.e. map matching data was received, but was too old
10: valid and used, map matching data was applied
11: valid and used, map matching data was applied. In case of sensor unavailability map matchingdata enables dead reckoning. This requires map matched latitude/longitude or heading data.

Bitfield flags2
This graphic explains the bits of flags2

Name

Description

psmState

power save mode state
0: ACQUISITION [or when psm disabled]
1: TRACKING
2: POWER OPTIMIZED TRACKING
3: INACTIVE

spoofDetState

Spoofing detection state (not supported in protocol versions less than 18)
0: Unknown or deactivated
1: No spoofing indicated
2: Spoofing indicated
3: Multiple spoofing indications
Note that the spoofing state value only reflects the dector state for the current navigation epoch. As
spoofing can be detected most easily at the transition from real signal to spoofing signal, this is also
where the detector is triggered the most. I.e. a value of 1 - No spoofing indicateddoes not mean thatthe receiver is not spoofed, it simply states that the detector was not triggered in this epoch.

UBX-13003221 - R17

Early Production Information

Page 339 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.22 UBX-NAV-SVINFO (0x01 0x30)
32.17.22.1 Space Vehicle Information
Message

UBX-NAV-SVINFO

Description

Space Vehicle Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Information about satellites used or visible
This message has only been retained for backwards compatibility; users arerecommended to use the UBX-NAV-SAT message in preference.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x30 8 + 12*numCh

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Number of channels
Bitmask (see graphic below)
Reserved

Format

0

U4

-

iTOW

ms

4
5
6

U1
X1
U1[2]

-

numCh
globalFlags
reserved1-

Start of repeated block (numCh times)

8 + 12*N

U1

-

chn

-

9 + 12*N

U1

-

svid

-

10 + 12*N
11 + 12*N
12 + 12*N
13 + 12*N
14 + 12*N
16 + 12*N

X1
X1
U1
I1
I2
I4

-

flags
quality
cno
elev
azim
prRes

dBHz
deg
deg
cm

Channel number, 255 for SVs not
assigned to a channel
Satellite ID, see Satellite Numbering for
assignment
Bitmask (see graphic below)
Bitfield (see graphic below)
Carrier to Noise Ratio (Signal Strength)
Elevation in integer degrees
Azimuth in integer degrees
Pseudo range residual in centimeters

End of repeated block

Bitfield globalFlags
This graphic explains the bits of globalFlags

UBX-13003221 - R17

Early Production Information

Page 340 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

chipGen

Chip hardware generation
0: Antaris, Antaris 4
1: u-blox 5
2: u-blox 6
3: u-blox 7
4: u-blox 8 / u-blox M8

Bitfield flags
This graphic explains the bits of flags

Name

Description

svUseddiffCorr
orbitAvail
orbitEphunhealthy
orbitAlm
orbitAopsmoothed

SV is used for navigation
Differential correction data is available for this SV
Orbit information is available for this SV (Ephemeris or Almanac)
Orbit information is Ephemeris
SV is unhealthy / shall not be used
Orbit information is Almanac Plus
Orbit information is AssistNow Autonomous
Carrier smoothed pseudorange used

Bitfield quality
This graphic explains the bits of quality

Name

Description

qualityInd

Signal Quality indicator (range 0..7). The following list shows the meaning of the different QI values:
0: no signal
1: searching signal
2: signal acquired
3: signal detected but unusable
4: code locked and time synchronized
5, 6, 7: code and carrier locked and time synchronized
Note: Since IMES signals are not time synchronized, a channel tracking an IMES signal can neverreach a quality indicator value of higher than 3.

UBX-13003221 - R17

Early Production Information

Page 341 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.23 UBX-NAV-SVIN (0x01 0x3B)
32.17.23.1 Survey-in data
Message

UBX-NAV-SVIN

Description

Survey-in data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20, 20.01, 20.1, 20.2 and 20.3(only withHigh Precision GNSS products)

Type

Periodic/Polled

Comment

This message contains information about survey-in parameters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x3B 40

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Reserved
GPS time of week of the navigation epoch.
See the description of iTOW for details.
Passed survey-in observation time
Current survey-in mean position ECEF X
coordinate
Current survey-in mean position ECEF Y
coordinate
Current survey-in mean position ECEF Z
coordinate
Current high-precision survey-in mean
position ECEF X coordinate. Must be in therange -99..+99.
The current survey-in mean position ECEF
X coordinate, in units of cm, is given by
meanX + (0.01 * meanXHP)
Current high-precision survey-in mean
position ECEF Y coordinate. Must be in
the range -99..+99.
The current survey-in mean position ECEF
Y coordinate, in units of cm, is given by
meanY + (0.01 * meanYHP)
Current high-precision survey-in mean
position ECEF Z coordinate. Must be in
the range -99..+99.
The current survey-in mean position ECEF
Z coordinate, in units of cm, is given by
meanZ + (0.01 * meanZHP)
Reserved
Current survey-in mean position accuracy

Format

0
1
4

U1
U1[3]
U4

-

versionreserved1
iTOW

ms

8
12

U4
I4

-

dur
meanX

s
cm

16

I4

-

meanY

cm

20

I4

-

meanZ

cm

24

I1

-

meanXHP

0.1_
mm

25

I1

-

meanYHP

0.1_
mm

26

I1

-

meanZHP

0.1_
mm

27
28

U1
U4

-

reserved2
meanAcc

0.1_
mm

UBX-13003221 - R17

Early Production Information

Page 342 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-SVIN continued
Byte Offset

Number

Scaling

Name

Unit

Description

Number of position observations usedduring survey-in
Survey-in position validity flag, 1 = valid,
otherwise 0
Survey-in in progress flag, 1 = in-progress,
otherwise 0
Reserved

Format

32

U4

-

obs

-

36

U1

-

valid

-

37

U1

-

active

-

38

U1[2]

-

reserved3-

32.17.24 UBX-NAV-TIMEBDS (0x01 0x24)
32.17.24.1 BDS Time Solution
Message

UBX-NAV-TIMEBDS

Description

BDS Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2,
20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message reports the precise BDS time of the most recent navigation
solution including validity flags and an accuracy estimate.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x24 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
BDS time of week (rounded to seconds)
Fractional part of SOW (range: +/500000000).
The precise BDS time of week in seconds
is:
SOW + fSOW * 1e-9
BDS week number of the navigation epoch
BDS leap seconds (BDS-UTC)
Validity Flags (see graphic below)
Time Accuracy Estimate

Format

0

U4

-

iTOW

ms

4
8

U4
I4

-

SOW
fSOW

s
ns

12
14
15
16

I2
I1
X1
U4

-

week
leapS
valid
tAcc

s
ns

UBX-13003221 - R17

Early Production Information

Page 343 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

sowValid
weekValid
leapSValid

1 = Valid SOW and fSOW (seeTime Validity section for details)
1 = Valid week (seeTime Validity section for details)
1 = Valid leapS

32.17.25 UBX-NAV-TIMEGAL (0x01 0x25)
32.17.25.1 Galileo Time Solution
Message

UBX-NAV-TIMEGAL

Description

Galileo Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message reports the precise Galileo time of the most recent navigation
solution including validity flags and an accuracy estimate.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x25 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Galileo time of week (rounded to seconds)
Fractional part of the Galileo time of week(range: +/-500000000).
The precise Galileo time of week inseconds is:
galTow + fGalTow * 1e-9
Galileo week number
Galileo leap seconds (Galileo-UTC)
Validity Flags (see graphic below)
Time Accuracy Estimate

Format

0

U4

-

iTOW

ms

4
8

U4
I4

-

galTow
fGalTow

s
ns

12
14
15
16

I2
I1
X1
U4

-

galWno
leapS
valid
tAcc

s
ns

UBX-13003221 - R17

Early Production Information

Page 344 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

galTowValid
galWnoValid
leapSValid

1 = Valid galTow and fGalTow (seeTime Validity section for details)
1 = Valid galWno (seeTime Validity section for details)
1 = Valid leapS

32.17.26 UBX-NAV-TIMEGLO (0x01 0x23)
32.17.26.1 GLO Time Solution
Message

UBX-NAV-TIMEGLO

Description

GLO Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2,
20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message reports the precise GLO time of the most recent navigation
solution including validity flags and an accuracy estimate.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x23 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
GLONASS time of day (rounded to integer
seconds)
Fractional part of TOD (range: +/500000000).
The precise GLONASS time of day inseconds is:
TOD + fTOD * 1e-9
Current date (range: 1-1461), starting at 1
from the 1st Jan of the year indicated by
N4 and ending at 1461 at the 31st Dec of
the third year after that indicated by N4
Four-year interval number starting from1996 (1=1996, 2=2000, 3=2004...)
Validity flags (see graphic below)
Time Accuracy Estimate

Format

0

U4

-

iTOW

ms

4

U4

-

TOD

s

8

I4

-

fTOD

ns

12

U2

-

Nt

days

14

U1

-

N4

-

15
16

X1
U4

-

valid
tAcc

ns

UBX-13003221 - R17

Early Production Information

Page 345 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

todValid
dateValid

1 = Valid TOD and fTOD (seeTime Validity section for details)
1 = Valid N4 and Nt (seeTime Validity section for details)

32.17.27 UBX-NAV-TIMEGPS (0x01 0x20)
32.17.27.1 GPS Time Solution
Message

UBX-NAV-TIMEGPS

Description

GPS Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message reports the precise GPS time of the most recent navigation
solution including validity flags and an accuracy estimate.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x20 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Fractional part of iTOW (range: +/500000).
The precise GPS time of week in seconds
is:(iTOW * 1e-3) + (fTOW * 1e-9)
GPS week number of the navigation epoch
GPS leap seconds (GPS-UTC)
Validity Flags (see graphic below)
Time Accuracy Estimate

Format

0

U4

-

iTOW

ms

4

I4

-

fTOW

ns

8
10
11
12

I2
I1
X1
U4

-

week
leapS
valid
tAcc

s
ns

UBX-13003221 - R17

Early Production Information

Page 346 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

towValid
weekValid
leapSValid

1 = Valid GPS time of week (iTOW & fTOW, (seeTime Validity section for details)
1 = Valid GPS week number (seeTime Validity section for details)
1 = Valid GPS leap seconds

32.17.28 UBX-NAV-TIMELS (0x01 0x26)
32.17.28.1 Leap second event information
Message

UBX-NAV-TIMELS

Description

Leap second event information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Information about the upcoming leap second event if one is scheduled.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x26 24

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
Message version (0x00 for this version).
Reserved
Information source for the current numberof leap seconds.
0: Default (hardcoded in the firmware, canbe outdated)
1: Derived from time difference between
GPS and GLONASS time
2: GPS
3: SBAS
4: BeiDou
5: Galileo
6: Aided data
7: Configured
255: Unknown

Format

0

U4

-

iTOW

ms

4
5
8

U1
U1[3]
U1

-

versionreserved1
srcOfCurrLs-

UBX-13003221 - R17

Early Production Information

Page 347 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-NAV-TIMELS continued
Byte Offset

Number

Scaling

Name

Unit

Descriptions

Current number of leap seconds since
start of GPS time (Jan 6, 1980). It reflects
how much GPS time is ahead of UTC time.
Galileo number of leap seconds is thesame as GPS. BeiDou number of leap
seconds is 14 less than GPS. GLONASS
follows UTC time, so no leap seconds.
Information source for the future leap
second event.
0: No source
2: GPS
3: SBAS
4: BeiDou
5: Galileo
6: GLONASS
Future leap second change if one isscheduled. +1 = positive leap second, -1 =negative leap second, 0 = no future leap
second event scheduled or no information
available.
Number of seconds until the next leap
second event, or from the last leap second
event if no future event scheduled. If > 0
event is in the future, = 0 event is now, < 0event is in the past. Valid only if
validTimeToLsEvent = 1.
GPS week number (WN) of the next leap
second event or the last one if no future
event scheduled. Valid only if
validTimeToLsEvent = 1.
GPS day of week number (DN) for the next
leap second event or the last one if nofuture event scheduled. Valid only if
validTimeToLsEvent = 1. (GPS and Galileo
DN: from 1 = Sun to 7 = Sat. BeiDou DN:
from 0 = Sun to 6 = Sat.)
Reserved
Validity flags (see graphic below)

Format9

I1-

currLs10

U1-

srcOfLsChange -

11

I1

-

lsChange

12

I4

-

timeToLsEvent s

16

U2

-

dateOfLsGpsWn -

18

U2

-

dateOfLsGpsDn -

20
23

U1[3]
X1

-

reserved2
valid

UBX-13003221 - R17s-

Early Production Information

Page 348 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

validCurrLs
validTimeToLs
Event

1 = Valid current number of leap seconds value.
1 = Valid time to next leap second event or from the last leap second event if no future event
scheduled.

32.17.29 UBX-NAV-TIMEUTC (0x01 0x21)
32.17.29.1 UTC Time Solution
Message

UBX-NAV-TIMEUTC

Description

UTC Time Solution

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Note that during a leap second there may be more or less than 60 seconds in aminute.
See the description of leap seconds for details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x21 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

iTOW

4
8
12
14
15
16
17
18
19

U4
I4
U2
U1
U1
U1
U1
U1
X1

-

tAcc
nano
year
month
day
hour
min
sec
valid

UBX-13003221 - R17

GPS time of week of the navigation epoch.
See the description of iTOW for details.
nsTime accuracy estimate (UTC)ns
Fraction of second, range -1e9 .. 1e9 (UTC)yYear, range 1999..2099 (UTC)month Month, range 1..12 (UTC)dDay of month, range 1..31 (UTC)hHour of day, range 0..23 (UTC)min
Minute of hour, range 0..59 (UTC)sSeconds of minute, range 0..60 (UTC)
Validity Flags (see graphic below)

Early Production Information

Page 349 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield valid
This graphic explains the bits of valid

Name

Description

validTOW
validWKN
validUTC
utcStandard

1 = Valid Time of Week (seeTime Validity section for details)
1 = Valid Week Number (seeTime Validity section for details)
1 = Valid UTC TimeUTC standard identifier.
0: Information not available
1: Communications Research Labratory (CRL)
2: National Institute of Standards and Technology (NIST)
3: U.S. Naval Observatory (USNO)
4: International Bureau of Weights and Measures (BIPM)
5: European Laboratory (tbd)
6: Former Soviet Union (SU)
7: National Time Service Center, China (NTSC)
15: Unknown

32.17.30 UBX-NAV-VELECEF (0x01 0x11)
32.17.30.1 Velocity Solution in ECEF
Message

UBX-NAV-VELECEF

Description

Velocity Solution in ECEF

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x11 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
ECEF X velocity
ECEF Y velocity
ECEF Z velocity
Speed accuracy estimate

Format

0

U4

-

iTOW

ms

4
8
12
16

I4
I4
I4
U4

-

ecefVX
ecefVY
ecefVZ
sAcc

cm/s
cm/s
cm/s
cm/s

UBX-13003221 - R17

Early Production Information

Page 350 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.17.31 UBX-NAV-VELNED (0x01 0x12)
32.17.31.1 Velocity Solution in NED
Message

UBX-NAV-VELNED

Description

Velocity Solution in NED

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

See important comments concerning validity of position given in section
Navigation Output Filters.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x01 0x12 36

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

GPS time of week of the navigation epoch.
See the description of iTOW for details.
North velocity component
East velocity component
Down velocity component
Speed (3-D)
Ground speed (2-D)
Heading of motion 2-D
Speed accuracy Estimate
Course / Heading accuracy estimate

Format

0

U4

-

iTOW

ms

4
8
12
16
20
24
28
32

I4
I4
I4
U4
U4
I4
U4
U4

1e-5
1e-5

velN
velE
velD
speed
gSpeedheading
sAcc
cAcc

cm/s
cm/s
cm/s
cm/s
cm/s
deg
cm/s
deg

UBX-13003221 - R17

Early Production Information

Page 351 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.18 UBX-RXM (0x02)
Receiver Manager Messages: i.e. Satellite Status, RTC Status.
Messages in the RXM class are used to output status and result data from the Receiver Manager.
32.18.1 UBX-RXM-IMES (0x02 0x61)
32.18.1.1 Indoor Messaging System Information
Message

UBX-RXM-IMES

Description

Indoor Messaging System Information

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message shows the IMES stations the receiver is currently tracking, theirdata rate, the signal level, the Doppler (with respect to 1575.4282MHz) and what
data (without protocol specific overhead) it has received from these stations so
far.
This message is sent out at the navigation rate the receiver is currently set to.
Therefore it allows users to get an overview on the receiver's current state fromthe IMES perspective.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x61 4 + 44*numTx

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Number of transmitters contained in themessage
Message version (0x01 for this version)
Reserved

Format

0

U1

-

numTx

-

1
2

U1
U1[2]

-

versionreserved1-

Start of repeated block (numTx times)

4 + 44*N
5 + 44*N
6 + 44*N
9 + 44*N
10 + 44*N
12 + 44*N

U1
U1
U1[3]
U1
U1[2]
I4

2^-12

reserved2
txId
reserved3
cno
reserved4
dopplerdBHz
Hz

16 + 44*N

X4-

position1_1-

20 + 44*N

X4-

position1_2-

24 + 44*N

X4-

position2_1-

28 + 44*NI4

32 + 44*N

I4

180*2^- lat24
360*2^- lon
25

UBX-13003221 - R17

deg

Reserved
Transmitter identifier
Reserved
Carrier to Noise Ratio (Signal Strength)
Reserved
Doppler frequency with respect to 1575.
4282MHz [IIIII.FFF Hz]
Position 1 Frame (part 1/2) (seegraphic
below)
Position 1 Frame (part 2/2) (seegraphic
below)
Position 2 Frame (part 1/3) (seegraphic
below)
Latitude, Position 2 Frame (part 2/3)

degLongitude, Position 2 Frame (part 3/3)

Early Production Information

Page 352 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-IMES continued
Byte Offset

Number

Scaling

Name

Unit

Description

Short ID Frame (see graphic below)
Medium ID LSB, Medium ID Frame (part1/2)
Medium ID Frame (part 2/2) (see graphic
below)

Format36 + 44*N
40 + 44*N

X4
U4

-

shortIdFrame
mediumIdLSB-

44 + 44*N

X4-

mediumId_2-

End of repeated block

Bitfield position1_1
This graphic explains the bits of position1_1

Name

Description

pos1Floor
pos1LatFloor number [1.0 floor resolution] (Offset: -50 floor)
Latitude [deg * (180 / 2^23)]

Bitfield position1_2
This graphic explains the bits of position1_2

Name

Description

pos1Lonpos1ValidLongitude [deg * (360 / 2^24)]
Position 1 Frame valid

Bitfield position2_1
This graphic explains the bits of position2_1

UBX-13003221 - R17

Early Production Information

Page 353 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

pos2Floor
pos2Alt
pos2Acc
pos2Valid

Floor number [0.5 floor resolution] (Offset: -50 floor)
Altitude [m] (Offset: -95m)
Accuracy Index (0:undef, 1:<7m, 2:<15m, 3:>15m)
Position 2 Frame valid

Bitfield shortIdFrame
This graphic explains the bits of shortIdFrame

Name

Description

shortId
shortValidshortBoundary

Short ID
Short ID Frame valid
Boundary Bit

Bitfield mediumId_2
This graphic explains the bits of mediumId_2

Name

Description

mediumIdMSB
mediumValidmediumboundaryMedium ID MSB

UBX-13003221 - R17

Medium ID Frame valid
Boundary Bit

Early Production Information

Page 354 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.18.2 UBX-RXM-MEASX (0x02 0x14)
32.18.2.1 Satellite Measurements for RRLP
Message

UBX-RXM-MEASX

Description

Satellite Measurements for RRLP

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

The message payload data is, where possible and appropriate, according to theRadio Resource LCS (Location Services) Protocol (RRLP) [1]. One exception is thesatellite and GNSS ids, which here are given according to the Satellite
Numbering scheme. The correct satellites have to be selected and their satellite
ID translated accordingly [1, tab. A.10.14] for use in a RRLP Measure Position
Response Component. Similarly, the measurement reference time of week has
to be forwarded correctly (modulo 14400000 for the 24 LSB GPS measurements
variant, modulo 3600000 for the 22 LSB Galileo and Additional Navigation
Satelllite Systems (GANSS) measurements variant) of the RRLP measureposition response to the SMLC.
Reference: [1] ETSI TS 144 031 V11.0.0 (2012-10), Digital cellular
telecommunications system (Phase 2+), Location Services (LCS), Mobile Station(MS) - Serving Mobile Location Centre (SMLC), Radio Resource LCS Protocol(RRLP), (3GPP TS 44.031 version 11.0.0 Release 11).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x14 44 + 24*numSV

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version, currently 0x01
Reserved
GPS measurement reference time
GLONASS measurement reference time
BeiDou measurement reference time
Reserved
QZSS measurement reference time
GPS measurement reference time
accuracy (0xffff = > 4s)
GLONASS measurement reference time
accuracy (0xffff = > 4s)
BeiDou measurement reference time
accuracy (0xffff = > 4s)
Reserved
QZSS measurement reference time
accuracy (0xffff = > 4s)
Number of satellites in repeated block
Flags (see graphic below)
Reserved

Format

0
1
4
8
12
16
20
24

U1
U1[3]
U4
U4
U4
U1[4]
U4
U2

2^-4

versionreserved1
gpsTOW
gloTOW
bdsTOW
reserved2
qzssTOW
gpsTOWacc

ms
ms
ms
ms
ms

26

U2

2^-4

gloTOWacc

ms

28

U2

2^-4

bdsTOWacc

ms

30
32

U1[2]
U2

2^-4

reserved3
qzssTOWacc

ms

34
35
36

U1
U1
U1[8]

-

numSV
flags
reserved4-

UBX-13003221 - R17

Early Production Information

Page 355 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-MEASX continued
Byte Offset

Number

Scaling

Name

Unit

Description

GNSS ID (see Satellite Numbering)
Satellite ID (see Satellite Numbering)
carrier noise ratio (0..63)
multipath index (according to [1]) (0 = notmeasured, 1 = low, 2 = medium, 3 = high)Doppler measurement
Doppler measurement
whole value of the code phasemeasurement (0..1022 for GPS)fractional value of the code phasemeasurement (0..1023)
Code phase
Integer (part of the) code phasepseudorange RMS error index (accordingto [1]) (0..63)
Reserved

FormatStart of repeated block (numSV times)

44 + 24*N
45 + 24*N
46 + 24*N
47 + 24*N

U1
U1
U1
U1

-

gnssIdsvId
cNo
mpathIndic-

48 + 24*N
52 + 24*N
56 + 24*N

I4
I4
U2

0.04
0.2
-

dopplerMS
dopplerHzwholeChips

m/s
Hz
-

58 + 24*N

U2-

fracChips-

60 + 24*N
64 + 24*N
65 + 24*N

U4
U1
U1

2^-21
-

ms
ms
-

66 + 24*N

U1[2]

-

codePhase
intCodePhase
pseuRangeRMSE
rr
reserved5-

End of repeated block

Bitfield flags
This graphic explains the bits of flags

Name

Description

towSetTOW set (0 = no, 1 or 2 = yes)

32.18.3 UBX-RXM-PMREQ (0x02 0x41)
32.18.3.1 Requests a Power Management task
Message

UBX-RXM-PMREQ

Description

Requests a Power Management task

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

Request of a Power Management related task of the receiver.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x02 0x41 8

PayloadChecksumsee below CK_A CK_B

Payload Contents:

UBX-13003221 - R17

Early Production Information

Page 356 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-PMREQ continued
Byte Offset

Number

Scaling

Name

Unit

Description

Scaling

Name

Unit

Description

Duration of the requested task, set to zerofor infinite duration. The maximum
supported time is 12 days.
task flags (see graphic below)

FormatByte Offset

NumberFormat0

U4-

duration

ms

4

X4

-

flags

-

Bitfield flags
This graphic explains the bits of flags

Name

Description

backup

The receiver goes into backup mode for a time period defined by duration. Provided that it is notconnected to USB

32.18.3.2 Requests a Power Management task
Message

UBX-RXM-PMREQ

Description

Requests a Power Management task

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

CommandComment

Request of a Power Management related task of the receiver.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x41 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

DescriptionmsMessage version (0x00 for this version)
Reserved
Duration of the requested task, set to zerofor infinite duration. The maximum
supported time is 12 days.
task flags (see graphic below)
Configure pins to wakeup the receiver. The
receiver wakes up if there is either a fallingor a rising edge on one of the configured
pins (see graphic below)

Format

0
1
4

U1
U1[3]
U4

-

versionreserved1
duration

8
12

X4
X4

-

flags
wakeupSources -UBX-13003221 - R17

Early Production Information

Page 357 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

backup

The receiver goes into backup mode for a time period defined by duration. Provided that it is notconnected to USB
Force receiver backup while USB is connected. USB interface will be disabled.

force

Bitfield wakeupSources
This graphic explains the bits of wakeupSources

Name

Description

uartrxextint0
extint1
spics

Wakeup the receiver if there is an edge on the UART RX pin.
Wakeup the receiver if there is an edge on the EXTINT0 pin.
Wakeup the receiver if there is an edge on the EXTINT1 pin.
Wakeup the receiver if there is an edge on the SPI CS pin.

32.18.4 UBX-RXM-RAWX (0x02 0x15)
32.18.4.1 Multi-GNSS Raw Measurement Data
Message

UBX-RXM-RAWX

Description

Multi-GNSS Raw Measurement Data

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 17(only with Time Sync products)

Type

Periodic/Polled

Comment

This message contains the information needed to be able to generate a RINEX 3
multi-GNSS observation file.
This message contains pseudorange, Doppler, carrier phase, phase lock andsignal quality information for GNSS satellites once signals have been
synchronized. This message supports all active GNSS.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x15 16 + 32*numMeas

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

FormatUBX-13003221 - R17

Early Production Information

Page 358 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-RAWX continued
Byte Offset

Number

Scaling

Name

Unit

s

Description

Format0

R8-

rcvTow

8
10

U2
I1

-

week
leapS

11
12

U1
X1

-

numMeasrecStat

13

U1[3]

-

reserved1

Measurement time of week in receiver
local time approximately aligned to the
GPS time system. The receiver local timeof week, week number and leap second
information can be used to translate thetime to other time systems. Moreinformation about the difference in timesystems can be found in RINEX 3
documentation. For a receiver operating in
GLONASS only mode, UTC time can be
determined by subtracting the leapS fieldfrom GPS time regardless of whether the
GPS leap seconds are valid.
weeks GPS week number in receiver local time.
s
GPS leap seconds (GPS-UTC). This field
represents the receiver's best knowledgeof the leap seconds offset. A flag is givenin the recStat bitfield to indicate if theleap seconds are known.
Number of measurements to follow
Receiver tracking status bitfield (seegraphic below)
Reserved

Start of repeated block (numMeas times)

16 + 32*N

R8

-

prMes

24 + 32*N

R8

-

cpMes

32 + 32*N

R4

-

doMes

36 + 32*N

U1-

gnssId37 + 32*N

U1

-

svId

38 + 32*N

U1-

reserved2

UBX-13003221 - R17m

Pseudorange measurement [m].
GLONASS inter frequency channel delays
are compensated with an internal
calibration table.
cycles Carrier phase measurement [cycles]. The
carrier phase initial ambiguity is initializedusing an approximate value to make themagnitude of the phase close to thepseudorange measurement. Clock resets
are applied to both phase and code
measurements in accordance with the
RINEX specification.
Hz
Doppler measurement (positive sign for
approaching satellites) [Hz]
GNSS identifier (see Satellite Numbering
for a list of identifiers)
Satellite identifier (see Satellite
Numbering)Reserved

Early Production Information

Page 359 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-RAWX continued
Byte Offset

Number

Scaling

Name

Unit

-

Description

Format39 + 32*N

U1-

freqId40 + 32*N

U2-

locktime

42 + 32*N

U1

-

cno

43 + 32*N

X1

44 + 32*N

X1

0.
prStdev
01*2^n0.004 cpStdev

45 + 32*N

X1

46 + 32*N

X1

0.
doStdev002*2^
ntrkStat47 + 32*N

U1-

reserved3

Only used for GLONASS: This is thefrequency slot + 7 (range from 0 to 13)
ms
Carrier phase locktime counter (maximum
64500ms)dBHz Carrier-to-noise density ratio (signal
strength) [dB-Hz]m
Estimated pseudorange measurement
standard deviation (see graphic below)
cycles Estimated carrier phase measurement
standard deviation (note a raw value of
0x0F indicates the value is invalid) (seegraphic below)
Hz
Estimated Doppler measurement
standard deviation. (see graphic below)-

Tracking status bitfield (see graphic below)
Reserved

End of repeated block

Bitfield recStat
This graphic explains the bits of recStat

Name

Description

leapSec
clkReset

Leap seconds have been determined
Clock reset applied. Typically the receiver clock is changed in increments of integer milliseconds.

Bitfield prStdev
This graphic explains the bits of prStdev

UBX-13003221 - R17

Early Production Information

Page 360 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

prStd

Estimated pseudorange standard deviation

Bitfield cpStdev
This graphic explains the bits of cpStdev

Name

Description

cpStd

Estimated carrier phase standard deviation

Bitfield doStdev
This graphic explains the bits of doStdev

Name

Description

doStd

Estimated Doppler standard deviation

Bitfield trkStat
This graphic explains the bits of trkStat

Name

Description

prValid
cpValid
halfCyc
subHalfCyc

Pseudorange valid

UBX-13003221 - R17

Carrier phase valid
Half cycle valid
Half cycle subtracted from phase

Early Production Information

Page 361 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.18.4.2 Multi-GNSS Raw Measurement Data
Message

UBX-RXM-RAWX

Description

Multi-GNSS Raw Measurement Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01(only with ADR or High Precision GNSS or Time Sync
products)

Type

Periodic/Polled

Comment

This message contains the information needed to be able to generate a RINEX 3
multi-GNSS observation file.
This message contains pseudorange, Doppler, carrier phase, phase lock andsignal quality information for GNSS satellites once signals have been
synchronized. This message supports all active GNSS.
The only difference between this version of the message and the previous
version (UBX-RXM-RAWX-DATA0) is the addition of the version field.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x15 16 + 32*numMeas

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

s

Description

Format0

R8-

rcvTow

8
10

U2
I1

-

week
leapS

11
12

U1
X1

-

numMeasrecStat

13
14

U1
U1[2]

-

versionreserved1

Measurement time of week in receiver
local time approximately aligned to the
GPS time system.
The receiver local time of week, weeknumber and leap second information canbe used to translate the time to other timesystems. More information about thedifference in time systems can be found in
RINEX 3 documentation. For a receiver
operating in GLONASS only mode, UTC
time can be determined by subtracting
the leapS field from GPS time regardlessof whether the GPS leap seconds are valid.
weeks GPS week number in receiver local time.
s
GPS leap seconds (GPS-UTC). This field
represents the receiver's best knowledgeof the leap seconds offset. A flag is givenin the recStat bitfield to indicate if theleap seconds are known.
Number of measurements to follow
Receiver tracking status bitfield (seegraphic below)
Message version (0x01 for this version).
Reserved

Start of repeated block (numMeas times)

UBX-13003221 - R17

Early Production Information

Page 362 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-RAWX continued
Byte Offset

Number

Scaling

Name

Unit

m

Description

Format16 + 32*N

R8

-

prMes

24 + 32*N

R8

-

cpMes

32 + 32*N

R4

-

doMes

36 + 32*N

U1-

gnssId37 + 32*N

U1

-

svId

38 + 32*N

U1

-

sigId

39 + 32*N

U1-

freqId40 + 32*N

U2-

locktime

42 + 32*N

U1

-

cno

43 + 32*N

X1

44 + 32*N

X1

0.
prStdev
01*2^n0.004 cpStdev

45 + 32*N

X1

46 + 32*N

X1

0.
doStdev002*2^
ntrkStat47 + 32*N

U1-

reserved2

Pseudorange measurement [m].
GLONASS inter frequency channel delays
are compensated with an internal
calibration table.
cycles Carrier phase measurement [cycles]. The
carrier phase initial ambiguity is initializedusing an approximate value to make themagnitude of the phase close to thepseudorange measurement. Clock resets
are applied to both phase and code
measurements in accordance with the
RINEX specification.
Hz
Doppler measurement (positive sign for
approaching satellites) [Hz]
GNSS identifier (see Satellite Numbering
for a list of identifiers)
Satellite identifier (see Satellite
Numbering)
New style signal identifier (see Signal
Identifiers).(not supported in protocol
versions less than 27)
Only used for GLONASS: This is thefrequency slot + 7 (range from 0 to 13)
ms
Carrier phase locktime counter (maximum
64500ms)dBHz Carrier-to-noise density ratio (signal
strength) [dB-Hz]m
Estimated pseudorange measurement
standard deviation (see graphic below)
cycles Estimated carrier phase measurement
standard deviation (note a raw value of
0x0F indicates the value is invalid) (seegraphic below)
Hz
Estimated Doppler measurement
standard deviation. (see graphic below)-

Tracking status bitfield (see graphic below)
Reserved

End of repeated block

UBX-13003221 - R17

Early Production Information

Page 363 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield recStat
This graphic explains the bits of recStat

Name

Description

leapSec
clkReset

Leap seconds have been determined
Clock reset applied. Typically the receiver clock is changed in increments of integer milliseconds.

Bitfield prStdev
This graphic explains the bits of prStdev

Name

Description

prStd

Estimated pseudorange standard deviation

Bitfield cpStdev
This graphic explains the bits of cpStdev

Name

Description

cpStd

Estimated carrier phase standard deviation

Bitfield doStdev
This graphic explains the bits of doStdev

UBX-13003221 - R17

Early Production Information

Page 364 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

doStd

Estimated Doppler standard deviation

Bitfield trkStat
This graphic explains the bits of trkStat

Name

Description

prValid
cpValid
halfCyc
subHalfCyc

Pseudorange valid
Carrier phase valid
Half cycle valid
Half cycle subtracted from phase

32.18.5 UBX-RXM-RLM (0x02 0x59)
32.18.5.1 Galileo SAR Short-RLM report
Message

UBX-RXM-RLM

Description

Galileo SAR Short-RLM report

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

OutputComment

This message contains the contents of any Galileo Search and Rescue (SAR)
Short Return Link Message detected by the receiver.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x59 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Message type (0x01 for Short-RLM)
Identifier of transmitting satellite (seeSatellite Numbering)Reserved
Beacon identifier (60 bits), with bytes
ordered by earliest transmitted (mostsignificant) first. Top four bits of first byte
are zero.
Message code (4 bits)
Parameters (16 bits), with bytes orderedby earliest transmitted (most significant)first.

Format

0
1
2

U1
U1
U1

-

version
type
svId

-

3
4

U1
U1[8]

-

reserved1
beacon

-

12
13

U1
U1[2]

-

messageparams-UBX-13003221 - R17

Early Production Information

Page 365 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-RLM continued
Byte Offset

Number

Scaling

Name

Unit

Description-

reserved2-

Reserved

Format15

U1

32.18.5.2 Galileo SAR Long-RLM report
Message

UBX-RXM-RLM

Description

Galileo SAR Long-RLM report

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

OutputComment

This message contains the contents of any Galileo Search and Rescue (SAR)Long Return Link Message detected by the receiver.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x59 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x00 for this version)
Message type (0x02 for Long-RLM)
Identifier of transmitting satellite (seeSatellite Numbering)Reserved
Beacon identifier (60 bits), with bytes
ordered by earliest transmitted (mostsignificant) first. Top four bits of first byte
are zero.
Message code (4 bits)
Parameters (96 bits), with bytes orderedby earliest transmitted (most significant)first.
Reserved

Format

0
1
2

U1
U1
U1

-

version
type
svId

-

3
4

U1
U1[8]

-

reserved1
beacon

-

12
13

U1
U1[12] -messageparams

-

25

U1[3]

reserved2-

UBX-13003221 - R17-

Early Production Information

Page 366 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.18.6 UBX-RXM-RTCM (0x02 0x32)
32.18.6.1 RTCM input status
Message

UBX-RXM-RTCM

Description

RTCM input status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 20.01, 20.1, 20.2, 20.3, 22, 23 and 23.01(only with ADR or High Precision GNSS products)

Type

OutputComment

Output upon processing of an RTCM input message
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x32 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0x02 for this version)
RTCM input status flags (see graphic
below)
Message subtype, only applies for RTCM
4072 message
Reference station ID
Message type

Format

0
1

U1
X1

-

version
flags

-

2

U2

-

subType

-

4
6

U2
U2

-

refStation
msgType-

Bitfield flags
This graphic explains the bits of flags

Name

Description

crcFailed

0 when RTCM message received and passed CRC check, 1 when failed in which case refStation andmsgType might be corrupted and misleading

UBX-13003221 - R17

Early Production Information

Page 367 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.18.7 UBX-RXM-SFRBX (0x02 0x13)
32.18.7.1 Broadcast Navigation Data Subframe
Message

UBX-RXM-SFRBX

Description

Broadcast Navigation Data Subframe

FirmwareSupported on:• u-blox 8 / u-blox M8 with protocol version 17(only with Time Sync products)

Type

OutputComment

This message reports a complete subframe of broadcast navigation data
decoded from a single signal. The number of data words reported in eachmessage depends on the nature of the signal. See the section on Broadcast
Navigation Data for further details.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x13 8 + 4*numWords

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Format

0
1

U1
U1

-

gnssId
svId

-

2
3

U1
U1

-

reserved1
freqId

-

4

U1

-

numWords

-

5
6
7

U1
U1
U1

-

reserved2
versionreserved3-

GNSS identifier (see Satellite Numbering)
Satellite identifier (see Satellite
Numbering)Reserved
Only used for GLONASS: This is thefrequency slot + 7 (range from 0 to 13)
The number of data words contained inthis message (0..16)
Reserved
Message version (0x01 for this version)
Reserved-

The data words

Start of repeated block (numWords times)

8 + 4*N

U4

-

dwrd

End of repeated block32.18.7.2 Broadcast Navigation Data Subframe
Message

UBX-RXM-SFRBX

Description

Broadcast Navigation Data Subframe

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

OutputComment

This message reports a complete subframe of broadcast navigation data
decoded from a single signal. The number of data words reported in eachmessage depends on the nature of the signal.
See the section on Broadcast Navigation Data for further details.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x02 0x13 8 + 4*numWords

PayloadChecksumsee below CK_A CK_B

Payload Contents:

UBX-13003221 - R17

Early Production Information

Page 368 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-SFRBX continued
Byte Offset

Number

Scaling

Name

Unit

Description

Scaling

Name

Unit

Description

FormatByte Offset

NumberFormat

0
1

U1
U1

-

gnssId
svId

-

2
3

U1
U1

-

reserved1
freqId

-

4

U1

-

numWords

-

5

U1

-

chn

-

6
7

U1
U1

-

versionreserved2-

GNSS identifier (see Satellite Numbering)
Satellite identifier (see Satellite
Numbering)Reserved
Only used for GLONASS: This is thefrequency slot + 7 (range from 0 to 13)
The number of data words contained inthis message (up to 10, for currently
supported signals)
The tracking channel number themessage was received on
Message version, (0x02 for this version)
Reserved-

The data words

Start of repeated block (numWords times)

8 + 4*N

U4

-

dwrd

End of repeated block32.18.8 UBX-RXM-SVSI (0x02 0x20)
32.18.8.1 SV Status Info
Message

UBX-RXM-SVSI

Description

SV Status Info

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

Status of the receiver manager knowledge about GPS Orbit Validity
This message has only been retained for backwards compatibility; users arerecommended to use the UBX-NAV-ORB message in preference.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x02 0x20 8 + 6*numSV

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

iTOW

4
6
7

I2
U1
U1

-

week
numVisnumSVGPS time of week of the navigation epoch.
See the description of iTOW for details.
weeks GPS week number of the navigation epoch
Number of visible satellites
Number of per-SV data blocks following

Start of repeated block (numSV times)

8 + 6*N
9 + 6*NU1
X1

UBX-13003221 - R17-

svid
svFlag-Satellite ID
Information Flags (see graphic below)

Early Production Information

Page 369 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-RXM-SVSI continued
Byte Offset

Number

Scaling

Name

Unit

Description

-

azim
elev
age

-

AzimuthElevationAge of Almanac and Ephemeris: (seegraphic below)

Format

10 + 6*N
12 + 6*N
13 + 6*N

I2
I1
X1

End of repeated block

Bitfield svFlag
This graphic explains the bits of svFlag

Name

Description

ura
healthyephValalmValnotAvailFigure of Merit (URA) range 0..15
SV healthy flag
Ephemeris valid
Almanac valid
SV not available

Bitfield age
This graphic explains the bits of age

Name

Description

almAgeAge of ALM in days offset by 4i.e. the reference time may be in the future:
ageOfAlm = (age & 0x0f) - 4

ephAgeAge of EPH in hours offset by 4.
i.e. the reference time may be in the future:
ageOfEph = ((age & 0xf0) >> 4) - 4

UBX-13003221 - R17

Early Production Information

Page 370 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.19 UBX-SEC (0x27)
Security Feature Messages
Messages in the SEC class are used for security features of the receiver.
32.19.1 UBX-SEC-UNIQID (0x27 0x03)
32.19.1.1 Unique Chip ID
Message

UBX-SEC-UNIQID

Description

Unique Chip ID

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.2, 20.
3, 22, 23 and 23.01

Type

OutputComment

This message is used to retrieve a unique chip identifier (40 bits, 5 bytes).
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x27 0x03 9

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionreserved1
uniqueId-

Message version (0x01 for this version)
Reserved
Unique chip ID

Format

0
1
4

U1
U1[3]
U1[5]

UBX-13003221 - R17

Early Production Information

Page 371 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.20 UBX-TIM (0x0D)
Timing Messages: i.e. Time Pulse Output, Time Mark Results.
Messages in the TIM class are used to output timing information from the receiver, like Time
Pulse and Time Mark measurements.
32.20.1 UBX-TIM-DOSC (0x0D 0x11)
32.20.1.1 Disciplined oscillator control
Message

UBX-TIM-DOSC

Description

Disciplined oscillator control

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

OutputComment

The receiver sends this message when it is disciplining an external oscillator andthe external oscillator is set up to be controlled via the host.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x11 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

versionreserved1
value-

Message version (0 for this version)
Reserved
The raw value to be applied to the DAC
controlling the external oscillator. The
least significant bits should be written to
the DAC, with the higher bits being
ignored.

Format

0
1
4

U1
U1[3]
U4

32.20.2 UBX-TIM-FCHG (0x0D 0x16)
32.20.2.1 Oscillator frequency changed notification
Message

UBX-TIM-FCHG

Description

Oscillator frequency changed notification

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Periodic/Polled

Comment

This message reports frequency changes commanded by the sync manager for
the internal and external oscillator. It is output at the configured rate even if thesync manager decides not to command a frequency change.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x16 32

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

version-Message version (0 for this version)

Format0

U1

UBX-13003221 - R17

Early Production Information

Page 372 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-FCHG continued
Byte Offset

Number

Scaling

Name

Unit

Description

Reserved
GPS time of week of the navigation epoch
from which the sync manager obtains the
GNSS specific data.
Like for the NAV message, the iTOW canbe used to group messages of a single
sync manager run together (See thedescription of iTOW for details)
Frequency increment of the internal
oscillator
Uncertainty of the internal oscillator
frequency increment
Current raw DAC setting commanded tothe internal oscillator
Frequency increment of the external
oscillator
Uncertainty of the external oscillator
frequency increment
Current raw DAC setting commanded tothe external oscillator

Format

1
4

U1[3]
U4

-

reserved1
iTOW

ms

8

I4

2^-8

intDeltaFreq

ppb

12

U4

2^-8

16

U4

-

intDeltaFreqU ppb
nc
intRaw
-

20

I4

2^-8

extDeltaFreq

24

U4

2^-8

28

U4

-

extDeltaFreqU ppb
nc
extRaw-

ppb

32.20.3 UBX-TIM-HOC (0x0D 0x17)
32.20.3.1 Host oscillator control
Message

UBX-TIM-HOC

Description

Host oscillator control

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Input

Comment

This message can be sent by the host to force the receiver to bypass thedisciplining algorithms in the SMGR and carry out the instructed changes tointernal or external oscillator frequency. No checks are carried out on the size ofthe frequency change requested, so normal limits imposed by the SMGR are
ignored.
It is recommended that the disciplining of that oscillator is disabled before thismessage is sent (i.e. by clearing the enableInternal or enableExternal flag in the
UBX-CFG-SMGR message), otherwise the autonomous disciplining processes may
cancel the effect of the direct command.
Note that the GNSS subsystem may temporarily lose track of some/all satellite
signals if a large change of the internal oscillator is made.
HeaderMessage Structure

Class ID

Length (Bytes)

0xB5 0x62 0x0D 0x17 8

PayloadChecksumsee below CK_A CK_B

Payload Contents:

UBX-13003221 - R17

Early Production Information

Page 373 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-HOC continued
Byte Offset

Number

Scaling

Name

Unit

Description

Scaling

Name

Unit

Description

Message version (0 for this version)
Id of oscillator:
0: internal oscillator
1: external oscillator
Flags (see graphic below)
Reserved
Required frequency offset or raw output,
depending on the flags

FormatByte Offset

NumberFormat

0
1

U1
U1

-

version
oscId

-

2
3
4

U1
U1
I4

2^-8

flags
reserved1
value

ppb/-

Bitfield flags
This graphic explains the bits of flags

Name

Description

raw

Type of value:
0: frequency offset
1: raw digital output

difference

Nature of value:
0: absolute (i.e. relative to 0)
1: relative to current setting

32.20.4 UBX-TIM-SMEAS (0x0D 0x13)
32.20.4.1 Source measurement
Message

UBX-TIM-SMEAS

Description

Source measurement

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Input/Output

Comment

Frequency and/or phase measurement of synchronization sources. The
measurements are relative to the nominal frequency and nominal phase.
The receiver reports the measurements on its sync sources using this message.
Which measurements are reported can be configured using UBX-CFG-SMGR.
The host may report offset of the receiver's outputs with this message as well.
The receiver has to be configured using UBX-CFG-SMGR to enable the use of theexternal measurement messages. Otherwise the receiver will ignore them.

UBX-13003221 - R17

Early Production Information

Page 374 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x13 12 + 24*numMeas

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message version (0 for this version)
Number of measurements in repeatedblock
Reserved
Time of the week
Reserved

Format

0
1

U1
U1

-

version
numMeas

-

2
4
8

U1[2]
U4
U1[4]

-

reserved1
iTOW
reserved2

ms-

Start of repeated block (numMeas times)

12 + 24*N

U1-sourceId

13 + 24*N
14 + 24*N

X1
I1

2^-8

flags
phaseOffsetFr ns
ac

15 + 24*N

U1

2^-8

phaseUncFrac

UBX-13003221 - R17-ns

Index of source. SMEAS can provide six
measurement sources. The first four
sourceId values represent measurements
made by the receiver and sent to the host.
The first of these with a sourceId value of
0 is a measurement of the internal
oscillator against the current receivertime-and-frequency estimate. Theinternal oscillator is being disciplined
against that estimate and this result
represents the current offset between theactual and desired internal oscillator
states. The next three sourceId values
represent frequency and timemeasurements made by the receiveragainst the internal oscillator. sourceId 1
represents the GNSS-derived frequency
and time compared with the internal
oscillator frequency and time. sourceId2
give measurements of a signal coming in
on EXTINT0. sourceId 3 corresponds to asimilar measurement on EXTINT1. The
remaining two of these measurements(sourceId 4 and 5) are made by the hostand sent to the receiver. A measurementwith sourceId 4 is a measurement by thehost of the internal oscillator and sourceId
5 indicates a host measurement of theexternal oscillator.
Flags (see graphic below)
Sub-nanosecond phase offset; the total
offset is the sum of phaseOffset andphaseOffsetFrac
Sub-nanosecond phase uncertainty

Early Production Information

Page 375 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-SMEAS continued
Byte Offset

Number

Scaling

Name

Unit

Description

Phase offset, positive if the source lags
accurate phase and negative if the sourceis early
Phase uncertainty (one standard
deviation)
Reserved
Frequency offset, positive if the source
frequency is too high, negative if thefrequency is too low.
Frequency uncertainty (one standard
deviation)

Format16 + 24*N

I4-

phaseOffset

ns

20 + 24*N

U4-phaseUncns

24 + 24*N
28 + 24*N

U1[4]
I4

2^-8

reserved3
freqOffset

ppb

32 + 24*N

U4

2^-8

freqUnc

ppb

End of repeated block

Bitfield flags
This graphic explains the bits of flags

Name

Description

freqValidphaseValid

1 = frequency measurement is valid
1 = phase measurement is valid

32.20.5 UBX-TIM-SVIN (0x0D 0x04)
32.20.5.1 Survey-in data
Message

UBX-TIM-SVIN

Description

Survey-in data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync or Time
Sync products)

Type

Periodic/Polled

Comment

This message contains information about survey-in parameters. For details
about the Time Mode see section Time Mode Configuration.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x04 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

dur

s

Passed survey-in observation time

Format0

U4

UBX-13003221 - R17

Early Production Information

Page 376 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-SVIN continued
Byte Offset

Number

Scaling

Name

Unit

cm

Description

Format

4

I4

-

meanX

8

I4

-

meanY

12

I4

-

meanZ

16

U4

-

meanV

20

U4

-

obs

24

U1

-

valid

25

U1

-

active

26

U1[2]

-

reserved1

Current survey-in mean position ECEF X
coordinatecm
Current survey-in mean position ECEF Y
coordinatecm
Current survey-in mean position ECEF Z
coordinatemm^2 Current survey-in mean position 3D
variance
Number of position observations usedduring survey-in
Survey-in position validity flag, 1 = valid,
otherwise 0
Survey-in in progress flag, 1 = in-progress,
otherwise 0
Reserved

32.20.6 UBX-TIM-TM2 (0x0D 0x03)
32.20.6.1 Time mark data
Message

UBX-TIM-TM2

Description

Time mark data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message contains information for high precision time stamping / pulse
counting.
The delay figures and timebase given in UBX-CFG-TP5 are also applied to thetime results output in this message.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x03 28

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Channel (i.e. EXTINT) upon which thepulse was measured
Bitmask (see graphic below)
rising edge counter.
week number of last rising edge
week number of last falling edge
tow of rising edge
millisecond fraction of tow of rising edgein nanoseconds
tow of falling edge

Format

0

U1

-

ch

-

1
2
4
6
8
12

X1
U2
U2
U2
U4
U4

-

flags
count
wnR
wnF
towMsR
towSubMsR

ms
ns

16

U4

-

towMsF

ms

UBX-13003221 - R17

Early Production Information

Page 377 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-TM2 continued
Byte Offset

Number

Scaling

Name

Unit

Description

millisecond fraction of tow of falling edgein nanoseconds
Accuracy estimate

Format20

U4-

towSubMsF

ns

24

U4

-

accEstns

Bitfield flags
This graphic explains the bits of flags

Name

Descriptionmode

0=single
1=runningrun

0=armed
1=stopped

newFallingEdg
etimeBase

new falling edge detected
0=Time base is Receiver Time
1=Time base is GNSS Time (the system according to the configuration inUBX-CFG-TP5 for tpIdx=0)
2=Time base is UTC (the variant according to the configuration in UBX-CFG-NAV5)

utc

0=UTC not available
1=UTC available

time

0=Time is not valid
1=Time is valid (Valid GNSS fix)

newRisingEdge

new rising edge detected

32.20.7 UBX-TIM-TOS (0x0D 0x12)
32.20.7.1 Time Pulse Time and Frequency Data
Message

UBX-TIM-TOS

Description

Time Pulse Time and Frequency Data

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Periodic

Comment

This message contains information about the time pulse that has just happened
and the state of the disciplined oscillators(s) at the time of the pulse. It gives the
UTC and GNSS times and time uncertainty of the pulse together with frequency
and frequency uncertainty of the disciplined oscillators. It also supplies leap
second information.

UBX-13003221 - R17

Early Production Information

Page 378 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x12 56

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

versiongnssIdDescription

Format

0
1

U1
U1

-

2
4
8
10
11
12
13
14
15

U1[2]
X4
U2
U1
U1
U1
U1
U1
U1

-

16

I4

-

20

U4

-

24
28
32

U4
U4
I4

-

36

U4

-

40
44

I4
U4

2^-8
2^-8

48
52

I4
U4

2^-8
2^-8

UBX-13003221 - R17-

Message version (0 for this version)
GNSS system used for reporting GNSS
time (see Satellite Numbering)reserved1
Reservedflags
Flags (see graphic below)
yearyYear of UTC timemonth
month Month of UTC timedaydDay of UTC timehour
hHour of UTC timeminutemin
Minute of UTC time
seconds
Second of UTC time
utcStandard
UTC standard identifier:0: unknown
3: UTC as operated by the U.S. Naval
Observatory (USNO)
6: UTC as operated by the former Soviet
Union
7: UTC as operated by the National Time
Service Center, China
utcOffset
nsTime offset between the preceding pulse
and UTC top of second
utcUncertaint ns
Uncertainty of utcOffset
yweek
GNSS week number
TOWs
GNSS time of week
gnssOffset
nsTime offset between the preceding pulse
and GNSS top of second
gnssUncertain ns
Uncertainty of gnssOffsetty
intOscOffset ppb
Internal oscillator frequency offset
intOscUncerta ppb
Internal oscillator frequency uncertainty
inty
extOscOffset ppb
External oscillator frequency offset
extOscUncerta ppb
External oscillator frequency uncertainty
inty

Early Production Information

Page 379 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Bitfield flags
This graphic explains the bits of flags

Name

Description

leapNow
leapSoon
leapPositive
timeInLimit
intOscInLimit
extOscInLimit
gnssTimeValid
UTCTimeValid
DiscSrc

1 = currently in a leap second
1 = leap second scheduled in current minute
1 = positive leap second
1 = time pulse is within tolerance limit (UBX-CFG-SMGR timeTolerance field)
1 = internal oscillator is within tolerance limit (UBX-CFG-SMGR freqTolerance field)
1 = external oscillator is within tolerance limit (UBX-CFG-SMGR freqTolerance field)
1 = GNSS time is valid
1 = UTC time is valid
Disciplining source identifier:
0: internal oscillator
1: GNSS
2: EXTINT0
3: EXTINT1
4: internal oscillator measured by the host
5: external oscillator measured by the hostraim

1 = (T)RAIM system is currently active. Note this flag only reports the current state of the GNSS
solution; it is not affected by whether or not the GNSS solution is being used to discipline theoscillator.

cohPulse
lockedPulse

1 = coherent pulse generation is currently in operation
1 = time pulse is locked

32.20.8 UBX-TIM-TP (0x0D 0x01)
32.20.8.1 Time Pulse Timedata
Message

UBX-TIM-TP

Description

Time Pulse Timedata

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3 and 22

Type

Periodic/Polled

Comment

This message contains information on the timing of the next pulse at the
TIMEPULSE0 output. The recommended configuration when using thismessage is to set both the measurement rate (UBX-CFG-RATE) and thetimepulse frequency (UBX-CFG-TP5) to 1Hz.
For more information see section Time pulse.
TIMEPULSE0 and this message are not available from DR products using thededicated I2C sensor interface, including NEO-M8L and NEO-M8U modules

UBX-13003221 - R17

Early Production Information

Page 380 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x01 16

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

ms

Description

Format

0

U4

-

towMS

4
8

U4
I4

2^-32
-

towSubMS
qErr

12

U2

-

week

14
15

X1
X1

-

flags
refInfoTime pulse time of week according to timebase
msSubmillisecond part of TOWMS
ps
Quantization error of time pulse (notsupported for the FTS product variant).
weeks Time pulse week number according totime basebitmask (see graphic below)
Time reference information (see graphic
below)

Bitfield flags
This graphic explains the bits of flags

Name

Description

timeBase

0=Time base is GNSS
1=Time base is UTC

utc

0=UTC not available
1=UTC available

raim(T)RAIM information
0=information not available
1=not active
2=active

Bitfield refInfo
This graphic explains the bits of refInfo

UBX-13003221 - R17

Early Production Information

Page 381 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Name

Description

timeRefGnss

GNSS reference information (only active if time base is GNSS -> timeBase=0)
0: GPS
1: GLONASS
2: BeiDou
15: Unknown

utcStandard

UTC standard identifier (only active if time base is UTC -> timeBase=1)
0: Information not available
1: Communications Research Laboratory (CRL)
2: National Institute of Standards and Technology (NIST)
3: U.S. Naval Observatory (USNO)
4: International Bureau of Weights and Measures (BIPM)
5: European Laboratory (tbd)
6: Former Soviet Union (SU)15: Unknown

32.20.9 UBX-TIM-VCOCAL (0x0D 0x15)
32.20.9.1 Stop calibration
Message

UBX-TIM-VCOCAL

Description

Stop calibration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

CommandComment

Stop all ongoing calibration (both oscillators are affected)
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x15 1

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

type

-

Message type (0 for this message)

Format0U132.20.9.2 VCO calibration extended command
Message

UBX-TIM-VCOCAL

Description

VCO calibration extended command

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

CommandComment

Calibrate (measure) gain of the voltage controlled oscillator. The calibration is
performed by varying the raw oscillator control values between the limits
specified in raw0 and raw1. maxStepSize is the largest step change that can beused during the calibration process. The "raw values" are either PWM duty cycle
values or DAC values depending on how the VCTCXO is connected to thesystem. The measured gain is the transfer functiondRelativeFrequencyChange/dRaw (not dFrequency/dVoltage). The calibration

UBX-13003221 - R17

Early Production Information

Page 382 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

process works as follows:
Starting from the current raw output the control value is changed in the
direction of raw0 in steps of size at most maxStepSize. Then the frequency ismeasured and the control value is changed towards raw1, again in steps of
maxStepSize. When raw1 is reached, the frequency is again measured and themessage version DATA0 is output containing the measured result. Normal
operation then resumes. If the control value movement is less than maxStepSize
then the transition will happen in one step - this will give fast calibration.
Care must be taken when calibrating the internal oscillator against the GNSS
source. In that case the changes applied to the oscillator frequency could besevere enough to lose satellite signal tracking, especially when signals are weak.
If too many signals are lost, the GNSS system will lose its fix and be unable tomeasure the oscillator frequency - the calibration will then fail. In this casemaxStepSize must be reasonably small.
It is also important that only the chosen frequency source is enabled during thecalibration process and that it remains stable throughout the calibration period;
otherwise incorrect oscillator measurements will be made and this will lead to
miscalibration and poor subsequent operation of the receiver.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x15 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Message type (2 for this message)
Message version (0 for this version)
Oscillator to be calibrated:
0: internal oscillator
1: external oscillator
Reference source:
0: internal oscillator
1: GNSS
2: EXTINT0
3: EXTINT1
Option 0 should be used when calibrating
the external oscillator. Options 1-3 should
be used when calibrating the internal
oscillator.
Reserved
First value used for calibration
Second value used for calibration
Maximum step size to be used

Format

0
1
2

U1
U1
U1

-

type
version
oscId

-

3

U1

-

srcId

-

4
6
8
10

U1[2]
U2
U2
U2

-

reserved1
raw0
raw1
maxStepSize

raw
value/s

UBX-13003221 - R17

Early Production Information

Page 383 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.20.9.3 Results of the calibration
Message

UBX-TIM-VCOCAL

Description

Results of the calibration

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 16, 17, 18, 19, 19.1, 19.2, 20, 20.01, 20.1, 20.
2, 20.3, 22, 23 and 23.01(only with Time & Frequency Sync products)

Type

Periodic/Polled

Comment

This message is sent when the oscillator gain calibration process is finished(successful or unsuccessful). It notifies the user of the calibrated oscillator gain.
If the oscillator gain calibration process was successful, this message willcontain the measured gain (field gainVco) and its uncertainty (fieldgainUncertainty). The calibration process can however fail. In that case the two
fields gainVco and gainUncertainty are set to zero.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x15 12

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

type
version
oscId

Description

Format

0
1
2

U1
U1
U1

-

3
6

U1[3]
U2

2^-16

8

I4

2^-16

-

Message type (3 for this message)
Message version (0 for this version)
Id of oscillator:
0: internal oscillator
1: external oscillator
reserved1
Reserved
gainUncertain 1/1
Relative gain uncertainty after calibration,ty
0 if calibration failed
gainVcoppb/ra Calibrated gain or 0 if calibration failed
w LSB

32.20.10 UBX-TIM-VRFY (0x0D 0x06)
32.20.10.1 Sourced Time Verification
Message

UBX-TIM-VRFY

Description

Sourced Time Verification

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Periodic/Polled

Comment

This message contains verification information about previous time received via
AID-INI or from RTC
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x0D 0x06 20

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

-

itow

ms

integer millisecond tow received by source

Format0

I4

UBX-13003221 - R17

Early Production Information

Page 384 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

UBX-TIM-VRFY continued
Byte Offset

Number

Scaling

Name

Unit

Description

sub-millisecond part of tow
integer milliseconds of delta time (current
time minus sourced time)
sub-millisecond part of delta time
week number
information flags (see graphic below)
Reserved

Format

4
8

I4
I4

-

frac
deltaMs

ns
ms

12
16
18
19

I4
U2
X1
U1

-

deltaNs
wno
flags
reserved1

ns
week
-

Bitfield flags
This graphic explains the bits of flags

Name

Descriptionsrc

aiding time source
0: no time aiding done
2: source was RTC
3: source was AID-INIUBX-13003221 - R17

Early Production Information

Page 385 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.21 UBX-UPD (0x09)
Firmware Update Messages: i.e. Memory/Flash erase/write, Reboot, Flash identification, etc..
Messages in the UPD class are used to update the firmware and identify any attached flash
device.
32.21.1 UBX-UPD-SOS (0x09 0x14)
32.21.1.1 Poll Backup File Restore Status
MessageUBX-UPD-SOS

Description

Poll Backup File Restore Status

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

Poll Request

Comment

Sending this (empty / no-payload) message to the receiver results in the receiver
returning a System Restored from Backup message as defined below.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x09 0x14 0

Checksumsee below CK_A CK_B

No payload

32.21.1.2 Create Backup File in Flash
MessageUBX-UPD-SOS

Description

Create Backup File in Flash

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

The host can send this message in order to save part of the BBR memory in a filein flash file system. The feature is designed in order to emulate the presence ofthe backup battery even if it is not present; the host can issue the save on
shutdown command before switching off the device supply. It is recommended
to issue a GNSS stop command before, in order to keep the BBR memory
content consistent.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x09 0x14 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

cmd
reserved1-

Command (must be 0)
Reserved

Format

0
1

U1
U1[3]

UBX-13003221 - R17

Early Production Information

Page 386 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.21.1.3 Clear Backup in Flash
MessageUBX-UPD-SOS

Description

Clear Backup in Flash

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

CommandComment

The host can send this message in order to erase the backup file present inflash. It is recommended that the clear operation is issued after the host hasreceived the notification that the memory has been restored after a reset.
Alternatively the host can parse the startup string 'Restored data saved on
shutdown' or poll the UBX-UPD-SOS message for getting the status.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x09 0x14 4

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description-

cmd
reserved1-

Command (must be 1)
Reserved

Format

0
1

U1
U1[3]

32.21.1.4 Backup File Creation Acknowledge
MessageUBX-UPD-SOS

Description

Backup File Creation Acknowledge

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The message is sent from the device as confirmation of creation of a backup filein flash. The host can safely shut down the device after received this message.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x09 0x14 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Command (must be 2)
Reserved
0: Not acknowledged
1: Acknowledged
Reserved

Format

0
1
4

U1
U1[3]
U1

-

cmd
reserved1
response

-

5

U1[3]

-

reserved2-

UBX-13003221 - R17

Early Production Information

Page 387 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

32.21.1.5 System Restored from Backup
MessageUBX-UPD-SOS

Description

System Restored from Backup

FirmwareSupported on:• u-blox 8 / u-blox M8 protocol versions 15, 15.01, 16, 17, 18, 19, 19.1, 19.2, 20, 20.01,
20.1, 20.2, 20.3, 22, 23 and 23.01

Type

OutputComment

The message is sent from the device to notify the host the BBR has been
restored from a backup file in flash. The host should clear the backup file after
receiving this message. If the UBX-UPD-SOS message is polled, this message
will be resent.
HeaderMessage Structure

Class ID

Length (Bytes)

Payload

0xB5 0x62 0x09 0x14 8

Checksumsee below CK_A CK_B

Payload Contents:
Byte Offset

Number

Scaling

Name

Unit

Description

Command (must be 3)
Reserved
0: Unknown
1: Failed restoring from backup file
2: Restored from backup file
3: Not restored (no backup)
Reserved

Format

0
1
4

U1
U1[3]
U1

-

cmd
reserved1
response

-

5

U1[3]

-

reserved2-

UBX-13003221 - R17

Early Production Information

Page 388 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

33 RTCM Protocol
The RTCM (Radio Technical Commission for Maritime Services) protocol is a protocol that is used
to supply the GNSS receiver with real-time differential correction data. The RTCM protocol
specification is available from http://www.rtcm.org.

33.1 RTCM2
33.1.1 Introduction
This feature is only applicable to GPS operation.
This feature only supports code differential positioning.
For effective differential positioning accuracy, it is necessary that the reference station
antenna is situated in a low multipath environment with an unobstructed view of thesky. It is recommended that reference receiver applies phase smoothing to thebroadcast corrections.
This feature is not available with the High Precision GNSS products.
33.1.2 Supported Messages
The following RTCM 2.3 messages are supported:
Supported RTCM 2.3 Message Types
Message

Description

Type

1
2
3
9

Differential GPS Corrections
Delta Differential GPS
Corrections
GPS Reference Station
Parameters
GPS Partial Correction Set

33.1.3 Configuration
The DGPS feature does not need any configuration to work properly. When an RTCM stream is
input on any of the communication interfaces, the data will be parsed and applied if possible,
which will put the receiver into DGPS mode.
The only configurable parameter of DGPS mode is the timeout that can be specified using UBXCFG-NAV5. This value defines the time after which old RTCM data will be discarded.
The RTCM protocol can be disabled/enabled on communication interfaces by means of the UBXCFG-PRT message. By default, RTCM is enabled.
33.1.4 Output
DGPS mode will result in following modified output:• NMEA-GGA: The quality field will be 2 (see NMEA Positon Fix Flags). The age of DGPS corrections
and Reference station ID will be set.

UBX-13003221 - R17

Early Production Information

Page 389 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual• NMEA-GLL, NMEA-RMC, NMEA-VTG, NMEA-GNS: The posMode indicator will be D (see NMEA Positon
Fix Flags).
• NMEA-PUBX-POSITION: The status will be D2/D3; The age of DGPS corrections will be set.
• UBX-NAV-SOL: The DGPS flag will be set.
• UBX-NAV-PVT: The diffSoln flag will be set.
• UBX-NAV-STATUS: The diffSoln flag will be set; the diffCorr flag will be set.
• UBX-NAV-SVINFO: The DGPS flag will be set for channels with valid DGPS correction data.
• UBX-NAV-DGPS: This message will contain all valid DGPS data
• If the base line exceeds 100km and a message type 3 is received, aUBX-INF-WARNING will be
output, e.g. "WARNING: DGNSS baseline big: 330.3km"
33.1.5 Restrictions
The following restrictions apply to DGPS mode:• The DGPS solution will only include measurements from satellites for which DGPS corrections
were provided. This is because the navigation algorithms cannot mix corrected with uncorrected
measurements.
• SBAS corrections will not be applied when using RTCM correction data.
• Precise Point Positioning will be deactivated when using RTCM correction data.
• RTCM correction data cannot be applied when using AssistNow Offline or AssistNow
Autonomous.
33.1.6 Reference
The RTCM2 support is implemented according to RTCM 10402.3 ("RECOMMENDED STANDARDSFOR DIFFERENTIAL GNSS").

33.2 RTCM version 3(Note: the RTCM3 protocol is not supported in protocol versions less than 20).
33.2.1 Introduction
This feature is only available with High Precision GNSS products.
This feature is only applicable to GPS, GLONASS or BeiDou operation.
This feature supports carrier phase differential positioning.
RTCM3 messages can also be transmitted through NTRIP (Networked Transport of
RTCM via Internet Protocol). u-center incorporates an NTRIP client and an NTRIP
server/caster.
For effective differential positioning accuracy, it is necessary that the reference station
antenna is situated in a low multipath environment with an unobstructed view of the sky
and continuous phase lock on all visible satellites.

UBX-13003221 - R17

Early Production Information

Page 390 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

33.2.2 Supported Messages
The following RTCM 3.3 input messages are supported:
Supported RTCM 3.3 Input Messages
Message Type

1001
1002
1003
1004
1005
1006
1007
1009
1010
1011
1012
1074
1075
1077
1084
1085
1087
1124
1125
1127
1230
4072, sub-type
0

Description

L1-only GPS RTK observations
Extended L1-only GPS RTK observations
L1/L2 GPS RTK observations
Extended L1/L2 GPS RTK observations
Stationary RTK reference station ARP
Stationary RTK reference station ARP with antenna height
Antenna descriptor
L1-only GLONASS RTK observations
Extended L1-only GLONASS RTK observations
L1/L2 GLONASS RTK observations
Extended L1/L2 GLONASS RTK observations
GPS MSM4
GPS MSM5
GPS MSM7
GLONASS MSM4
GLONASS MSM5
GLONASS MSM7
BeiDou MSM4
BeiDou MSM5
BeiDou MSM7GLONASS code-phase biases
Reference station PVT (u-blox proprietary RTCM Message)

The following RTCM 3.3 output messages are supported:
When configuring RTCM output messages using the UBX protocol message UBX-CFG-MSG, theClass/Ids shown in the table shall be used.
Supported RTCM 3.3 Output Messages
Message TypeCls/ID

1005
1074
1077
1084
1087
1124
1127
1230
4072, sub-type
0

0xF5 0x05
0xF5 0x4A
0xF5 0x4D
0xF5 0x54
0xF5 0x57
0xF5 0x7C
0xF5 0x7F
0xF5 0xE6
0xF5 0xFE

UBX-13003221 - R17

Description

Stationary RTK reference station ARPGPS MSM4
GPS MSM7
GLONASS MSM4
GLONASS MSM7
BeiDou MSM4
BeiDou MSM7GLONASS code-phase biases
Reference station PVT (u-blox proprietary RTCM Message)

Early Production Information

Page 391 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

33.2.3 u-blox Proprietary RTCM Messages
The RTCM message type 4072 is the u-blox proprietary RTCM message. It is supported by the
RTCM standard version 3.2 and above.
33.2.3.1 Sub-Types
There are different available sub-types of the RTCM message type 4072. The table below shows
the available RTCM 4072 sub-types.
RTCM 4072 Sub-TypesSub-

Message Type

Sub-Type

Type

NumberNumber

1

0xFE8

0x001

Description

Message Data (Payload) Length (bits)

Additional reference
station information

112+48*(2*N)(N = the number of enabled GNSS
constellations)33.2.4 Configuration
The configuration of the RTK rover and reference station is explained in the RTK Mode
Configuration section.
The RTCM3 protocol can be disabled/enabled on communication interfaces by means of the UBXCFG-PRT message. By default, RTCM3 is enabled.
The configuration of the RTCM3 correction stream must be done according to the following rules:• The RTCM3 stream must contain a reference station message (type 1005 or type 1006) inaddition to the GNSS observation messages.
• The RTCM3 stream must contain a reference station message (type 1005, type 1006, ortype
4072, sub-type 0) in addition to the GNSS observation messages.
• All observation messages must be broadcast at the same rate.
• The reference station ID field in the GNSS observation messages must be consistent with thereference station ID field in the reference station message otherwise the rover will not be able tocompute its position.
• The RTCM3 stream must contain the GLONASS code-phase biases message (type 1230)
otherwise the GLONASS ambiguities can only be estimated as float unless the receiver is able
to identify the code-phase bias from receiver descriptor message (RTCM 1033), even in RTK
fixed mode.
• The static reference station message (type 1005 or type 1006) does not need to be broadcast at
the same rate as the observation messages but the rover will not be able to compute its
position until it has received a valid reference station message.
• The moving baseline reference message (type 4072, sub-type 0) must be broadcast at the samerate as the observation messages.
• The RTCM3 stream should only contain one type of observation messages per constellation.
When using a multi-constellation configuration, all constellations should use the same type ofobservation messages. Mixing RTK and MSM messages will result in undefined rover behavior.
• The moving baseline reference message (type 4072, sub-type 0) should only be used in
combination with MSM7 observation messages.
• If the receiver is configured to output RTCM messages on several ports, they must all have thesame RTCM configuration otherwise the MSM multiple message bit might not be set properly.
UBX-13003221 - R17

Early Production Information

Page 392 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

33.2.5 Output
RTK Rover and MB Rover Modes will result in following modified output:• NMEA-GGA: The quality field will be 4 for RTK fixed and 5 for RTK float (see NMEA Positon Fix
Flags). The age of differential corrections and reference station ID will be set.
• NMEA-GLL, NMEA-VTG: The posMode indicator will be D for RTK float and RTK fixed (see NMEA
Positon Fix Flags).
• NMEA-RMC, NMEA-GNS: The posMode indicator will be F for RTK float and R for RTK fixed (seeNMEA Positon Fix Flags).
• UBX-NAV-PVT: The carrSoln flag will be set to 1 for RTK float and 2 for RTK fixed.
• UBX-NAV-RELPOSNED: The diffSoln and refPosValid flags will be set. The carrSoln flag will be set
to 1 for RTK float and 2 for RTK fixed. In moving baseline rover mode, the isMoving flag will beset, and the refPosMiss and refObsMiss flags will be set for epochs during which extrapolated
reference position or observations have been used.
• 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. In moving baseline rover mode, the doCorrUsed flag will also be
set.
• UBX-NAV-STATUS: The diffSoln flag will be set; the diffCorr flag will be set.
• If the baseline exceeds 10km and a message type 1005, type 1006 ortype 4072, sub-type 0 is
received, a UBX-INF-WARNING will be output, e.g. "WARNING: DGNSS baseline big: 12.7km"
33.2.6 Reference
The RTCM3 support is implemented according to RTCM STANDARD 10403.3 DIFFERENTIALGNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS) SERVICES - VERSION 3.

UBX-13003221 - R17

Early Production Information

Page 393 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Appendix
A Satellite Numbering
A summary of all the SV numbering schemes is provided in the following table.
Satellite numbering
GNSS Type SV range

UBX gnssId:

UBX svId

svId

GPS
SBAS

NMEA 2.X-

NMEA 2.X-4.0

NMEA 4.10+ NMEA 4.10+

4.0 (strict)(extended)(strict)(extended)

1-32
33-64,152158
301-336401-437

1-32
33-64

1-32
33-64,152158
1-36
1-37

173-182
193-197
65-96, null

65-96,
null

0:1-32
1:120-158

1-32
120-158

1-32
33-64

Galileo
BeiDouG1-G32S120S158
E1-E36
B1-B37

2:1-36
3:1-37

-

IMES
QZSS
GLONASS

I1-I10
Q1-Q5
R1-R32,R?

4:1-10
5:1-5
6:1-32, 6:
255

211-246
159-163,3364
173-182
193-197
65-96, 255

65-96,
null

1-36
1-37

173-182
193-197
65-96, nullB UBX and NMEA Signal Identifiers
UBX and NMEA protocols use signal identifiers (commonly abbreviated to "sigId") to distinguishbetween different signals from GNSS.
Signal identifiers are only valid when combined with a GNSS identifier (see above). The table below
shows the range of identifiers currently supported in the firmware.

C u-blox 8 / u-blox M8 Default Settings
The default settings listed in this section apply to u-blox 8 / u-blox M8 receivers. These values
assume that the default levels of the configuration pins have been left unchanged and no settingthat affects the default configuration was written to the eFuse. Default settings are dependent
on the configuration pin and eFuse settings. For information regarding these settings, consult theapplicable Data Sheet.
If nothing else is mentioned, the default settings apply to u-blox 8 and u-blox M8
receivers.

C.1 Antenna Supervisor Settings (UBX-CFG-ANT)
For parameter and protocol description see section UBX-CFG-ANT.
Antenna Supervisor Default Settings
Parameter

SPG 2.xx

SPG 3.xx,

ADR 3.xx

HPG 1.xx

flags-svcs
flags-scd
flags-pdwnOnSCD
flags-recovery
flags-ocd

UBX-13003221 - R17

1
1
1
1
0

1
1
1
1
0

ADR 4.xx,

FTS 1.xx

TIM 1.0x

TIM 1.1x

0
0
0
0
0

1
1
0
1
0

1
0
0
0
0

UDR 1.xx

1
0
0
0
0

Early Production Information

1
0
0
0
0

Page 394 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Antenna Supervisor Default Settings continued
Parameter

SPG 2.xx

SPG 3.xx,

ADR 3.xx

HPG 1.xx

pins-pinSwitch
pins-pinSCD
pins-pinOCD

16
15
31

16
15
14

ADR 4.xx,

FTS 1.xx

TIM 1.0x

TIM 1.1x

31
31
31

16
15
31

16
15
14

UDR 1.xx

16
31
31

16
15
14

C.2 Data Batching Settings (UBX-CFG-BATCH)
For parameter and protocol description see section UBX-CFG-BATCH.
Data Batching Default Settings
Parameter

SPG 3.51

flags-enableflags-extraPvt
flags-extraOdo
flags-pioEnableflags-pioActiveLow
bufSizenotifThrs
pioId

0
1
1
0
0
0
0
0

C.3 Datum Settings (UBX-CFG-DAT)
For parameter and protocol description see section UBX-CFG-DAT.
Datum Default Settings
Parameter

datumNum
datumName
majA
flat
dX
dY
dZ
rotX
rotY
rotZ
scale

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

0WGS84
6378137298.257223563
0
0
0
0
0
0
0

C.4 Geofencing Settings (UBX-CFG-GEOFENCE)
For parameter and protocol description see section UBX-CFG-GEOFENCE.
Geofencing Default Settings
Parameter

SPG 2.xx, SPG 3.xx, HPG 1.xx, ADR 3.xx, ADR 4.xx, UDR 1.xx

numFences
confLvlpioEnabled
pinPolarity

UBX-13003221 - R17

0
0
0
0

Early Production Information

Page 395 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Geofencing Default Settings continued
Parameter

SPG 2.xx, SPG 3.xx, HPG 1.xx, ADR 3.xx, ADR 4.xx, UDR 1.xx

pin0

C.5 High Navigation Rate Settings (UBX-CFG-HNR)
For parameter and protocol description see section UBX-CFG-HNR.
High Navigation Rate Default Settings
Parameter

highNavRate

ADR 3.xx, UDR 1.xx

ADR 4.xx

010

C.6 GNSS System Settings (UBX-CFG-GNSS)
For parameter and protocol description see section UBX-CFG-GNSS.
GNSS System Default Settings
Parameter

SPG 2.xx,

SPG 3.0x

ADR 3.xx

numTrkChHw
numTrkChUse
numConfigBlocks
gnssIdflags-enable
resTrkCh
maxTrkCh

ADR 4.xx,

FTS 1.xx

UDR 1.xx

TIM 1.0x

TIM 1.1x,

HPG 1.xx

SPG 3.5x

32
32
28
32
32
32
32
32
32
28
32
32
32
28
5
7
7
5
6
7
4
0, 1, 3, 5, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 3, 5, 0, 1, 3, 4, 0, 1, 2, 3, 0, 3, 5, 6
6
4, 5, 64, 5, 665, 6
4, 5, 6
1, 1, 0, 1, 1, 1, 0, 0, 1, 1, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1
1
0, 1, 10, 1, 11
1, 1
0, 1, 18, 1, 8, 0, 8, 1, 4, 8, 8, 1, 4, 8, 8, 1, 8, 0, 8, 1, 8, 0, 8, 1, 4, 8, 8, 8, 0, 8
80, 0, 80, 0, 880, 80, 0, 816, 3, 16, 16, 3, 8, 16, 3, 8, 16, 3, 16, 16, 3, 16, 16, 3, 8, 16, 16, 3,
3, 14
16, 8, 3, 16, 8, 3,
3, 14
8, 3, 14 16, 8, 3,
14
14
14
14

C.7 INF Messages Settings (UBX-CFG-INF)
For parameter and protocol description see section UBX-CFG-INF.
C.7.1 UBX Protocol
INF Messages Default Settings for UBX protocol
Parameter

protocolID
infMsgMask-ERROR
infMsgMask-WARNING
infMsgMask-NOTICE
infMsgMask-TEST
infMsgMask-DEBUG

UBX-13003221 - R17

SPG 2.xx, SPG 3.xx, FTS 1.xx, TIM 1.xx, HPG 1.xx, ADR 3.xx, ADR 4.xx, UDR 1.xx

00,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0

Early Production Information

Page 396 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

C.7.2 NMEA Protocol
INF Messages Default Settings for NMEA protocol
Parameter

SPG 2.xx, TIM 1.0x, FTS 1.xx, SPG 3.xx, TIM 1.1x, HPG 1.xx

ADR 4.xx, UDR 1.xx

ADR 3.xx

protocolID
infMsgMask-ERROR
infMsgMask-WARNING
infMsgMask-NOTICE
infMsgMask-TEST
infMsgMask-DEBUG

1
1,1,1,1,1,1
1,1,1,1,1,1
1,1,1,1,1,1
0,0,0,0,0,0
0,0,0,0,0,0

1
1,1,0,1,1,0
1,1,0,1,1,0
1,1,0,1,1,0
0,0,0,0,0,0
0,0,0,0,0,0

1
1,1,0,1,1,0
1,1,0,1,1,0
1,1,0,1,1,0
0,0,0,0,0,0
0,0,0,0,0,0

C.8 Jammer/Interference Monitor Settings (UBX-CFG-ITFM)
For parameter and protocol description see section UBX-CFG-ITFM.
Jamming/Interference Monitor Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

config-bbThresholdconfig-cwThresholdconfig-enableconfig2-antSetting
config2-enable2

3
15
0
0
0

C.9 Logging Settings (UBX-CFG-LOGFILTER)
For parameter and protocol description see section UBX-CFG-LOGFILTER.
Logging Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

flags-recordEnabled
flagspsmOncePerWakupEnabledflags-applyAllFilterSettings
minInterval
timeThreshold
speedThresholdpositionThreshold

0
0

0
0
0
0
0

C.10 Navigation Settings (UBX-CFG-NAV5)
For parameter and protocol description see section UBX-CFG-NAV5.
Navigation Default Settings
Parameter

SPG 2.xx,

SPG 3.xx

ADR 3.xx

mask-dynmask-minEl
mask-posFixModemask-drLim
UBX-13003221 - R17

1
1
1
1

ADR 4.xx,

FTS 1.xx

TIM 1.0x

TIM 1.1x

HPG 1.xx

1
1
1
1

1
1
1
1

1
1
1
1

1
1
1
1

UDR 1.xx

1
1
1
1

1
1
1
1

Early Production Information

Page 397 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Navigation Default Settings continued
Parameter

SPG 2.xx,

SPG 3.xx

ADR 3.xx

mask-posMask
mask-timeMask
mask-staticHoldMask
mask-dgpsMask
mask-cnoThresholdmask-utc
dynModelfixModefixedAlt
fixedAltVar
minElev
drLimit
pDop
tDop
pAcc
tAcc
staticHoldThresh
dgpsTimeOut
cnoThreshNumSVs
cnoThreshstaticHoldMaxDist
utcStandard

ADR 4.xx,

FTS 1.xx

TIM 1.0x

TIM 1.1x

HPG 1.xx

1
1
1
1
1
1
2
3
0
1
5
0
25
25
100
300
0
60
0
0
200
3

1
1
1
1
1
1
2
3
0
1
5
0
25
25
100
350
0
60
0
0
200
3

1
1
1
1
1
1
2
3
0
1
5
0
25
25
100
350
0
60
0
0
0
3

1
1
1
1
1
1
0
3
0
1
10
0
25
25
100
350
0
60
0
0
0
0

FTS 1.xx, TIM 1.

TIM 1.1x

UDR 1.xx

1
1
1
1
1
1
0
3
0
1
5
0
25
25
100
300
0
60
0
0
200
0

1
1
1
1
1
1
0
3
0
1
5
0
25
25
100
350
0
60
0
0
0
0

1
1
1
1
1
1
4
3
0
1
10
0
25
25
100
350
0
60
0
0
0
0

C.11 Navigation Settings (UBX-CFG-NAVX5)
For parameter and protocol description see section UBX-CFG-NAVX5.
Navigation Default Settings (SPG/FTS/TIM)
Parameter

SPG 2.xx

SPG 3.0x

SPG 3.5x0x

mask1-minMax
mask1-minCno
mask1-initial3dfix
mask1-wknRoll
mask1-ackAid
mask1-ppp
mask1-aop
mask2-adr
minSVsmaxSVsminCNOiniFix3D
ackAidingwknRollover
usePPPUBX-13003221 - R17

1
1
1
1
1
1
1
0
3
20
6
0
0
1756
0

1
1
1
1
1
1
1
0
3
32
6
0
0
1867
0

Early Production Information

1
1
1
1
1
1
1
0
3
32
6
0
0
1936
0

1
1
1
1
1
1
1
0
1
20
9
0
0
1756
0

1
1
1
1
1
1
1
0
1
32
9
0
0
1867
0

Page 398 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Navigation Default Settings (SPG/FTS/TIM) continued
Parameter

SPG 2.xx

SPG 3.0x

SPG 3.5x

FTS 1.xx, TIM 1.

TIM 1.1x

0x

aopCfg-useAOP
aopOrbMaxErr
gnssTofsCfg-tolerance
gnssTofsCfguseMeasVarTest
gnssTofsCfgaopPreCalEnabled
gnssTofsCfg-aopPreCalDt
gnssTofsCfgaopPreCalInhInt
useAdr

0
100
0
0

0
100
0
0

0
100
0
0

0
100
0
0

0
100
0
0

0

0

0

0

0

0
0

0
0

0
0

0
0

0
0

0

0

0

0

0

Navigation Default Settings (ADR/UDR/HPG)
Parameter

mask1-minMax
mask1-minCno
mask1-initial3dfix
mask1-wknRoll
mask1-ackAid
mask1-ppp
mask1-aop
mask2-adrmask2-sigAttenComp
minSVsmaxSVsminCNOiniFix3D
ackAidingwknRollover
sigAttenCompMode
usePPP
aopCfg-useAOP
aopOrbMaxErr
useAdrADR 3.xx

1
1
1
1
1
1
1
0
n/a
2
20
6
0
0
1756
n/a
0
0
100
1

ADR 4.0x,

ADR 4.2x,

ADR 4.1x

UDR 1.2x

1
1
1
1
1
1
1
0
0
5
24
12
0
0
1867
0
0
0
100
1

1
1
1
1
1
1
1
0
0
5
24
20
0
0
2005
0
0
0
100
1

UDR 1.00

HPG 1.30

HPG 1.40

1
1
1
1
1
1
1
0
0
5
24
12
0
0
1867
0
0
0
100
1

1
1
1
1
1
1
1
0
0
3
20
6
0
0
1867
0
1
0
100
0

1
1
1
1
1
1
1
0
0
3
20
6
0
0
1867
0
1
0
100
0

C.12 NMEA Protocol Settings (UBX-CFG-NMEA)For parameter and protocol description see section UBX-CFG-NMEA.
NMEA Protocol Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

filter-posFilt
filter-mskPosFilt
filter-timeFilt

UBX-13003221 - R17000

Early Production Information

Page 399 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

NMEA Protocol Default Settings continued
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

filter-dateFilt
filter-gpsOnlyFilter
filter-trackFilt
nmeaVersion
numSV
flags-compat
flags-consider
flags-limit82
flags-highPrec
gnssToFilter-gps
gnssToFilter-sbas
gnssToFilter-qzss
gnssToFilter-glonass
gnssToFilter-beidou
svNumbering
mainTalkerId
gsvTalkerId
bdsTalkerId

0
0
0
0x40
0
0
1
0
0
0
0
0
0
0
0
0
0
not setC.13 Odometer Settings (UBX-CFG-ODO)
For parameter and protocol description see section UBX-CFG-ODO.
ODO Default Settings
Parameter

SPG 2.xx, SPG 3.0x, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG SPG 3.5x
1.xx

flags-useODO
flags-useCOG
flags-outLPVelflags-outLPCog
odoCfg-profile
cogMaxSpeed
cogMaxPosAcc
velLpGain
cogLpGain

0
0
0
0
0
1
50
153
76

1
1
1
1
0
1
50
153
76

C.14 Power Management 2 Configuration (UBX-CFG-PM2)
For parameter and protocol description see section UBX-CFG-PM2.
Power Management 2 Configuration Default Settings
Parameter

SPG 2.xx, ADR

SPG 3.0x

SPG 3.51

TIM 1.0x

TIM 1.1x

0
0

0
0

0
0

0
0

3.xx, FTS 1.xx,
ADR 4.xx, UDR
1.xx

maxStartupStateDurflags-extintSel

UBX-13003221 - R17

0
0

Early Production Information

Page 400 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Power Management 2 Configuration Default Settings continued
Parameter

SPG 2.xx, ADR

SPG 3.0x

SPG 3.51

TIM 1.0x

TIM 1.1x

0
0
0
0
0
0
1
0
1
1000
10000
0
0
0
0

0
0
0
0
0
0
0
1
1
1000
10000
0
0
300
0

0
0
n/a
0
1
0
1
0
1
1000
10000
0
0
0
n/a

0
0
0
0
1
0
1
0
1
1000
10000
0
0
0
0

3.xx, FTS 1.xx,
ADR 4.xx, UDR
1.xx

flags-extintWake
flags-extintBackup
flags-extintInactive
flags-limitPeakCurr
flags-waitTimeFix
flags-updateRTC
flags-updateEPH
flags-doNotEnterOff
flags-mode
updatePeriod
searchPeriod
gridOffset
onTimeminAcqTime
extintInactivityMs

0
0
n/a
0
0
0
1
0
1
1000
10000
0
0
0
n/a

C.15 Port Configuration (UBX-CFG-PRT)
For parameter and protocol description see section UBX-CFG-PRT.
C.15.1 UART Port Configuration
For parameter and protocol description see section UBX-CFG-PRT-UART.
UART 1 Default Settings
ParametertxReady-en
txReady-pol
txReady-pin
txReady-thres
baudRate
inProtoMask

SPG 2.xx, SPG 3.xx, FTS 1.

ADR 3.xx, ADR 4.xx, UDR 1.

xx, TIM 1.xx

xx

0
0
0
0
0
0
0
0
9600
9600
inUbx,inNmea,inRtcm inUbx,inNmea,inRtcm

outProtoMask
flags-extendedTxTimeout

outUbx,outNmea

outUbx,outNmea

00

HPG 1.xx

0
0
0
0
9600
inUbx,inNmea,
inRtcm3
outUbx,outNmea,
outRtcm30C.15.2 USB Port Configuration
For parameter and protocol description see section UBX-CFG-PRT-USB.
USB Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM

HPG 1.xx

1.xx, ADR 4.xx, UDR 1.xx

UBX-13003221 - R17

Early Production Information

Page 401 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

USB Default Settings continued
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM

HPG 1.xx

1.xx, ADR 4.xx, UDR 1.xx

txReady-en
txReady-pol
txReady-pin
txReady-thres
inProtoMask
outProtoMask
flags-extendedTxTimeout

00
00
inUbx,inNmea,inRtcm
outUbx,outNmea
0

0
0
0
0
inUbx,inNmea,inRtcm3
outUbx,outNmea,outRtcm30

C.15.3 SPI Port Configuration
For parameter and protocol description see section UBX-CFG-PRT-SPI.
SPI Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

txReady-en
txReady-pol
txReady-pin
txReady-thresmode-spiMode
mode-flowControl
mode-ffCnt
inProtoMask
outProtoMask
flags-extendedTxTimeout

0
0
0
0
0
0
0
None
None
0

C.15.4 DDC Port Configuration
For parameter and protocol description see section UBX-CFG-PRT-DDC.
DDC Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM

HPG 1.xx

1.xx, ADR 4.xx, UDR 1.xx

txReady-en
txReady-pol
txReady-pin
txReady-thresmode-slaveAddr
inProtoMask
outProtoMask
flags-extendedTxTimeout

0
0
0
0
0x42
inUbx,inNmea,inRtcm
outUbx,outNmea
0

0
0
0
0
0x42
inUbx,inNmea,inRtcm3
outUbx,outNmea,outRtcm30

C.16 Output Rate Settings (UBX-CFG-RATE)
For parameter and protocol description see section UBX-CFG-RATE.
Output Rate Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

measRate

1000

UBX-13003221 - R17

Early Production Information

Page 402 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Output Rate Default Settings continued
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, ADR 4.xx, UDR 1.xx, HPG 1.xx

navRatetimeRef

1
1

C.17 Remote Inventory Settings (UBX-CFG-RINV)For parameter and protocol description see section UBX-CFG-RINV.
Remote Inventory Default Settings
Parameter

SPG 2.xx, SPG 3.xx, ADR 3.xx, FTS 1.xx, TIM 1.xx, HPG 1.xx

flags-dump
flags-binary

00C.18 Receiver Manager Configuration Settings (UBX-CFG-RXM)
For parameter and protocol description see section UBX-CFG-RXM.
Power Management Default Settings
Parameter

lpModeSPG 2.xx, FTS 1. SPG 3.0x, TIM 1.
xx, TIM 1.0x

1x, HPG 1.xx

00

ADR 3.xx

ADR 4.xx, UDR

SPG 3.5x

1.xx

0

0

1

C.19 SBAS Configuration Settings (UBX-CFG-SBAS)
For parameter and protocol description see section UBX-CFG-SBAS.
SBAS Configuration Default Settings
Parameter

SPG 2.xx,

SPG 3.0x

SPG 3.5x

ADR 3.xx

FTS 1.xx, TIM

ADR 4.xx,

TIM 1.1x

UDR 1.xx

1.0x

mode-enabled *mode-test
usage-range
usage-diffCorr
usage-integrity
maxSBAS *scanmode2
scanmode1

1
0
1
1
0
3
None
120,124,
126,129,
133,135,
137,138

1
0
1
1
0
3
None
120,123,
127-129,
133,135138

1
0
1
1
0
3
None
120,123,
127-129,
133,135138

1
0
1
1
0
3
None
120,124,
126,127129,133,
135,137,
138

1
0
1
1
0
3
None
120,123,
127-129,
133,135138

0
0
1
1
0
3
None
120,123,
127-129,
133,135138* These parameters are deprecated; use UBX-CFG-GNSS instead.

C.20 Timepulse Settings (UBX-CFG-TP5)
For parameter and protocol description see section UBX-CFG-TP5.

UBX-13003221 - R17

Early Production Information

Page 403 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

TIMEPULSE1 Default Settings
Parameter

antCableDelay
rfGroupDelay
freqPeriod
freqPeriodLock
pulseLenRatio
pulseLenRatioLock
userConfigDelayflags-active
flags-lockGpsFreq
flags-lockGnssFreq
flags-lockedOtherSet
flags-isFreq
flags-isLength
flags-alignToTow
flags-polarity
flags-gridUtcGps
flags-gridUtcGnss
flags-syncMode

SPG 2.xx

SPG 3.xx, HPG 1. ADR 3.xx, ADR

50
01000000
1000000
0
100000
0
1
1
n/a
1
0
1
1
1
0
n/a
n/a

xx

4.xx, UDR 1.xx

50
01000000
1000000
0
100000
0
1
n/a
1
1
0
1
1
1
n/a
0
0

50
0
0
0
0
0
0
0
n/a
1
1
0
1
1
0
n/a
0
0

FTS 1.xx

TIM 1.xx

50
0
0
0
0
0
0
1
n/a
1
1
0
1
1
0
n/a
1
0

50
0
1000000
1000000
0
100000
0
1
n/a
1
1
0
1
1
1
n/a
1
0

C.21 USB Settings (UBX-CFG-USB)
For parameter and protocol description see section UBX-CFG-USB.
USB Default Settings
Parameter

SPG 2.xx, ADR 3.xx, FTS 1.xx, TIM 1.0x, ADR

SPG 3.xx, TIM 1.1x, HPG 1.xx

4.xx, UDR 1.xx

vendorID
productID
powerConsumption
flags-reEnum
flags-powerModevendorString
productString
serialNumber

UBX-13003221 - R17

0x15460x01A8100
01
u-blox AG - www.u-blox.com
u-blox GNSS receiver
not setEarly Production Information

0x15460x01A8100
01
u-blox AG - www.u-blox.com
u-blox GNSS receiver
not setPage 404 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Related Documents
Overview
As part of our commitment to customer support, u-blox maintains an extensive volume oftechnical documentation for our products. In addition to product-specific data sheets andintegration manuals, general documents are also available. These include:• GPS Compendium, Docu. No GPS-X-02007• GPS Antennas - RF Design Considerations for u-blox GPS Receivers, Docu. No GPS-X-08014
Our website www.u-blox.com is a valuable resource for general and product specificdocumentation.
For design and integration projects the Receiver Description Including Interface Description
should be used together with the Data Sheet and Hardware Integration Manual of the GNSS
receiver.

UBX-13003221 - R17

Early Production Information

Page 405 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Revision History
Revision

Date

Name

Status / Comments

R01
R02
R03
R04
R05
R06
R07
R08
R09
R10
R11
R12

30-Sep-2013
01-Nov-2013
15-Dec-2013
10-Feb-2014
27-Jun-2014
09-Sep-2014
09-Sep-2014
19-Nov-2014
30-Nov-2015
15-Feb-2016
04-May-2016
28-Apr-2017

efav
efav
efav
efav
efav
mfre
mfre
mfre
mfre
mfre
mfre
jhak

R13
R14
R15
R16
R17

06-Jul-2017
24-Oct-2017
06-Mar-2018
05-Nov-2018
17-May-2019

jhak
jhak
jhak
jhak
ssid

Added u-blox M8 firmware 2.00
Added u-blox M8 firmware 2.01
Added u-blox M8 ADR product variant
Added u-blox M8 Time & Frequency Sync product variant
Added u-blox M8 Timing product variant
Minor corrections
Added u-blox M8 firmware 2.30
Added u-blox M8 L-type modules product variant
Added u-blox 8 / u-blox M8 SPG 3.01 firmware
Added u-blox 8 / u-blox M8 TIM 1.10 firmware
Added u-blox 8 / u-blox M8 ADR 4.00 and UDR 1.00 firmware
Added u-blox 8 / u-blox M8 ADR 4.10, HPG 1.40 and SPG 3.51
firmwareAdded HPG 1.40 firmware information
Added ADR 4.11 firmware information
Updated Super-E messages
Added ADR 4.21 and UDR 1.21 firmware information
Minor corrections

UBX-13003221 - R17

Early Production Information

Page 406 of 407

u-blox 8 / u-blox M8 Receiver Description - Manual

Contact
For complete contact information visit us at www.u-blox.com

u-blox Offices
North, Central and South America
u-blox America, Inc.
Phone:+1 703 483 3180
E-mail:info_us@u-blox.com
Regional Office West Coast:
Phone:+1 408 573 3640
E-mail:info_us@u-blox.com

Headquarters
Europe, Middle East, Africa
u-blox AG
Phone:+41 44 722 74 44
E-mail:info@u-blox.com
Support: support@u-blox.com
Documentation Feedback
E-mail:docsupport@u-blox.com

Technical Support:
Phone:+1 703 483 3185
E-mail:support_us@u-blox.com

Asia, Australia, Pacificu-blox Singapore Pte. Ltd.
Phone:+65 6734 3811
E-mail:info_ap@u-blox.com
Support: support_ap@u-blox.com
Regional Office Australia:
Phone:+61 2 8448 2016
E-mail:info_anz@u-blox.com
Support: support_ap@u-blox.com
Regional Office China (Beijing):
Phone:+86 10 68 133 545
E-mail:info_cn@u-blox.com
Support: support_cn@u-blox.com
Regional Office China (Chongqing):
Phone:+86 23 6815 1588
E-mail:info_cn@u-blox.com
Support: support_cn@u-blox.com
Regional Office China (Shanghai):Phone:+86 21 6090 4832
E-mail:info_cn@u-blox.com
Support: support_cn@u-blox.com
Regional Office China (Shenzhen):Phone:+86 755 8627 1083
E-mail:info_cn@u-blox.com
Support: support_cn@u-blox.com
Regional Office India:
Phone:+91 80 4050 9200
E-mail:info_in@u-blox.com
Support: support_in@u-blox.com
Regional Office Japan (Osaka):
Phone:+81 6 6941 3660
E-mail:info_jp@u-blox.com
Support: support_jp@u-blox.com
Regional Office Japan (Tokyo):Phone:+81 3 5775 3850
E-mail:info_jp@u-blox.com
Support: support_jp@u-blox.com
Regional Office Korea:
Phone:+82 2 542 0861
E-mail:info_kr@u-blox.com
Support: support_kr@u-blox.com
Regional Office Taiwan:
Phone:+886 2 2657 1090
E-mail:info_tw@u-blox.com
Support: support_tw@u-blox.com

UBX-13003221 - R17

Early Production Information

Page 407 of 407