RTK Torch Accuracy Verification

[orrious]

I have a RTK Torch, SW Maps, and have GEOID18 Grid #7 be loaded.

I was following the Accuracy Verification - SparkFun RTK Product Manual document to ensure everything was configured properly with my setup and am not getting the results I expect.

The more I learn about GIS, the more I realize just how little I know, so please forgive me.

I expect to see ELLIP. HT. NAD 83(2011) -4.873 m to WSG84 -6.420 m however the RTK Torch is reporting -4.828 m.

RTK Torch is configured internally to report Tip Altitude and the instrument height of 2.0m. SW Maps was configured for 0 m and 2.0 m for different readings.

Steps I performed:

1.) Used NGS Data Explorer to find the nearest monument

 AB5488 ***********************************************************************
 AB5488  DESIGNATION -  95 058
 AB5488  PID         -  AB5488
 AB5488  STATE/COUNTY-  FL/OSCEOLA
 AB5488  COUNTRY     -  US
 AB5488  USGS QUAD   -  ASHTON (2018)
 AB5488
 AB5488                         *CURRENT SURVEY CONTROL
 AB5488  ______________________________________________________________________
 AB5488* NAD 83(2011) POSITION- 28 12 50.66702(N) 081 14 37.85304(W)   ADJUSTED
 AB5488* NAD 83(2011) ELLIP HT-    -4.873 (meters)        (06/27/12)   ADJUSTED
 AB5488* NAD 83(2011) EPOCH   -  2010.00
 AB5488* NAVD 88 ORTHO HEIGHT -    23.1   (meters)       76.    (feet) GPS OBS
 AB5488  ______________________________________________________________________
 AB5488  NAVD 88 orthometric height was determined with geoid model    GEOID93
 AB5488  GEOID HEIGHT    -        -28.825 (meters)                     GEOID93
 AB5488  GEOID HEIGHT    -        -27.970 (meters)                     GEOID18
 AB5488  NAD 83(2011) X  -    856,220.766 (meters)                     COMP
 AB5488  NAD 83(2011) Y  - -5,558,985.741 (meters)                     COMP
 AB5488  NAD 83(2011) Z  -  2,997,429.124 (meters)                     COMP
 AB5488  LAPLACE CORR    -         -1.07  (seconds)                    DEFLEC18
 AB5488
 AB5488  Network accuracy estimates per FGDC Geospatial Positioning Accuracy
 AB5488  Standards:
 AB5488         FGDC (95% conf, cm)     Standard deviation (cm)     CorrNE
 AB5488            Horiz  Ellip           SD_N   SD_E   SD_h      (unitless)
 AB5488  -------------------------------------------------------------------
 AB5488  NETWORK    1.49   1.90           0.64   0.58   0.97      0.03361225
 AB5488  -------------------------------------------------------------------

2.) Used Horizontal Time-Dependent Positioning.

HTDP Output
 ****************************************
 HTDP OUTPUT, VERSION 3.5.0   

 TRANSFORMING POSITIONS FROM NAD_83(2011/CORS96/2007) (EPOCH = 06-27-2012 (2012.4863))
                          TO WGS84(G2139)             (EPOCH = 03-26-2025 (2025.2301))

                         
  LATITUDE     28 12 50.66702 N     28 12 50.68857 N       -0.78 mm/yr  north
  LONGITUDE    81 14 37.85304 W     81 14 37.87700 W        1.29 mm/yr  east
  ELLIP. HT.              -4.873              -6.420 m     -0.66 mm/yr  up
  X                   856220.766          856219.865 m      1.24 mm/yr
  Y                 -5558985.741        -5558984.183 m      0.41 mm/yr
  Z                  2997429.124         2997428.978 m     -1.00 mm/yr

3.) Survey results from SW Maps with RTK FIX

lat	lon	elv	ortho_ht	instrument_ht	fix_quality	accuracy_h	accuracy_v
28.214074896	-81.243848496	-4.821	23.132	0	4	0.009	0.021
28.214074737	-81.243848642	-4.828	23.125	0	4	0.009	0.022
28.214074746	-81.243848635	-6.838	21.116	2	4	0.009	0.021
28.214074745	-81.243848633	-6.839	21.115	2	4	0.009	0.021

[orrious]

The NTRIP I’m using is FPRN which uses NAD(83)-(2011)-(Epoch 2010.0000) as its datum. I’ve read that the datum the NTRIP provides is the datum the GNSS receiver (UM980) emits.

I have been converting everything to WGS84, potentially incorrectly? Is the elevation coming from the Torch in NAD(83) or WGS84 datum?

