What is a Mass-Market GNSS Correction Network? Do they work for Survey, Construction and Farming?

Mike Horton
5 min readOct 25, 2021

--

Updated with new results Sept 2022

When a GPS / GNSS receiver utilizes corrections from a GNSS correction network, the receiver’s position accuracy can instantly improve from meters to centimeters in clear sky conditions. GNSS correction networks, also known as CORS (Continuously Operating Reference Networks) networks, have been around for a while but CORS networks have never reached a mass market status like Cellular and WiFi networks.

On the one hand government organizations, e.g., the Department of Transportation, provide near free regional correction networks to surveyors, and on the other hand, specialized Geospatial companies like Trimble, Hexagon, and John Deere provide correction networks for Construction and Farming which may require higher uptime or better coverage than government provided options. Neither of these options are mass market solutions.

Recently several new entrants are focusing on mass market GNSS correction service, and they have started operational service covering the Continental USA (CONUS). These services primarily target IoT, Automotive, and Mobile applications — “New Precision Applications”. The cost is very LOW compared to traditional survey grade GNSS vendor-supplied CORS networks. These networks also promise excellent reliability for safety-critical applications. So can these new GNSS correction networks be used in traditional high-accuracy requirements using existing fielded GNSS equipment? Well it depends, but in many cases yes.

CORS Network Comparison

Four Networks, 35 Test Locations

This blog outline a series of tests done in 35 locations throughout the USA on the following CORS networks:

In this study, Hexagon SmartNet is representative of the traditional survey grade network and the other three networks are new low-cost options. The study considers rural and urban conditions as well as both 2D Accuracy (Horizontal) and 3D Accuracy (including Vertical). Farming applications are generally concerned with performance outside city centers and focused on 2D Horizontal accuracy, where as Construction/Survey applications focus on 3D Accuracy traceable to the NAD83 Datum as well as Vertical Accuracy.

Precision Farming Systems Frequently use a CORS Network for GNSS Corrections

The data collected and Python code to compare these CORS networks has been made open source here: https://github.com/easyrtk/cors_compare

In order to efficiently and fairly compare these networks a number of ways were considered. One idea was to use four Ublox F9P developer boards and take them to different locations around the USA. This idea required too much manual testing, and at the same time physically going to 35 locations around the USA is very time consuming. Another idea was to use public streams available on RTK2GO as the rover and look at their corrected positions using RTKLib as the positioning engine. The struggle with this is that some of the receivers on RTK2GO are in uncontrolled locations making their streams unpredictable. Another issue is that on a typical day maybe there are 10 dual-band RTCM3 streams live in the USA and they are not necessarily well spread throughout the continental USA.

The National Geodetic Survey (NGS) operates survey-grade stations through the USA, and many of these stations posts 1-second data every hour.Instead of using RTK2GO or Ublox F9, we decided to utilize NGS station logs along with post processing. The location of these stages is well established to better than 1cm accuracy. Overlapping data from each CORS network was simultaneous collected, and the processing pipeline is shown below.

Processing Pipeline for CORS_Compare Python Framework
35 Test Locations (NGS CORSStations used as Virtual Rovers)
Location Results

Except for Swift, there were a few locations that failed to generate corrections. Swift generated a solution for each of the 35 locations tested. This is not entirely unexpected as most of these networks do show a few coverage gaps in their coverage maps. Notably SmartNet, the oldest and most mature network compared, also has the most gaps. Areas like South Florida are surprisingly not covered. On the other hand, SmartNet is the only service to directly support a NAD83 mount point which is probably the most convenient for existing high-accuracy GNSS users. The following list of datum are supported, and the CORS_compare code goes thru a few careful steps to convert all datums back to NAD83 for comparison.

•Hexagon SmartNet — NAD83(2011) Epoch 2010 (except high-velocity regions)

•Verizon Hyper Precise — ITRF(2014) Epoch 2010

•Swift Navigation Skylark — ITRF(2014) Epoch 2021.x

•PointOne Polaris — ITRF(2014) Epoch 2021.x

The average accuracy results across the validated locations are shown in the two tables below.

3D Accuracy and Convergence Time with Wide-Lane Support
Horizontal Accuracy and Standard Deviation, Height (Vertical) Accuracy with Wide-Lane Support

Another question is how do the networks compare in rural versus urban locations. This result was a major surprise. The results in rural location are quite consistent with urban results overall. One potential issue is that “rural” for an NGS station may not be truly rural. This study considered a station rural if it is located in a small town (typ <10,000 people).

Summary of Results

In summary, there are several new options for low-cost GNSS correction networks in the USA each with pro’s and a few con’s. These networks offer RTCM3 corrections and as such they are easy to use with existing GNSS equipment. The accuracy is generally very promising, but very careful attention to Datum and Datum Epoch is required. For applications requiring <5cm Centimeter Accuracy or high Vertical Accuracy careful testing should be done in desired usage region prior to deployment.

Thank you to Swift Nav

Swift Navigation analyzed the results of the original blog post. After determining lack of wide-lane ambiguity support in RTK Lib negatively impacted initially reported results, Swift Navigation improved RTK Lib to support wide-lane ambiguity resolution and the results of the blog were updated.

--

--