U Blox5 Protocol Specifications (GPS.G5 X 07036)
U Blox5 Protocol Specifications (GPS.G5 X 07036)
U Blox5 Protocol Specifications (GPS.G5 X 07036)
Zürcherstrasse 68
8800 Thalwil
Switzerland
www.u-blox.com
u-blox 5
NMEA, UBX Protocol Specification
u-blox 5 GNSS Receiver
Public Release
Specification
Title NMEA, UBX Protocol Specification
Subtitle u-blox 5 GNSS Receiver Public Release
Doc Type Specification
Doc Id GPS.G5-X-07036-E
Revision Date Author Status / Comment
This document and the use of any information contained therein, is subject to the acceptance of the u-blox
terms and conditions. They can be downloaded from www.u-blox.com. u-blox makes no warranties based on
the accuracy or completeness of the contents of this document and reserves the right to make changes to
specifications and product descriptions at any time without notice. u-blox reserves all rights to this document
and the information contained herein. Reproduction, use or disclosure to third parties without express
permission is strictly prohibited. Copyright © 2008, u-blox AG.
For most recent documents, please visit www.u-blox.com
Receiver Configuration
Information about configuration concept, organization and storage media is included in the section Receiver
Configuration and relates to the message CFG-CFG in the Protocol Specification.
Serial Communication
Serial Communication and the different communication ports supported by u-blox 5 technology are described
in the section Serial Communication Ports Description. The exact types and number of ports supported is
specific to the receiver and Firmware versions used. Software configuration of these ports is done with CFG-PRT
explained in the Protocol Specification.
Power Modes
Maximum Performance and Eco Power Modes are available with u-blox 5. A description of these modes is
provided in this section and configuration details are given under the message CFG-RXM and in the section
Power Modes for Search Engine of the Protocol Specification.
Timing
Timepulse and Timing Mode functions are detailed in section Timepulse Configuration and are configured with
the message CFG-TP described in the Protocol Specification.
The special timing premium features available only on selected modules are detailed in section Time Mode
Configuration and are configured with the message CFG-TMODE described in the Protocol Specification.
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 1
Antenna / Antenna Supervision
Antenna Supply and Antenna Supervision continue to be features supported by selected u-blox 5 receivers.
These are described in the applicable Hardware Integration Manual for the specific receiver, as well as in the
Receiver Description. The status is reported by the message MON-HW described in the Protocol Specification.
System
System Functions such as Hardware Monitoring, Reset and Firmware Update are explained in the section
Receiver Status Monitoring and are implemented with the messages MON, and CFG-RST described in the
Protocol Specification.
UART Ports
The receivers feature one or two universal asynchronous receiver/transmitter (UART) ports that can be used to
transmit GPS measurements, monitor status information and configure the receiver. The availability of the
second port depends on the type of module or chip set (see our online product selector matrix for modules and
chip sets).
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
or for different protocols on the same port.
Possible UART Interface Configurations
Baud Rate Data Bits Parity Stop Bits
4800 8 none 1
9600 8 none 1
19200 8 none 1
38400 8 none 1
57600 8 none 1
115200 8 none 1
If too much data is being configured for a certain port's bandwidth (e.g. all UBX messages shall be
output on a UART port with a baud rate of 9600), the buffer will fill up. Once the buffer's space is
exceeded, the receiver will deactivate messages automatically.
Please note that for protocols such as NMEA or UBX, it does not make sense to change the default values of
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 2
word length (data bits) since these properties are defined by the protocol, not by the electrical interface.
See CFG-PRT for UART for a description on the contents of the UART port configuration message.
USB Port
The receivers feature one USB (Universal Serial Bus) port, depending on the type of module or chip set (see our
online product selector matrix for modules and chip sets). This port can be used not only for communication
purposes, but also to power the GPS receiver.
The USB interface supports two different power modes:
• In the Self Powered Mode the receiver is powered by its own power supply. VDDUSB is used to detect the
availability of the USB port, i.e. whether the the receiver is connected to a USB host.
• In the Bus Powered Mode the device is powered by the USB bus, therefore no additional power supply is
needed. The default maximum current that can be drawn by the receiver is 120mA in that mode. See
CFG-USB for a description on how to change this maximum. Configuring the Bus Powered Mode implies
that the device enters a low power state with disabled GPS functionality when the host suspends the device,
e.g. when the host is put into stand-by mode.
The voltage range for VDDUSB is specified from 3.0V to 3.6V, which differs slightly from the
specification for VCC
DDC Port
A DDC Bus (Display Data Channel) is implemented, which is a 2-wire communication interface compatible with
the I2C standard (Inter-Integrated Circuit). Its availability is depending on the type of module or chip set (see
our online product selector matrix for modules and chip sets).
In contrast to all other interfaces, the DDC is not able to communicate in full-duplex mode, i.e. TX and RX are
mutually exclusive. u-blox 5 acts as a slave in the communication setup, therefore it cannot initiate data
transfers on its own. The master provides the data clock, therefore master and slave don't need to be
configured to use the same baud rate. Moreover, a baud rate setting is not applicable for the slave.
The baud rate clock provided by the master must not exceed 100kHz
The receiver's DDC address is set to 0x42 by default. This address can be changed by setting the mode field in
CFG-PRT for DDC accordingly.
As the receiver will be run in slave mode and the 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 DDC implements a simple streaming interface that allows the constant polling of data, discarding
everything that is not parseable. This means that the receiver returns 0xFF if no data is available.
If no data is polled for an extended period, the receiver temporarily stops writing data to the output buffer to
prevent overflowing.
Read Access
To allow both polled access to the full message stream and quick access to the key data, the register layout
depicted in Figure DDC Register Layout is provided. The data registers 0 to 252, at addresses 0x00 to 0xFC,
each 1 byte in size, contain information to be defined at a later point in time. At addresses 0xFD and 0xFE, the
currently available number of bytes in the message stream can be read. At address 0xFF, the message stream is
located. Subsequent reads from 0xFF return the messages in the transmit buffer, byte by byte. If the number of
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 3
bytes read exceeds the number of bytes indicated, the payload is padded using the value 0xFF.
The registers 0x00 to 0xFC will be defined in a later firmware release. Do not use them, as they
don't provide any meaningful data!
DDC Register Layout
Write Access
The receiver does not provide any write access except for writing UBX messages (and NMEA messages) to the
receiver, such as configuration or aiding data. Therefore, the register set mentioned in section Read Access is
not writable. Following the start condition from the master, the 7-bit device address including the RW bit (which
SPI Port
An SPI Bus (Serial Peripheral Interface is provided, depending on the type of module or chip set (see our online
product selector matrix for modules and chip sets). The SPI is a 3-wire synchronous communication interface; In
contrast to UART the master provides a clock, meaning that master and slave don't need to be configured to
use the same baud rate. Moreover, a baud 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 baud rate clock provided by the master must not exceed 250kHz
Read Access
As the register mode is not implemented for the SPI port, only the UBX/NMEA message stream is provided. 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.
In order to prevent the receiver from being busy parsing the incoming data, the parsing process is stopped after
20 subsequent bytes containing 0xFF. The parsing process gets re-enabled with the first byte not equal to 0xFF.
The number of bytes to wait for deactivation (20 by default) can be adjusted using the field mode.ffCnt in
CFG-PRT for SPI.
If the receiver has no more data to send, it pulls MISO to logic high, i.e. all bytes transmitted are set to 0xFF.
This means that the master should ignore all 0xFF which are not part of a message. It can resume data
processing as soon as the first byte not equalling 0xFF is received.
Geodetic Datum
Predefined Datum
The following, predefined Datum Values are available and can be configured using UBX message CFG-DAT.
For the ellipsoid parameters, see ellipsoid section below. For the rotation and scale parameters, see rotation and
scale section below.
Ellipsoids
Ellipsoids
Index Description Semi Major Axis [m] Flattening
0 WGS 84 6378137.000 298.257223563
1 Airy 1830 6377563.396 299.3249646
2 Modified Airy 6377340.189 299.3249646
3 Australian National 6378160.000 298.25
4 Bessel 1841 (Namibia) 6377483.865 299.1528128
5 Bessel 1841 6377397.155 299.1528128
6 Clarke 1866 6378206.400 294.9786982
7 Clarke 1880 6378249.145 293.465
8 Earth-90 6378136.000 298.257839303
9 Everest (India 1830) 6377276.345 300.8017
10 Everest (Sabah Sarawak) 6377298.556 300.8017
Timepulse Configuration
The receiver provides a hardware-synchronized timepulse pin with a time pulse (TP) period of 1 ms to 60 s. The
polarity (rising or falling edge) and the pulse duration can be configured. Use the UBX proprietary message
CFG-TP to change the timepulse settings. The UBX-TIM-TP message provides the time information for the next
timepulse, time source and a quantization error.
The CFG-TP message comprises the following parameters defining the hardware-synchronized timepulse:
• pulse interval - time interval between timepulses
• pulse length - duration of the timepulse (time period between rising and falling edge)
• pulse mode - if not disabled the synchronization of timepulse can be configured to be done on rising or
falling edge
• time reference - the reference time source (time base) used for timepulse synchronization and timepulse
time given in TIM-TP output message
• synchronization mode - the timepulse can be configured to be always synchronized and will be available
only in this case. If the timepulse is allowed to be asynchronized it will be available at any time even when
the time is not valid.
• antenna cable delay - the signal delay due to the cable between antenna and receiver
• RF group delay - delay of the signal in the RF module of the u-blox 5 receiver (hard coded)
• user delay - the cable delay from u-blox 5 receiver to the user device plus signal delay of any user
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 15
application
Notes:
• The pulse interval must be an integer division of 60 seconds.
• The maximum pulse length can’t exceed the pulse period minus 1 microsecond.
• A timepulse is only output when the receiver has determined the time with sufficent accuracy and reliability.
Recommendations:
• When using the timepulse for a timing application it is recommended to calibrate the
RF signal 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 accurate position is needed. Once the
receiver is in timing mode, the dynamic model does not influence the timing accuracy.
• If relative time accuracy between mutiple receivers is required, do not mix receivers of different product
family or brand; or else set cable delays on one of the two receivers such that the timepulses are not biased.
Example:
The example shows the 1PPS timepulse signal generated according the specific parameters of the CFG-TP
message.
PAGEBREAK
Receiver Configuration
Configuration Concept
u-blox 5 positioning technology is fully configurable with UBX protocol configuration messages (message class
UBX-CFG). The configuration used by the u-blox 5 GPS core during normal operation is termed "Current
Configuration". The Current Configuration can be changed during normal operation by sending any
UBX-CFG-XXX message to the receiver over an I/O port. The receiver will change its Current Configuration
immediately after receiving the configuration message. The u-blox 5 GPS core always uses only the Current
Configuration.
Unless the Current Configuration is made permanent by using CFG-CFG as described below, the Current
Configuration will be lost in case of (see message CFG-RST)
• a power cycle
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 17
• a hardware reset
• a (complete) controlled software reset
The Current Configuration can be made permanent (stored in a non-volatile memory) by saving it to the
"Permanent Configuration". This is done by sending a UBX-CFG-CFG message with an appropriate saveMask
(UBX-CFG-CFG/save).
The Permanent Configurations are copied to the Current Configuration after start-up or when a UBX-CFG-CFG
message with an appropriate loadMask (UBX-CFG-CFG/load) is sent to the receiver.
The Permanent Configuration can be restored to the receiver's Default Configuration by sending a
UBX-CFG-CFG message with an appropriate clearMask (UBX-CFG-CFG/clear) to the receiver.
This only replaces the Permanent Configuration, not the Current Configuration. To make the receiver operate
with the Default Configuration which was restored to the Permanent Configuration, a UBX-CFG-CFG/load
command must be sent or the receiver must be reset.
The mentioned masks (saveMask, loadMask, clearMask) are 4 byte bit fields . Every bit represents one
configuration sub-section. These sub-sections are defined in section "Organization of the Configuration
Sections"). All three masks are part of every UBX-CFG-CFG message. Save, load and clear commands can be
combined in the same message. Order of execution is save, load, clear.
The following diagram illustrates the process:
There are several compatible SBAS systems available or in development all around the world:
• WAAS (Wide Area Augmentation System) for North America has been in operation since 2003.
• MSAS (Multi-Functional Satellite Augmentation System) for Asia has been in operation since 2007.
• EGNOS (European Geostationary Navigation Overlay Service) is in test mode ESTB (EGNOS satellite test bed).
EGNOS has passed the ORR (Operational Readiness Review) in Q2/2005. Full operation of EGNOS is planned
for 2008.
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 20
• GAGAN (GPS Aided Geo Augmented Navigation), developed by the Indian government is in test mode and
expected to be operational by 2010.
Other systems are planned for Canada (CSAS), Africa (EGNOS) and South America.
SBAS support allows u-blox 5 technology to take full advantage of the augmentation systems that are currently
available (WAAS, EGNOS, MSAS), as well as those being tested and planned (such as GAGAN).
With SBAS enabled the user benefits from additional satellites for ranging (navigation). u-blox 5 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 is the use of GPS integrity information. In this way SBAS Control stations can ‘disable’ usage of
GPS satellites in case of major GPS satellite problems within a 6 second alarm time. If integrity monitoring is
enabled, u-blox 5 GPS technology will only use satellites, for which integrity information is available.
For more information on SBAS and associated services please refer to
• RTCA/DO-229C (MOPS). Available from www.rtca.org
• gps.faa.gov for information on WAAS and the NSTB
• www.esa.int for information on EGNOS and the ESTB
• www.essp.be for information about European Satellite Services Provider EEIG is the EGNOS operations
manager.
• www.kasc.go.jp for information on MSAS
SBAS GEO PRN Numbers
GEO identification Stationed over GPS PRN SBAS Provider
Inmarsat AOR-E Eastern Africa 120 EGNOS
Inmarsat AOR-W Western Africa 122 WAAS
ESA Artemis Africa (Congo) 124 EGNOS
Inmarsat IND-W Africa (Congo) 126 EGNOS
Insat-NAV (tbd) 127 GAGAN
Insat-NAV (tbd) 128 GAGAN
MTSAT-1R (or MTSAT-2) Pacific 129 MSAS
Inmarsat IOR Indian Ocean 131 EGNOS
Inmarsat POR Pacific 134 WAAS
PanAmSat Galaxy XV 133° West 135 WAAS
MTSAT-2 (or MTSAT-1R) (tbd) 137 MSAS
Telesat Anik F1R 107° West 138 WAAS
SBAS Features
This u-blox 5 SBAS implementation is, in accordance with standard RTCA/DO-229C, a class 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 5 is capable of receiving multiple SBAS satellites in parallel, even from different SBAS systems (WAAS,
EGNOS, MSAS, etc.). They can be tracked and used for navigation simultaneously. At least three SBAS satellites
can be tracked in parallel. Every SBAS satellite tracked utilizes one vacant GPS receiver tracking channel. Only
As each GEO services a specific region, the correction signal is only useful within that region. Therefore, mission
planning is crucial to determine the best possible configuration. The different stages (Testmode vs. Operational)
of the various SBAS systems further complicate this task. The following examples show possible scenarios:
Example 1: SBAS Receiver in North America
At the time of writing, the WAAS system is in operational stage, whereas the EGNOS system is still in test mode
(ESTB). Therefore, and especially in the eastern parts of the US, care must be taken in order not to have EGNOS
satellites taking preference over WAAS satellites. This can be achieved by disallowing Test Mode use (this
inhibits EGNOS satellites from being used as a correction data source), but keeping the PRN Mask to have all
SBAS GEOs enabled (which allows EGNOS GEOs to be used for navigation).
Example 2: SBAS Receiver in Europe
At the time of writing, the EGNOS system is still in test mode. To try out EGNOS operation, Testmode usage
must be enabled. Since the WAAS GEO #122 can be received in the western parts of Europe, but since this
GEO does not carry correction data for the European continent, the GEOs from all but the EGNOS system
should be disallowed, using the PRN Mask. It is important to understand that while EGNOS is in test mode,
anything can happen to the EGNOS signals, such as sudden interruption of service or broadcast of invalid or
inconsistent data.
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 Enables or disables the SBAS subsystem
Mode - Allow test mode usage Allow / Disallow SBAS usage from satellites in Test Mode (Message 0)
Services/Usage - Ranging Use the SBAS satellites for navigation
Services/Usage - Apply SBAS Combined enable/disable switch for Fast-, Long-Term and Ionosphere
correction data Corrections
Services/Usage - Apply integrity Use integrity data
information
Number of tracking channels Sets how many channels are reserved for SBAS tracking (if that many
SBAS signals were acquired). E.g., if this is set to three and five SBAS
SVs are acquired, only three of them will prioritized over available GPS
signals.
PRN Mask Allows to selectively enable/disable SBAS satellite. With this parameter,
for example, one can 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.
Introduction
Time Mode is a special stationary GPS receiver mode where the position of the receiver is known and fixed and
only the time is calculated using all available satellites. This mode allows for maximum time accuracy as well as
for single-SV solutions.
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 a Survey-in. Errors in the fixed position will
translate into time errors depending on the satellite constellation. Using the TDOP value (see UBX-NAV-DOP)
and assuming a symmetrical 3D position error , the expected time error can be estimated as
time error = tdop * position error
As a rule of thumb the position should be known better than 1m for a time accuracy on the order of
nanoseconds. If only microseconds accuracy is required, a position accuracy of roughly 300m is sufficient.
Survey-in
Survey-in is the procedure of determining a stationary receiver's position prior to using Time Mode by
averaging. The current implementation builds a weighted mean of all valid 3D position solutions. Two stop
criteria can 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 forces the calculated position to be of at least the given
accuracy. As the position error translates into a time error when using Time Mode (see above), one should
carefully evaluate the time accuracy requirements and the choose an appropriate position accuracy
requirement.
Platform settings
u-blox 5 positioning technology supports different dynamic platform models to adjust the navigation engine to
the expected environment. These platform settings can be changed dynamically without doing a power cycle or
reset. It allows a better interpretation of the measurements and hence provides a more accurate position
output. Setting the receiver to an unsuitable platform model for the application environment may reduce the
receiver performance and position accuracy significantly.
Dynamic Platform Model
Platform Description
Portable Default setting. Applications with low accelerations, as any portable devices. Suitable for
most situations. MAX Altitude [m]: 12000, MAX Velocity [m/s]: 310, MAX Vertical Velocity
[m/s]: 50, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium
Stationary Used in timing applications (antenna must be stationary) or other stationary applications.
Velocity is constrained to 0 m/s. Zero dynamics assumed. MAX Altitude [m]: 9000, MAX
Velocity [m/s]: 10, MAX Vertical Velocity [m/s]: 6, Sanity check type: Altitude and Velocity,
Max Position Deviation: Small
Pedestrian Applications with low accelerations and low speed, as a pedestrian would move. Assuming
low accelerations. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX Vertical Velocity
[m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation: Small
Automotive Used for applications that can be compared with the dynamics of a passenger car.
Assuming low vertical acceleration. MAX Altitude [m]: 5000, MAX Velocity [m/s]: 62, MAX
Vertical Velocity [m/s]: 15, Sanity check type: Altitude and Velocity, Max Position Deviation:
Medium
At sea Recommended for applications at sea, with zero vertical velocity. Assuming zero vertical
velocity. MAX Altitude [m]: 500, MAX Velocity [m/s]: 25, MAX Vertical Velocity [m/s]: 5,
Sanity check type: Altitude and Velocity, Max Position Deviation: Medium
Airborne <1g Used for applications that have to handle a higher dynamic range than a car and higher
vertical accelerations. No 2D position fixes supported. MAX Altitude [m]: 50000, MAX
Velocity [m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max
Position Deviation: Large
Airborne <2g Recommended for typical airborne environment. No 2D position fixes supported. MAX
Altitude [m]: 50000, MAX Velocity [m/s]: 250, MAX Vertical Velocity [m/s]: 100, Sanity
check type: Altitude, Max Position Deviation: Large
Airborne <4g Only recommended for an extreme dynamic environment. No 2D position fixes supported.
MAX Altitude [m]: 50000, MAX Velocity [m/s]: 500, MAX Vertical Velocity [m/s]: 100,
Sanity check type: Altitude, Max Position Deviation: Large
Dynamic platforms designed for high acceleration systems (e.g. airborne <2g) may result in a
greater standard deviation in the reported position.
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver Receiver Description
GPS.G5-X-07036-E Public Release Page 25
Navigation Input Filters
The navigation input filters mask the input data of the navigation engine.
These settings are already optimized. It is not recommended that changes to any parameters be
made unless advised by u-blox support engineers.
Navigation Input Filter parameters
Parameter Description
fixMode By default, the receiver calculates a 3D position fix if possible but reverts to a 2D position if
necessary (Auto 2D/3D). It is possible to force the receiver to permanently 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 zero must be
fixedAltVar supplied as well.
minElev Minimum elevation of a satellite above the horizon in order to be used in the navigation
solution. Low elevation satellites may provide degraded accuracy, because of the long
signal path through the atmosphere.
drLimit Dead Reckoning limit: The time during which the receiver provides an extrapolated
solution. After the DR timeout has expired, no GPS solution is provided at all.
Static Hold
The 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 issues such as multi-path and improves position accuracy especially in stationary applications. By
default, static hold mode is disabled.
If the speed goes below the defined ‘Static Hold Threshold’, the position is kept constant. Once the static hold
mode has been entered, the position and velocity output will be kept constant, until there is evidence of
movement. 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.
2D Navigation
If the receiver only has 3 satellites to calculate a position, the navigation algorithm uses a constant altitude to
make up for the missing fourth satellite. When losing a satellite after a successful 3D fix (min. 4 SV available),
the altitude is kept constant to the last known altitude. This is called a 2D fix.
The u-blox 5 positioning technology does not calculate any solution with a number of SVs less than
3. Only u-blox 5 Timing Receivers can calculate timing solution with only one SV when stationary.
Input/Output system
The I/O system is a GPS-internal layer where all data input- and output capabilities (such as UART, DDC, SPI,
USB) of the GPS 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 MON-TXBUF can be used. This message shows the current and maximum buffer usage, as well as
error conditions.
If too much data is being configured for a certain port's bandwidth (e.g. all UBX messages shall be
output on a UART port with a baud rate of 9600), the buffer will fill up. Once the buffer's space is
exceeded, the receiver will deactivate messages automatically.
Inbound data to the GPS receiver is placed in buffers. These buffers' usage are shown with the message
MON-RXBUF. Further, as data is then decoded within the receiver (e.g. to separate UBX- and NMEA data), the
Startup Strategies
• Coldstart: In this startup mode, the receiver has no information about last position, time, velocity, frequency
etc. Therefore, the receiver has to search the full time- and frequency space, and also all possible satellite
numbers. If a satellite signal is found, it is being tracked to decode ephemeris (18-36 seconds under strong
signal conditions), whereas the other channels continue to search satellites. Once there are sufficient number
of satellites with valid ephemeris, the receiver can calculate position- and velocity data. Please note that
some competitors call this startup mode Factory Startup.
• Warmstart: In Warmstart mode, the receiver has approximate information of time, position, and coarse
data on Satellite positions (Almanac). In this mode, after power-up, the receiver basically needs to download
ephemeris until it can calculate position- and velocity data. As the ephemeris data usually is outdated after 4
hours, the receiver will typically start with a warmstart if it was powered down for more than that amount of
time. For this scenario, several augmentations exist. See the sections on AssistNOW online and offline below.
• Hotstart: In Hotstart, the receiver was powered down only for a short time (4 hours or less), so that its
ephemeris is still valid. Since the receiver doesn't need to download ephemeris again, this is the fastest
Aiding Data
The following aiding data can be submitted to the receiver:
• Position: Position information can be submitted to the receiver using the UBX-AID-INI message. Both,
ECEF X/Y/Z and latitude/longitude/height formats are supported.
• Time: The 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 external interrupt. Both methods are supported in the UBX-AID-INI
message.
• Frequency: It is possible to supply hardware frequency aiding by connecting a continuous signal to an
external interrupt using the UBX-AID-INI message.
• Orbit data: Orbit data can be submitted using UBX-AID-ALM and UBX-AID-EPH.
• Additional information: UBX-AID-HUI can be used to supply health information, UTC parameters and
ionospheric data to the receiver.
Aiding Sequence
A typical aiding sequence would comprise following steps:
• Power-up the GPS receiver
• Send UBX-AID-INI (time, clock and position) message.
• Send UBX-AID-EPH (ephemeris) message.
• Apply optional hardware time synchronization pulse within 0.5s after (or before, depending on the
configuration in UBX-AID-INI) sending the UBX-AID-INI message if hardware time synchronization is
required. When sending the message before applying the pulse, make sure to allow the GPS receiver to
parse and process the aiding message. The time for parsing depends on the baud rate. The processing time
is 100ms maximum.
• Send optional UBX-AID-HUI (health, UTC and ionosphere parameters) message.
• Send optional UBX-AID-ALM (almanac) message.
Messaging wise, AssistNow Online consists of Aiding data which deliver Position and Time UBX-AID-INI,
Ephemerides UBX-AID-EPH, Almanac UBX-AID-ALM and Health/UTC/Iono information UBX-AID-HUI
AssistNow Offline
AssistNow Offline is an A-GPS service that boosts GPS acquisition performance, bringing Time To First Fix (TTFF)
down to seconds. Unlike AssistNow Online, this solution enables instant positioning without the need for
connectivity at start-up. The system works by using AlmanacPlus (ALP) differential almanac correction data to
speed up acquisition, enabling a position fix within seconds. Users access the data by means of occasional
Internet downloads, at the user's convenience.
Please note that this functionality is only supported on u-blox 5 Firmware 4.0 and above.
Message specifics
The three variants of this message always have a header and variable-size data appended within the same
message. The very first field, idSize gives the number of bytes where the header within the UBX payload
ends and data starts.
In case of the ALP client request, the server must assemble a new message according to the
AID-ALPSRV-SRV variant. The header needs to be duplicated for as many as idSize bytes. Additionally, the
server needs to fill in the fileId and dataSize fields. Appended to the idSize-sized header, data must be
added as requested by the client (from offset ofs, for size number of values).
Range checks
The server needs to perform an out-of-bounds check on the ofs and size fields, as the client may request
data beyond the actually available data. If the client request is within the bounds of available data, the
dataSize field needs to be filled in with 2 x the content of the size field (the size field is in units of 16 bits,
whereas the dataSize field expects number of bytes). If the client request would request data beyond the
limits of the buffer, the data should be reduced accordingly, and this actual number of bytes sent shall be
indicated in the dataSize field
Please note that this functionality is only supported on u-blox 5 Firmware 4.0 and above and with
special versions of Antaris 4 receivers.
Download Procedure
The following steps are a typical sequence for downloading an ALP file to the receiver:
• The server downloads a copy of a current ALP file, and stores it locally
• It sends the first N bytes from that file, using the AID-ALP-TX message
• The server awaits a AID-ALP-ACK or AID-ALP-NAK message.
• If can then continue, sending the next N bytes if the message was acknowledged.
• Once all data has been transferred, or a NAK has been received, the server sends an AID-ALP-STOP
message
Please note that
• N should not be larger than ~700 bytes (due to the input buffers on the RS232/USB lines). Smaller values of
N might improve reliability
• N must be a multiple of 2.
• There is no re-send mechanism. If a NAK message is received, the full downloading process must be
restarted.
• There is no explicit checksum, but an implicit one, as the ALP file already includes a checksum to verify
consistency
Overview of the different versions of AID-ALP messages
Short Name Content Direction
AID-ALP-TX ALP server sends Data to client Server -> Client
AID-ALP-STOP ALP server terminates a transfer sequence Server -> Client
AID-ALP-ACK ALP client acknowledges successful receipt of data. Client -> Server
AID-ALP-NAK ALP client indicates a failed reception of data Client -> Server
AID-ALP-STAT ALP client reports status of the ALP data stored in flash memory Client -> Server
For further information on the NMEA Standard please refer to NMEA 0183 Standard For Interfacing Marine
Electronic Devices, Version 2.30, March 1, 1998. See http://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 is used for all non-standard
messages. These proprietary NMEA messages therefore have the address field set to PUBX. The first data field
in a PUBX message identifies the message number with two digits.
power-up, after but user limits (linear receivers) position fix (only on DR
UBX GPSFixOK 0 0 0 1 1 1 1
UBX GPSFix 0 >1 1 1 2 3 4
The following list shows how u-blox implements the NMEA protocol, and the conditions determining how flags
are set in version 2.2 and below.
NMEA Message: Field No position fix (at Valid position fix, Dead reckoning EKF (only on DR 2D position fix 3D position fix combined GPS/EKF
power-up, after but user limits (linear receivers) position fix (only on DR
GLL, RMC, VTG: Mode Indicator. This field is not output by this NMEA version.
UBX GPSFixOK 0 0 0 1 1 1 1
UBX GPSFix 0 >1 1 1 2 3 4
By default the receiver will not output invalid data. In such cases, it will output empty fields.
In Antaris firmware versions older than 3.0, the receiver did output invalid data and marked it with
the 'Invalid/Valid' Flags. If required, this function can still be enabled in later firmware versions,
using the UBX protocol message CFG-NMEA.
49 GLL 0xF0 0x01 Latitude and longitude, with time of position fix and status
GGA
Message GGA
Description Global positioning system fix data
Firmware Supported on u-blox 5 from firmware version 4.00 up to version 5.00.
Type Output Message
Comment The output of this message is dependent on the currently selected datum (Default:
WGS84)
Time and position, together with GPS fixing related data (number of satellites in use, and
the resulting HDOP, age of differential data if in use, etc.).
ID for CFG-MSG Number of fields
Message Info 0xF0 0x00 17
Message Structure:
$GPGGA,hhmmss.ss,Latitude,N,Longitude,E,FS,NoSV,HDOP,msl,m,Altref,m,DiffAge,DiffStation*cs<CR><LF>
Example:
$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,8,1.01,499.6,M,48.0,M,,0*5B
Field Example Format Name Unit Description
No.
0 $GPGGA string $GPGGA - Message ID, GGA protocol header
1 092725.00 hhmmss.ssshhmmss. - UTC Time, Current time
ss
2 4717.11399 ddmm.mmmm Latitude - Latitude, Degrees + minutes, see Format description
3 N character N - N/S Indicator, N=north or S=south
4 00833.91590 dddmm. Longitud - Longitude, Degrees + minutes, see Format
mmmm e description
5 E character E - E/W indicator, E=east or W=west
6 1 digit FS - Position Fix Status Indicator, See Table below and
Position Fix Flags description
7 8 numeric NoSV - Satellites Used, Range 0 to 12
8 1.01 numeric HDOP - HDOP, Horizontal Dilution of Precision
9 499.6 numeric msl m MSL Altitude
10 M character uMsl - Units, Meters (fixed field)
11 48.0 numeric Altref m Geoid Separation
12 M character uSep - Units, Meters (fixed field)
13 - numeric DiffAge s Age of Differential Corrections, Blank (Null) fields
when DGPS is not used
14 0 numeric DiffStat - Diff. Reference Station ID
ion
15 *5B hexadecimal cs - Checksum
16 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPGLL,4717.11364,N,00833.91565,E,092321.00,A,A*60
Field Example Format Name Unit Description
No.
0 $GPGLL string $GPGLL - Message ID, GLL protocol header
1 4717.11364 ddmm.mmmm Latitude - Latitude, Degrees + minutes, see Format description
2 N character N - N/S Indicator, hemisphere N=north or S=south
3 00833.91565 dddmm. Longitud - Longitude, Degrees + minutes, see Format
mmmm e description
4 E character E - E/W indicator, E=east or W=west
5 092321.00 hhmmss.sss hhmmss. - UTC Time, Current time
ss
6 A character Valid - V = Data invalid or receiver warning, A = Data valid.
See Position Fix Flags description
Start of optional block
Example:
$GPGSA,A,3,23,29,07,08,09,18,26,28,,,,,1.94,1.18,1.54*0D
Field Example Format Name Unit Description
No.
0 $GPGSA string $GPGSA - Message ID, GSA protocol header
1 A character Smode - Smode, see first table below
2 3 digit FS - Fix status, see second table below and Position Fix
Flags description
Start of repeated block (12 times)
Example:
$GPGSV,3,1,10,23,38,230,44,29,71,156,47,07,29,116,41,08,09,081,36*7F
$GPGSV,3,2,10,10,07,189,,05,05,220,,09,34,274,42,18,25,309,44*72
$GPGSV,3,3,10,26,82,187,47,28,43,056,46*77
Field Example Format Name Unit Description
No.
0 $GPGSV string $GPGSV - Message ID, GSV protocol header
1 3 digit NoMsg - Number of messages, total number of GPGSV
messages being output
2 1 digit MsgNo - Number of this message
3 10 numeric NoSv - Satellites in View
Start of repeated block (1..4 times)
4+ 23 numeric sv - Satellite ID
4*N
5+ 38 numeric elv degr Elevation, range 0..90
4*N ees
6+ 230 numeric az degr Azimuth, range 0..359
4*N ees
7+ 44 numeric cno dBH C/N0, range 0..99, null when not tracking
4*N z
End of repeated block
Example:
$GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A*57
Field Example Format Name Unit Description
No.
0 $GPRMC string $GPRMC - Message ID, RMC protocol header
1 083559.00 hhmmss.sss hhmmss. - UTC Time, Time of position fix
ss
2 A character Status - Status, V = Navigation receiver warning, A = Data
valid, see Position Fix Flags description
3 4717.11437 ddmm.mmmm Latitude - Latitude, Degrees + minutes, see Format description
4 N character N - N/S Indicator, hemisphere N=north or S=south
5 00833.91522 dddmm. Longitud - Longitude, Degrees + minutes, see Format
mmmm e description
6 E character E - E/W indicator, E=east or W=west
7 0.004 numeric Spd knot Speed over ground
s
8 77.52 numeric Cog degr Course over ground
ees
9 091202 ddmmyy date - Date in day, month, year format
10 - numeric mv degr Magnetic variation value, not being output by
ees receiver
11 - character mvE - Magnetic variation E/W indicator, not being output
by receiver
12 - character mode - Mode Indicator, see Position Fix Flags description
13 *57 hexadecimal cs - Checksum
14 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPVTG,77.52,T,,M,0.004,N,0.008,K,A*06
Field Example Format Name Unit Description
No.
0 $GPVTG string $GPVTG - Message ID, VTG protocol header
1 77.52 numeric cogt degr Course over ground (true)
ees
2 T character T - Fixed field: true
3 - numeric cogm degr Course over ground (magnetic), not output
ees
4 M character M - Fixed field: magnetic
5 0.004 numeric sog knot Speed over ground
s
6 N character N - Fixed field: knots
7 0.008 numeric kph km/ Speed over ground
h
8 K character K - Fixed field: kilometers per hour
9 A character mode - Mode Indicator, see Position Fix Flags description
10 *06 hexadecimal cs - Checksum
11 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPGRS,082632.00,1,0.54,0.83,1.00,1.02,-2.12,2.64,-0.71,-1.18,0.25,,,*70
Field Example Format Name Unit Description
No.
0 $GPGRS string $GPGRS - Message ID, GRS protocol header
1 082632.00 hhmmss.sss hhmmss. - UTC Time, Time of associated position fix
ss
2 1 digit mode - Mode (see table below), u-blox receivers will always
output Mode 1 residuals
Start of repeated block (12 times)
3 + 0.54 numeric residual m Range residuals for SVs used in navigation. The SV
1*N order matches the order from the GSA sentence.
End of repeated block
Example:
$GPGST,082356.00,1.8,,,,1.7,1.3,2.2*7E
Field Example Format Name Unit Description
No.
0 $GPGST string $GPGST - Message ID, GST protocol header
1 082356.00 hhmmss.sss hhmmss. - UTC Time, Time of associated position fix
ss
2 1.8 numeric range_rm m RMS value of the standard deviation of the ranges
s
3 - numeric std_majo m Standard deviation of semi-major axis, not
r supported (empty)
4 - numeric std_mino m Standard deviation of semi-minor axis, not
r supported (empty)
5 - numeric hdg degr Orientation of semi-major axis, not supported
ees (empty)
6 1.7 numeric std_lat m Standard deviation of latitude, error in meters
7 1.3 numeric std_long m Standard deviation of longitude, error in meters
8 2.2 numeric std_alt m Standard deviation of altitude, error in meters
9 *7E hexadecimal cs - Checksum
10 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPZDA,082710.00,16,09,2002,00,00*64
Field Example Format Name Unit Description
No.
0 $GPZDA string $GPZDA - Message ID, ZDA protocol header
1 082710.00 hhmmss.sss hhmmss. - UTC Time
ss
2 16 dd day day UTC time: day, 01..31
3 09 mm month mon UTC time: month, 01..12
th
4 2002 yyyy year year UTC time: 4 digit year
5 00 -xx ltzh - Local zone hours, not supported (fixed to 00)
6 00 zz ltzn - Local zone minutes, not supported (fixed to 00)
7 *64 hexadecimal cs - Checksum
8 - character <CR><LF> - Carriage Return and Line Feed
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*5B
Field Example Format Name Unit Description
No.
0 $GPGBS string $GPGBS - Message ID, GBS protocol header
1 235503.00 hhmmss.sss hhmmss. - UTC Time, Time to which this RAIM sentence
ss belongs
2 1.6 numeric errlat m Expected error in latitude
3 1.4 numeric errlon m Expected error in longitude
4 3.2 numeric erralt m Expected error in altitude
5 03 numeric svid - Satellite ID of most likely failed satellite
6 - numeric prob - Probability of missed detection, no supported
(empty)
7 -21.4 numeric bias m Estimate on most likely failed satellite (a priori
residual)
8 3.8 numeric stddev m Standard deviation of estimated bias
9 *40 hexadecimal cs - Checksum
10 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPDTM,W84,,0.0,N,0.0,E,0.0,W84*6F
$GPDTM,W72,,0.00,S,0.01,W,-2.8,W84*4F
$GPDTM,999,CH95,0.08,N,0.07,E,-47.7,W84*1C
Field Example Format Name Unit Description
No.
0 $GPDTM string $GPDTM - Message ID, DTM protocol header
1 W72 string LLL - Local Datum Code, W84 = WGS84, W72 = WGS72,
999 = user defined
2 - string LSD - Local Datum Subdivision Code, This field outputs
the currently selected Datum as a string (see also
note above).
3 0.08 numeric lat min Offset in Latitude
utes
4 S character NS - North/South indicator
5 0.07 numeric lon min Offset in Longitude
utes
6 E character EW - East/West indicator
7 -2.8 numeric alt m Offset in altitude
8 W84 string RRR - Reference Datum Code, W84 = WGS 84. This is the
only supported Reference datum.
9 *67 hexadecimal cs - Checksum
10 - character <CR><LF> - Carriage Return and Line Feed
Example:
$EIGPQ,RMC*3A
Field Example Format Name Unit Description
No.
0 $EIGPQ string $xxGPQ - Message ID, GPQ protocol header, xx = talker
identifier
1 RMC string sid - Sentence identifier
2 *3A hexadecimal cs - Checksum
3 - character <CR><LF> - Carriage Return and Line Feed
Example:
$GPTXT,01,01,02,u-blox ag - www.u-blox.com*50
UBX,00
Message UBX,00
Description Lat/Long Position Data
Firmware Supported on u-blox 5 from firmware version 4.00 up to version 5.00.
Type Output Message
Comment The output of this message is dependent on the currently selected datum (Default:
WGS84)
This message contains position solution data. The datum selection may be changed using
the message CFG-DAT.
ID for CFG-MSG Number of fields
Message Info 0xF1 0x00 23
Message Structure:
$PUBX,00,hhmmss.ss,Latitude,N,Longitude,E,AltRef,NavStat,Hacc,Vacc,SOG,COG,Vvel,ageC,HDOP,VDOP,TDOP
,GU,RU,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 Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 00 numeric ID - Propietary message identifier: 00
2 081350.00 hhmmss.sss
hhmmss. - UTC Time, Current time
ss
3 4717.113210 ddmm.mmmm Latitude - Latitude, Degrees + minutes, see Format description
4 N character N - N/S Indicator, N=north or S=south
5 00833.915187 dddmm. Longitud - Longitude, Degrees + minutes, see Format
mmmm e description
6 E character E - E/W indicator, E=east or W=west
7 546.589 numeric AltRef m Altitude above user datum ellipsoid.
8 G3 string NavStat - Navigation Status, See Table below
9 2.1 numeric Hacc m Horizontal accuracy estimate.
10 2.0 numeric Vacc m Vertical accuracy estimate.
11 0.007 numeric SOG km/ Speed over ground
h
12 77.52 numeric COG degr Course over ground
ees
13 0.007 numeric Vvel m/s Vertical velocity, positive=downwards
14 - numeric ageC s Age of most recent DGPS corrections, empty = none
available
Example:
$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 Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 03 numeric ID - Propietary message identifier: 03
2 11 numeric GT - Number of GPS satellites tracked
Start of repeated block (GT times)
Example:
$PUBX,04,073731.00,091202,113851.00,1196,113851.00,1930035,-2660.664,43,*3C
Field Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 04 numeric ID - Propietary message identifier: 04
2 073731.00 hhmmss.sss hhmmss. - UTC Time, Current time in hour, minutes, seconds
ss
3 091202 ddmmyy ddmmyy - UTC Date, day, month, year format
4 113851.00 numeric UTC_TOW s UTC Time of Week
5 1196 numeric week - GPS week numer, continues beyond 1023
6 113851.00 numeric reserved - reserved, for future use
7 1930035 numeric Clk_B ns Receiver clock bias
8 -2660.664 numeric Clk_D ns/s Receiver clock drift
9 43 numeric PG ns Timepulse Granularity, The quantization error of the
Timepulse pin
10 *3C hexadecimal cs - Checksum
11 - character <CR><LF> - Carriage Return and Line Feed
Example:
$PUBX,04*37
Field Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 04 numeric MsgID - Requested PUBX message identifier
2 *37 hexadecimal cs - Checksum
3 - character <CR><LF> - Carriage Return and Line Feed
Example:
$PUBX,40,GLL,1,0,0,0,0,0*5D
Field Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 40 numeric ID - Proprietary message identifier
2 GLL string MsgId - NMEA message identifier
3 1 numeric rddc cycl output rate on DDC
es - 0 disables that message from being output on this
port
- 1 means that this message is output every epoch
4 1 numeric rus1 cycl output rate on USART 1
es - 0 disables that message from being output on this
port
- 1 means that this message is output every epoch
5 1 numeric rus2 cycl output rate on USART 2
es - 0 disables that message from being output on this
port
- 1 means that this message is output every epoch
6 1 numeric rusb cycl output rate on USB
es - 0 disables that message from being output on this
port
- 1 means that this message is output every epoch
7 1 numeric rspi cycl output rate on SPI
es - 0 disables that message from being output on this
port
- 1 means that this message is output every epoch
8 0 numeric reserved - Reserved, Always fill with 0
9 *5D hexadecimal cs - Checksum
10 - character <CR><LF> - Carriage Return and Line Feed
Example:
$PUBX,41,1,0007,0003,19200,0*25
Field Example Format Name Unit Description
No.
0 $PUBX string $PUBX - Message ID, UBX protocol header, proprietary
sentence
1 41 numeric ID - Proprietary message identifier
2 1 numeric portID - ID of communication port, for a list of port IDs see
CFG-PRT.
3 0007 hexadecimal inProto - Input protocol mask. Bitmask, specifying which
protocols(s) are allowed for input. For details see
corresponding field in CFG-PRT.
4 0003 hexadecimal outProto - Output protocol mask. Bitmask, specifying which
protocols(s) are allowed for input. For details see
corresponding field in CFG-PRT.
5 19200 numeric baudrate bits/ Baudrate
s
6 0 numeric autobaud - Autobauding: 1=enable, 0=disable (not supported
ing on u-blox 5, set to 0)
7 *25 hexadecimal cs - Checksum
8 - character <CR><LF> - Carriage Return and Line Feed
Message Naming
Referring to messages is done by adding the class name and a dash in front of the message name. For example,
the ECEF-Message is referred to as NAV-POSECEF. Referring to values is done by adding a dash and the name,
e.g. NAV-POSECEF-X
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. A technical description of the
IEEE754 format can be found in the AnswerBook from the ADS1.x toolkit.
The following table gives information about the various values:
Short Type Size (Bytes) Comment Min/Max Resolution
U1 Unsigned Char 1 0..255 1
I1 Signed Char 1 2's complement -128..127 1
X1 Bitfield 1 n/a n/a
U2 Unsigned Short 2 0..65535 1
I2 Signed Short 2 2's complement -32768..32767 1
X2 Bitfield 2 n/a n/a
U4 Unsigned Long 4 0..4'294'967'295 1
I4 Signed Long 4 2's complement -2'147'483'648 .. 1
2'147'483'647
X4 Bitfield 4 n/a n/a
R4 IEEE 754 Single Precision 4 -1*2^+127 .. ~ Value * 2^-24
2^+127
R8 IEEE 754 Double Precision 8 -1*2^+1023 .. ~ Value * 2^-53
2^+1023
CH ASCII / ISO 8859.1 Encoding 1
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 at the end of the packet.
Acknowledgement
When messages from the Class CFG are sent to the receiver, the receiver will send an Acknowledge (ACK-ACK)
or a Not Acknowledge (ACK-NAK) message back to the sender, depending on whether or not the message
was processed correctly.
There is no ACK/NAK mechanism for message poll requests outside Class CFG.
Polling Mechanism
All messages that are output by the receiver in a periodic manner (i.e. Messages in Classes MON, NAV and
RXM) can also be polled.
There is not a single specific message which polls any other message. The UBX protocol was designed such,
that when sending a message with no payload (or just a single parameter which identifies the poll request) the
message is polled.
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver UBX Protocol
GPS.G5-X-07036-E Public Release Page 62
UBX Messages Overview
Page Mnemonic Cls/ID Length Type Description
UBX Class ACK Ack/Nack Messages
130 AID-ALM 0x0B 0x30 0 Poll Request Poll GPS Aiding Almanach Data
131 AID-ALM 0x0B 0x30 1 Poll Request Poll GPS Aiding Almanach Data for a SV
131 AID-ALM 0x0B 0x30 (8) or (40) Input/Output Message GPS Aiding Almanach Input/Output Message
133 AID-ALPSRV 0x0B 0x32 16 Output Message ALP client requests AlmanacPlus data from server
134 AID-ALPSRV 0x0B 0x32 16 + 1*dataSize Input Message ALP server sends AlmanacPlus data to client
135 AID-ALPSRV 0x0B 0x32 8 + 2*size Output Message ALP client sends AlmanacPlus data to server.
135 AID-ALP 0x0B 0x50 0 + 2*Variable Input message ALP file data transfer to the receiver
136 AID-ALP 0x0B 0x50 1 Input message Mark end of data transfer
137 AID-ALP 0x0B 0x50 1 Output message Indicate problems with a data transfer
130 AID-DATA 0x0B 0x10 0 Poll Polls all GPS Initial Aiding Data
132 AID-EPH 0x0B 0x31 0 Poll Request Poll GPS Aiding Ephemeris Data
132 AID-EPH 0x0B 0x31 1 Poll Request Poll GPS Aiding Ephemeris Data for a SV
133 AID-EPH 0x0B 0x31 (8) or (104) Input/Output Message GPS Aiding Ephemeris Input/Output Message
128 AID-HUI 0x0B 0x02 0 Poll Request Poll GPS Health, UTC and ionosphere parameters
129 AID-HUI 0x0B 0x02 72 Input/Output Message GPS Health, UTC and ionosphere parameters
126 AID-INI 0x0B 0x01 0 Poll Request Poll GPS Initial Aiding Data
127 AID-INI 0x0B 0x01 48 Polled Aiding position, time, frequency, clock drift
126 AID-REQ 0x0B 0x00 0 Virtual Sends a poll (AID-DATA) for all GPS Aiding Data
109 CFG-ANT 0x06 0x13 0 Poll Request Poll Antenna Control Settings
107 CFG-CFG 0x06 0x09 (12) or (13) Command Clear, Save and Load configurations
100 CFG-INF 0x06 0x02 1 Poll Request Poll INF message configuration for one protocol
118 CFG-NAV5 0x06 0x24 0 Poll Request Poll Navigation Engine Settings
117 CFG-NAVX5 0x06 0x23 0 Poll Request Poll Navigation Engine Expert Settings
117 CFG-NAVX5 0x06 0x23 40 Get/Set Get/Set Navigation Engine Expert Settings
113 CFG-NMEA 0x06 0x17 0 Poll Request Poll the NMEA protocol configuration
113 CFG-NMEA 0x06 0x17 4 Set/Get Set/Get the NMEA protocol configuration
92 CFG-PRT 0x06 0x00 0 Poll Request Polls the configuration of the used I/O Port
92 CFG-PRT 0x06 0x00 1 Poll Request Polls the configuration for one I/O Port
94 CFG-PRT 0x06 0x00 20 Get/Set Get/Set Port Configuration for USB Port
96 CFG-PRT 0x06 0x00 20 Get/Set Get/Set Port Configuration for SPI Port
97 CFG-PRT 0x06 0x00 20 Get/Set Get/Set Port Configuration for DDC Port
106 CFG-RATE 0x06 0x08 0 Poll Request Poll Navigation/Measurement Rate Settings
101 CFG-RST 0x06 0x04 4 Command Reset Receiver / Clear Backup Data Structures
116 CFG-TMODE 0x06 0x1D 0 Poll Request Poll Time Mode Settings
90 INF-DEBUG 0x04 0x04 0 + 1*variable ASCII String output, indicating debug output
89 INF-NOTICE 0x04 0x02 0 + 1*variable ASCII String output, with informational contents
89 INF-TEST 0x04 0x03 0 + 1*variable ASCII String output, indicating test output
122 MON-MSGPP 0x0A 0x06 120 Periodic/Polled Message Parse and Process Status
Bitfield flags
This Graphic explains the bits of flags
Name Description
gpsFixOk within DOP and ACC Masks
diffSoln 1 if DGPS used
Bitfield diffStat
This Graphic explains the bits of diffStat
Name Description
dgpsIStat DGPS Input Status
00: none
01: PR+PRR Correction
10: PR+PRR+CP Correction
11: High accuracy PR+PRR+CP Correction
Name Description
GPSfixOK i.e within DOP & ACC Masks
DiffSoln 1 if DGPS used
WKNSET 1 if Week Number valid
TOWSET 1 if Time of Week valid
Name Description
tow 1=Valid Time of Week
week 1=Valid Week Number
utc 1=Valid Leap Seconds, i.e. Leap Seconds already known
Bitfield valid
This Graphic explains the bits of valid
Name Description
Bitfield globalFlags
This Graphic explains the bits of globalFlags
Name Description
isU5 u-blox 5 generation receiver
Bitfield flags
This Graphic explains the bits of flags
Name Description
svUsed SV is used for navigation
diffCorr Differential correction data is available for this SV
orbitAvail Orbit information is available for this SV (Ephemeris or Almanach)
orbitEph Orbit information is Ephemeris
unhealthy SV is unhealthy / shall not be used
orbitAlm Orbit information is Almanac Plus
Name Description
qualityInd Signal Quality indicator (range 0..7). The following list shows the meaning of the different QI values:
0: This channel is idle
1: Channel is searching
2: Signal aquired
3: Signal detected but unusable
4: Code Lock on Signal
5, 6, 7: Code and Carrier locked
12 + 12*N U1 - svid - SV Id
13 + 12*N U1 - flags - Flags for this SV
14 + 12*N U1 - udre - Monitoring status
15 + 12*N U1 - svSys - System (WAAS/EGNOS/...)
same as SYS
16 + 12*N U1 - svService - Services available
same as SERVICE
17 + 12*N U1 - res0 - Reserved
18 + 12*N I2 - prc cm Pseudo Range correction in [cm]
20 + 12*N I2 - res1 - Reserved
22 + 12*N I2 - ic cm Ionosphere correction in [cm]
End of repeated block
Bitfield service
This Graphic explains the bits of service
Bitfield svFlag
This Graphic explains the bits of svFlag
Name Description
ura Figure of Merit (URA) range 0..15
healthy SV healthy flag
ephVal Ephemeris valid
almVal Almanach valid
Bitfield age
This Graphic explains the bits of age
Name Description
almAge Age of ALM in days offset by 4
i.e. the reference time may be in the future:
ageOfAlm = (age & 0x0f) - 4
ephAge Age of EPH in hours offset by 4.
i.e. the reference time may be in the future:
ageOfEph = ((age & 0xf0) >> 4) - 4
Comment This message has a variable length payload, representing an ASCII string.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x04 0x00 0 + 1*variable see below CK_A CK_B
Payload Contents:
Byte Offset Number Scaling Name Unit Description
Format
Start of repeated block (variable times)
Comment This message has a variable length payload, representing an ASCII string.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x04 0x01 0 + 1*variable see below CK_A CK_B
Payload Contents:
Byte Offset Number Scaling Name Unit Description
Format
Start of repeated block (variable times)
Comment This message has a variable length payload, representing an ASCII string.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x04 0x02 0 + 1*variable see below CK_A CK_B
Payload Contents:
Byte Offset Number Scaling Name Unit Description
Format
Start of repeated block (variable times)
Comment This message has a variable length payload, representing an ASCII string.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x04 0x03 0 + 1*variable see below CK_A CK_B
Payload Contents:
Byte Offset Number Scaling Name Unit Description
Format
Start of repeated block (variable times)
Comment This message has a variable length payload, representing an ASCII string.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x04 0x04 0 + 1*variable see below CK_A CK_B
Payload Contents:
Byte Offset Number Scaling Name Unit Description
Format
Start of repeated block (variable times)
Bitfield mode
This Graphic explains the bits of mode
Name Description
reserved Default 1 for compatibility with A4
Bitfield inProtoMask
This Graphic explains the bits of inProtoMask
Bitfield outProtoMask
This Graphic explains the bits of outProtoMask
Bitfield inProtoMask
This Graphic explains the bits of inProtoMask
Bitfield outProtoMask
This Graphic explains the bits of outProtoMask
Bitfield mode
This Graphic explains the bits of mode
Name Description
spiMode 00 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(mechanism off)-255
Bitfield outProtoMask
This Graphic explains the bits of outProtoMask
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 infMsgMask
This Graphic explains the bits of infMsgMask
Name Description
eph Ephemeris
alm Almanach
health Health
klob Klobuchard
pos Position
clkd Clock Drift
osc Oscilator Parameter
utc UTC Correction Parameters
rtc RTC
Bitfield flags
This Graphic explains the bits of flags
Name Description
syncMode 0=Time pulse always synchronized and only available if time is valid
1=Time pulse allowed to be asynchronized and available even when time is not valid
Bitfield clearMask
This Graphic explains the bits of clearMask
Name Description
ioPort I/O Port Assignements, Protocols and Baud Rates (See messages UBX-CFG-PRT and UBX-CFG-USB)
msgConf Message Configuration (See message UBX-CFG-MSG)
infMsg INF Message Configuration (See UBX-CFG-INF)
Bitfield deviceMask
This Graphic explains the bits of deviceMask
Name Description
devBBR device battery backed RAM
devFlash device Flash
devEEPROM device EEPROM
Bitfield flags
This Graphic explains the bits of flags
Name Description
svcs Enable Antenna Supply Voltage Control Signal
scd Enable Short Circuit Detection
ocd Enable Open Circuit Detection
pdwnOnSCD Power Down Antenna supply if Short Circuit is detected. (only in combination with Bit 1)
recovery Enable automatic recovery from short state
Name Description
pinSwitch PIO-Pin used for switching antenna supply
pinSCD PIO-Pin used for detecting a short in the antenna supply
pinOCD PIO-Pin used for detecting open/not connected antenna
reconfig if set to one, and this command is sent to the receiver, the receiver will reconfigure the pins as specified.
Bitfield flags
This Graphic explains the bits of flags
Name Description
svcs Enable Antenna Supply Voltage Control Signal
scd Enable Short Circuit Detection
ocd Enable Open Circuit Detection
pdwnOnSCD Power Down Antenna supply if Short Circuit is detected. (only in combination with Bit 1)
Bitfield pins
This Graphic explains the bits of pins
Name Description
pinSwitch PIO-Pin used for switching antenna supply
pinSCD PIO-Pin used for detecting a short in the antenna supply
pinOCD PIO-Pin used for detecting open/not connected antenna
Name Description
enabled SBAS Enabled (1) / Disabled (0)
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 Use SBAS GEOs as a ranging source (for navigation)
diffCorr Use SBAS Differential Corrections
integrity Use SBAS Integrity Information
Bitfield scanmode2
This Graphic explains the bits of scanmode2
Bitfield scanmode1
This Graphic explains the bits of scanmode1
Name Description
posFilt disable position filtering
mskPosFilt disable masked position filtering
timeFilt disable time filtering
dateFilt disable date filtering
sbasFilt enable SBAS filtering
trackFilt disable track filtering
Bitfield flags
This Graphic explains the bits of flags
Name Description
compat enable compatibility mode.
This might be needed for certain applications when customer's NMEA parser expects a fixed number of digits in
position coordinates
consider enable considering mode.
Bitfield flags
This Graphic explains the bits of flags
Name Description
reEnum force re-enumeration
powerMode self-powered (1), bus-powered (0)
Bitfield mask1
This Graphic explains the bits of mask1
Name Description
minMax Apply min/max SVs settings
minCno Apply minimum C/N0 setting
3dfix Apply initial 3D fix settings
wknRoll Apply GPS weeknumber rollover settings
Name Description
dyn Apply dynamic model settings
minEl Apply minimum elevation settings
fixMode Apply fix mode settings
drLim Apply DR limit settings
posMask Apply position mask settings
timeMask Apply time mask settings
staticHoldMas Apply static hold settings
k
Bitfield errors
This Graphic explains the bits of errors
Name Description
limit Buffer limit of corresponding target reached
mem Memory Allocation error
alloc Allocation error (TX buffer full)
Bitfield flags
This Graphic explains the bits of flags
Name Description
rtcCalib RTC is calibrated
Bitfield tmCfg
This Graphic explains the bits of tmCfg
Bitfield flags
This Graphic explains the bits of flags
Name Description
pos Position is valid
time Time is valid
clockD Clock drift data contains valid clock drift, must not be set together with clockF
tp Use time pulse
clockF Clock drift data contains valid frequency, must not be set together with clockD
lla Position is given in LAT/LON/ALT (default is ECEF)
altInv Altitude is not valid, in case lla was set
prevTm Use time mark received before AID-INI message (default uses mark received after message)
Name Description
health Healthmask field in this message is valid
utc UTC parameter fields in this message are valid
klob Klobuchar parameter fields in this message are valid
Bitfield flags
This Graphic explains the bits of flags
Name Description
timeBase 0=Time base is GPS
1=Time base is UTC
utc 0=UTC not available
1=UTC available
Bitfield flags
This Graphic explains the bits of flags
Name Description
mode 0=single
1=running
run 0=armed
1=stopped
newFallingEdg new falling edge detected
e
NMEA, UBX Protocol Specification, u-blox 5 GNSS Receiver UBX Protocol
GPS.G5-X-07036-E Public Release Page 130
Bitfield flags Description continued
Name Description
timeBase 0=Time base is Receiver Time
1=Time base is GPS
2=Time base is UTC
utc 0=UTC not available
1=UTC available
time 0=Time is not valid
1=Time is valid (Valid GPS fix)
newRisingEdge new rising edge detected