hans mayer's weblog

Update ZED-X20P with Debian on piHAT

Thu, 23 Jul 2026 13:32:00 +0200

Here I want to show you how to update a ZED-X20P without u-center2. This scenario is typically used if the X20P is mounted on a piHAT sitting on a Raspberry Pi running Linux like Debian.

In my case, I’m use the pHAT from sparkfun. It is mounted on a Raspberry Pi5 with Debian 13 trixie. And of course there is no easy way to run u-center2 directly. I found information to connect the Linux box and the Windows box with “ser2net” on Debian and HW VSP (Virtual Serial Port) on Windows part. But this didn’t work for me.

Luckily, I found a thread at https://portal.u-blox.com/ where someone posted a binary file “ubxfwupdate” which runs perfect on 64-bit ARM platform.

So I had to download the latest image which is available from the official U-blox website: UBX_20_HPG_210_ZED_X20P-01B.512369040097ce18fd3475e71e7c627f.bin

Normally I run “gpsd” from the gpsd package. It’s important to stop this as we need the serial interface for the update.

systemctl stop gpsd.service 
systemctl stop gpsd.socket

The next step is also important. Set the baud rate for UART1 to the same value as the first parameter of the “-b” option. In my case it is 460800 bd. Since I also have the second interface available I could do this easily over the second interface for UART1.

ubxtool3 -z CFG-UART1-BAUDRATE,460800

Now check the communication between X20P and tty of the Raspberry.

/usr/local/bin/ubxtool -f /dev/ttyAMA0 -s 460800 -p MON-VER

This should show the current (old) version.

Now comes the magic moment. Run the update:

ubxfwupdate -p /dev/ttyAMA0  -v 1 --no-fis 1 -C 1 -s 1 -b 460800:9600:460800 UBX_20_HPG_210_ZED_X20P-01B.512369040097ce18fd3475e71e7c627f.bin

----------CMD line arguments-----------
Image file:        UBX_20_HPG_210_ZED_X20P-01B.512369040097ce18fd3475e71e7c627f.bin
Flash:             <compiled-in>
Fis:               flash.xml
Port:              /dev/ttyAMA0
Baudrates:         460800/9600/460800
Safeboot:          1
Reset:             1
AutoBaud:          0
Verbose:           1
Erase all:         1
Erase only:        0
Training sequence: 1
Chip erase:        1
Merging FIS:       1
Update RAM:        0
Use USB alt:       0
---------------------------------------
0 u-blox Firmware Update Tool version 24.11
0 Updating Firmware 'UBX_20_HPG_210_ZED_X20P-01B.512369040097ce18fd3475e71e7c627f.bin' of receiver over '/dev/ttyAMA0'
0   - Opening and buffering image file
0   - Verifying image
0   - Got an encrypted image with footer info
0   - CRC Value         	:    BC410967
0   - Footer Version    	:    1
0   - Number of Images  	:    2
0   - Footer Size       	:    28
0   - Image Config Size 	:    40
0   - Image 0 Size     	:    716648
0   - Image 1 Size     	:    444856
0   - Trying to open port /dev/ttyAMA0
0   - Setting baudrate to 460800
2   - Received Version information
2   - Receiver currently running SW 'EXT HPG 2.02 (43e74c)'
2   - Receiver HW '000B0000', Generation 20.0
2   - Sending ROM CRC Poll
2 ROM CRC: 0x00A9D329
2 u-blox20 ROM1.10 hardware detected (0x00A9D329)
2  Getting Port connection to receiver
6   - Connected port is: UART1
6  Commanding Safeboot
1   - Setting baudrate to 9600
3   - Sending training sequence
5  Detecting Flash manufacturer and device IDs
5   - Flash ManId: 0x009D DevId: 0x6016
7   - Not merging anything
7   - Flash size:   4194304
7   -  Flash block:  1024 x 4096
7 Stable clock enabled successfully
8   - Setting baudrate to 460800
0  Start Flash retention
0   - flash retention success
0 Chip erase started
0  Receiver info collected, downloading to flash...
5 Chip erase complete
0 FW download complete
0  Verifying Image on hardware
4  Firmware Verification and Flash update complete
4  Verify Flash retention
4  flash retention success
4  Rebooting receiver
4 Firmware Update SUCCESS

If you check the MON_VER again, you should see:

UBX-MON-VER:
  swVersion EXT HPG 2.10 (b0eda3)
  hwVersion 000B0000
  extension ROM BASE 0x00A9D329
  extension FWVER=HPG 2.10
  extension PROTVER=50.11
  extension MOD=ZED-X20P
  extension GPS;GLO;GAL;BDS
  extension SBAS;QZSS
  extension NAVIC;LBAND

And what you can see here GLONASS is also available, at least in my geographic region.

My ZED-X20P from sparkfun in action.

u-blox ZED-X20P initialization and GPSD

Sun, 31 May 2026 17:56:00 +0200

I use the gpsd tool set since a while. In Debian it is available as package or you can find it here: gpsd
Several programs from the gpsd tool set worked as expected when I use it with a ZED-F9P. Not so with the newer ZED-X20P. The reason is simple. When starting the gpsd process it initialize the F9P and others u-blox devices with several messages, but not so with the X20P. The X20P stays in the factory default setup.
So I saw that gpscsv -n 1 -c SAT didn’t work. With help of several resources I could initialize the X20P in way so that gpscsv is working. These are the parameters

  ubxtool -z CFG-MSGOUT-UBX_NAV_PVT_UART1,1 
  ubxtool -z CFG-MSGOUT-UBX_NAV_SAT_UART1,1 
  ubxtool -z CFG-MSGOUT-UBX_NAV_SIG_UART1,1 
  ubxtool -z CFG-UART1OUTPROT-NMEA,0 
  ubxtool -z CFG-UART1OUTPROT-UBX,1 
  ubxtool -z CFG-MSGOUT-UBX_NAV_TIMEGPS_UART1,1

Of course I cannot say if these are all parameters which are set for F9P and others but at least for my gpscsv issue with ZED-X20P is it working. Currently I am using gpsd version 3.27.6. Maybe in later releases it will work.

The Austrian Cloud

Thu, 28 May 2026 14:32:00 +0200

Tap on the image to see details.

Aufgenommen in der Friedensstraße, Wien Mauer
Im Zentrum unten die Sternbauten von Atzgersdorf, rechts die Tilgnergasse

“Kreuz und Quer” Nicht alle Bilder sind mit KI manipuliert.
Aufgenommen in der Taglieberstraße

RTK - base/rover with U-blox GNSS receivers

Sun, 03 May 2026 17:47:00 +0200

After some tests with Precise Point Positioning ( see below 1-5 ) and in detailed with (4) I describe this time a setup with a base station sending RTCM (Radio Technical Commission for Maritime Services) data to a rover station. For both ( base and rover ) I use Raspberry Pi’s with a GNSS pi-hat with the latest Debian OS trixie Version 13 and the latest Version of https://gitlab.com/gpsd/gpsd. I also use github.com/rtklibexplorer/RTKLIB written by Jens Reimann. It’s not necessary to have this tool on these servers. Most most of the time, I run it from a third server, using ‘ubxtool’ to interact with the gpsd instances remotely.

