Galileo HAS precise point positioning

Panoramax street-mapping ¦ JuraMap mapping

Galileo High Accuracy Service (HAS) correction data for RTKLIB-based static Precise Point Positioning (PPP) provides mock location data for a mobile Panoramax streetview base station comprising a smartphone with a Raspberry Pi microcomputer and a low-cost GPS receiver.

As explained in an Implementation Note for a Panoramax streetview service, our main interest is to accurately geo-tag images captured in remote areas (in Tanzania's Usumbara Mountains) where Internet and commercial real-time online Precise Point Positioning (PPP) services are unavailable. However, low-cost GNSS receivers which will have their firmware updated regularly and are capable of processing the free and globally available Signal-In-Space (SIS) Galileo High Accuracy Service (HAS) corrections delivered directly from satellites are currently not available. As a first step, since mobile internet connections are available in parts of the Usumbaras it is useful to make use of the HAS Internet Data Distribution NTRIP correction service to replace commercial online real-time PPP services.

Summarised below are most of the steps which are needed to use low-cost GNSS receivers in association with a microcomputer and a smartphone. The described set-up aims to have applications installed on a microcomputer (a Raspberry Pi 3B+) that can process HAS corrections to provide accurate positioning for a base station and a rover.

In the first instance we discuss real-time Precise Point Positioning (RT-PPP) to obtain an accurate position for a base station where a Panoramax image is taken and OpenStreetMap features mapped. This will be followed by a discussion of real-time kinetic Precise Point Positioning (RTK-PPP) where the precisely positioned static base station sends corrections to a moving rover to obtain high real-time precision for the rover's position.

A. HAS RT-PPP results to-date

The obvious starting point for RT-PPP is to use the BKG NRIP Client (BNC) to retrive state-space representation (SSR) correction data from the HAS Internet Data Distribution NTRIP service.

Following rtklibexplorer, the BNC client pulls the HAS data stream and republishes the raw (RTCM3) output at a TCP port through BNC’s "Miscellaneous" tab. The corrections are then pulled into the RTKLIB RTKNAVI application for navigation processing in real time in conjunction with data on precise satellite orbits and time corrections and data from a base station's GPS receiver (in other words, positioning is calculated by RTKNAVI and not by the GNSS receiver). RTKNAVI, or more correctly the RTKLIB's RTKPLOT application, is then used to monitor and plot the position of the base station.

Results to date indicate that applying HAS corrections allows the base's position to be determined to standard deviations of 12 cm east-west and 27 cm north-south (HAS targets a standard deviation of 20 cm in a horizontal direction).

However, at this early stage in the implementation of HAS one must be be aware that RTKLIB does not support SSR corrections for code bias which are provided by HAS. RTKLIB requires appropriate configurations to overcome the absence of code bias corrections. Certain limitations may also arise. Second, HAS does not provide phase biases so while they cannot be used by RTKLIB they can be partially compensated. It is also unclear how correctly the HAS corrections are interpreted by RTKLib and how they are interpolated during the periods when the HAS corrections are not available.

B. Set-up

Our base station connects a Drotek RTK module (DP0601) by a USB cable to a RasperryPi single-board computer (RaspberryPi 3B+) powered using a nominally 5 Volt powerbank (SBS). A note in passing: acquiring suitable powerbanks for a RasberryPi is not straightforward (some exotic brands - CRAVE Plus 10000 mAh and RAVPower 20000 mAh - are recommended). The RaspberryPi connects to a Google smartphone (Pixel 4a) WiFi hotspot and the smartphone's RealVNC Viewer remote desktop app is used to manipulate the RaspberryPi and the Drotek DP601 GPS receiver platform (u-blox ZED-F9P module).

There are two types of low-cost antenna for GPS receivers, namely survey and patch antenna. We use either an uncalibrated, ground-plane surveying Drotek DA901 antenna or a u-blox ANN-MB2-00 all-band patch antenna.

For the PPP positioning of a base station, high-performance geodetic survey antenna provide 2 to 3 times better accuracy than patch antenna largely owing to multipath effects. Second, low-cost calibrated survey antenna perform better than patch antenna, athought a patch antenna's horizontal accuracy may be better. In general, therefore, a survey antenna is probably preferable for a single base station that is not configured as a base - rover arrangement.

For a base - rover arrangement to be discussed later, it is best to have the same antenna for both the base and the rover. Patch antenna are better than low-cost survey antenna for real-time kinetic (RTK) positioning the rover if the separation (baseline) between the base and the rover is short (less than a kilometre). In terms of repeatability of the baseline, the repeatability using patch antenna decreases when the baseline exceeds 25 km.

Before connecting the GPS receiver to the RaspberryPi it is probably wise to establish factory settings on the Drotek's DP0601 u-blox ZED-F9P multi-band GNSS receiver using u-center on a Windows PC. It is also necessary to check firmware using the dialog in uCenter found at: UBX ⇒ MON (Monitor) ⇒ VER (Version) ⇒ "Poll". Drotek provides instructions for updating firmware.

B1. WiFi

Installing RealVNC on an Android smartphone and a RaspberryPi is discussed elsewhere. A key initial step is to configure the Raspberry's WiFi so that it connects to the WiFi network that is used to configure the RaspberryPi and the GPS receiver. A RaspberryPi terminal command:

  • sudo nano/etc/wpa_supplicant/wpa_supplicant.conf

is used to edit the file "wpa_supplicant.conf" by adding:

network={convert

ssid=" MyNetworkSSID"

psk=" Password"

}

Connecting a smartphone to the RaspberryPi's desktop requires the internet address of the smartphone's hotspot. In our case, the simplest is to display the address by connecting the RaspberryPi to a display screen before configuration and photographing starts. The address is displayed when the drop-down at the top-right of the RaspberryPi's desktop is used to connect the RaspberryPi to the hotspot. The address in our case is of the form "192.168.x.83". Fortunately, the number x remains the same until the Pixel 4a (Android version 14) is rebooted. The Network Anaylzer app that scans the local area network can also identify the Pixel 4a WiFi hotspot Internet address.

B2. PyGPSclient

Once the GPS receiver is connected to the Internet and to the GPS receiver, the PyGPSclient graphical GNSS testing, diagnostic and device configuration application is installed on the RaspberryPi. PyGPSclient is written in Python and can be installed in a virtual environment using terminal commands of the form:

  • sudo apt install -y python3-pip
  • mdir pygps
  • cd pygps
  • python3 -m venv .
  • source bin/activate
  • pip3 install --upgrade pygpsclient
  • pygpsclient

PyGPSclient is used to obtain the base's position for geo-tagging photos taken at the base's position. The most straightforward procedure appears to be to set the receiver's configuration to the PyGPSclient default settings (in PyGPSclient: USB/UART ⇒ UBX Config ⇒ "RESTORE FACTORY DEFAULTS") with the PyGPSclient's NTRIP Client configuration "Data type" set to "SPARTN".

The u-blox Windows application u-center can also be used by connecting the receiver to a Windows PC USB port, selecting the u-center COM port and setting Messages View ⇒ UBX ⇒ CFG ⇒ CFG ⇒ "Revert to default configuration" ⇒ Send. Also needed is UBX ⇒ RXM ⇒ RAWX ⇒ right click ⇒ "Enable message".

If a u-center Network Connection is used instead of a USB connection u-center default configuration can be set using View ⇒ Configuration View ⇒ CFG (Configuration) ⇒ "Revert to default configuration" ⇒ Send (in other words, use Configuration View instead of Messages View). RAWX messages are enabled using View ⇒ Configuration View ⇒ MSG (Messages) ⇒ 02-15 RXM-RAWX ⇒ check USB.

B4. Bluetooth

Connecting a Pixel 4a to a RaspberryPi 3B+ to set up a Network Connection using Bluetooth is not particularly straightforward. For a RasberryPi 3B+ with the current 64bit Bookworm RaspberryPi OS, relevant terminal commands for Bluetooth are:

  • systemctl status/start bluetooth (to check/start Bluetooth)
  • hciconfig ("hciconfig -a" to check and obtain the Bluetooth address)
  • bluetoothctl (to run the various commands that pair the Pixel 4a to a Windows PC)
  • sudo l2ping XX:XX:XX:XX (to check that the Pixel 4a Bluetooth is connected where XX:... is the Pixel 4a Bluetooth address)

One then needs to set up the RaspberryPi so that the smartphone's Bluetooth connection can connect to the GPS receiver's serial port. Accordingly, in a terminal:

  • sudo nano /etc/systemd/system/dbus-org.bluez.service
  • add " -C" to the end of "ExecStart=/usr/lib/bluetooth/bluetoothd"
  • add "ExecStartPost=/usr/bin/sdptool add SP" as the next line

After a reboot and restarting Bluetooth, run in a terminal:

  • sudo sdptool browse local

to check that a "Serial Port" with "Channel 1" is listed. Then connect to the Bluetooth part with:

  • sudo rfcomm watch hci0 1

If the RaspberryPi is listening for a connection on Bluetooth serial, the terminal should display "Waiting for connection on Channel 1" and when a Bluetooth connection to the Raspberry Pi is made: "Connection from XX:XX:XX:XX:XX to /dev/rfcomm0" is displayed.

A smartphone app such as Serial Bluetooth Terminal (currently Version 1.48) can be used to type smartphone terminal commands that are displayed in a new Raspberry Pi terminal using:

  • cat /dev/rfcomm0

At this stage it is wise to check that u-center on the Windows PC can acquire GPS observation data when the GPS receiver is connected to one of the RaspberryPi's USB ports. When the Drotek receiver is connected the u-blox F9P creates automatically a port called "/dev/ttyACM0". Check this using:

  • ls /dev/tty*
  • sudo cat /dev/ttyACM0

The receiver's output should be displayed on using the terminal command:

  • python -m serial.tools.miniterm /dev/ttyACM0

B5. GPSD

To connect the receiver's ttyACM0 to a serial port (often ttyAMA0 or ttyS0) gpsd is often needed but in fact does gpsd does not work with the PointPerfect NTRIP service (and many other NTRIP services) since a GNGGA message string (sentence) is needed to identify the receiver's position. The following is noted nevertheless.

  • sudo apt-get install gpsd gpsd-clients

Some processes (identified using the terminal "ps aux ¦ grep ttyS0") may need to be removed and it helps to stop and disable gpsd at boot:

  • sudo systemctl stop gpsd.socket
  • sudo systemctl disable gpsd.socket

gpsd is manually run in a terminal:

  • sudo gpsd /dev/serial0 -F /var/run/gpsd.sock

The terminal commands "gpsmon", "cgps", "xgps", and "gpspipe -r" should display receiver data.

But as noted, gpsd does not work with the PointPerfect NTRIP service.

In using a Bluetooth connection with a GNNS client such as Lefebure it is wise to check that the baud rates are the same for the serial and receiver ports and for the receiver's UART1 port (in u-center: UBX ⇒ CFG ⇒ PRT ⇒ Baudrate). Terminal settings can be checked with the terminal settings tool stty as follows:

  • sudo stty -F /dev/serial0 (the Bluetooth terminal created as above using "sudo rfcomm watch hci0 1")
  • sudo stty -F /dev/ttyACM0 (the terminal created on connecting the receiver)

Baudrates can set by specifying the rate, e.g.:

  • sudo stty -F /dev/serial0 38400

but there seems to no straightforward way to automatically set the baud rate for the serial ("serial0") and receiver ("ttyACM0") UART ports. So the default value is retained (9600) and receiver's UART1 port is configured accordingly.

B6. ser2net

PyGPSClient and pygnssutils.gnssntripclient both support the PointPerfect SPARTN NTRIP service and can return the required GNGGA sentence(s), formatted with either fixed reference coordinates or the live position from an active receiver.

In the meantime, u-centre on the Windows PC can be used as the client by setting up a u-center WiFi Network Connection. This requires redirecting the serial interface of the RaspberryPi to a network port by installing ser2net and editing or creating a "ser2net.conf" file:

  • apt install ser2net
  • sudo nano /etc/ser2net.conf

with the line

  • 6000:raw:600:/dev/ttyACM0:115200 NONE 1STOPBIT 8DATABITS XONXOFF LOCAL -RTSCTS

Starting ser2net followed by checking the interface with:

  • sudo ser2net -u
  • sudo netstat -ltnp | grep 6000

should display a message which refers to tcp6 output on port number 6000 and gives the process id (PID). The "-u" option disables UUID locking so that ser2net with a PID displayed as say "1234" can be stopped with:

  • sudo kill 1234

Other recipes have been proposed. None seem to work, including possibly the one proposed here. In the end one resorts to rebooting the RasberryPi in order to stop ser2net.

B7. str2str

An alternative to ser2net is the RTKLIB str2str. The advantage of str2str is that the NTRIP correction data can be streamed to the receiver with the corrected output streamed to a tcp/ip port. The str2str terminal command is of the form:

  • ./str2str -in ntrip://pp_username:pp_password@pp_hostname:pp_port/pp_mountpoint -out serial://ttyACM0:115200#50000 -b 1

The "pp_" parameters are for a -blox PointPerfect GNSS correction service or equivalent NTRIP account and the corrected output is streamed to TCP/IP port = 50000 (i.e., to the smartphone's hotspot, say 192.168.33.83:50000) thus making the corrected data available to the NTRIP client (e.g., Lefebure or GNSS Master) used to set the smartphone's mock location.

In our case, since correction data is being fed to the Drotek 601, the receiver's RTK status LED blinks while the RTK type is "float" and switches off when a "fix" is obtained. Similarly, the SW Maps, the colour for the position pointer changes colour when a "fix" is acheived (blue: regular GNSS fix; orange: RTK Float); green: RTK Fix).

The corrected data stream can be strated automatically on booting up the RaspberryPi. Several recipes have been demonstrated:

rc.local autostart edit rc.local (sudo nano /etc/rc.local") by adding:

  • cd /etc/usr/local
  • sudo ./str2str -in ntrip://pp_username:pp_password@pp_hostname:pp_port/pp_mountpoint -out serial://ttyACM0:115200#50000 -b 1

(note that "sudo" is need) to move to the str2str directory, which can of course be on a USB key that is mounted using a terminal command of the form:

  • sudo mount /dev/sda1 /media/usb -o uid=raspi,gid=raspi

register a bash file, say "ntrip-serial.sh", that starts corrected data streaming as an autostart file.

crontab with “crontab -e" to add the task:

  • @reboot sudo /etc/usr/local/str2str <statement above> &

B8. TCP/IP

For TCP/IP connections as opposed to Bluetooth:

  • u-center: when using u-center, create a Receiver ⇒ Connection ⇒ Network Connection ⇒ New of the form "tcp:192.168.x.y:6000" where the address is the address of the RaspberryPI and connect the receiver by selecting "Network connection" in the u-center "Select Receiver Port" dropdown. If the connection is via the smartphone's hotspot with for example "192.168.111.83" as the address the Network Connection address is say "tcp:192.168.111.83:6000" (the Windows PC will of course need to have its WiFi connection set to the smartphone's hotspot) . If the connection is via the RaspBerryPi's LAN WiFi address, say "192.168.1 222", the Network Address is "tcp:192.168.1.222:6000"
  • str2str: when using str2str with a NTRIP client app such as GNSS Master for a mock location, set the TCP connection address as the Raspberry Pi's LAN WiFi address (say "192.168.1 222:5000") or its hotspot address (say "192.168.112.83:5000") if the Raspberry Pi is connected to the smartphone's hotspot .

It seems that positioning corrections are applied if the receiver is configured with either the u-centre "Revert to default configuration" (i.e., connecting the receiver to a Windows PC USB port and setting Messages View ⇒ UBX ⇒ CFG ⇒ CFG ⇒ "Revert to default configuration" ⇒ Send) or the PyGPSclient's "RESTORE FACTORY DEFAULTS". The u-center default configuration can also be set when u-center uses a network connection instead of a USB connection. In this case, View ⇒ Configuration View ⇒ CFG (Configuration) ⇒ "Revert to default configuration" ⇒ Send must be used (i.e., use Confguration View instead of Messages View).

C. Commercial RT-PPP corrections

While using commercial RT-PPP correction services instead of the global and freely available HAS service is not our aim it is nevertheless useful to check the receiver set-up using a commercial service and adjust the set up so that EXIF position coordinate tags can be automatically, or at least easily, transferred to images taken at the base position. To date, only the PointPerfect correction service has been used (requires setting up a Thingstream account).

Once a RTK fix is established, for photos taken at the base position, the base coordinates can be noted or stamped as EXIF geo-tags if the camera allows (as is the case for Android streetmap and mapping apps mentioned above). The coordinates stored in a .jpg image can be adjusted if necessary using the JOSM OpenStreetMap editor with the photo_geotagging and photoadjust modules installed. On opening an image in JOSM, the "Geotagged Images" layer is set as active and "Edit" ⇒ "Edit photo GPS data" is selected in order to enter the base's latitude and longitude coordinates. A right click on "Geotagged Images" ⇒ "Write coordinates to image header" is then needed before the geo-tagged photo is uploaded to the Panoramax server.

Instead of noting or stamping the base-station's coordinates, a PyGPSclient log file can be saved in a directory called "data" for example. A webserver is then established using the terminal commands:

  • cd data
  • python3 -m http.server

such that the log file is available at the web address of the Raspberry Py web server ("http://192.168.1.222:8000" as an example). Of the many other alternatives for transferring files from a Raspberry Pi to a Windows PC WinSCP is recommended. The log file can also be streamed to a USB key. Once downloaded, the log file can be played using u-center on a Windows system to obtain the photo's latitude and longitude coordinates (displayed as Reference Position ⇒ Average in u-center's Deviation Map).

Another procedure (which can also be used for a series of geo-tagged photos) is to convert the .obs file to a .gpx file. The .gpx file is then edited in Notebook or a similar editor to create waypoints by replacing "trk" an the tags by "w" and deleting the <tk> and <trkseg> tags. Separately, JOSM preferences at Edit ⇒ Preferences ⇒ GPS Points ⇒ Waypoint labelling is set to "?{ '{time}' }" so that the time a geo-tagged photo was taken is displayed in JOSM beside each waypoint. The displayed waypoint times are then matched to the base-station's geo-tagged photo in order to set the base-station position in JOSM.

Yet another possibility stems from the fact that JOSM also allows interpolation of a photo's position using a GPS track.

At this point, since one is now talking about mapping, it is perhaps useful to point out that to determine the GPS coordinates of any measured point first requires the definition of a reference frame (a global network of accurately measured points with defined Cartesian coordinates). Moreover, in order to achieve meaningful centimetre or millimetre level accuracy, all components in the end-to-end application (including the GPS data source, maps and geo-referenced imagery) must use the same or related "plate-fixed" reference frame.

WGS84 is the reference system used by the Global Positioning System (GPS) and is the default reference datum used by ZED-F9P (see UBX-CFG-DATUM). WGS84 is regularly released to keep it coincident with the ITRF reference frame. The PointPerfect reference frame is ITRF2020 current epoch. WGS84 realisations since October 2018 are coincident with ITRF at the sub-centimetre level so while there are no official transformation parameters one can consider that ITRF2020 and WGS84 are likely to agree at the sub-centimetre level. Photos tagged using u-blox F9P observations can therefore be treated in JOSM in the same way as OpenStreetMap features.

The Galileo HAS system uses the Galileo Terrestrial Reference Frame (GTRF). For a given point, the difference between coordinates expressed in ITRF and GTRF is less than 3 cm.

D. Online post-processing correction

If real-time correction data is not available (in our case because a reasonably priced Internet mobile data connection is not available to receive HAS corrections) the GPS receiver's log file can be used for post-processing to obtain the base-station's position accurately. In this case, once a fix is achieved the PyGPSclient.log file is saved and downloaded to the Windows PC.

The file is then renamed as .ubx and the rtklib rtlconf executable is used to convert the .ubx log file with u-blox protocol to a .obs RINEX file (the u-blox F9P receiver's raw observation data is configured to supply UBX-RXM-RAWX data packets which are decoded and rendered as RINEX). As above, recommended is the demo5 version (the latest is demo5 b34k) of rtklib which has Windows executables (dated 11/9/2021 and synchronised up to the b34 versions of rtklib version 2.4.3). The RINEX observation file can then be uploaded to Canada's CSRS-PPP service or other similar services (APPS, AUSPOS, DGDPS, OPUS) to receive by email a CSRS-PPP report giving the corrected position of the base station.

To avoid the need for a Windows PC in the field, a solution would be to install u-center on the RasberryPi by first installing Wine. However, in the field it would probably be impactical to use a RealVNC desktop on a smartphone to manipulate u-center.

Nonetheless, it is worth noting that if a Windows PC is available in the field, instead of transfering the .ubx file from the RaspberryPi as described above, the Windows PC with u-center and a Bluetooth or TCP/IP hotspot connection to a RasberryPi connected to the GPS receiver can be used to configure a GPS receiver and collect GPS observation data. RTK corrections are then applied by post-processing (using either a real-time service with playback of the observation data or via online submission of the observation data).

E. HAS RTKLIB corrections

E1. BKG Ntrip Client

Using HAS corrections with RTKLIB requires the BKG NRIP Client (BNC) to retrieve state-space representation (SSR) correction data from the HAS Internet Data Distribution NTRIP service. BNC for the Raspberry Pi operating system (specifically for Debian 12 Bookworm) can be downloaded as a zip file. The simplest is to extract the zip and copy the contents of the bnc-2.13.1-raspi directory to say /home/user/bnc and change the name of bnc-2.13.1 to bnc. Then in a terminal:

  • cd /home/user/bnc
  • chmod +x bnc

A configuration file is needed to run BNC together with a HAS account (request for access). Installation of BNC gives examples of conguration files in the "Example_Configs" directory. Adding a configuration file for HAS called say "has.bnc" is executed using:

  • ./bnc --conf Example_Configs/has.bnc

A window is not displayed if a option "-nw" is added. An example configuration ("13_PPGalHAS.bnc") is included for HAS. BNC’s "Miscellaneous" tab is used to pull the HAS data stream and republish the raw (RTCM3) output at a TCP port. Appropriate "Miscellaneous" settings are:

  • Mountpoint: SSRA00EUH0
  • Log latency: 1 min
  • Scan: RTCM
  • Port: 9000

The mountpoint is the same as the HAS mountpoint which is included in the email message confirming registration to the Galileo HAS Internet Data Distribution and is used on adding a stream (see "Add Stream" menu item). Using "13_PPGalHAS.bnc", aside from the "miscIntr=1 min", "miscMount=SSRA00EUH0", "miscPort=9000", and "miscScanRTCM=2" entries and the "casterUrlList" and "mountPoints" entries the only important change is to set "ntripVersion=2s".

E2. RTKLIB

E2.1. Install command line RTKLIB apps

Installing the RTKLIB str2str is fairly straightforward. The latest RTKLIB "rtkexplorer demo 5" fork (b34k) is downloaded:

  • wget -qO - https://github.com/rtklibexplorer/RTKLIB/archive/refs/tags/b34j.tar.gz | tar -xvz

or cloned:

  • git clone /https://github.com/rtklibexplorer/RTKLIB.git

and the str2str compilation flags are set by editing the makefile in the directory "/home/user/RTKLIB/app/consapp/str2str/gcc"

The rtkexplorer version of RTKLIB is optimised for low-cost GNSS receivers, especially u-blox receivers. It is based on RTKLIB 2.4.3 and is kept reasonably closely synced to that branch.

The key statement is:

  • CTARGET = -mcpu=cortex-a52 -funsafe-math-optimizations

the terminal commands are:

  • cd /home/user/RTKLIB/app/consapp/str2str/gcc
  • make
  • sudo make install

The install command copies the str2str executable in the "gcc" directory to "/usr/local/bin".

Similarly for rtkrcv, the terminal commands are:

  • cd /home/user/RTKLIB/app/consapp/rtkrcv/gcc
  • make
  • sudo make install

str2str and rtkrcv are perhaps best used by copying the executables to "/home/user/rtklib"

E2.2. Install graphical user interface RTKLIB apps

RTKLIB includes versions of its apps that have graphical user interfaces (GUI). These apps are installed as folows:

  • cd /home/user/RTKLIB/app/qtapp
  • sudo apt install qt5-make
  • make
  • sudo make install

The "make" command may give rise to an error indicating that a serial port module is missing (e.g., "Project ERROR: Unknown module(s) in QT: core gui widgets serialport"). In this case, before runing the "make" command again, enter:

  • sudo apt.-get install libqt5serialport5-dev

The "sudo make install" comand simply copies executables to "/usr/local/bin". Once again, copying the executables to a directory such as "/home/user/rtklib" may be convenient.

The GUI versions a generally more useful if different configurations are being tested using RTKNAVI combimed with RTKPLOT. rtkrcv is the command line version of RTKNAVI that is executed when the positioning is being estimated using a smartphone with a microcomputer connected to a GPS receiver. rtkrcv terminal commands options are of the form (see manual):

./rtkrcv [-s] [-nc] [-p monitor_port] [-o config_file] [-w password] [-r solution_status] [t -trace_level] [-sta DCB_station]

and there are a series of terminal commands (start/stop/restart, etc).

F. RTKLIB HAS processing

The starting point GNSS positioning has been to use the RTKLIB "f9p_ppp_kin.conf" configuration file given in the RTKLIB demo5 b34k download. Details of changes will not be described at this stage except to say that appropriate files were used for Satellite and Receiver antenna (.PCV), for DCB and EOP data and for Ocean Loading (.BLQ). For input:

  • Rover: Serial (Port: ACM0; Bitrate: 115200)
  • Base Station: NTRIP Client (NTRIP Caster Address: products.igs-ip.net; Port: 2101; Mountpoint: BCEP00BKG0)
  • Correction: TCP Client (Server Address:localhost; Port: 9000)

Ground tracks monitored in RTKPLOT when using "PPP Kinematic" as the RTKNAVI "Positioning Mode" were extrmely noisy, although convergence was often possible. We decided instead to focus on "PPP Static" which gave convergence - at least visually in terms of North-South and East-West position profiles - in approximately 30 minutes. The standard deviations mentioned above were achieved routinely. The postioning error was at most 300 cm based on the swisstopo swissImage orthophoto aerial mosaic with a ground resolution of 10 cm and a positioning standard deviation (1 sigma) of 150 cm. Observations at a nearby swisstopo Planimetric Control Point are needed to establish a more accurate estimate of the positioning error.

With a local TCP/IP network available, a smartphone's mock position could be established by having the Raspberry Pi's (TCP Address: 192.168.1.123) RTKNAVI output as a .pos positioning file in (NMEA0183 format) which was the input to STRSVR. The STRSVR output was specified as "TCP Server" with a port number (say "9004"). The smartphone's GNSS Master app's receiver was set to:

  • TCP Address: 192.168.1.123
  • TCP Port: 9004

Images (.jpg) taken at the Panoramx base-station location using Mapillary for Android, Baba and OpenCamera are EXIF geo-tagged with the mock location data in the Degrees - Minutes - Seconds (DMS) format; SW Maps images are not geo-tagged. Mapillary and Baba images are tagged accurately to 6 decimal places and OpenCamera to only four decimal places.

To avoid using a local area network, the smartphone's hotspot can be used to stream HAS connection data and a broadcast ephemeris stream (the IGS BCEP00BKG0 stream in our case, for example) to the Raspberry Pi and the Raspberry Pi's RTKNAVI output (once again in the NMEA0183 format) to the smartphone to set the base station's mock position. The only change is to replace the Raspberry Pi's IP address (192.168.1.123) on the local area network with the IP address of the smartphone's hotspot (an address of the form 192.168.x.83 in our case).

The main problem in using a hotspot instead of a local area network is that the mock location for the Baba app (but not for Mapillary and SW Maps) cycled between the true position and another position every few seconds. Adjusting the STRSVR settings changed the cycle frequency but a setting that suppressed the cycling has not been found.

G. Base station summary

Pending discussion of base-rover RTK-PPP positioning, the discussion so far has described how the accurate geo-tagging of photos taken at a specific position (called a base station position) can be carried out using a simple kit comprising:

  • a smartphone (Pixel 4a) having available a mobile data Internet connection and access to an Internet-distributed GPS correction service (PointPerfect);
  • a low-cost GPS receiver (Drotex DP0601 connected to a Drotek DA09011 survey antenna or a u-blox ANN-MB2-00 patch antenna);
  • a small computer (RaspberryPi 3B+) with on-board wireless networking (WiFi);
  • a low-cost smartphone power bank (SBS) to power the RaspberryPi and the GPS receiver.

Preliminaries

  • the RaspberryPi has been configured after connecting it to a monitor, keyboard and mouse (automatic WiFi hotspot);
  • the RaspberryPi hotspot address (e.g., 192.168.111.83) is known using the RasberryPi's desktop WiFi dropdown or an Android app such as Network Analyzer;
  • the receiver has been configured using u-center or PyGPSclient default/factoryconfiguration;
  • putting aside the use of an online correction service, either in real-time or for the submission of data for post-processing, the BNC Raspberry Pi app is used to stream correction data to RTKNAVI (or its command-line equivalent RTLRCV);

Pixel 4a

If positioning correction is processed by the GPS receiver so that a smartphone's mock location provider for a camera app can geo-tag images:

-- PyGPSclient

  • open a RaspberryPi terminal
  • enter "cd /pygpsclient" (location of PyGPSclient)
  • enter "source bin/activate"
  • enter "pygpsclient"
  • select UBS/UART (to start GPS observation data collection and saving of a .ubx file in a "data" directory)
  • select NTRIP Client and select arrow icon to start
  • once a RTK fix is indicated, note the coordinates displayed in View ⇒ Scatter Plot window
  • open a webserver ("python3 -m http.server") and download the .ubx file for post-processing correction.

-- str2str

  • open a RaspberryPi terminal
  • execute the RasberryPi str2str command to stream corrected observation data to the smartphone.

If positioning correction is not carried out by the GPS receiver:

  • The RVNC Viewer app manipulates the RaspberryPi so that RTKNAVI positioning data can be used to geo-tag images. It is unclear whether there is a reasonably simple procedure. If not, it will be necessary to tag images manually.

29 January 2025

PeterBoswell.com