Skip to content

u-blox receiver configuration

This guide is written w.r.t. usage of the older versions of u-center from u-blox. This update is based on configuration using u-center v.22.02 See https://www.u-blox.com/en/product/u-center for details and updates.

For more on GNSS and GNSS glossary see the GNSS Glossary.

Time of Week (iTOW) timestamps

  • All the main UBX-NAV messages (and some other messages) contain an iTOW field.
  • iTow indicates the GPS time (millisecond accuracy) at which the navigation epoch occurred.
  • Messages with the same iTOW value can be assumed to have come from the same navigation solution.
  • The most reliable absolute time information is found using the UBX-NAV-PVT navigation solution message. This message contains the UTC time + additional fields that indicate the validity and accuracy of the calculated times
  • GNSS time can also be outputted with UBX-NAV-TIMEGPS message.

Connect device and open config window

  • Start u-center.
  • Find the Connect-button (2nd. button below File in the top menu) on the toolbar and press the dropdown button see which COM-ports are available. Close the dropdown.
  • Connect the u-blox receiver, wait a bit for Windows to configure the device, press the Connect-dropdown again, and select the new COM-port.
    • The COM-port number can also be found using Windows Device Manager. Sometimes with the new u-blox driver, it does not register correctly and it needs to be uninstalled from the device manager. Right click the device, go to Update Driver, "Browse my computer for driver software", "Let me pick from a list", select a u-blox COM port, choose "Next" and install this driver instead. This does not seem to be a problem anymore.
  • To read what each message type does, and poll the receiver for the current reading, open the “Messages” view in u-center: [F9]
  • Now open the "Configure" view in u-center: [Ctrl] + [F9]. Alternatively hit "View" -> "Configure view".
    • In this view, each configuration is pulled automatically from the receiver. To check that you have a valid connection, go to a random menu, change the value (without pressing "Send"), press the "Poll"-button, and verify that the value changes back.
    • After each change you make, make sure to press the "Send"-button at the bottom left of the window. If not your changes will be discarded.
    • After all changes have been made, to store the changes to the u-blox's non-volatile memory, go to CFG (UBX-CFG), make sure "Save current configuration" and
      • '0 - BBR' and
      • '1 - FLASH' are selected, and
      • press 'Send'. Without this, all the changes are discarded when you power off the u-blox.
    • If you’re trying to select a menu item that is not available for the connected receiver, the menu item will just jump to another value, so make sure you’re changing the correct value.

Configure u-blox

The following changes should be made to both the base and the rover receivers for RTK GNSS (with the SentiBoard). If the base and rovers are the same or you are using a multiple receiver setup, you can

  • save the setup/configuration on the first receiver ("Tools" -> "Receiver Configuration" -> "Transfer GNSS->File") and
  • load it on the second ("Tools" -> "Receiver Configuration" -> "File->Transfer GNSS" ).

Remember to press “Send” after every change and save to flash ("UBX-CFG" and "Save").

This config listed below is just a suggested setup, and an actual setup should be set to fit your purpose. All binary u-blox messages are supported by the SentiBoard with the default setup.

DGNSS (Differentaion GNSS configuration)

  • 3 - RTK fixed