Base station is a Raspberry Pi5 with a ZED-X20P from U-blox. The pi-hat is from sparkfun.
Rover is a Raspberry Pi4 with a ZED-F9P from U-blox. The pi-hat is from uputronics.
OS is in both cases Debian 13 (trixie)

Antennas
For X20P I use the antenna HAB-ANN-MB2 permanently roof-mounted with a clear sky view.
F9P uses the HAB-ANN-MB-00-00 antenna, which is moved mobile in the garden. To place it on a metal plate is an advantage.

In both cases I use the second interface UART2 to communicate between base and rover for the RTCM traffic. How to setup I described in second interface for u-blox receiver
I use str2str for communication between both systems. It is started in background with option “–deamon”, see below.
Note: In RTKLIB’s str2str, the parameter is literally spelled –deamon instead of –daemon.
The data path for RTCM traffic looks like this:
X20P/UART2 --- str2str --- TCP/IP --- str2str --- UART2/F9P
Bandwidth is about 12 Kb from base to rover and 1.5 Kb from rover to base

In advance I want to say that this combination with ZED-X20P and ZED-F9P is not perfect but possible. The reasons are multiple: ZED-F9P can handle only the L1 and L2 band. ZED-X20P is designed for L1/L2/L5/E6/B3/L. Another reason is that ZED-X20P cannot handle GLONASS (Globalnaja nawigazionnaja sputnikowaja sistema) at the moment (and potentially never due to hardware/firmware focus or political situations). And the Navigation Indian Constellation (NavIC) can only be used by ZED-X20P. Independent of that I don’t see any Indian satellite here in Vienna ( 48N 16E ). Therefore, only 3 GNSS constellations remain: GPS, Galileo and BeiDou as lowest common denominator and common source.

Below you can find 2 scripts: setup_base_sh and setup_rover_sh. The first one is to setup the base station which is a little bit more complex. The second one is for the rover. These scripts require certain prerequisites. For example there are servers with hostname “base” and “rover” or at least an DNS CNAME for it. SSH should be possible without password.

functubxtool_ksh defines a function “ubxtool” like this

    export UBXOPTS='-P 27.50'
    /usr/local/bin/ubxtool $@ rover:gpsd:/dev/serial0

This is to avoid to add each time “rover:gpsd:/dev/serial0” as additional argument

setup_base_sh

#!/usr/bin/env bash 

# ident setup_base_sh 
# Wed May  6 05:26:22 PM CEST 2026 - mayer 

. functubxtool_ksh base

ntrip(){

  logger -p user.debug "setup_base_sh ntrip with argument $1  " 
  
  case "$1" in 
    stop ) 
        # kill a possible running str2str 
        ssh base pkill str2str 
        ;; 
    start ) 
        # start a new one - this is the communication to the rover for RTCM traffic 
        ssh base "str2str -in serial://ttyAMA3:921600:8:n:1:off -out tcpsvr://:42101 --deamon"
        ;;
    status ) 
        ssh base 'pgrep -a -f "str2str -in serial://ttyAMA3:921600:8:n:1:off -out tcpsvr://:42101 --deamon"' 
        ;;
    "" ) 
        ntrip stop ; ntrip start 
        ;;
  esac 
}


setup_initial(){ 

  # Setup Script for u-blox (ZED-X20P) base station 
  logger -p user.debug "setup_base_sh setup_initial " 
  # this is the initial setup to prepare the base station for it's function 
  
  # make sure in advance that baudrate for uart1 is high enough 
  if test -z "`ubxtool -g  CFG-UART1-BAUDRATE | grep UART1-BAUDRATE | head -1 | grep 921600`" 
    then 
      echo $0: UART1-BAUDRATE,921600 failed 
      exit 1 
  fi 
  
  ubxtool -z  CFG-UART2-BAUDRATE,921600 | grep UBX-ACK-ACK: 
  
  if test $? -ne 0 
    then 
      echo $0: UART2-BAUDRATE,921600 failed 
      exit 1 
  fi 

  # make sure that no Survey-In is running 
  ubxtool -z CFG-TMODE-MODE,0 | grep UBX-ACK-ACK:
  
  # reference coordinates set to ECEF
  ubxtool -z CFG-TMODE-POS_TYPE,0 | grep UBX-ACK-ACK:
  
  # position of the base station , unit is cm 
  # 48.1493013022 16.2838442507 288.08 
  # make sure that there is the exact position of the base station 
  ubxtool -z CFG-TMODE-ECEF_X,409252331 | grep UBX-ACK-ACK:
  ubxtool -z CFG-TMODE-ECEF_Y,119548502 | grep UBX-ACK-ACK:
  ubxtool -z CFG-TMODE-ECEF_Z,472818312 | grep UBX-ACK-ACK:
  
  # set  High-Precision Register to zero 
  ubxtool -z CFG-TMODE-ECEF_X_HP,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-TMODE-ECEF_Y_HP,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-TMODE-ECEF_Z_HP,0 | grep UBX-ACK-ACK:
  
  # RTCM data (1 Hz Intervall )
  # activate RTCM3 output on UART2 (Port 2) , communication with str2str 
  # 1005: Station ID & Position, 
  # 1077: GPS MSM7 
  # 1097: Galileo GAL MSM7 
  # 1124: BeiDou BDS MSM4 included in 1127 
  # 1127: BeiDou BDS MSM7 
  for MSG in 1005 1077 1097 1127 # 1124 
    do
      ubxtool -z CFG-MSGOUT-RTCM_3X_TYPE${MSG}_UART2,1  | grep UBX-ACK-ACK:
    done

  # to check what the rover sees
  # rover# ubxtool -w 30 | grep -A 1 "UBX-RXM-RTCM" | sort -u 
  
  # FIXED MODE schalten
  ubxtool -z CFG-TMODE-MODE,2 | grep UBX-ACK-ACK:

  # necessary as the rover (ZED-F9P) can only bands L1 and L2 
  ubxtool -z CFG-SIGNAL-PLAN,1 | grep UBX-ACK-ACK:
    
  ubxtool -z CFG-SIGNAL-GPS_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-SBAS_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GAL_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-QZSS_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GLO_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-NAVIC_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_B2A_ENA,0 | grep UBX-ACK-ACK:
  
  ubxtool -z CFG-SIGNAL-GPS_L1CA_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GPS_L2C_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GPS_L5_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-SBAS_L1CA_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GAL_E1_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GAL_E5A_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GAL_E5B_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GAL_E6_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_B1_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_B2_ENA,1 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_B1C_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-BDS_B3_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-QZSS_L1CA_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-QZSS_L1S_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-QZSS_L2C_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-QZSS_L5_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GLO_L1_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-GLO_L2_ENA,0 | grep UBX-ACK-ACK:
  ubxtool -z CFG-SIGNAL-NAVIC_L5_ENA,0 | grep UBX-ACK-ACK:

  ntrip 

}  
  
