RTK Torch: Local base station corrections vs Point Perfect

GPS/GNSS Enclosed Products
1

I bought an RTK Torch recently and have been wondering about how it will perform with corrections coming from a local base station vs corrections from PointPerfect. I’m sharing my results so that they might help someone else. I also have questions about the results.

I have a base station based on an RTK Surveyor and TOP106 dual-band GPS antenna. I used PPP and 24 hours of data to determine its location. It’s acting as an NTRIP server and is casting corrections through rtk2go. The base station is about 26 meters from my test location.

I set up the Torch to receive NTRIP corrections from the base station and put it at the test location. Once it connected to my wifi network, it moved quickly into RTK Fix mode. The latitude and longitude error read 11 mm and the “age of differential data” was almost always 2 seconds. I averaged 50 readings and captured this location result: 30.52999699417858,-97.70260421030356.

Then I set up the Torch to receive corrections from PointPerfect and put it at the same test location (+/- 1 mm). It said that the fix type was Single until the first PointPerfect corrections were received and then the fix type changed to DGPS. In about a minute the fix type changed to RTK Float and, about five minutes later, changed to RTK Fix. The latitude and longitude error read 14 mm and the age of differential data varied between 5 seconds and 12 seconds. About a minute after the fix type became RTK Fix, I averaged 50 readings and captured this location result:

30.529997691258917,-97.70260388406844.

According to this set of GPS calculators: https://www.gpsvisualizer.com/calculators, the distance between these location readings is 0.27 inches or 8 cm.

My questions:

  1. Why did it take so long for the PointPerfect corrections to result in a fix type of RTK Fix? Is this related to the long “age of differential data” intervals that I saw?

  2. For my application, 8 cm is big measurement difference. The PointPerfect website says I should expect an accuracy of 3 to 6 cm. Is the 8 cm difference I measured ‘normal’?

2

PointPerfect Orbit and Clock corrections are sent every 5 seconds, but Atmospheric Corrections are sent every 30 seconds.

I Consider PP to be a “every 30 seconds” correction source.

