RTK Express Accuracy with and w/o RTK Corrections

So I just received my RTK Express kit. The first thing I did was make a few laps of my property, using SW Maps to record my track with just my phone’s GPS, the RTK Express without corrections, and the RTK Express with corrections from RTK2Go (the base station is roughly 10 miles from my house):

The Blue tracks are Cell GPS (reported accuracy in SW Maps ~1-2m), Red is the RTK Express without corrections (reported accuracy in SW Maps ~.3 m), and Yellow is the RTK Express with corrections (reported accuracy in SW Maps ~0.012-0.018 m).

Since the Yellow line was the most accurate, I expected the other tracks to deviate from that according to their accuracy. I.e. the Red track should be no more than ~0.3 m from the Yellow Track, and the Blue Track no more than ~2m from the Yellow track. But that isn’t the case:

Here, the distance between the red track and the yellow track is 3 m, not the expected 0.3 m.

So, which do I trust more? I understand that the RTK corrections are relative to the base station, so the position accuracy is really only as good as the base station’s, and maybe with a free source like RTK2Go, you get what you pay for.

How accurate is the position in Google maps? If I place my antenna at a landmark I can see in Google Maps, can I judge how accurate the GNSS position is by the distance between where it shows I am in Google maps and where it shows the landmark?

Thanks for any suggestions, ideas, or information you may have!

Welcome to the community @Jack3 !

Lots to unpack, so I’ll give some quick answers and be happy to explain anything in more detail.

  1. “reported accuracy” from any gnss device is an estimate, it’s a guess based on many factors. Don’t put much confidence in the accuracies you listed.
  2. GNSS has a hard time under tree canopy. You will notice your 3 tracks have better agreement in Open Sky.
  3. Free Online Aerial Imagery is generally not expected to be geolocated with an accuracy comparable to RTK.

Take your RTK Express to the middle of that area (in the wide open), connect to the Base, and log a RTK Fixed point. Walk away and come back to the same point and log it again. Then use SW Maps to measure the distance between the 2 points. That’s going to give you an idea on the precision. You should be able to reproduce the position easily.

Thanks for the response. As you suggested, I recorded some waypoints at the center of the pasture, again with the RTK Express w/o corrections, with corrections, and with just my phone’s GPS:

This was the most I could zoom in, but you can see the five waypoints recorded with the corrections (yellow) are very precise, nearly all on top of each other, while the waypoints recorded without corrections (red) have more variation, and the waypoints recorded with just my phone (blue) are still more variable.

But I still see a bias or offset between the data with corrections and that without. I was expecting something more like this:

But instead it looks more like this:

or maybe this?

Precision is great, but of course I want accuracy as well. How can I tell which data source (with or without corrections) is more accurate?

There is a huge range of answers to that question. I’ll start with the “General” version for simplicity.

RTK positions are considered more “accurate”, because the rover gets the benefit of the base station observations to reduce several atmospheric and timing errors that are inherent to GNSS. The RTK Express can easily reproduce positions to <1cm (precision) under the same conditions with a proper workflow.

But to define the accuracy, one needs to know the true coordinates of the point (the center of the target in your sketches) - which is not a trivial task. You will also need to know the Reference Frame and Epoch of the Base Station Position. You will need the Antenna Calibration, always point the antenna to the North, accurate Rod Height to the ARP, etc. However, you are still hoping whoever owns the Base did their job correctly.

Many times we lean towards post processing when accuracy is required. That is generally long static sessions that are later “corrected” with OPUS, NSRS-PPP, etc, a few weeks later. After many sessions and a lot of work, you can start to gain confidence in the actual accuracy of a single position.

If you verify a Base or Correction Service suits your needs, then RTK is the easy button. Just know that humans will introduce Random and Systematic errors to the process. We are generally the limiting factor, not the GNSS equipment.