help(){
  echo "usage: $0 help | setup_initial | ntrip " 
  echo "          help  ...  this help "
  echo "          setup_initial ... this will initialise the base station " 
  echo '          ntrip start | stop | status | "" '
  echo "                to manage the communication with the base station with a str2str process "
  echo "                without argument it will restart the str2str process " 
  exit 1 
}

usage(){ 
  echo "usage: $0 help | setup_initial | ntrip " 
  exit 1 
} 


case "$1" in 
  setup_initial ) setup_initial ;; 
  ntrip ) ntrip $2 ;; 
  help ) help ;; 
  * ) usage ;; 
esac

Some hints on the base station setup. The unit of measurement for ECEF mode is centimeters. Note that most tools like mine transform ecef wgs84 use meters instead. Another important setup is to disable CFG-SIGNAL-BDS_B1C_ENA and CFG-SIGNAL-BDS_B3_ENA. As long as these signals were enabled, I was unable to achieve BeiDou-based RTCM corrections.

setup_rover_sh

#!/usr/bin/env bash 

# ident setup_rover_sh 
# Wed May  6 05:26:22 PM CEST 2026 - mayer 

. functubxtool_ksh rover


ntrip(){

  logger -p user.debug "setup_rover_sh ntrip with argument $1  " 
  case "$1" in 
    stop ) 
  	# kill a possible running str2str 
  	# ssh rover pkill str2str 
	ssh rover 'pkill -f "str2str -in tcpcli://base:42101 -out serial://ttyAMA5:921600:8:n:1:off --deamon"'
	;; 
    start ) 
  	# start a new one - this is the communication to the base for RTCM traffic 
  	ssh rover "str2str -in tcpcli://base:42101 -out serial://ttyAMA5:921600:8:n:1:off --deamon"
	;;
    status ) 
	ssh rover 'pgrep -a -f "str2str -in tcpcli://base:42101 -out serial://ttyAMA5:921600:8:n:1:off --deamon"'
	;;
    "" ) 
	ntrip stop ; ntrip start 
	;;
  esac 
}

setup_initial(){ 
  
  logger -p user.debug "setup_rover_sh setup_initial " 
  # this is the initial setup to prepare the rover sation for it function 

  # make sure in advance that baudrate for uart1 is high enough 
  if test -z "`ubxtool -g  CFG-UART1-BAUDRATE | grep UART1-BAUDRATE | head -1 | grep 921600`" 
    then 
      echo $0: UART1-BAUDRATE,921600 failed 
      exit 1 
  fi 
  
  ubxtool -z  CFG-UART2-BAUDRATE,921600 | grep UBX-ACK-ACK: 
  
  if test $? -ne 0 
    then 
      echo $0: UART2-BAUDRATE,921600 failed 
      exit 1 
  fi 
  
  # is set per default layer 7 
  ubxtool -z CFG-UART2INPROT-RTCM3X,1  | grep UBX-ACK-ACK: 
  
  # disable not usable GNSS 
  ubxtool -z  CFG-SIGNAL-SBAS_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-QZSS_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-GLO_ENA,0 | grep UBX-ACK-ACK: 
  
  ubxtool -z  CFG-SIGNAL-SBAS_L1CA_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-QZSS_L1CA_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-QZSS_L1S_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-QZSS_L2C_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-GLO_L1_ENA,0 | grep UBX-ACK-ACK: 
  ubxtool -z  CFG-SIGNAL-GLO_L2_ENA,0 | grep UBX-ACK-ACK: 

  ntrip 
  
  ubxtool -z CFG-MSGOUT-UBX_RXM_RTCM_UART1,1 | grep UBX-ACK-ACK:
  
  # set high precision mode 
  # The accuracy is only as good as that of the base station. 
  ubxtool -z CFG-NMEA-HIGHPREC,1 | grep UBX-ACK-ACK: 
  ubxtool -z CFG-MSGOUT-UBX_NAV_HPPOSLLH_UART1,1 | grep UBX-ACK-ACK: 

  # don't restart gpsd after initialization 
  # this is one of the parameters changed at start or use option -p --passive for gpsd restart 
  ubxtool -z CFG-MSGOUT-NMEA_ID_GGA_UART1,1  | grep UBX-ACK-ACK:  

}

nmea_pipe(){
  	
  logger -p user.debug "setup_rover_sh nmea_pipe with argument $1  " 
  # this pipe is for monitoring with rtkplot_q 

  case "$1" in 
    stop ) 
  	# kill a possible running gpspipe 
  	ssh rover "pkill -f 'socat EXEC:gpspipe -r TCP-LISTEN:10001,reuseaddr,fork'"
	;; 
    start )  
  	# start a gpspipe for monitoring with rtkplot_qt / option -r is NMEA output 
  	ssh rover nohup "socat EXEC:'gpspipe -r' TCP-LISTEN:10001,reuseaddr,fork  > /dev/null 2>&1 & disown " 
	echo pipe ready for rtkplot_qt as TCP Client , server rover at port 10001 and solution format NMEA0183 
 	;;
    status )  
	ssh rover 'pgrep -a -f "socat EXEC:gpspipe -r TCP-LISTEN:10001,reuseaddr,fork"'
 	;;
    "" ) 
	nmea_pipe stop ; nmea_pipe start 
 	;;
  esac  
}

raw_pipe(){

  logger -p user.debug "setup_rover_sh raw_pipe  with argument $1  " 

  case "$1" in 
    stop ) 
  	# kill a possible running gpspipe
  	ssh rover "pkill -f 'socat EXEC:gpspipe -RB TCP-LISTEN:10002,reuseaddr,fork'"
	;;
    start ) 
  	# start a gpspipe for logging with strsvr_qt or str2str 
  	ssh rover nohup "socat EXEC:'gpspipe -RB' TCP-LISTEN:10002,reuseaddr,fork  > /dev/null 2>&1 & disown " 
  	echo for example its possible to start now: str2str -in tcpcli://rover:10002 -out file://log_%Y%m%d%h%M.ubx
	;;
    status ) 
  	ssh rover "pgrep -a -f 'socat EXEC:gpspipe -RB TCP-LISTEN:10002,reuseaddr,fork'"
	;;
    "" )
	raw_pipe stop ; raw_pipe start 
	;;
  esac 
}


navpvt(){
  logger -p user.debug "setup_rover_sh navpvt " 
  ubxtool -p NAV-PVT -v 2 | sed -n -e '/^UBX-NAV-PVT:/,/^$/ p' | awk -v RS= 'NR==2' 
}