[rftop]

Since your control and correction source are both in NAD83(2010), I don’t see a need in converting to WGS84.

Considering the “Network Adjusted” Position as the truth, you’re looking to see how close your solution is to an Ellipsoid Height of -4.873m.
[The Geoid’s don’t factor into the comparison of Height above Ellipsoid, only Ortho]

Facet (w/ SW Maps) = -4.825m (average of your 2 data points)
The Delta is 48mm, or your reported position is <2" Higher than the published control for AB5488.

I’d consider that Good Results for a small Helical Antenna without a NGS Calibration.

Looking at the Control Point, I see it’s a Horizontal Control Only.
The Ellipsoid Height Accuracy is listed as 1.90cm, or 19mm.

I’d try a 1’st Order Combined Station if you want to dig a little deeper.
I see lots of them close to ya.

But you are getting into the realm where you need the electrical phase center for the antenna (from NGS Calibration), and careful field procedures.

I think you absolutely “nailed it” given the circumstances mentioned above

[orrious]

1.) 116mm is the phase center of the RTK Torch and is set accurately in the configuration.

2.) I’ll absolutely try this again with a Combined Control!

3.) For the vast majority of the time, the NTRIP will be FPRN which uses NAD(83)-(2011).

Looking at the GeoPKG that SW Maps exports, table st_geometry_columns shows that the tables are in 4326:WGS 84 geodetic, elevations appear to be in NAD83(2011). Are horizontal coordinates in NAD(83)-(2011) or 4326:WGS 84 geodetic?

[rftop]

116mm is the Mechanical Phase Center, not the electrical/RF phase center. I’m not sure if NGS will model a helical antenna these days ?

[orrious]

This makes sense.

1.) From what I’ve been reading, the Torch outputs EPSG:4326 (WGS84) datum normally.

2.) If the Torch connects to a RTCM3 source, could be via NTRIP, that uses a different datum, the Torch then switches to the base’s datum NAD83(2011) for my case with FPRN.

3.) I assume and would like to get confirmation that this happens when it achieves RTK FIX with the base.

4.) To further complicate things, even though RTCM3 messages 1005 and 1006 support transmitting the datum in protocol, no one does this.
The datum field is not used/defined, which often leads to confusion if a local datum is used

@AvinabMalla if the RTCM3 messages that SW Maps passes does not contain the local datum, how does SW Maps know how to represent the coordinates? Since the datum is not based on the GNSS receiver, it would seem the NTRIP configuration section would be a good place to set the datum per NTRIP source.

I further notice that SW Maps 3.0 (only Andriod version has Project Settings) EPSG:6349 is not supported. Can you help me understand what the requirements for EPSGs are?

Thanks everyone!

[rftop]

Your assumptions and statements align with my understanding.

When a GNSS device receives (and uses) a RTK correction, it’s actually getting Observation Data from the Base. The RTK position has no choice but to now be in the same Reference Frame that the Base Station is using.

That’s a big reason why you can have a DGPS position that has stabilized and appears pretty “still”. A couple seconds after you connect to NTRIP and receive a RTCM correction, the position will jump ~1meter into RTK Fixed. That’s the Reference Frame IMHO (mostly). The Rover’s Raw Data from the Satellites didn’t change.

[orrious]

@rftop would you agree the NTRIP section would be the best place to configure the datum then, as it will change per correction source?

I can really see this messing folks up if they don’t know what datum their coordinates are in.

[rftop]

@orrious

@rftop would you agree the NTRIP section would be the best place to configure the datum then, as it will change per correction source?

Not exactly, due to the various ways we consume RTK corrections.
Lots of delivery methods like: NTRIP, MQTT over IP, Sub-GHz Radios, 2.4GHz radios, etc.

Proper Field Collection requires training, or you learn through experience (the hard way)…usually some of both

I started out with GPS in a professional setting in 1996 and I generally learn something new every day.

@orrious

I can really see this messing folks up if they don’t know what datum their coordinates are in.

Yes it does. Metadata helps with that, and data validation.

I also have an account with the Florida RTN (FPRN) and have started using it in the past couple of months. When using SW Maps, I set the Minimum Fix Quality to RTK FIX, so I know any position stored is in NAD83(2011, 2010 epoch) when I connect to FPRN, which is also what most State networks are.

The same goes for other sources, such as PointPerfect. I know those positions are ITRF.

If I was Surveying for an Engineering Project, I’d be using a data collector with Surveying Software and I would setup the project in any system that I wanted - which would typically be SPCS… and not collecting with SW Maps that day.

