hans mayer's weblog

RTK - base/rover with U-blox GNSS receivers

Sun, 03 May 2026 16:47:00 +0000

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 +0000

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 +0000

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 +0000

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 +0000

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

MON-VER gives the following information

# ubxtool  -p MON-VER 
UBX-MON-VER:
  swVersion EXT HPG 2.02 (43e74c)
  hwVersion 000B0000
  extension ROM BASE 0x00A9D329
  extension FWVER=HPG 2.02
  extension PROTVER=50.10
  extension MOD=ZED-X20P
  extension GPS;GAL;BDS
  extension SBAS;QZSS
  extension NAVIC

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.

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

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

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 +0000

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.

PPP with gpsrinex, CSRS-PPP and ECTT

Wed, 21 Jan 2026 17:31:00 +0000

In my previous blog PPP Precise Point Positioning with averaging 3 years ago I used the method “averaging” to get a precise position.

This time I used this Canadian service CSRS-PPP for post-processing the data.

So I prepared my GNSS receiver ZEF-F9P for this job. This is well documented in the man page for “gpsrinex”.

So I run over several days commands like this:
gpsrinex -i 30 -n 1440 -f gpsrinex2025322205923.obs
This would collect the information for a period of 12 hours.
2025322205923 means: year 2025 day number 322 of this year at 20:59:23 h

If this job is finished it’s theoretical possible to upload this file immediately to the Canadian service. But then you get a result as product type “ultra rapid”. If you wait two days or so it’s “rapid” and if you wait more than two weeks you get the “final” version. Because it takes some time for them to get all the correction data to make a qualitativ high post processing with my collected data.

If one submits this file one will get the result per e-mail. This e-mail may take several hours but it could also be available after several minutes. It depends on how much requests are in the queue.

As processing mode I selected “Static” and “ITRF” (International Terrestrial Reference Frame)

This is the final result

date	latitude	longitude	high
2023117170821	48.1492922571	16.2838437976	286.6270
2025322205923	48.1492917165	16.2838443722	287.0627
2025323203540	48.1492922225	16.2838446130	286.7583
2025324091707	48.1492910139	16.2838430433	286.9125
2025327220019	48.1492924369	16.2838438271	286.7396
2025330191355	48.1492919858	16.2838448611	286.8052
average	48.1492919387	16.2838440857	286.817

N: 48 8 57.45097  E: 16 17 1.83870  H: 286.817 m 
X: 4092523.2481   Y: 1195484.9891   Z: 4728181.4834

If I compare this result with the result of “averaging” then there is a gap of about 47 cm in direction 156 deg South-Southeast (SSE)

This is the result as graph

Now using the ETRF/ITRF Coordinate Transformation Tool ECTT to convert from ITRF2020 ( over ITRF2000 ) to ETRF2000 for epoche 2026.0 I get

4092523.9026   1195484.3949   4728181.0565
48.1492862849  16.2838339544  286.8070
48 8 57.43062  16 17 1.80223

A commandline tool to transform ecef wgs84 data.

Wetter 2025 in Wien Mauer

Thu, 01 Jan 2026 00:00:00 +0000

Wien 23. Bezirk Liesing, Ortsteil: Mauer
Position: 48° 8’ 57.1” N, 16° 17’ 2.1” E
Meeresniveau: 235 m ü. A.

Temperatur

Die fünf heißesten Tage im Jahr 2025

Datum	maxT
2025-07-03	38.0
2025-06-26	36.2
2025-08-15	35.5
2025-08-14	35.0
2025-08-13	34.7

Die fünf kältesten Tage im Jahr 2025

Datum	minT
2025-02-19	-8.4
2025-02-20	-7.0
2025-02-17	-5.9
2025-11-24	-5.5
2025-11-23	-5.4

Fünf Tage mit geringster Tageserwärmung

Datum	maxT	minT	Delta
2025-01-22	-1.1	-1.8	0.7
2025-12-16	0.8	0.0	0.8
2025-11-13	4.5	3.6	0.9
2025-12-23	3.5	2.5	1.0
2025-01-18	-0.1	-1.3	1.2