sat_used(){

  logger -p user.debug "setup_rover_sh sat_used " 

  # NAVSAT=`ubxtool -p NAV-SAT -v 2 | sed -n -e '/^UBX-NAV-SAT:/,/^$/ p' | awk -v RS= 'NR==2'  | grep -B 2 -A 2  -i rtcm | egrep 'flags'`

  echo only GPS, Galileo and BeiDou are counted 
  echo -e -n Status: ; navpvt | grep carrSoln
  NAVSAT=`ubxtool -p NAV-SAT -v 2 | sed -n -e '/^UBX-NAV-SAT:/,/^$/ p' | awk -v RS= 'NR==2' ` 

  echo "                    satellites total seen : " `echo "$NAVSAT" | grep -c gnssId `

  SYST=`echo "$NAVSAT" | grep gnssId  | awk '{ print ( $2 ) }' | sort | uniq -c`
  echo $SYST | awk '{ print ( "                                      GPS :  "  $1 "  Galileo: " $3  "  BeiDou: " $5 ) }' 

  echo "                          satellites used : " `echo "$NAVSAT" | grep 'flags(' | grep -c svUsed `

  SYST=`echo "$NAVSAT" | grep  -B 2 svUsed | grep gnssId  | awk '{ print ( $2 ) }' | sort | uniq -c`
  echo $SYST | awk '{ print ( "                                      GPS :  "  $1 "  Galileo: " $3  "  BeiDou: " $5 ) }' 

  echo "     satellites used with RTCM correction : " `echo "$NAVSAT" | grep -c rtcm `
  echo "  satellites with pseudorange corrections : " `echo "$NAVSAT" | grep -c prCorrUsed `

  echo "satellites with carrier range corrections : " `echo "$NAVSAT" | grep -c crCorrUsed `
  SYST=`echo "$NAVSAT" | grep  -B 2 crCorrUsed | grep gnssId  | awk '{ print ( $2 ) }' | sort | uniq -c`
  echo $SYST | awk '{ print ( "                                      GPS :  "  $1 "  Galileo: " $3  "  BeiDou: " $5 ) }' 
}

help(){ 
  echo "usage: $0 help | setup_initial | nmea_pipe | raw_pipe | sat_used | navpvt | ntrip " 
  echo "          help  ... this help " 
  echo "          setup_initial ... this will initialise the base station " 
  echo "          nmea_pipe ... this will create a gpspipe with NMEA protocol listen on port 10001 "
  echo "          raw_pipe ... this will create a gpspipe with raw data listen on port 10002 "
  echo "          sat_used ... will show the used satellites based on ubxtool -p NAV-SAT command "
  echo "          navpvt ... will show the status based on ubxtool -p NAV-PVT command "
  echo '          ntrip start | stop | status | "" '
  echo "                to manage communication between base station and rover with a str2str process "
  echo "                without argument it will restart the str2str process " 
  exit 1 
} 

usage(){ 
  echo "usage: $0 help | setup_initial | nmea_pipe | raw_pipe | sat_used | navpvt | ntrip " 
  exit 1 
} 


case "$1" in 
  setup_initial ) setup_initial ;; 
  nmea_pipe ) nmea_pipe "$2" ;; 
  raw_pipe ) raw_pipe "$2" ;; 
  sat_used ) sat_used ;; 
  navpvt ) navpvt ;; 
  ntrip ) ntrip "$2" ;; 
  help ) help ;; 
  * ) usage ;; 
esac

Usage

setup_initial

Both scripts setup_base_sh and setup_rover_sh has to be run with this option. If this is done a communication between setup_base_sh and setup_rover_sh is established and a “Fixed” solution should be reached within a short time.

The following options are just for the rover.

nmea_pipe

After setting up base and rover it will take some time to get a precision position with status Fixed. Worst case is one hour in my situation. But typically it takes 10 minutes or a little bit more. Running command setup_rover_sh nmea_pipe will create a gpspipe with
socat EXEC:gpspipe -r TCP-LISTEN:10001,reuseaddr,fork. Running rtkplot_qt & and connecting to this port 10001 at server rover will show you the current position at the rover.

The graph above shows the measurement for a short period of time. Each data point represents a one-second interval. As we can see almost all dots are within a circle of 5 mm radius. Moving the rover antenna by 3 cm results in a distinct new cluster of points, precisely reflecting the displacement. If the antenna is moved further away - for example one meter - then the status “Fixed” is lost and falls back to “Floating”.

The example above shows a longer period of time and we can see that all dots are in a square of 3 x 3 cm.

sat_used

With option sat_used will give you the information how many satellites are used. A typical output could be this:

only GPS, Galileo and BeiDou are counted
Status:    carrSoln (Fixed)
                    satellites total seen :  38
                                      GPS :  11  Galileo: 11  BeiDou: 16
                          satellites used :  26
                                      GPS :  10  Galileo: 6  BeiDou: 10
     satellites used with RTCM correction :  26
  satellites with pseudorange corrections :  26
satellites with carrier range corrections :  21
                                      GPS :  7  Galileo: 6  BeiDou: 8

In the example above we see a status fixed. I have never seen more than 25 satellites with carrier range corrections. Maybe this is a limitation from the U-blox receiver or there are never more than 25 satellites available with the needed requirements.
There are 3 states possible

    carrSoln (None)
    carrSoln (Floating)
    carrSoln (Fixed)

Status “None” is only visible short time after power on. Fixed is of course our goal.

raw_pipe

Using option raw_pipe will create a second gpspipe. This will allow to use
str2str -in tcpcli://rover:10002 -out file://log_%Y%m%d%h%M.ubx which logs the data to file. Then it’s possible to extract data in a future process.

navpvt

navpvt show the output of command “ubxtool -p NAV-PVT”

UBX-NAV-PVT:
  iTOW 576850000 time 2026/05/02 16:13:52 valid x37
  tAcc 24 nano 341196 fixType 3 flags x83 flags2 xea
  numSV 29 lon 162837865 lat 481492049 height 277494
  hMSL 235357 hAcc 15 vAcc 24
  velNED 2 2 16 gSpeed 3 headMot 24410926
  sAcc 131 headAcc 18000000 pDOP 119 flags3 x4 reserved0 x334c2e2c
  headVeh 0 magDec 0 magAcc 0
    valid (validDate ValidTime fullyResolved)
    fixType (3D)
    flags (gnssFixOK, diffSoln, Carrier Phase fixed,)
    flags2 (confirmedAvai confirmedDate confirmedTime)
    psmState (Not Active)
    carrSoln (Fixed)
    flags3 () lastCorrectionAge 2

help

usage: ./setup_rover_sh help | setup_initial | nmea_pipe | raw_pipe | sat_used | navpvt | ntrip 
          help  ... this help 
          setup_initial ... this will initialise the base station 
          nmea_pipe ... this will create a gpspipe with NMEA protocol listen on port 10001 
          raw_pipe ... this will create a gpspipe with raw data listen on port 10002 
          sat_used ... will show the used satellites based on ubxtool -p NAV-SAT command 
          navpvt ... will show the status based on ubxtool -p NAV-PVT command 
          ntrip start | stop | status | "" 
                to manage communication between base station and rover with a str2str process 
                without argument it will restart the str2str process 