If I happened to need points from SW Maps transformed into a different system, I’d do that in AutoCAD.

[orrious]

My background is in IT product development and I dabble a bit in CAD. Recently purchased vacant land and need a repeatable / accurate way of going between CAD and the physical world. I’ve been doing it manually for too many years and the RTK Torch was so reasonably priced, it will cost me more in the long run not to have it.

That said, I’ve been using QGIS to project from one datum to another and export to AutoCAD and FreeCAD. I’m in the process of writing some python to extract the SW Maps data, run it through QGIS for datum projection, and export as DXF in inches.

Then the opposite direction. AutoCAD / FreeCAD → QGIS → geoPKG → google drive → SW Maps.

Even thought it’s not ideal, I’ll add a custom attribute to the layer to let my python script know that the coordinates captured are in NAD83(2011, 2010 epoch) . I’ll fix it before QGIS gets it. It needs to be in EPSG:2236 and rescaled from feet to inches before it goes to DXF anyways.

Having SW Maps capture the from GNSS in the right datum and record it with the layer in the project would just make it easier.

[rftop]

I dont use FreeCad, but I assume it will let you import a points file (.txt etc).
Will it also let you use a projection (.prj) file for the import ?
If so, that would be simple.

Depending on your version of AutoCAD, the same can be done.
SW Maps Export straight into AC.

[orrious]

AutoCAD is my go to for 2D. I tend to use FreeCAD or SolidWorks for 3D. I’m pushing more towards FreeCAD as I’m planning on synchronizing the point cloud ODM (Open Drone Map) generates with the reference points I get from the Torch, which is all 3D.

[AORPLS]

If you really want to know the why and how of some of this stuff I suggest reading GNSS surveying by Jan Van Sickle. But heres the thing when using cors network you have to calibrate to some known benchmarks. I work for a city as a surveyor and we calibrated about 20 or so benchmarks to give us a city wide site calibration. We get a couple hundredths when we go check ones we did not tie. Vertical with GPS is also a hit or miss.

This brings another good thing to light while the torch is cool since it does not have an NGS calibration you can’t say do high precision static with it.

[gdt]

I think you’re mostly straightened out (and I broadly concur with rftop), but a key point is that coordinates can be in one datum but labeled in another. And, SW Map does not deal with this well at all, is my understanding. You will get data that says it is in WGS84 but really it will be in the frame of the RTCM source, 6319.

Without differential, and without multiple constellations, GPS receivers output in WGS84. But they do not output in 4326. They output in a particular realization, the one that is at that moment in use by the GPS Control Segment. Saying 4326 formally means "my coordinates are in one of a set of 8 or so datums called WGS84 and I do not know which one.

It is not so much that the receiver “switches” as that any differential solution is implicitly in the reference frame of the base station’s coordinates. Yes, a program that gets NTRIP data (including the SF firmware) should be able to label the datum.

You will need to be able to relabel (not transform!) the data from the wrongly-applied 4326 to 6319.

As for phase center, in an ideal world there would be ANTCAL data and you would load that into the receiver which would use it i the solution so that the coordinates it outputs would be those of the ARP. Or the mark, depending on where you configure the ARP-mark offset. What you need is an average APC-ARP offset so that on balance the coordinates that come out are the ARP. I have found that when taking the L1 and L2 APC offsets and averaging them, it’s pretty reasonable, but further study is needed. I’m not quite clear on what you are putting in for vertical offset.

Once you are talking 2 cm in height, you have succeeded. Keep in mind that due to geometry vertical errors tend to be 2x, at least, horizontal errors. If you want to do better, you’ll need equipment that uses ANTCAL files – and not a helical antenna. Then you’ll need hours of static occupation, or hours of RTK that’s averaged.

[gdt]

If you are trying to figure out GNSS accuracy the right thing to do is work in HAE and to stay in your regional plate-fixed datum so the data sheets and your positions should match.

Humans do not think in terms of HAE. We talk loosely about “above sea level” and formally that is “orthometric height in datum X”. For you (and me), today, that datum is NAVD88, which has some distortions but basically water flows from higher to lower NAVD88 elevations. To convert from NAD83 HAE to NAVD88 you use a geoid model. This will have limited accuracy, because it’s measured, and because NAVD88 itself has lower accuracy because it was based on leveling measurements taken before 1988. If you need heights for water analysis, you need it, but if you are trying to understand RTK performance it is just confounding. I personally am recording 3d points in 6319, not in NAVD88, and will transform later, so my source data remains as accurate as possible. Today I was visualizing LIDAR elevations which I think has been transformed to NAVD88 to understand stream and swamp drainage.