If we were to assume/pretend that your base station coordinates are 100% accurate - then a PointPerfect (PP) Rover using a LONG baseline covering a large region getting within 8cm (3") of the Rover using a local base with a 26meter baseline isn’t hard for me to believe. You are dealing with 2 independent Systems.

It does feel like you are on the wrong end of the bell curve for this pair of measurements “hopefully”… but it doesn’t sound unreasonable to me personally.

A local base/rover combo is preferable. PointPerfect fills in the gaps when that’s not a option or for cases where the Ease-of-Use outweighs the difference in apparent accuracy. To me, it just depends on what you are using the positions for.

3

Jim,

1. Why did it take so long for the PointPerfect corrections to result in a fix type of RTK Fix? Is this related to the long “age of differential data” intervals that I saw?

This is something that I’ve noticed as well; always at least a 2 minute Time To First Fix difference between L-Band and IP based PointPerfect. I’ve had suspicions that it is related to network latency (less about internet speed, more about latency in how PointPerfect generates the SPARTN correction packets to be sent via MQTT), but it has proved difficult to test for causation. This would be a good question for the ublox forum; we have it on a list of items to ask them about as well.

2. For my application, 8 cm is big measurement difference. The PointPerfect website says I should expect an accuracy of 3 to 6 cm. Is the 8 cm difference I measured ‘normal’?

I believe what you are seeing is the difference between reference frames (datums), though many factors can influence accuracy at this scale. The default datum on the RTK Surveyor (ZED F9P receiver) is WGS84, while the datum used by PointPerfect is ITRF2020. To further complicate things, the USGS’s free PPP service (OPUS) operates using NAD83, while Canada’s CSRS-PPP service uses IGS20, so the measurements you are seeing really depend on your setup and process. The difference between datums in a fixed location can range anywhere between < 1mm and >5m, depending on the datums and the location. I wish I had a stronger answer here, but the minutiae of how each reference system interacts with each other system is a bit beyond my knowledge.

Below are some useful links for pinning down which datum is used where.

https://www.icsm.gov.au/education/funda … illimetres.

https://portal.u-blox.com/s/question/0D … er-rtk-fix

https://portal.u-blox.com/s/question/0D … orrections

4

Hi Jim,

I’m from the UK, so your “0.27 inches or 8 cm” jumped out at me. I knocked up some python just to check the numbers. It’s 0.27 feet or 8cm…

Here’s the code I came up with. The standard great-circle distance formula works great for large distances. For small distances, that rounds to zero and haversines are needed.

import math
import argparse
from haversine import haversine, Unit

def greatCircleDistance(lat1, lon1, lat2, lon2):
    # https://en.wikipedia.org/wiki/Great-circle_distance
    lat1_radians = math.radians(lat1)
    lon1_radians = math.radians(lon1)
    lat2_radians = math.radians(lat2)
    lon2_radians = math.radians(lon2)
    delta_lon = lon1_radians - lon2_radians
    cos_delta_lon = math.cos(delta_lon)
    sin_lat1 = math.sin(lat1_radians)
    cos_lat1 = math.cos(lat1_radians)
    sin_lat2 = math.sin(lat2_radians)
    cos_lat2 = math.cos(lat2_radians)
    central_angle = math.acos((sin_lat1 * sin_lat2) + (cos_lat1 * cos_lat2 * cos_delta_lon))
    earth_radius = 6371008.8
    distance = earth_radius * central_angle
    return distance

def greatCircleDistanceHaversine(lat1, lon1, lat2, lon2):
    return haversine((lat1, lon1), (lat2, lon2), unit=Unit.METERS)

if __name__ == '__main__':
    
    parser = argparse.ArgumentParser(
        description='Great Circle Distance Calculator')

    parser.add_argument('-lat1', dest='lat1', default=30.52999699417858, type=float,
                        help='Latitude 1 in Degrees')

    parser.add_argument('-lon1', dest='lon1', default=-97.70260421030356, type=float,
                        help='Longitude 1 in Degrees')

    parser.add_argument('-lat2', dest='lat2', default=30.529997691258917, type=float,
                        help='Latitude 2 in Degrees')

    parser.add_argument('-lon2', dest='lon2', default=-97.70260388406844, type=float,
                        help='Longitude 2 in Degrees')

    args = parser.parse_args()

    print("{:.4f}m".format(greatCircleDistance(args.lat1,args.lon1,args.lat2,args.lon2)))
    print("{:.4f}m".format(greatCircleDistanceHaversine(args.lat1,args.lon1,args.lat2,args.lon2)))

The output is:

0.0000m

0.0836m

Now, this will (probably) spark another discussion about datums and geoids. Looking at the haversine source, they’re using _AVG_EARTH_RADIUS_KM = 6371.0088. Strictly, that radius should be adjusted to match your preferred datum at your position… :smiley:

https://github.com/mapado/haversine/blo … versine.py

Best wishes,

Paul

5

+1 to @swells comment below;

I believe what you are seeing is the difference between reference frames (datums), though many factors can influence accuracy at this scale. The default datum on the RTK Surveyor (ZED F9P receiver) is WGS84, while the datum used by PointPerfect is ITRF2020. To further complicate things, the USGS’s free PPP service (OPUS) operates using NAD83, while Canada’s CSRS-PPP service uses IGS20,

6

I confess that I’ve been avoiding the topic of datums and hoping it would all work out OK. When I set up my base station, I gave it ECEF coordinates that I obtained from CSRS-PPP after collecting and processing 24 hours of base station data. I selected the Static and ITRF options when processing the data. From the CSRS-PPP website:

Beginning with GNSS observations collected on Sunday, 27 November 2022, CSRS-PPP will output ITRF solutions in the IGS20 reference frame. This new reference frame is the International GNSS Service (IGS) realization of ITRF2020.

My interpretation of that is that the datum of my RTK base station is ITRF2020 and that locations I collect using my RTK rover will also use the ITRF2020 datum. Is this right?

7

Jim,

You aren’t alone it that; it is a really complex topic, and hard to get a good understanding without some formal training.

My interpretation of that is that the datum of my RTK base station is ITRF2020 and that locations I collect using my RTK rover will also use the ITRF2020 datum. Is this right?

This sounds correct to me. PointPerfect explicitly states ITRF2020; the IGS20 that CSRS operates in is built on ITRF2020, so I expect it to be closer than 8cm.