RTK Workflow needed for Known Points in NAD83(2011)

Hello,
I am looking for a simple workflow for using an RS2 (Base) and RS+ (Rover) to collect ground control points. In another thread I am also trying to use PPK for the same purpose. I made a new thread to keep the information separate between RTK and PPK.

I am in the United States and need an RTK workflow for setting up my RS2 as my base on a known point. Unfortunately the known points I will be using are from the National Geodetic Survey and are all (The ones close to me that I will be using) in NAD83(2011), heights NAD83(2011) with the data sheet also showing an orthometric height and a geoid height. Sheet below.

I know that RS2/+ want a Manual input to be in WGS 84 in base mode.
I use Pix4D for my mapping software so it is fine if I have my GCPs and Checkpoints in WGS84, but per Pix4D it is best to have your GCPs be in the same coordinate system as your final expected output.
I would also like to have orthometric heights in my output maps.
I am not sure of conversions/transformations between NAD83(2011) and WGS 84.

Can anyone please just outline a workflow for using these NAD83(2011) control points for my RS2 as my base and RS+ as my rover using Lora.

2 Likes

Why don’t you get rid of that RS+ for another RS2, or build your own rover with a M2, Lora, antenna and battery pack to get FULL multi-band capability with your RS2? Otherwise you’re limiting yourself to single band of the RS+.

Once you get under tree canopy, between buildings, urban areas, you’ll see the problem with single band.

But if wide open clear sky, no need. (but then all you needed was (2) RS+ or (2) M+)

2 Likes

Here’s the post that started in DroneDeploy for background.

1 Like

So we can indeed tell from your datasheet that the control points are NAD83 so we need to convert that to WGS84 for manual entry into base mode. Here’s a tool I found to convert NAD83 Lat/Lon to WGS84 Lat/Lon.
https://tagis.dep.wv.gov/convert/

image

Base Mode needs decimal degrees though so if you hit view on Google Maps it will give them to you.

image

1 Like

Okay, thank you.
So I would now enter the WGS 84 coordinates into Reachview in the Base Manual Setting. And then I would survey my points. I know Pix4D will except them in WGS84 and still let me choose what output I want/need. Could I also then take my points in WGS84 and then use the process above to convert them back into NAD83?

I finally downloaded and installed Reachview 3 and looked at it but have not used it.
Would using Reachview 3 with its ability to now choose coordinate systems work?
Say I set up my RS2 Base over the known point which we know is in NAD83(2011). In Reachview 3 if I choose Coordinate System NAD 83(2011) it states with the i "Make sure your base or NTRIP is in NAD83(2011). So will this work, as the RS2 base is setup on my point and in Base Mode Manual I entered NAD83(2011) coordinates.

And I have yet to delve into the height as I am sure that will add more “fun” :slight_smile:

2 Likes

I fully agree and wish I went that route. But I did not have the funds when I purchased all of my equipment. I hope to add another RS2 in the future.

For now my largest mapping project is an old airport and a beach. The airport has open sky all around, but the beach has highrises on one side. But the beach will be mapped in PPK with the RS2 as my base and a Baamtech multiband PPK kit on my Phantom 4 Pro.

The GCP mapping in RTK is just for backup to my Phantom 4 Pro, but also to allow me to use other nonPPK drones that I have or my real job has.

Before I tackle the PPK and Baamtech PPK, I just want to get a solid workflow that I can show others to create quick maps of parts of the airfield with RTK.

So I am sure I will have questions added onto my PPK thread too.

1 Like

The problem with using Reachview 3 in that sense is that you can only use NAD83 if the base is pushing NAD83 which the Emlid receivers don’t do. You can still use Reachview 3 just like Reachview 2 on WGS84. You should be able to use that tool to go back and forth.

Yes, ellipsoid height is another factor that I won’t be much help on as I have never had to find it on a specific point. I thought there was a calculator that would give you the WGS84 ellipsoid height from a coordiante but cannot find it.

1 Like

Why is it “unfortunate” that you are using NGS’s stations ? Your statement doesn’t make any sense. Consider yourself “fortunate” that you have NGS passive control stations available. Everyone wants to be a Land Surveyor but don’t have the knowledge to start ? Need to go to a certified school or train under a licensed professional.

Why do you need to convert to WGS84 ? It is my understanding if you enter NAD83 coords as your base coords, the resultant coords via RTK would be NAD83. Emlid support has explained this before I thought.

This is the exact issue I have brought up before. If you state what coordinate system you are using, the software should translate the base coords as
entered by the user internally to the coord system selected. This needs to be fixed if Emlid is going to try to engage the surveying community. As I have stated before, every system I’ve ever used in the last 25 years works this way. I’ve never had to enter an ellipsoid height in any GNSS field software before. The ellipsoid-geoid speration should be known by the software if selecting any project coordinate system. All GNSS systems are based on the WGS84 system and I understand the methodology as I’ve been n using this technology for the last 30 years but others starting out that have no knowledge of how to survey or even knowing the underlining basis of any GNSS system shouldn’t even have to worry about this. I’m embarrassed to even recommend the Emlid system to fellow Surveyors due to this issue. Emlid needs to fix this issue. I have high hopes for Emlid and I like their products, but this needs to be a top priority by the software team.

2 Likes

There is a option you can uncheck for decimal degrees. ; )

1 Like

I just read and digested an older thread on Reachview 3 on its journey through Beta, very interesting.

I found in that thread where an Emlid developer says you can just enter NAD83(2011) into the base Manual mode, or at least that is what I am getting from his statement.

I also found this is Reachview 3 Docs Section, Reachview 3, Working with coordinate systems, United States
https://docs.emlid.com/reachrs2/reachview-3/countries/usa#base-setup