some internal links

These are some possibilities to look for a precise point position. Definitelly one needs to have one exact position for the base station in a rover/base setup.

(1) PPP - Precise Point Positioning with averaging
(2) PPP with gpsrinex, CSRS-PPP and ECTT
(3) PPP with RTKlib and local correction
(4) PPP with NTRIP source for u-blox GNSS receiver over gpsd
(5) High Precision Positioning with RTK and rtknavi_qt

Tools at github:
A commandline tool to transform ecef wgs84 data.

Comparison Precise Point Positioning (PPP) and RTK Methods

Mon, 16 Mar 2026 14:02:00 +0100

Comprehensive Comparison: Precise Point Positioning (PPP) Methods

This report documents the evolution of GNSS measurement techniques from basic statistical averaging to professional-grade post-processing and real-time RTK solutions. All experiments were conducted using a fixed roof-mounted antenna and u-blox ZED-F9P/ZED-X20P receivers.

1. Overview of Evaluated Methods

Method	Title	Core Technique	Data Source
1	Statistical Averaging	Long-term mean calculation (24h)	Autonomous GNSS
2	CSRS-PPP Service	Cloud-based post-processing	Global Ephemerides
3	RTKLIB (Local)	Manual post-processing	Local Base (APOS)
4	NTRIP (Hardware)	Internal RTK Engine	Real-time NTRIP Stream
5	RTKNAV (Software)	External RTK processing	Real-time NTRIP Stream

2. Detailed Method Analysis

Method 1: Precise Point Positioning with Averaging

This “brute force” approach relies on the law of large numbers. By averaging data over 24 hours, local ionospheric fluctuations are partially smoothed out.

Performance: Achieved a precision within a 20 cm radius.
Key Insight: Changing the dynModel to “stationary” did not significantly improve the result. The absolute offset compared to corrected methods remained over 1 meter.

Method 2: CSRS-PPP & ECTT Transformation

Utilizes the Canadian Spatial Reference System (CSRS) for professional post-processing.

Workflow: Collect RINEX data -> Upload to CSRS -> Wait for “Final” orbit products -> Transform coordinates.
The Transformation Factor: Results are delivered in ITRF. For European accuracy, the ECTT tool must be used to convert to ETRF, accounting for tectonic plate drift (approx. 2.5 cm/year).

Method 3: RTKLIB with Local Correction (APOS)

The most precise “offline” method using local reference stations from the Austrian BEV (APOS service).

Technique: Manual calculation using rnx2rtkp and .obs files from both the rover and a nearby base station (e.g., WIEN00AUT).
Results: Extremely tight clustering with a maximum deviation of only 26 mm.
Comparison: After transformation, it aligned within 11 cm of the CSRS-PPP result.

Method 4: NTRIP over gpsd (Hardware RTK)

A real-time solution where the u-blox ZED-F9P processes RTCM3 correction data internally.

Workflow: Direct NTRIP stream via gpsd to the receiver.
Stability: High percentage of Status: FIXED (Q=1).
Precision: The average value was only 3.9 cm away from the high-precision results of Method 3.

Method 5: Software-Based RTK (rtknavi_qt)

Utilizes the RTKlib software suite to perform the heavy lifting of RTK calculations on a host PC rather than the chip.

Hardware: Conducted with the u-blox ZED-X20P.
Observations: It required approximately 30 minutes to achieve a “FIX.”
Control: Offers the most granular control over navigation systems (GPS, Galileo, BDS) and satellite selection.

3. Comparison Table

Feature	Method 1	Method 2	Method 3	Method 4	Method 5
Real-Time	No	No	No	Yes	Yes
Complexity	Low	Medium	High	Medium	High
Accuracy (Relative)	~20-40 cm	< 5 cm	< 3 cm	~5 cm	~5-10 cm
Ref. System	WGS84	ITRF (Global)	ETRF (Local)	ETRF	ETRF
Data Effort	Zero	RINEX Upload	RINEX + Base	NTRIP Login	NTRIP + Config

4. Final Conclusion & Recommendations

For Static Surveying: Method 3 (Post-processing with local APOS data) is the gold standard, providing the highest repeatability and millimeter-level precision.
For Daily Use: Method 4 (NTRIP into F9P) is the most efficient. It provides professional “Fixed” solutions in real-time with minimal software overhead.
Critical Factor: When comparing results over time (e.g., 2023 vs 2026), always perform a coordinate transformation (ITRF to ETRF). Without it, continental drift will be misinterpreted as measurement inaccuracy.

5. Links to this 5 methods

High Precision Positioning with RTK and rtknavi_qt

Sun, 15 Mar 2026 11:13:00 +0100

This is now my fifth attempt and probably the last one to get a high precision position (using RTK) of my stationary GNSS antenna on the roof of my house. You can find the methods I used previously in my blogs here:

(1) PPP - Precise Point Positioning with averaging
(2) PPP with gpsrinex, CSRS-PPP and ECTT
(3) PPP with RTKlib and local correction
(4) PPP with NTRIP source for u-blox GNSS receiver over gpsd

As GNSS receiver I used my brand new u-blox ZED-X20P
to manage this device I use the gpsd package.

The method is quite simple. Use rtknavi_qt to configure a rover / base station setup. Rover is the own GNSS receiver with a stationary antenna. The base station is an external RTCM stream. So feed RTCM data as a NTRIP ( Networked Transport of RTCM via Internet Protocol ) stream to rtknavi_qt. rtknavi_qt is part of the package RTKlib which can be found here github.com/rtklibexplorer/RTKLIB. I run it on Debian Linux.

To do so, one must use any NTRIP caster. There are several available for free and of course also some commercial. In any case you have to register as you need username and password.

This method doesn’t differ much from method (4). The main difference: processing is now handled by rtknavi_qt, whereas in (4) it was calculated on-board by the u-blox receiver itself.

To prepare my u-blox for this task, I run the following commands to enable RAWX and SFRBX messages:

ubxtool -z CFG-MSGOUT-UBX_RXM_SFRBX_UART1,1 | grep ACK-ACK
ubxtool -g CFG-MSGOUT-UBX_RXM_SFRBX_UART1 | grep UART
ubxtool  | grep SFRBX

ubxtool -z CFG-MSGOUT-UBX_RXM_RAWX_UART1,1 | grep ACK-ACK
ubxtool -g CFG-MSGOUT-UBX_RXM_RAWX_UART1 | grep UART
ubxtool  | grep RAWX

# DYNMODEL stationary 
ubxtool -z CFG-NAVSPG-DYNMODEL,2 | grep ACK-ACK
ubxtool -g CFG-NAVSPG-DYNMODEL | grep CFG-NAVSPG-DYNMODEL

Now configure rtknavi_qt