[orrious]

I’m not quite clear on what you are putting in for vertical offset.

Within the RTK Torch settings > Instrument Setup

Menu: Instrument Setup
Combined Height of Instrument: 2.116m
1) Set Antenna Height (a.k.a. Pole Length): 2.000m
2) Set Antenna Phase Center (a.k.a. ARP): 116.0mm
3) Report Tip Altitude: Enabled
4) Tilt Compensation: Enabled

116mm is the recommended ARP for the Torch and I set my pole to 2m. Within SW Maps I set the pole height to zero (0).

I think I grok what you’ve said. Let me see if I can apply it.

• CORS and specifically FPRN uses NAD(83)-(2011)-(Epoch 2010.0000) as it’s datum. Elevation is from Ellipsoid GRS80.
• NAD(83)-(2011)-(Epoch 2010.0000) is EPSG:6319, which does not include NAVD88 or GEOID18 ortho
• When using FPRN as NTRIP source and in RTK FIX, datum will be NAD(83)-(2011)-(Epoch 2010.0000) / EPSG:6319 from the RTK Torch
• SW Maps allows me to load GEOID18 corrections and store ortho heights along side elevation
• SW Maps 3.0 does allow users to select project datums, but EPSG:6319 is not recognized
• When exporting project as GeoPKG or SW own format, both are in sqlite3 databases.
• with python, without transforming, from ‘gpkg_contents’ table, change the ‘srs_id’ from 4326 to 6319 for any layers that have been captured, including Photos
• When importing the GeoPKG into QGIS, it now imports as EPSG:6319. I can either use the NAV88/GEOID18 ortho heights from SW Maps or I can apply needed transforms in QGIS

[gdt]

I think you have it right, with a few nits:

• the menu is confused about line 2 being ARP. ARP stands for Antenna Reference Point and it is not a length. It is a phsyical location on the antenna, and is almost always “Bottom of Antenna mount”. This line item surely means “APC - ARP”, or the distance from the ARP to the phase center. Likewise item 1 should be “ARP - tip”, which is pole height. but not to top of thread, but to Bottom of Antenna mount. Except it’s not antenna, it’s ‘torch’.
• “elevation is from ellipsoid GRS80”. This is off because ellipsoids are a shape and don’t have a position. NAD83 uses GRS80 but the point is that it defines the orientation/position. So “reported heights are HAE in NAD83(2011)” is the right way to say it.
• indeed 6319 is pure NAD83(2011), with HAE
• Even in RTK float still the same datum, but then you shouldn’t believe heights to better than a meter or two, maybe 3 or more.
• project datum in SW maps or qgis is different from “treat incoming coordinates as some datum”. But SW maps can’t do that either

My approach would be just capture in 6319 and don’t mess with geoid models in SW Maps (or QField, in my case, as I avoid proprietary software), and do what you need to do in QGIS.

Finally, I don’t believe that the 116mm has been adequately established experimentally and documented (but send me a link if I’m wrong). Antenna phase centers have varying offsets by elevation and azimuth and that’s what NGS ANTCAL is about. When you use an antenna without an ANTCAL file (because it doesn’t have one, or because your receiver can’t accept them), then you put in a single value that is in lieu proper processing, and ideally it would be an average of the effects over the typical az/el that you get in practice. That’s what I meant by experimental validation, to establish HAE/horizontal of a mark with actual professional/calibrated equipment using static processing, and then to measure with the torch in RTK over say 8h, and see what offset minimizes RMS height error.

[rftop]

Lots of great information in @gdt 's posts in this thread

Everyone should take note of this:

@gdt

Once you are talking 2 cm in height, you have succeeded.

Especially considering the Station used for evaluation was a Horizontal Only Control Point.

Even when we use a Combined or a Vertical NGS Control Point, it’s important to remember these are Network Adjusted Positions. That means the Network of Points are all adjusted to establish a system of physical reference. “Adjustment” means the original calculated coordinates are updated/changed during the process.

@orrious , That’s why I also said “You nailed it”.
IE: A Lab-Grade Choke Ring Antenna and very long occupation times over many days/missions won’t exactly match the NGS Published “Adjusted” Coordinates…because the published coordinates are moved during the least-squares adjustment as part of a complete Network of Points. That’s required to establish any physical reference system. It spreads the Total error across measurements, and can be based on the confidence of individual measurements.

A least-squares adjustment is even used on a 1-acre property survey.

[orrious]