Fünf Tage mit höchster Tageserwärmung

Datum	maxT	minT	Delta
2025-03-06	20.8	-0.3	21.1
2025-06-22	31.7	13.1	18.6
2025-03-07	20.1	2.0	18.1
2025-05-14	24.2	6.1	18.1
2025-07-02	34.3	16.2	18.1

Insgesamt gab es 7 Eistage

Die Temperatur bleibt den ganzen Tag unter 0° Celsius

Datum	minT	maxT
2025-01-01	-3.8	-2.0
2025-01-02	-4.6	-1.2
2025-01-18	-1.3	-0.1
2025-01-19	-2.8	-1.0
2025-01-20	-3.0	-1.7
2025-01-21	-2.4	-1.1
2025-01-22	-1.8	-1.1

Längste Periode an Eistagen

von	bis	minT	maxT	avgT	Tage
2025-01-18	2025-01-22	-3.0	-0.1	-1.70	5

Insgesamt gab es 63 Frosttage

Die Temperatur fällt unter den Gefrierpunkt

Datum	minT	maxT
2025-01-01	-3.8	-2.0
2025-01-02	-4.6	-1.2
2025-01-03	-1.2	4.2
2025-01-04	-0.7	3.0
2025-01-05	-2.9	0.1
2025-01-07	-0.3	6.3
2025-01-12	-0.6	2.0
2025-01-13	-0.7	1.2
2025-01-14	-3.6	2.0
2025-01-15	-1.1	2.1
2025-01-17	-0.1	3.5
2025-01-18	-1.3	-0.1
2025-01-19	-2.8	-1.0
2025-01-20	-3.0	-1.7
2025-01-21	-2.4	-1.1
2025-01-22	-1.8	-1.1
2025-01-23	-1.3	4.3
2025-01-24	-1.6	7.7
2025-01-30	-0.9	11.6
2025-01-31	-0.9	8.6
2025-02-01	-1.4	4.8
2025-02-03	-2.6	5.0
2025-02-04	-4.4	5.0
2025-02-05	-4.5	6.6
2025-02-08	-0.1	5.1
2025-02-10	-0.1	7.2
2025-02-11	-2.8	6.6
2025-02-12	-0.3	3.2
2025-02-13	-0.3	2.4
2025-02-15	-1.8	2.5
2025-02-16	-1.5	2.0
2025-02-17	-5.9	2.2
2025-02-18	-3.9	2.5
2025-02-19	-8.4	3.6
2025-02-20	-7.0	5.6
2025-02-21	-2.8	5.0
2025-02-22	-1.6	7.5
2025-02-23	-3.1	2.1
2025-03-03	-1.2	12.4
2025-03-04	-1.0	13.1
2025-03-05	-0.7	14.6
2025-03-06	-0.3	20.8
2025-03-18	-2.7	7.6
2025-03-19	-3.8	12.4
2025-03-20	-2.1	13.9
2025-11-18	-0.9	6.4
2025-11-19	-3.1	4.2
2025-11-20	-1.5	4.6
2025-11-22	-1.2	1.8
2025-11-23	-5.4	1.3
2025-11-24	-5.5	1.1
2025-11-27	-1.1	4.1
2025-11-28	-1.6	4.8
2025-11-29	-3.3	4.8
2025-12-15	-0.6	1.3
2025-12-24	-0.3	2.5
2025-12-25	-1.3	0.3
2025-12-26	-1.4	2.3
2025-12-27	-2.1	5.1
2025-12-28	-0.2	4.3
2025-12-29	-1.4	5.1
2025-12-30	-1.0	1.9
2025-12-31	-3.2	0.7

Letzter und erster Frosttag

letzterFrosttag	minT	maxT
2025-03-20	-2.1	13.9

ersterFrosttag	minT	maxT
2025-11-18	-0.9	6.4

Anzahl der Frosttage pro Monat