Another thing to note is that 10 miles is a bit beyond the usual recommended limit for base station distance (10 km ), which will reduce the accuracy of RTK/corrected one a bit

You can perform a 24-hr survey if you’d like to try testing the maximum accuracy (and then afterward you could use that as a base for corrections!)

You will need to understand what “Coordinate Reference System” or datum you are using. In the US, GNSS without RTK will get you perhaps the most recent WGS84, and perhaps some recent ITRF (because it’s differential, e.g. WAAS). But these are all more or less the same. Professional RTK that isn’t trying to be worldwide is very likely “NAD83(2011) epoch 2010.0” which is the National Spatial Reference System. Some RTK base stations will be in WGS84/ITRF. You absolutely need to understand which and pay attention.

In MA, RTK via MassDOT’s network is so good that whether you hold the pole vertical carefully is the major contribution to error. Make sure the point you are measuring repeatedly is fixed and stable.

For reported accuracy, there are two big issues. One is that sometimes people report a 95% 2D error bound E, such that the distance from true to observed is <= E for 95% of measurements. People also report standard deviation, and that’s maybe half of the 95% bound, maybe not quite. Marketing people like to find the smallest number they can say without being convicted of lying :slight_smile: GNSS module manufacturers put in code that outputs an accuracy metric, but it’s really hard to find the spec that explains exactly what it means. Overall I’m very skeptical of reported errors.

My take for the F9P in autonomous (GNSS only + WAAS), float RTK, fixed RTK with full sky view is that 95% accuracies are about 5m, about 1 meter, and about 2 cm. This while fixed is showing 0.01. With better leveling, the 4 cm might be 1 cm. But once it reports 0.017m instead of 0.01m, it’s noticeably worse.

Your data looks reasonable. Taking a bunch of measurements (starting over, different days) and asking “what’s the diameter of the circle that includes them” gets you a real repeatability/precision estimate. For me, holding the rod by hand, 30s averages, multiple times, some canopy, that’s a 4 cm circle. For someone else, maybe mosaic instead, holding the rod with a tripod, full sky view, it was about a 1 cm circle.

If you can, find a good NGS control point and go measure that. And, see if your state DOT has a network you can use. I would expect a professional RTK network, even at 16 km, to be much better than a 24h average.

As for imagery, it varies. I would not trust google because they don’t publish metadata. My state’s GIS department publishes imagery, which is ground controlled to NAD83(2011) epoch 2010.0, at 15 cm resolution. I find that positions from MassDOT RTK (“MaCORS”) line up with this imagery to within a pixel.

Your phone data and your non-RTK data line up with each other. There is a shift with RTK data. This suggests a different datum.

Coincidentally: The same exercise in August – a crazy 48hrs.

Short answer:

Accuracy&repeatability to

  1. 6cm if rtk fix with PPP
  2. 6cm if rtk fix with VRS/CORS in a single session
  3. 1 meter day to day variance with VRS/CORS

Without fix 1..3 meters, subject to multipath and obscuration

Post Processing solutions:PPK

  1. < 6cm: with high precision orbitals and relativistic clock corrections
  2. 6cm: with EspNow/Base Facet
  3. 1m: LORA/Base Facet

TLDR/ how to get the same results

Findings:

VRS/NTRIP

  1. Static position is dead on accurate for each session so long as range to station is <10km, southerly better
  2. Boot-to-Boot repeatbility is 1Meter at best.
  3. VRS (virtual reference) is recomputed with each session (thus cep 1M)
  4. many stations have inherant 10-20s dwell (useless!)
  5. many stations are not where they are reported to be (useless! check range)
  6. Station listings are obscure/hard to find/geolocate (much voodoo)
  7. Numerous variations of caster address/port & usernames (useless failpoint)

Point Perfect (clear winner)

  1. Static Positions repeatability dead on accurate,
  2. Does not vary boot to boot
  3. Single Access Point/user&password