Open rtknavi_qt & and new window will appear.
Click on Options... on the bottom left side there is a Load... button. Load the file f9p_ppk.conf which comes with the source tree. Some of the settings I changed. Positioning Mode I set to Static as my antenna is fix mounted. As Navigation Systems I selected GPS, Galileo and BDS. This should fit what the base station is delivering. In the Positions tab for Base Station I selected RTCM/Raw Antenna Position. It is also possible to set Lat/Lon/height or X/Y/Z but as long as the base station is propagating its own position “RTCM/Raw Antenna Position” is the easy way.
Back in the main menu press I for input streams. Select Rover with TCP Client as Stream Type. As Stream Options enter IP address and port number where you start the following process

socat EXEC:'gpspipe -RB' TCP-LISTEN:10001,reuseaddr,fork &

and Format u-blox UBX

gpspipe must be able to connect to the own gpsd process and socat offers this data on port 10001
It would be possible too to connect rtknavi_qt via the serial port to the X20P directly. But then the gpsd process has to be stoppped. I like to have still the possibility to communicate via ubxtool to the GNSS receiver even if another task is running.

The base station is NTRIP Client, in Stream Options enter Caster Address, port, mountpoint, user name and password what you want to use. Format is RTCM 3.

Press the “OK” button. Ideally save the new configuration with a new name in the options tab.

Now it’s time to press the Start button. Very soon I get as solution “float”. But it took almost every time up to 30 minutes to get status FIX. So take a coffee or do something useful in the meantime.

Even I can see 40 or more satellites normally only 14 of them are used for calculation. If not enough satellites are available a “FIX” could fail completely.

Press the O button to define an output stream if you want to document the results.

I have done this several times and this is the result

date	latitude	longitude	altitude
TRF200AUT0_0309120300	48.14928606302	16.28383433228	286.40506914692
TRF200AUT0_0309134300	48.14928580935	16.28383415321	286.48471173372
TRF200AUT0_0309151800	48.14928595710	16.28383435701	286.45548243359
TRF200AUT0_0309183400	48.14928600921	16.28383449567	286.53004319113
TRF200AUT0_0310140400	48.14928578354	16.28383411977	286.46952323780
TRF200AUT0_0310172500	48.14928596503	16.28383407456	286.48586886361
average	48.14928593121	16.28383425542	286.47178310113

The points are all within 23 mm of the average value.

4092523.7097    1195484.3619    4728180.7806
48.14928593121  16.28383425542  286.471
48 8 57.42935   16 17 1.80331

Taking the average value and calculating the distance to method (2) we get an offset of 4.5 cm. Distance to method (3) is 12.4 cm. Distance to method (4) is 8.8 cm.

Below the is a plot of one of these traces done with rtkplot_qt

As we can see there are 71.4% of all points with Q = 1 that is status “FIX”. I took only those point for the calculation of the average value. The area is about 5 times 6 cm.

Note: The quality of your RTK fix depends heavily on the quality and proximity of the NTRIP caster. If you experience inconsistent results, double-check the coordinates provided by the caster’s mountpoint.

Tools at github:
A commandline tool to transform ecef wgs84 data.

second interface for u-blox GNSS receiver on Pi4 and Pi5

Mon, 09 Mar 2026 18:35:00 +0100

This post will just describe how to setup a second interface on a Raspberry Pi4 and Pi5 with Debian 13 (trixie) for the second interface on the GNSS receiver called UART2.
A detailed description how to prepare a Raspberry Pi4 and Pi5 for gpsd and ntpd can be found here:
GPSD on Raspberry Pi5 with Debian Trixie
GPSD on Raspberry Pi4 with Debian Bullseye

I own a pHAT from uputronics with a ZED-F9P on Pi4 and a pHAT from sparkfun with a ZED-X20P on Pi5.
Both GNSS receivers have a second interface called UART2 and both systems are wired to GPIO pins of the Raspberry Pi.

And sometimes it’s useful to have a second connection to the receiver. For example, if the interface speed of the primary interface is accidentally changed or misconfigured. Or if one wants to feed RTCM3 data over a different path. But there are also other use cases where it’s useful to have access over a second way.

Pi 4

In my case the uputronics board UART2 is connected to GPIO12 for TXD5 and GPIO13 for RXD5. Don’t mix up the GPIO name with the pin number. For example GPIO12 is pin 32 and GPIO13 is pin 33 on the 40 pin connector.

For the Pi 4 the modification is easy. Add a line in /boot/firmware/config.txt in the global section

dtoverlay=uart5

and reboot. That’s it. Now you will find a new device /dev/ttyAMA5. One can access this interface for example with /usr/local/bin/ubxtool -f /dev/ttyAMA5 -s 38400 and the command you want to submit.

Pi 5

On the Raspberry Pi5 it was a little bit more tricky as there is a complete redesign. The pin usage was unchanged but the hardware below changed.
sparkfun connected UART2 of ZED-X20P to GPIO8 and GPIO9 which is UART3. I created a section [all] already for the first interface at the end of the file /boot/firmware/config.txt and did add a new line with dtoverlay=uart3-pi5. The complete change looks like this

[all]
# iface 1: Standard-UART on GPIO 14 (TX) and 15 (RX)
enable_uart=1

# GPIO 8/9 (UART3)
dtoverlay=uart3-pi5

Reboot. That’s it. Now you will find a new device /dev/ttyAMA3. If you create a function like this

ubxtool3(){
  /usr/local/bin/ubxtool -f /dev/ttyAMA3 -s 38400 $@ 
}

you can easily access the u-blox device without adding each time device and speed. Just use ubxtool3 instead of ubxtool.

Just another hint. I use this function for normal operation.

ubxtool(){
  /usr/local/bin/ubxtool $@ localhost:gpsd:/dev/serial0 
}

I compiled the gpsd source tree by myself. Therefore “ubxtool” and others are found in /usr/local/bin
If you install the delivered package you will find /usr/bin/ubxtool

u-blox ZED-X20P

Mon, 09 Mar 2026 17:47:00 +0100

Some days ago I got the new ZED-X20P from manufacturer u-blox.
I bought this device from DigiKey as redistributor for sparkfun.

In July I updated to the latest version. MON-VER gives now the following information

# ubxtool  -p MON-VER
  swVersion EXT HPG 2.10 (b0eda3)
  hwVersion 000B0000
  extension ROM BASE 0x00A9D329
  extension FWVER=HPG 2.10
  extension PROTVER=50.11
  extension MOD=ZED-X20P
  extension GPS;GLO;GAL;BDS
  extension SBAS;QZSS
  extension NAVIC;LBAND

As you can see this pHAT from sparkfun has a submodul with the ZED-X20P

This pHat is mounted on a Raspberry Pi5.
The submodule is connect with a very short antenna cable to the pHAT. Below there is the 5V/3A USB power connector.

Since some years I own a u-blox ZED-F9P too. But now I am happy that I can do some experiments with the latest family of GNSS receivers from u-blox. If you are missing GLONASS in version 2.02 the version 2.10 is the solution. Read here how to update without u-center 2