Monat	Anzahl
Januar	20
Februar	18
März	7
November	9
Dezember	9

Insgesamt gab es 10 Tropennächte

Die Temperatur fällt nicht unter 20 °C

Datum	minT	maxT
2025-06-26	20.4	36.2
2025-06-27	21.3	30.9
2025-06-29	23.0	34.0
2025-06-30	21.9	32.8
2025-07-03	20.7	38.0
2025-07-04	20.8	27.4
2025-07-15	20.1	31.1
2025-08-16	21.1	33.7
2025-08-17	20.2	27.8
2025-08-29	20.7	28.5

Insgesamt gab es 38 Hitzetage

Die Tageshöchstwerte klettern über 30 °C

Datum	minT	maxT
2025-05-03	13.2	30.3
2025-05-31	13.0	31.0
2025-06-01	15.6	31.2
2025-06-05	19.4	30.4
2025-06-06	16.5	30.7
2025-06-07	17.8	30.3
2025-06-15	13.8	31.3
2025-06-18	15.3	30.5
2025-06-19	18.5	31.7
2025-06-22	13.1	31.7
2025-06-23	16.1	34.1
2025-06-24	19.1	30.5
2025-06-25	18.4	33.6
2025-06-26	20.4	36.2
2025-06-27	21.3	30.9
2025-06-29	23.0	34.0
2025-06-30	21.9	32.8
2025-07-01	17.3	32.6
2025-07-02	16.2	34.3
2025-07-03	20.7	38.0
2025-07-05	15.8	31.3
2025-07-06	19.1	34.5
2025-07-13	13.8	30.7
2025-07-14	16.3	31.9
2025-07-15	20.1	31.1
2025-07-20	18.9	33.4
2025-07-21	17.7	31.9
2025-07-24	19.0	30.3
2025-08-08	15.7	33.8
2025-08-09	19.8	34.5
2025-08-10	19.5	34.5
2025-08-12	15.4	30.9
2025-08-13	17.5	34.7
2025-08-14	19.1	35.0
2025-08-15	18.4	35.5
2025-08-16	21.1	33.7
2025-08-20	15.9	31.4
2025-08-28	15.3	32.9

Anzahl der Hitzetage mit über 30 Grad pro Monat

Monat	Anzahl
Mai	2
Juni	15
Juli	11
August	10

Längste Periode an Hitzetagen

von	bis	minT	maxT	avgT	Tage
2025-06-22	2025-06-27	13.1	36.2	24.96	6

Monatsübersicht 2025

Nr	Monat	minT	maxT	avgT
1	Januar	-4.6	15.0	1.65
2	Februar	-8.4	13.5	1.78
3	März	-3.8	20.8	7.94
4	April	0.6	26.6	13.18
5	Mai	5.0	31.0	14.75
6	Juni	11.0	36.2	22.48
7	Juli	12.4	38.0	21.49
8	August	11.5	35.5	22.05
9	September	6.1	29.6	17.33
10	Oktober	0.3	18.3	10.64
11	November	-5.5	15.8	5.00
12	Dezember	-3.2	11.9	2.61

Jahreszusammenfassung 2025

Jahr	minT	maxT	avgT	Messwerte
2025	-8.4	38.0	11.79	525451

Niederschläge

1 mm Niederschlag entspricht 1 Liter pro Quadratmeter

Monat	mm
2025-01	4.5
2025-02	2.0
2025-03	66.5
2025-04	37.3
2025-05	42.0
2025-06	68.8
2025-07	99.2
2025-08	33.1
2025-09	101.6
2025-10	32.0
2025-11	47.0
2025-12	24.0

Siehe auch: Niederschläge 2024

GPSD and NTP on Raspberry Pi5 with Debian OS 13 trixie

Sat, 20 Dec 2025 18:55:00 +0000

OS installation

I decided to buy a Raspberry Pi5.
I installed this image

2025-12-04-raspios-trixie-arm64-lite.img with unziped file size 2986344448

And the idea was to setup a stratum 1 NTP server.

I used the GPS-hat I already have since years.