Downsides to Usability:

  1. Minutes to initial fix: Why? Ephemeride observation from sats (excessive if under canopy)
  2. Fix in 15s? Define your WIFI, and then AssistNow, which is already part of the firmware will download ephemerides at boot time (no joke fix in 15s!)
  3. Adding WIFI to your .txt exposes your password, use router guest network (and hide it)
  4. Dynamic (or static)Position not accurate if in RTK/Float (anything other than fix)
  5. Set correct GNSS mode: pedestrian if walking, portable if mobile breaks at 25mph
  6. RTK/Fix can be and is often times is wrong; due to reflection and obstruction.
  7. ymmv: Trust it to 6inches if in the clear, likely due to the fact that Sat Clock Variances and high precision orbit positions not incorporated realtime into VRS and PPP (typicaly 24hrs later, useless!)
  8. Are the high precision updates available from PPP? NO. from CORS/VRS, maybe – ymmv

Is there another alternative. Yes.

  1. RTKLIB takes raw ubx and converts to truer than VRS/PPP, download latest version
  2. Hours worth of canyon survey resolved in minutes on thinkPad class pc
  3. Doesn’t require any connectivity in the field! Set Rover to collect and post-process!
  4. Requires RINEX availablility from VRS/COR, PPP not available, or sourced from a Second Survey-in/Facet
  5. Drop your .ubx file from SDcard directly into RTKPlot and you have the real deal (status of fix & position), ask google gemini on the other steps to get you ubx data converted to PPK/truth (.pos). ibid
  6. drop the ppk .pos answer into RTKPlot compare to collected raw/ubx and SW Maps.
  7. Solves most, but not everything (fails under trees, and other after the fact obvious places

Facet Connectivity/Magic

  1. not really required, just collect ubx from VRS/Base Facet and post process
  2. Not as satisfying as seeing rtk fix realtime but infuriating when wrong
  3. Measurement rate faster than 1hz will NOT log required ephemerides, waste your time and fail
  4. Pragmatic choice: use both VRS (or fixed base} and then PPK

ESP Now (winner, ppk high quality fix!)

  1. range limit (50m obstructed/100 clear) but PPK renders RTK Fix (green) twice that range and considered trusted
  2. Close enough that no one is going to nick your equipment and not too too far-away to walk to reposition for the next overlapping survey. Plan ahead.
  3. Very low usage of available EspNow Bandwdith (high unused margin)
  4. Tempting to process at higher rate but sdcard taps out at 1hz, need to stream it
  5. Downside, every ESP (even nonFacet) can (and probably does) broadcast to the world (don’t trust your security to pairing)

LORA (lower quality fix over larger distances, but bandwidth maxed out)

  1. Minimum Airspeed required 19200 (requires voodoo to winnow, don’t bother)
  2. RF chip spec max’d out just below 38400 (in other words, it’s at the limit, requires high voodoo).
  3. RTK Fix stable when clear, unstable when its not (otherwise not helpful at all)
  4. LED’s too dim to see in ambient light (but do render status when link degrades)
  5. Nowhere to mount LORA antenna (can’t mount it on top, requires your own fixture)
  6. Range limit (100m/300m clear) PPK renders all yellow, no RTK fix in PPK result.

What will go wrong:

  1. RTKLIB directory is path sensitive, choose well; after first use do not move executable/files/directories or you will get: no-obs data (clearly a library is missed)
  2. ubx, not saving to SDcard? missing obs/ephemerides? A: You have to use the GNSS/Menu option to set default survey+raw option (and save), use beyond-compare to see magic set points added to .txt file
  3. Measurement rate when writing to sd cannot exceed 1hz!
  4. Learning curve, ask gemini, find web example, get a win, then read the manual (only need RTKCONV/POST/PLOT)

Yes. Yoy can read the man page in your man cave,

but only if you have a linux shell, but isn’t that against the rules?

Obviously NOT… there is so much wrong in the post.