PPP with NTRIP source for u-blox GNSS receiver over gpsd

Sat, 28 Feb 2026 18:32:00 +0100

This is now my fourth attempt to get an exact position (Precise Point Positioning) of my fixed mounted GNSS antenna at the roof of my house. You can find the methods I used previously in my blogs here:
(1) PPP - Precise Point Positioning with averaging
(2) PPP with gpsrinex, CSRS-PPP and ECTT
(3) PPP with RTKlib and local correction

As GNSS receiver I used again my u-blox ZED-F9P
to manage this device I use the gpsd package.

The method is quite simple. Feed RTCM date as a NTRIP ( Networked Transport of RTCM via Internet Protocol ) stream to the GNSS receiver. To do so, one must use any NTRIP caster. There are several available for free and of course also some commercial. In any case you have to register as you need username and password.

As I am using the gpsd package I use the daemon gpsd itself to do this job.
This can be achieved by 2 different methods

start gpsd with an additional argument like ntrip://my.user:my.passwd@157.90.249.44:2101/MOUNTPOINT
run “gpsdctl add ntrip-URL”. This needs that gpsd was started with option “-F /run/gpsd.sock”

So what we need is username, password, the DNS name or IP address of the caster, the port number which is in almost all cases 2101 and the mountpoint. All mountpoints for a caster can be found at the caster itself and you should use one which is very close to you.

To be sure that my ZED-F9P is well configured I run some checks.

  ubxtool -g CFG-UART1INPROT-RTCM3X | grep CFG-UART1INPROT-RTCM3X 
  
  echo check if skipped frames count up 
  ubxtool -p MON-COMMS  | grep -A 7 UBX-MON-COMMS: | grep skipped
  sleep 10 
  ubxtool -p MON-COMMS  | grep -A 7 UBX-MON-COMMS: | grep skipped
  
  ubxtool  -g CFG-NAVSPG-DYNMODEL | grep CFG-NAVSPG-DYNMODEL | head -1 
  ubxtool  -z CFG-NAVSPG-DYNMODEL,2 | grep UBX-ACK-ACK: 
  
  if test -z "`ubxtool -p NAV-PVT -v 2 | grep -i carrSoln | grep Fixed`"
    then 
      echo state not fixed 
      ubxtool -p NAV-PVT -v 2 | grep -i carrSoln
      exit 1 
  fi 
 
  echo number of satellites with cno greater 40 
  ubxtool -p NAV-SIG -v 2 | grep cno | awk '{ if ( $12 > 40 ) print ( $2, $4 ) }' | sort -u | wc -l 
 
  echo accuracy in 0.1 mm 
  ubxtool -p NAV-RELPOSNED -v 2 | grep -i accN

  ubxtool -z CFG-MSGOUT-UBX_RXM_RTCM_UART1,1 | grep UBX-ACK-ACK:
  
  RESULT=`ubxtool -v 2 -w 10 | grep -i RTCM`
  
  if test -z "$RESULT" 
    then 
      echo we dont get RTCM data 
      exit 1 
  fi
    
  ubxtool -z CFG-NMEA-HIGHPREC,1  | grep UBX-ACK-ACK: # ist default 0 
  ubxtool -z CFG-MSGOUT-NMEA_ID_GGA_UART1,1 | grep UBX-ACK-ACK:  
  
  # for standard deviation 
  ubxtool -z CFG-MSGOUT-NMEA_ID_GST_UART1,1 | grep UBX-ACK-ACK:

I start gpspipe

nohup socat EXEC:'gpspipe -rRB gpsdhost\:2947\:/dev/serial0' 'TCP-LISTEN:10001,reuseaddr,fork' &

and I collect the data with

SEC=3600
DAT=`date '+%j%H%M00'`
timeout $SEC nc 127.0.0.1 10001 | grep --line-buffered -aE "GGA|GST" > $MP/messung_$DAT.nmea

$SEC is the time in seconds how long I want to collect the data. One hour is normally good enough. $MP is the mountpoint selected in the ntrip-URL. If all is fine I extract the position data from the file with this script

nmea2pos.bash $MP/messung_$DAT

This will create a file $MP/messung_$DAT.pos which can be viewed with rtkplot-qt.

I run this scenario over several times. And this is the result

date	latitude	longitude	altitude
messung_049220424	48.14928668858	16.28383489981	286.34149647059
messung_049220558	48.14928651058	16.28383491739	286.34408541973
messung_049224529	48.14928646948	16.28383476017	286.32093080357
messung_051190411	48.14928674470	16.28383504772	286.35412230216
messung_053164800	48.14928685024	16.28383472580	286.29313600000
messung_053164900	48.14928721850	16.28383476294	286.34042372881
messung_053170600	48.14928712056	16.28383469769	286.35376422764
messung_053171700	48.14928646645	16.28383503276	286.33033740831
messung_053182000	48.14928761124	16.28383548462	286.31665768194
messung_053184700	48.14928675778	16.28383470345	286.25878328474
messung_056172800	48.14928653393	16.28383432340	286.44596396396
messung_056173000	48.14928641814	16.28383453253	286.46528272251
messung_056174600	48.14928641787	16.28383439221	286.44075187970
messung_056174700	48.14928635164	16.28383422094	286.38687192983
messung_056203500	48.14928663041	16.28383471765	286.38973867596
messung_057102300	48.14928749432	16.28383523683	286.41764218009
messung_057113100	48.14928616931	16.28383569321	286.21828049137
messung_057172000	48.14928643937	16.28383441440	286.37522851677
messung_064192300	48.14928611437	16.28383541068	286.39431147541
messung_064193000	48.14928626123	16.28383493320	286.45333041958
messung_065185800	48.14928580792	16.28383442479	286.43519302326
average	48.14928662270	16.28383482534	286.36553964790

4092523.5748    1195484.3667    4728180.7527
48.14928662270  16.28383482534  286.3655
48 8 57.43184   16 17 1.80537

The maximum distance to the average point is 13.5 cm. The maximum distance between 2 measuring points is 21.5 cm.

Takeing the average value and calculating the distance to method (2) we get an offset of 6.8 cm. Distance to method (3) is 3.9 cm.

Below the is a plot of one of these traces done with rtkplot_qt

As we can see there are 71.4% of all points with Q = 1 that is status “FIX”. I took only those point for the calculation of the average value. The area is about 5 times 6 cm.

Tools at github:
A commandline tool to transform ecef wgs84 data.
A commandline tool which converts NMEA to high-precision .pos position logs data.

PPP with RTKLIB and local correction

Sat, 21 Feb 2026 13:43:00 +0100

This is now my third attempt to get an exact position of my fixed mounted GNSS antenna at the roof of my house. You can find the methods I used previously in my blogs here:
(1) PPP - Precise Point Positioning with averaging
(2) PPP with gpsrinex and CSRS-PPP and ECIT