As you can see the vendor is M0UPU. I bought this GPS modules at uputronics.com
This is not available anymore. At that time an ublox MAX-M8Q was used as chip on the gps HAT.

I decided to compile GPSD and NTPD by myself and not to use an available package. As it was a brand new installation a lot of packages are needed:

NTPD

For NTP I took NTPsec from https://gitlab.com/NTPsec/ntpsec
As first step I installed the official package from OS with
apt-get install ntpsec ntpsec-doc ntpsec-ntpdate
With this I got the necessary scripts to start which I had to change only slightly for the self compiled version.
Additional the following packages were needed: git, m4, m4-doc, bison, bison-doc

The basic steps to compile are:

git clone https://gitlab.com/NTPsec/ntpsec.git
cd ntpsec/
./waf configure --refclock=gpsd,generic,shm,pps,nmea,local
./waf build
sudo ./waf install

For the further usage it’s important to set $PYTHONPATH correct. In my case

export PYTHONPATH=/usr/local/lib/python3.13/site-packages/

With ntp.conf from the package one can test if ntpd works well, but in the moment not as stratum 1 service.

GPSD

To run a GNSS disciplined stratum 1 NTP server the gpsd package is not necessary. What we need is a 1PPS ( one puls per second ) which we get from the gps HAT with the available drivers from the OS. But the gpsd package with all its tools makes the life easier.

You can find the source here: https://gitlab.com/gpsd/gpsd

But gpsd needs a lot of additional packages:

 scons ncurses-base ncurses-bin ncurses-doc ncurses-term python-matplotlib-data python3-matplotlib
 python3-serial python3-cairo:arm64 python3-gi-cairo libqt6network6 libqt6networkauth6 
 qt6-networkauth-dev libncurses-dev libgtk-3-dev

For testing the following packages are additional useful: minicom , ppstest

For complete documentation I want to refer to the Internet

https://gpsd.io/building.html
https://gpsd.gitlab.io/gpsd/installation.html

But compiling is quite straight forward:

git clone git@gitlab.com:gpsd/gpsd.git 
scons ; scons check ; sudo scons install

If you decide later on to update to the latest version run:

git pull origin master --rebase
scons --config=force

OS configuration

To make it runnable some minor changes are necessary in the system. And this is maybe the most tricky part.

/boot/firmware/cmdline.txt

This was the original content:

console=serial0,115200 console=tty1 root=PARTUUID=e20c853e-02 rootfstype=ext4 fsck.repair=yes rootwait

Strip away which makes troubles. Then it looks like this

root=PARTUUID=e20c853e-02 rootfstype=ext4 fsck.repair=yes rootwait

There is still the console on the HDMI port available.

/boot/firmware/config.txt

Add a line in the global block:

dtoverlay=pps-gpio,gpiopin=18

And add a new block at the end of the file

[all]
enable_uart=1

If your HAT delivers the 1PPS on a different gpiopin then you have to change the number of course.
For a detailed list see bananapi-gpio-wiringbp

modules

Create a new file /etc/modules-load.d/pps-gpio.conf with one line:

pps-gpio

I modified /etc/group to be sure not having permission issues. User nobody is important as gpsd is running as nobody.

dialout:x:20:admin,root,nobody

ttyS0.service

To ensure that a getty or login process isn’t taken this device it should be deactivated

systemctl stop    serial-getty@ttyS0.service
systemctl disable serial-getty@ttyS0.service
systemctl mask    serial-getty@ttyS0.service

reboot

Now reboot the Pi5 and check the logs. With

dmesg | egrep 'tty|pps'

you should see something like this:

[    0.000093] printk: legacy console [tty0] enabled
[    0.012546] 107d001000.serial: ttyAMA10 at MMIO 0x107d001000 (irq = 16, base_baud = 0) is a PL011 rev3
[    0.012557] printk: legacy console [ttyAMA10] enabled
[    1.131186] pps_core: LinuxPPS API ver. 1 registered
[    1.136167] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    1.594509] 107d50c000.serial: ttyS0 at MMIO 0x107d50c000 (irq = 33, base_baud = 6000000) is a Broadcom BCM7271 UART
[    1.605118] serial serial0: tty port ttyS0 registered
[    2.656325] 1f00030000.serial: ttyAMA0 at MMIO 0x1f00030000 (irq = 125, base_baud = 0) is a PL011 AXI
[    4.337107] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[    4.400531] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[    4.604327] systemd[1]: Expecting device dev-ttyAMA10.device - /dev/ttyAMA10...

Check if the pps_gpio module is loaded

pi5# lsmod | grep pps_gpio
pps_gpio               49152  0

modinfo pps_gpio gives also some information

There are new devices

pi5# ls -ld /dev/serial? /dev/pps0
crw-rw---- 1 root root 250, 0 Dec 18 18:01 /dev/pps0
lrwxrwxrwx 1 root root      7 Dec 18 18:01 /dev/serial0 -> ttyAMA0

Checking pps0 is useable. It could also be that it is pps1. Of course a GPS-hat must be connected now.

pi5# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1766270742.000503580, sequence: 9871 - clear  0.000000000, sequence: 0
source 0 - assert 1766270743.000502921, sequence: 9872 - clear  0.000000000, sequence: 0
source 0 - assert 1766270744.000502632, sequence: 9873 - clear  0.000000000, sequence: 0
source 0 - assert 1766270745.000502269, sequence: 9874 - clear  0.000000000, sequence: 0

If this is the result then it’s fine.

To see if data are received run

minicom -b 9600 -o -D /dev/serial0

You should see a lot of clear text data coming from the GPS module. Of course the speed could be a different. If you see some wired character then it’s the wrong speed. In my case it’s working with 9600 bd. Typical baud rates are: 9600, 38400 or 115200 bd. But also possible 230400 or 460800 for newer GNSS receiver.

Now it’s time to start gpsd and see if it is working

/usr/local/sbin/gpsd -n -s 9600 /dev/serial0 /dev/pps0

Now the following test should bring some results:

pi5# ntpshmmon
ntpshmmon: version 3.27.2~dev
#      Name  Seen@                 Clock                 Real                 L Prc
sample NTP0  1766270978.149410814  1766270978.148436931  1766270977.999800704 0  -1
sample NTP0  1766270979.149198025  1766270979.148583713  1766270978.999803051 0  -1
sample NTP0  1766270980.149027698  1766270980.148546201  1766270979.999805398 0  -1

To verify the working daemon run cgps -s -u m. You should see some satellite information.

To start next time successfully with systemctl modify file /etc/default/gpsd like this:

OPTIONS=/dev/serial0
DEVICES="/dev/pps0"
GPSD_OPTIONS="-G -n -s 9600"
USBAUTO="false"

Now it’s time for ntpd

The relevant part in /etc/ntpsec/ntp.conf is the following

# pps needs at least one server to get the time
# for easy start I take another stratum-1 in my network
server 192.168.241.190 minpoll 4 maxpoll 4 prefer

# Enabling PPS/ATOM support
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS time1 0.000500
fudge 127.127.22.0 flag3 1 flag4 1  # enable kernel PLL/FLL clock discipline and clockstats

# gpsd shared memory clock, if 192.168.241.190 fails this will jump in
server 127.127.28.0 minpoll 4 maxpoll 4 # PPS requires at least one preferred peer
fudge 127.127.28.0 refid GPS
fudge 127.127.28.0 time1 +0.15 flag4 1 # coarse processing delay offset

The time parameter “time1” you have to adjust for your situation. And of course several other configuration lines are necessary to start the deamon.

After some time you should see:

pi5# ntpq -pn 
     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
oPPS(0)                                  .PPS.            0 l    8   16  377   0.0000   0.0002   0.0004
+SHM(0)                                  .GPS.            0 l   15   16  377   0.0000  -2.0118   1.7784
*192.168.241.190                         .GPS.            1 u   13   16  377   0.7064   0.2019   9.8784