So, Reachview 3 will let me enter NAD83 (2011) into the Base Section as long as I chose it as the coordinate system when I start a project?

My understanding is that the coordinate has to be supplied in WGS84 Latitude and Longitude and WGS84 ellipsoid height? If WGS84 and NAD83 do not equal each other how does it convert on the fly? They do not match each other in horizontal or in ellipsoid GRS80 vs WGS84.

Can we separate what RV2 does vs RV3? The OP started with RV2.

This is my understanding as well, after I learned that driving my tractor vs surveying the yard used different datums.

Its also outlined in the F9P Manual and is part of the function of the chip.
“When operating as a rover, the ZED-F9P can receive RTCM 3.3 corrections from another ZED-F9P
operating as a base, or via NTRIP from a virtual reference service provider operating a network
of base receivers. In this mode, the receiver coordinates will be expressed in the datum used by
the RTCM correction provider. For more information on this topic please refer to the RTCM ITRF
Geodetic models section in the Appendix.”

Does this only work over NTRIP?

“Real time kinematic (RTK) is a differential system where the rover uses the reference datum of
the reference station. The International Terrestrial Reference Frame (ITRF) must be obtained from
the reference network and then used to transform the rover position output to match the required reference frame. The rover does not output the position in the local receiver WGS84 (based on ITRF2008) datum, it matches the reference receiver (or base) reference frame. The user application needs to do the transformation for use in a mapping application if it does not use the same reference frame. An offset can occur if this is not done.

So this must be the magic that goes on inside the EMLID Nuetis chip? its not just a web interface after all?

RTK works even better when, both rover and base are on the same datum. Somehow Emlid just knows magically at the other end. But Trimble tractor rovers start acting goofy if the rover datum is not manually set to the base datum. +1 Emlid

I’m just not trying to get confused with different hardware and software. The OP has an RS2 base and a RS+ rover using RV2 as the survey software. Can we stick to that to figure out the specific example?

My collapse is that NTRIP is one thing and local base is another.

Its the same hardware, Emlid is a very upscale feature rich F9P. If you look at the board there are two main chips The F9P and Neutis.

Its my fault on jumping to RV3, I was just hoping that it could be a simple fix for my problem if I just start using it.

For discussion, here is the orthomap I made with the following in RTK to my RS+ Rover

RS2 Base on known point ( NAD 83(2011)- 39 21 36.67824(N) 074 27 25.36127 ELLIP HT- -32.371
This is what I entered into RV2 in Base Manual 39.3601884000, -74.4570447972, -32.371 ellipsoid height

I collected 5 GCPs and 4 Checkpoints in Reachview
I exported in a Shape File and also a CSV

If I take the Shapefile and place it in ArcMap, Arcmap says the Coordinate system is:
GCS_WGS_1984
WKID: 4326 Authority: EPSG

Angular Unit: Degree (0.0174532925199433)
Prime Meridian: Greenwich (0.0)
Datum: D_WGS_1984
Spheroid: WGS_1984
Semimajor Axis: 6378137.0
Semiminor Axis: 6356752.314245179
Inverse Flattening: 298.257223563

I took my CSV GCP sheet and entered it into Pix4D as WGS84 obtained GCPS and Checks
image

I then processed my data and output to:
image

My resulting point cloud looks like this in Pix4D with the GCPs and Checks being the markers:

When I then place my orthomap in tif into Arcmap which will take on the coordinate system of the first thing opened in it I am in:
image

I then in Arcmap drag in the GCP Shapefile that is WGS84 but has Arcmap Transform into WGS 84 UTM 18N and get this with the GCPs and Checks being spot on for location:

And finally if I really zoom in on my GCP targets the Shapefile GCP locations are dead on where they should be (Notice the tiny white point) All points from the Shapefile are all just as accurate:

And finally my Quality Report:

So what are everyone’s thoughts?

The data looks great, but noone here can confirm your accuracy. Of course ArcMap is going to look good because you entered the GCP’s in as WGS84. Obviously when we did the coordinate conversion earlier the difference were very small and longitude in particular it was so small that your GNSS gear cannot even shoot that accurately. This is what is dangerous because unless you have an independent set of checks and balances you could easily look good but then you check into a point 0.5mi away and are off 0.20ft and wonder why. If you have control to check I think it is easier to spot a bust in elevation between WGS84 and NAD83 than it is horizontal but it does vary across the country.

Who knows what entering in NAD83 coordinates and processing as WGS84 is relative to. Can someone with a CORS service providing NAD83 come behind you and the the exact points?

@EBE111057 @PotatoFarmer, Is this what you guys mean by saying “if you manually enter NAD83, you get NAD83”? Just because they are so similar that it is more of a shift? At what point or is there a distance at which this wouldn’t work?

This is exactly what I am trying to get concrete. Especially between WGS84 and NAD83.

My test of NAD83 base coordinates and rover RV3 set to NAD83, produced the same coordinates the professional surveyors have on the four pins of my acreage. Very small baseline 200meters or so.

1 Like

The way I understood everything is that if you transmit a correction using coordinates in another datum than WGS84, you should still use WGS84 as your project datum in RV3 if you don’t want it to be transformed (which would make it incorrect). Then when you export you can simply define the projection as the original base datum in whatever software you will use the data in.

Ok so…

NAD83 Base, WGS84 in Emlid RV3, No Emlid Transformation, Transform to NAD83 using PC software

or

NAD83 Base, NAD83 in EMLID RV3, Emlid Transforms, No processing required by PC

These would be the two conditions, would the second be not be simpler? The second case is the whole reason for RV3 I thought to be able to work in the local projection, the first condition would be for the original RV2 before the extra capability was added.

4 Likes