As GNSS receiver I used again my u-blox ZED-F9P
to manage this device I use the gpsd package.

This time I used RTKlib to make the post-processing by myself. There are different versions available, I used this: github.com/rtklibexplorer/RTKLIB

The method is about this:
1) create an UBX file over several hours.
2) apply the correction with a RINEX file offered from an external service provider.

Within a shell script I prepared my ZED-F9P with the following settings:

check if baud-rate is high enough

ubxtool -g CFG-UART1-BAUDRATE | grep CFG-UART1-BAUDRATE

I use 921600 bd. This is the highest value I can use. 38400 would be the default.
now disable NMEA protocol and check the response

ubxtool -d NMEA | grep UBX-ACK-ACK:
ubxtool -z CFG-UART1OUTPROT-NMEA,0 | grep UBX-ACK-ACK:
ubxtool -g CFG-UART1OUTPROT-NMEA | grep CFG-UART1OUTPROT-NMEA | head -1

enable or disable different satellites
I disabled Michibiki, the japanese satellites as I can see them very rarely.

ubxtool -z CFG-SIGNAL-SBAS_L1CA_ENA,1 | grep UBX-ACK-ACK:
ubxtool -z CFG-SIGNAL-SBAS_ENA,1 | grep UBX-ACK-ACK:
ubxtool -z CFG-SIGNAL-QZSS_L1CA_ENA,0 | grep UBX-ACK-ACK:
ubxtool -z CFG-SIGNAL-QZSS_L1S_ENA,0 | grep UBX-ACK-ACK:
ubxtool -z CFG-SIGNAL-QZSS_L2C_ENA,0 | grep UBX-ACK-ACK:
ubxtool -z CFG-SIGNAL-QZSS_ENA,0 | grep UBX-ACK-ACK:
ubxtool -g CFG-SIGNAL | sed -n -e '/^UBX-CFG-VALGET:/,/^$/ p' | awk -v RS= 'NR==1'

enable raw data

ubxtool -e RAWX | grep UBX-ACK-ACK:
ubxtool | grep RAWX

to get satellite track data

ubxtool -e SFRBX | grep UBX-ACK-ACK: 
ubxtool -z CFG-MSGOUT-UBX_RXM_SFRBX_UART1,1 | grep UBX-ACK-ACK:

SECS=50400
DAT=`date '+%Y%j%H%M00'`
FILE=`echo result$DAT`
gpspipe -x $SECS -R gpsdhost:gpsd:/dev/serial0 > $FILE.ubx

This gpspipe job will run 14 hours. ( = 50400 seconds )
Next is to generate $FILE.obs , $FILE.nav and $FILE.sbs To do this run convbin

convbin $FILE.ubx

Instead of convbin one can run the GUI rtkconv_qt & interactive.

If files $FILE.obs and $FILE.nav are available one can view some graphs with
rtkplot_qt -r $FILE.obs $FILE.nav &

For example the skyplot for Galileo for the period of 14 hours.

Now comes the part of preparing the correction.

For this we need the RINEX (Receiver Independent Exchange Format) data from a reference station. I use the APOS-PP from BEV. BEV is the Federal Office of Metrology and Surveying ( Bundesamt für Eich- und Vermessungswesen ) in Austria and APOS-PP is a free service they offer. APOS-PP is the Austrian Position Service Post Processing. See APOS

The free available RINEX files are accessible short time after 00:00 UTC, so I fetched them next day. As there are about 60 reference stations one has to select a station which is near to the own position. In my case it’s WIEN00AUT. As each file has only 1 hour of data therefore multiple files are needed. The files have type .crx.gz. To get a .rnx run first gunzip and than CRX2RNX. CRX2RNX is also free available and should have at least version : ver.4.2.0. Older Versions are buggy. Finally all these files have to be combined to one file. This is done with gfzrnx which is also free available. Current available VERSION: gfzrnx-2.2.0 at GFZ.de

Now comes the real part of correction. There are 2 possibilities:

a GUI rtkpost_qt
a command line tool: rnx2rtkp

As first step I run the GUI. The reason is that some settings can be saved in a configuration file which can be used with the command line tool as argument. I configured under “Setting1” position mode “Static” and selected Navigation Systems: GPS, Galileo, Glonass and BDS. In selector “Positions” I entered below “Base Station” the position in X/Y/Z-ECEF format ( Earth-Centered, Earth-Fixed ). The values can be found in the final .rnx file in line marked with APPROX POSITION XYZ. Don’t worry, it’s not approximately, it is exact. In case of WIEN00AUT it is 4085097.7110 1200224.1682 4733306.7362. It’s important to enter the exact values, otherwise the calculated result is wrong. Now press the “Save” button and give the configuration file a name, e.g. “myconfig.conf”. Back to the main window enter the necessary file names. It is the .obs file for Rover, the .rnx file for the basestation and also needed .nav and .sbs file. In the solutions sections you get a proposal for the final position file name. Press the “Execute” button. After a while - maybe a minute - you get the result. Press the “Plot” button. It will start rtkplot_qt with the .pos file. If “Ground Track” is selected we can see that the position goes around only few centimeter during the last hours. Better to see using the “Position” tab.

As we can see the curve swings in. As value I don’t use the last line of the result file, I use the average of the last 3 hours. Especially don’t use the first 2 lines for calculating the average.

Instead of using the GUI with rtkpost_qt it’s also possible to use the command line tool rnx2rtkp. As we have now a config file we can apply this as argument with option -k calling rnx2rtkp. A typical call looks like this:

rnx2rtkp -k myconfig.conf -o $FILE.pos $FILE.obs $FILE.rnx $FILE.nav $FILE.sbs

I run this scenario over several days. And this is the result

date	longitude	latitude	altitude
result2026031081521.pos	48.14928692997	16.28383533848	286.24190831482
result2026035020026.pos	48.14928677086	16.28383492415	286.22960926852
result2026036020000.pos	48.14928679808	16.28383546030	286.25004589815
result2026037020000.pos	48.14928691925	16.28383549683	286.25375274075
result2026038020000.pos	48.14928667076	16.28383506609	286.26456416667
result2026039020000.pos	48.14928684631	16.28383542232	286.27070575001
result2026040020000.pos	48.14928671316	16.28383543821	286.23612560186
result2026041020000.pos	48.14928684210	16.28383505095	286.26883948147
average	48.14928681131	16.28383527467	286.25194390275

4092523.4777    1195484.3731    4728180.6821
48.14928681131  16.28383527467  286.251
48 8 57.43252   16 17 1.80698

All results are within a circle with a radius of 26 mm. The maximum distance between 2 points is 46 mm.
But when I compare this result with the result I got using gpsrinex (Method 2) then there is an offset of about 87 cm bevor the coordination transformation was applied but only 11 cm after the coordination transformation was applied.
Comparing this with the averaging method 1 I see an offset of 1.1 meters.

A commandline tool to transform ecef wgs84 data.