I took the WGS84 coordinate I calculated for the ZHN1 station and placed them in NAD83 PA11 and the difference is 1.9 meters, offset to the NWW. By my math, about 90cm of that is explained by movement of the Pacific Plate in that direction since 2010…
@daygeckoart OK, now we are making some progress and thanks to @jbonde002 for jumping in and doing the legwork. You have now established:
- VALR & ZHN1 are coordinated to NAD83
- You have confidence in the accuracy of their published coordinates
- You can now post-process your data directly into permanent local NAD83 coordinates, without the baggage of WGS84. (see note below)
- You are now able to correct your older data (previously assumed WGS84) and have saved yourself accruing an additional 4m or so error into the future.
- You have demonstrated Emlid Studio is capable of post-processing an accurate single point (with appropriate inputs).
With these references you are now in a good position to start delving deeper into your own observations. Suggest the logical next step is to do some extended observations on a good known point such as Tantalus Lookout or similar, and - using the same settings, don’t change to much each step- differentially correct to each of the local CORS and see what comes up.
I suspect that your erratic fixes may stem from the limitations of your single frequency in the environments you are working. I’ve seen the same processing single frequency RINEX from a Garmin 66i, and testing in those situations gave better overall results simply sticking to float. In RTKLIB you can configure the integer ambiguity resolution to off but that is one of a number of options that does not (at least yet) appear in Emlid Studio.
So the logic behind the suggestion above of first doing the next step on the known point is not just for the accuracy reference, but also because the Tantalus site appears to be a good GNSS environment to enable comparing the detail with your previous observations.
Re Emlid Studio and coordinates, maybe the simplest way to get your head around that is Emlid Studio is not doing anything with datums, there are no coordinate systems built in as you get with professional applications. Think of it that it’s only doing differential calculations. And because the CORS station coordinates are NAD83 you are simply getting a differential offset from those, by default then in NAD83. E.g. whatever the datum in the CORS is what you will get and why you need to know that datum. An even simpler view could be just think of it as the CORS stations are tricking Emlid Studio to make it easier for you.
Hold on, before we get to testing and all that, I need an explanation of what you said regardint tricking.
Let’s say I process data in Emlid Studio and get a coordinate, either by using the built in “single best” or averaging in GIS. Emlid Studio thinks everything is in WGS84 but it’s really NAD83? So I have to place my resulting coordinates as NAD83 PA11?
In the context of processing against VALR and ZHN1 the short answer is yes, your result is in NAD83
The basic concept would be base datum in = position datum out…unless you choose to override it. For example:
- If you input NAD83 base data then your result is in NAD83
- If you choose to input WGS84 base data (e.g. raw from your device or a rogue CORS) your result will be in WGS84…at least on that day.
- If you created your own datum on the ellipsoid called geko23 and overrode the base coordinates of either of the above, e.g. by dragging in a geko23 pos file, then your result will be in geko23.
Maybe just think of Emlid Studio as having an agnostic ellipsoid model and weaving it’s magic to calculate accurate differences between coordinates on it, and it’s up you to keep track of which datum.
Anyway, don’t let this get in the way, you can ponder it while you’re up on the hill. We’ve been patiently waiting since @MapScience first recommended it.
I understand that tricking the software is basically good enough because the offsets between NAD83 and WGS84 mostly even out. But surely it can’t be good practice.
Differential correction works by calculating the delay of the signals to the sub-wavelength level right? So the absolute position of the base station is important. I can see that a few cm off, the algorithm will just think the signals are delayed or sped up from each respective satellite. It’s not just an offset in position, it just looks that way.
But several meters seems like way too much! The algorithm would have to think signals can travel faster than lightspeed! Then again, that seems to be exactly what happens. I put in a base station coordinate that was 3 meters off and basically got the same plot offset by 3 meters.
I would think the fewer satellites you collect with the rover, the less it looks like an offset and the more likely it is to be a random shift.
All you need to worry about ellipsoids is that NAD83 like most modern datums is based on the same ellipsoid as WGS84, and it’s called GRS80 as was pointed out by others earlier. And NAD83 been tried and proven with CORS for decades deriving mm level precision on the ground which is why it’s used.
Another example, look at my accuracy chart example I posted earlier. This test over a 13.8km baseline used a CORS coordinated in our GDA2020 datum, which is the equivalent to your NAD83 so identical situation, and shows with sufficient time the accuracy can get down to 5mm using Emlid Studio.
I have three CORS at reasonable distances in various directions, the other two are further away. All are coordinated in GDA2020, and I can get quicker and more accurate results using my professional software, with all three consistently agreeing with my own base reference to within a few mm.
So the datum and system just plain works & works well.
You have some limitations with equipment, for example single frequency and no geodetic antenna, but your baselines are short and time is your friend. The system is more than capable of giving more than what you need or what you may be able to extract from it.
Now get up the hill and do some testing and start having a look yourself!
2 Likes