GNSS (GNSS config)

  • For non-9-series products (like m8t): Enable and disabled which system/frequency (single frequency config) of preference. Recommended use:
    • GPS L1C/A
    • SBAS L1C/A
    • Galileo E1
    • GLONASS L1OF
    • QZSS L1C/A (this is recommended in u-blox the documentation and is due to this signal's properties)
    • Be beware of baud-rate limitations if UBX-RXM-RAXW messages are enabled with several GNSS constellations enabled and with heigh measurement rate. Consult the data sheet.
    • Reduce number of constellations if needed. Such as either
      • GPS L1C/A + Galileo E1 or
      • GPS L1C/A + GLONASS L1OF
  • For 9-series products (like f9p, f9t): View -> Generation 9 Configuration View -> Enable and disabled which system/frequencies of preference. Recommended use:
    • GPS L1C/A + L2C
    • SBAS L1C/A
    • Galileo E1 + E5b/E5a
    • GLONASS L1/L1OF + L2/L2OF (G1+G2)
    • QZSS L1C/A (this is recommended in u-blox documentation and is due to this signals properties)

U-blox reports the following in their datasheet for the ZED-F9p:

GNSS GPS+GLO+GAL+BDS GPS+GLO+GAL GPS+GAL GPS+GAL GPS+GLO GPS
Hor. pos.
acc.		 NAV-PVT 1.5 m CEP 1.5 m CEP 1.5 m CEP 1.5 m CEP 1.5 m CEP 1.5 m CEP
SBAS 1.0 m CEP 1.0 m CEP 1.0 m CEP 1.0 m CEP 1.0 m CEP 1.0 m CEP
RTK 0.01 m+1 ppm CEP 0.01 m + 1 ppm CEP 0.01 m + 1 ppm CEP 0.01 m + 1 ppm CEP 0.01 m + 1 ppm CEP 0.01 m + 1 ppm CEP
Ver. pos.
acc.		 RTK 0.01 m + 1 ppm R50 0.01 m + 1 ppm R50 0.01 m + 1 ppm R50 0.01 m + 1 ppm R50 0.01 m + 1 ppm R50 0.01 m + 1 ppm R50

For more on the respective GNSS constellations (GPS+GLO+GAL+BDS) see Navipedia GNSS signals for GNSS signal overview. For more details on the performance on the F9P see u-blox zed-f9p-module.

MSG (Messages)

Turn off all messages, except the ones specified below (this is a hassle right now, as you need to go through all messages and turn off each one).

For all the messages below, turn on UART1 and USB (not needed for UAV-receiver). Disable the others.

  • For RTK-calculations:
    • 02-15 RXM-RAWX
    • 02-13 RXM-SFRBX
  • For accurate time calculation, and single pos. accuracy, choose:
    • 01-07 NAV-PVT (always use since this message provides the most accurate/granular time)
    • 01-20 UBX-NAV-TIMEGPS (for GPS time including GPS week and GPS TOW with nano seconds)
    • 01-32 NAV-SBAS (enable if SBAS is enabled and you would like to do post-processing using RTKlib or equivalents)
  • For accurate position output use (if running RTK real-time) choose either:
    • 01-13 NAV-HPPOSECEF
    • 01-14 NAV-HPPOSLLH
  • For position covariance
    • 01-36 UBX-NAV-COV (position and velocity covariances including cross covariance given in NED)
  • For outputting measured baseline between rover and base enable on the rover side
    • 01-3C NAV-RELPOSNED
  • For fixed dGNSS/RTK base station receivers
    • 01-3B NAV-SVIN (USB output might be sufficient to see if the base has surveyed in its position)
  • Set depending of mode. Change as needed
    • Dynamic model: 5 – Sea (Recommended by u-blox for applications at sea, with zero vertical velocity. Zero vertical velocity assumed. Sea level assumed. Adds more filtering to GNSS altitude output measurements, not given that this is smart if used in conjunction with an INS and the IMU bias estimation)
    • Dynamic model: 6 - Airborne < 1g (Used for applications with a higher dynamic range and greater vertical acceleration than a passenger car. No 2D position fixes supported.)
    • Dynamic model: 7 – Airborne < 2g (Recommended by u-blox for typical airborne environments. No 2D position fixes supported.)
    • Dynamic model: 8 – Airborne < 4g (Only recommended by u-blox for extremely dynamic environments. No 2D position fixes supported. Recommended by SentiSystems for flying applications.)
  • Fix Mode: 3 – Auto 2D/3D
  • UTC Standard: 3 – USNO (GPS)
  • Min SV Elevation: 15 (ideal), 10 (is GNSS signal reception is bad or one is using one GNSS constellation)
Platform Max altitude [m] Max horizontal velocity [m/s] Max vertical velocity [m/s] Sanity check type Max position deviation
Portable 12000 310 50 Altitude and velocity Medium
Stationary 9000 10 6 Altitude and velocity Small
Pedestrian 9000 30 20 Altitude and velocity Small
Automotive 6000 100 15 Altitude and velocity Medium
At sea 500 25 5 Altitude and velocity Medium
Airborne <1g 50000 100 100 Altitude Large
Airborne <2g 50000 250 100 Altitude Large
Airborne <4g 50000 500 100 Altitude Large
Wrist 9000 30 20 Altitude and velocity Medium

PRT (Ports):

  • Target: 1 - UART1
    • Protocol in: 0 - UBX
    • Protocol out: 0 - UBX
    • Baudrate: 115200
  • Target: 2 - UART2
    • Protocol in: 5 - RTCM3 (useful if using the receiver as rover during online RTK)
    • Protocol out: 5 - RTCM3 (useful if using the receiver as stationary or moving base during online RTK)
    • Baudrate (minimum): 38400
  • Target: 3 - USB
    • Protocol in: 0+1 - UBX+NMEA+RTCM (useful for verifying the output in u-center, can be disabled during operation, RTCM only needed to verify RTK setup
    • Protocol out: 0+1 - UBX+NMEA+RTCM (useful for verifying the output in u-center, can be disabled during operation, RTCM only needed to verify RTK setup)
  • All others:
    • Protocol in: none
    • Protocol out: none

RATE (Rates)

  • Time source: 1 - GPS time
  • For 1 Hz raw data and navigation rate
    • Measurement Period: 1000 ms
    • Navigation Rate: 1 cyc
  • For 5 Hz raw data and 1 Hz navigation rate
    • Measurement Period: 200 ms
    • Navigation Rate: 5 cyc
  • For 10 Hz raw data and 1 Hz navigation rate
    • Measurement Period: 100 ms
    • Navigation Rate: 10 cyc
  • For 2 Hz raw data and 1 Hz navigation rate
    • Measurement Period: 500 ms
    • Navigation Rate: 2 cyc
  • Note: Check the datasheet of your receiver to check what is supported.
  • Note: For integration with INS 1 Hz navigation rate should suffice for most application. INS will provide samples in between GNSS navigation samples.

SBAS

  • Subsystem: Enable
  • Services:
    • Ranging: Enable
    • Apply SBAS Correction data: Enable
    • Apply integrity information: Perform tests. Loss of GNSS solution has been experienced before with firmware 1.13 and 1.30. Test this before field deployment if you enable this! Loss of GNSS solution might be due that other signals than GPS L1C/A is not used in the positioning solution. Hence, GPS L2C and all other signals for other constellations are discarded. This can be observed in u-center -> "Message view" -> UBX-NAV-PVT -> #SVs Used. Position solution might be improved after lock on SBAS satellites. Hence, testing is needed.
  • Number of search channels: 2 or 3. More that two is not necessary for EGNOS in 2022 unless using PRN126 which is in test mode. See next point.
  • PRN Code: Use EGNOS if in Europe or WAAS in the US. Check what system is supported in your area. It is also possible to discriminate SBAS satellites. individually. Check the documentation/website of the relevant system in your area for find out which SBAS satellites are relevant for you.
    • For EGNOS PRN and PRN136 is operational from 23rd of March 2020 and onwards https://gssc.esa.int/navipedia/index.php/EGNOS_Space_Segment. PRN126 is in test mode. Recommended settings are to use 2 search channels and PRN123+PRN136. For WAAS or other systems see the available documentation of those systems.

TMODE3 (Time Mode 3)

  • For rovers: 0 - Disabled
  • For RTK moving bases (MB): 0 - Disabled
  • For dGNSS/RTK stationary bases with unknown location: 1 - Survey-in.
    • Set Minimum observation time. Default is 86400 which is 24 hours. Set 120 for two minutes etc.
    • Set Required position std dev. Default is 0.001 meters. This might be too low. Al least for shorter Minimum observation time. Test was suites you and your application.
    • The shorter Minimum observation time and higher Required position std dev the faster the receiver can act as a base station. This will however effect the performance.
  • For dGNSS/RTK stationary bases with known location: 2 - Fixed-mode.
    • Specify location of receiver in Fixed TIME Mode True Position (ECEF)

TP (Timepulse)

Danger

This configuration has to match the configuration of the respective UART port on the SentiBoard the receiver is/will be connected to. This is critical in order match the UTC/GPS time to the samples of other sensor via Time-of-validity (TOV) of all SentiBoard collected measurement samples.

  • Alternative 1
    • Pulse mode: -1 – falling edge
    • Pulse period: 1000 ms
    • Pulse frequency: 1 Hz
    • Pulse length: 100 ms
    • Time source: 1 – GPS time
  • Alternative 2
    • Pulse mode: +1 – rising edge
    • Pulse period: 1000 ms
    • Pulse frequency: 1 Hz
    • Pulse length: 100 ms
    • Time source: 1 – GPS time

Not all legacy receivers support both options. Try one of the alternatives. This "Send" and the "Poll" to see if the chosen setting remains valid.

RTCM Configuration for fixed-base and moving-baseline applications

Fixed base

The recommended list of RTCM messages for a fixed base

  • RTCM 1005: Stationary RTK reference station ARP
  • RTCM1074: GPS MSM4
  • RTCM 1084: GLONASS MSM4
  • RTCM 1094: Galileo MSM4
  • RTCM 1124: BeiDou MSM4 (not used)
  • RTCM 1230: GLONASS code-phase biases

Danger

The correction stream should only contain one type of observation messages per constellation!

Moving baseline

Bandwidth limitations

The moving base algorithm was optimized for HPG 1.13.

  • RTCM 4072.1 is no longer needed
  • RTCM MSM7 messages can be replaced by RTCM MSM4 messages

Both setting will help reduce serial communication and RF link load.

Recommended list of RTCM messages is:

  • RTCM 4072.0: Reference station PVT information
  • RTCM 1074: GPS MSM4
  • RTCM 1084: GLONASS MSM4
  • RTCM 1094: Galileo MSM4
  • RTCM 1124: BeiDou MSM4 (not used)
  • RTCM 1230: GLONASS code-phase biases
  • By default the ZED-F9P UART2 is assigned a baud rate of 38400 baud. This will need to be increased for navigation rates above 1 Hz.
No bandwidth limitations

If non RF link or serial bandwidth issues on 1 Hz navigation rate: Using MSM7 messages

Recommended list of RTCM messages is:

  • RTCM 4072.0: Reference station PVT information
  • RTCM 1077: GLONASS MSM7
  • RTCM 1087: GPS MSM7
  • RTCM 1097: Galileo MSM7
  • RTCM 1127: BeiDou MSM7 (not used)
  • RTCM 1230: GLONASS code-phase biases
  • For the UART2 interface a speed of 460800 baud is ideal.
  • Minimum baud rate is 38400 baud for a 1 Hz navigation rate application
  • 60800 baud is recommended for a 8 Hz navigation rate application (usually limit the radio technology that can be used as the gross data rate will need to be considerably higher to transfer data forwards and backwards).

NB: The correction stream should only contain one type of observation messages per constellation!

Rover

As long as the RTCM config is correctly set and that RTCM is set to output on the correct out and in port on the base and the rover respectively the rover receiver will automatically go in to 'rover mode'. The result can be seen in 'UBX-NAV-RELPOSNED' message. If the rover and base are F9H receivers the 'RELPOSNED' message will only output a unit vector. In this case one can see the field 'Relative Position Normalized' ticked off in u-center. If a F9P unit is used, 'UBX-NAV-RELPOSNED' will contain the relative measurement (unit cm/mm in the raw data, m in u-center).

CFG (Configuration)

  • Remember to save the configuration to the u-blox FLASH
  • “Save current configuration”
  • Devices:
    • “0 - BBR” (not sure if this is needed, but I’ve always used it)
    • “1 – FLASH”
  • Press “Send”

Now, power off the u-blox. Connect to it up again and make sure your configuration is saved.

Improvements Firmware 1.30

  • Improved USB interface robustness; changed USB behavior at startup where a USB bus detached startup state is simulated at startup for 1 sec.
  • Receiver can tolerate RTCM input correction streams ending with an RTCM MT MSM1131-1137 (NavIC).
  • Improved I2C interface robustness.
  • Galileo time aiding via UBX-MGA-INI-TIME_GNSS is now possible.
  • Ignore RTCM messages for unhealthy satellites.
  • GPS L2C signal tracking improvements under challenging conditions.
  • NMEA 4.11 now reports signal IDs in hex format as specified in the standard.
  • RTK_STAT pin level correctly indicates RTK status and NMEA-GGA correction age is not empty, when receiving/using SBAS/SLAS corrections in parallel with RTCM corrections.
  • Correct fix type reported and correct RTK fix status reported, when SBAS integrity data are applied.
  • Odometer distance traveled does not update, when the position accuracy exceeds the maximum threshold configured in CFG-ODO-ODOMAXPOSACC.
  • RTCM correction streams containing messages with millisecond-ambiguous corrections(RTCM MT 1001, 1003, 1009, 1011, MSM1 to MSM3) no longer result in bad RTK performance.
  • Improved handling of highly eccentric Galileo orbits.
  • Receivers configured without GPS no longer experience a slower time to first fix at startup(warm/hot/aided startup) when certain conditions were met.
  • BeiDou Space Vehicles 38 to 63 are now correctly reported in UBX-NAV-SBAS and NMEA-PUBX03 messages.
  • The single-byte SVID for BeiDou Space Vehicles 6 to 37 is now correctly reported in UBX-NAV-SBAS and NMEA-PUBX-SVSTATUS messages.
  • Improved handling of Galileo SISA values• Improved start-up robustness against unexpected system restarts.
  • Receiver recovers gracefully after entering software backup mode or sleep mode.
  • Satellite Vehicle information no longer reported twice in consecutive NMEA-GxGSV messages. This would occur when the latter message contained info on untracked SV (i.e. when Cn0 was0).
  • Enabling the low pass velocity filter (CFG-ODO-OUTLPVEL) no longer triggers ERROR messages.
  • Improved start-up robustness in rare cases where the receiver would drop for 1 to 3 epochs intoa 'no fix' solution from a 'fix ok' solution
  • Improved SBAS Message Type 1 content handling when containing invalid data
  • UBX-MON-RF no longer reports the same value (0) for the blockId field in all its repeated blocks.
  • Configuring the CFG-RATE-NAV configuration item with the unsupported value 128 no longer causes a system restart.
  • Improved L2 tracking performance when receiver configured with GPS and GLONASS.

Known limitations Firmware 1.30

  • A receiver moving at very slow speed (less than 10cm/s) does not update the heading information in UBX-NAV-PVT. The velocity vectors can be used reliably.
  • Geofence status pin must not be re-assigned to another pin.
  • If the receiver is configured to output RTCM messages on several ports, the ports must have the same RTCM configuration, otherwise the MSM multiple message bit might not be set correctly.
  • Time pulse can only be synced to GNSS. Configuration items and relevant flag cannot be set to false (CFG-TP-SYNC_GNSS_TP1, UBX-CFG-TP5).
  • If the receiver is configured to GLONASS only operation, it cannot get a PPP-RTK fix when using SPARTN corrections.
  • Static hold mode is unreliable at navigation rates larger than 1Hz.
  • In correct SBAS pseudo range value corresponding to 4ms shift maybe reported in UBX-RXM-SFRBX messages. This can be detected by monitoring the halfCyc flag in UBX-RXM-RAWX.
  • Lower navigation rate achievable compared to previous firmware; performance figures available in related Datasheet document.
  • When QZSS L1S is enabled, it can be observed that QZSS L1C/A reports 'Halfcycleinvalid' in UBX-RXM-RAWX.
  • UART2 may report different UBX-INF-ERROR messages than the ones reported on the other interfaces.