In case anyone is interested. Here is a python script that will take an input geopkg in EPSG:4326 and output a re-labeled geopkg in EPSG:6319. This does not transform nor reproject the coordinates.

#!/usr/bin/env python3
import sqlite3
import argparse
import shutil

EPSG6319 = {'srs_name': 'NAD83(2011)', 
            'srs_id': 6319,  
            'organization': 'EPSG', 
            'organization_coordsys_id': 6319, 
            'definition': 'GEOGCRS["NAD83(2011)",DATUM["NAD83 (National Spatial Reference System 2011)",ELLIPSOID["GRS 1980",6378137,298.257222101,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],CS[ellipsoidal,3],AXIS["geodetic latitude (Lat)",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],AXIS["geodetic longitude (Lon)",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],AXIS["ellipsoidal height (h)",up,ORDER[3],LENGTHUNIT["metre",1]],USAGE[SCOPE["Geodesy."],AREA["Puerto Rico - onshore and offshore. United States (USA) onshore and offshore - Alabama; Alaska; Arizona; Arkansas; California; Colorado; Connecticut; Delaware; Florida; Georgia; Idaho; Illinois; Indiana; Iowa; Kansas; Kentucky; Louisiana; Maine; Maryland; Massachusetts; Michigan; Minnesota; Mississippi; Missouri; Montana; Nebraska; Nevada; New Hampshire; New Jersey; New Mexico; New York; North Carolina; North Dakota; Ohio; Oklahoma; Oregon; Pennsylvania; Rhode Island; South Carolina; South Dakota; Tennessee; Texas; Utah; Vermont; Virginia; Washington; West Virginia; Wisconsin; Wyoming. US Virgin Islands - onshore and offshore."],BBOX[14.92,167.65,74.71,-63.88]],ID["EPSG",6319]]',
            'description': "NAD83(2011) is a geodetic reference system. It is based on the GRS 1980 ellipsoid."}

parser = argparse.ArgumentParser(description="Relabel GeoPackage from EPSG:4326 with EPSG:6319. This does not transform or reproject the data, it only updates the metadata.")
parser.add_argument("-i", "--input", required=True, help="Path to the input GeoPackage file.")
parser.add_argument("-o", "--output", required=True, help="Path to the output GeoPackage file.")
args = parser.parse_args()
shutil.copy(args.input, args.output)
conn = sqlite3.connect(args.output)
cursor = conn.cursor()
insert_query = """
INSERT INTO gpkg_spatial_ref_sys (srs_name, srs_id, organization, organization_coordsys_id, definition, description)
VALUES (?, ?, ?, ?, ?, ?)
"""
values = (
    EPSG6319["srs_name"],
    EPSG6319["srs_id"],
    EPSG6319["organization"],
    EPSG6319["organization_coordsys_id"],
    EPSG6319["definition"],
    EPSG6319["description"] 
)
cursor.execute(insert_query, values)
cursor.execute("SELECT COUNT(*) FROM gpkg_contents WHERE srs_id = 4326")
rows_to_update_contents = cursor.fetchone()[0]
cursor.execute("UPDATE gpkg_contents SET srs_id = 6319 WHERE srs_id = 4326")
print(f"Rows updated in 'gpkg_contents': {rows_to_update_contents}")
cursor.execute("SELECT COUNT(*) FROM gpkg_geometry_columns WHERE srs_id = 4326")
rows_to_update_geometry_columns = cursor.fetchone()[0]
cursor.execute("UPDATE gpkg_geometry_columns SET srs_id = 6319 WHERE srs_id = 4326")
print(f"Rows updated in 'gpkg_geometry_columns': {rows_to_update_geometry_columns}")
cursor.execute("DELETE FROM gpkg_spatial_ref_sys WHERE srs_id = 4326")
conn.commit()
conn.close()

I wasn’t aware of QField previously, thanks @gdt. I’m already a QGIS user, so this seems like a better solution moving forward.

[gdt]

QField has a lot of rough edges. Notably, there is support for persistent tracklogging recently, and while that’s useful, there are significant bugs (see the tracker and look for issues I filed :-). I don’t think it’s any more troubled than SW Maps, and it’s Free Software, so you should be able to make it better, and keep using it should upstream stop maintaining it.

I find it really unfortunate that SparkFun recommends proprietary software. As the SimpleMobileTools debacle shows, proprietary software is fundamentally unreliable over the long term. In the case of SMT, the apps were Free Software, and they live on (uninfested) as a community fork Fossify. (That’s not an accusation about SW Maps right now; it’s a comment about the structural situation.)