I got the following warning from the NRCan Report - “Warning : A priori and estimated positions differ by more than 50 metres. Solution is likely erroneous and should be verified.”
What is the significance of this message and how should I rectify it?
What the NRCan warning is doing is comparing its position solution of your rinex file (the estimated position) to the approximate position listed in the rinex file header by your GPS receiver (which it calls the a priori position). Stand-alone GPS (no corrections) should have an accuracy of 10m and a dual frequency receiver can improve on that even with no corrections. Most of the time I’ve submitted to NRCan, these positions are a few meters different.
To be off by 50m+ is worrisome.
Did you make any changes to your rinex header position before submitting to NRCan or did your convert your ubx file to rinex yourself with rtklib?
If you want help looking at this specific case, please post the NRCan solution pdf, the rinex file you submitted, and the original ubx raw file from your gps.
Thanks Africwaterdoc. I converted my ubx file to rinex with rtkconv with settings to add “Rec #/Type/Vers”, “Ant #/Type” and “Ant Delta H/E/N” to include the height of 1.960m I tried before without those added to the rinex header and got an additional error from NRCan saying no antenna type could be detected. See attached pdf, rinex file and ubx raw file from RS2 attached. Thanks in advance for the help. I have other questions regarding how to correct all my GCPs too, but I wanted to focus on figuring out how to establish a “known point” first so I can use that as my manual position for the base station. See dropbox link to data here: (Dropbox - File Deleted)
RTKCONV_Settings|582x550 m_Error.zip?dl=0)
I should also add, I did not get any warnings like this when submitting the same files to AUSPOS and NOAA OPUS. So I’m not quite sure what to trust. The datums they output are a little confusing too. I’d like to work in WGS84 because it is still sort of standard for a lot of GIS work but my specific location uses NAD83 (PA11)/NAVD88. I’ll need to figure out a reliable transformation from the NRCan/AusPOS/OPUS. Maybe this is simple in ArcGIS/QGIS but I haven’t tried it yet. Just trying to figure out a “known point” first. Any help will be much appreciated.
Hi Scott,
So I looked at the data and the output file from NRCAN. On the bright side, the warning about the difference between the a priori (rinex header) position and the NRCAN estimated position is based on the height difference between those two (the lat/long were both less than 10m). Non-corrected GPS height can be significantly worse than 10m depending on ionosphere and troposphere characteristics. Another possibility is the log started up right when you turned on the unit and it hadn’t stabilized on its solution (thus it logged its initial a prior point with few satellites and bad resolution on the height). When I run your observation file through RTKLIB in single mode it gives me an uncorrected height of 358.096m, about a meter off of the NRCAN estimate. This leads me to believe the issue is really with the initial position written to the file by the GPS. Let the GPS run for a few min before starting the log next time and see if it clears up the issue.
Now, how you move forward on getting your absolute position really depends on what you are doing and the accuracy you need. A lot of GIS work is okay being 1-3m accurate. If this is the case, you can run PPP and get the coordinates in ITRF2014 and assume they are equivalent to WGS84. You mentioned GCPs, which makes me think you might be running drones for orthometric photos or photogrammetry. If you need high relative accuracy, but are okay with absolute being 1-3m, you can still use the above. If you need survey grade accuracy throughout all of your work, you are going to need to do more to make that happen. WGS84 and ITRF2014 are reference frames that are not tied to any one tectonic plate so they are only valid in the moment of time that they are collected and your local plate will continue to move away from that position. You will need to use the tectonically tied NAD83(PA11). Since I don’t work in your region, I am unsure if NRCAN automatically selects NAD842(PA11) for the pacific plate -> you will need to research to make sure this is the case and its not giving you a result in the north american plate.
I see that there is a JPL operated CORS near your location (named MKEA). It has its coordinates in NAD83(PA11). I see its sampling rate is low (30s), but you could PP the location of your base station against that in static mode and get a high quality position for your base station in NAD83(PA11) and your work is then tied in to a CORS monument. Great for repeatability of your accuracy. Once your base station is in NAD83(PA11), then all of your GCPs will be in the same reference frame (make sure you choose it in the emlid survey function). This will require likely two visits to the field, one to establish the base station monument and the next to set your GCPs once you have PPed the base station to the CORS. The other alternative is to do it all at once, GCPs relative to the base, while you log the base (starting in average single mode), and then you will have to correct the base by PP after the fact and then adjust each GCP by the deltas between the original average single base point and the PP point you get later. If it’s a few GCPs and you have good PP software, this might save you field time at the expense of more office work and doing more adjustments/conversions. Well after writing this section about this CORS, I looked up the actual distance and it seems you’re approx 70 km from this station, which is starting to hit the upper range for reliable PP. You’d need ideal conditions, patience and probably a good PP software package to help out with this. And I would make sure you are able to actually PP the base before trying to set GCPs.
Excellent explanation Africawaterdoc ! I tell people to always let the receiver stabilize at least 5 minutes before logging for any static position. As explained in another post, if you are surveying a large area, i. e.
multiple counties, the receiver still thinks it’s in the last county. People are in to much of a rush to get the project done or are very impatient.
That applies to EVERYTHING these days!!! : /
Thanks for the very well presented explanation! My plan is to use your strategy of returning to the field multiple times and that is why I’m trying to set up a new “known location” through NRCan.
I also submitted the same file to NOAA OPUS and did not get any warnings. The solution from OPUS seems to be reasonable according to their website:
“Overall RMS is less than 3 cm
Peak-to-peak errors are less than 5 cm
For OPUS-RS: the solution contains no warning messages”.
My report from OPUS is the following:
"OVERALL RMS: 0.016(m)
REF FRAME: NAD_83(PA11)(EPOCH:2010.0000) ITRF2014 (EPOCH:2021.4737)
X: -5483171.506(m) 0.011(m) -5483172.623(m) 0.011(m)
Y: -2499531.204(m) 0.010(m) -2499528.021(m) 0.010(m)
Z: 2084015.320(m) 0.008(m) 2084016.710(m) 0.008(m)"
My question is:
When I go to set up my base station Emlid RV3 allows me to create a new project and choose the coordinate system I want to work in (e.g. NAD83(PA11) / UTM zone 5N) and gives me options for vertical datum (Ellipsoid height, EGM2008, EGM96 height, NAVD88 depth, NAVD88 height or NAVD88(GEOID12B) height). This is confusing because I am assuming the base station and the project coordinate reference systems should be the same, but RV3 only allows me to use WGS84 for the base station. So when I set up my base station over this OPUS derived point, do I need to first do a transformation from the opus provided NAD83(PA11) or ITRF2014 coordinates to WGS84 and use that transformed coordinate as my known point? Or is RV3 automatically calculating those differences between the base and the project’s coordinate system when doing RTK or PPK even though my base is on a different datum than my project? I don’t see any settings for the Rover that would allow me to use a specific CRS either. What would be easier; transforming my OPUS solution to WGS 84 and keeping everything in that datum or setting up my project to work in more of a local coordinate system?
Perhaps this is something I need to discuss with Emlid support, but if anyone here has experience with this any advice would be greatly appreciated.
Africawaterdoc, you were correct in your assessment of my wanting to set up GCPs for a project site and monitoring some earthworks over time with photogrammetry and/or direct measurements. I may not need the absolute accuracy but for my own personal development I would like to understand it and know how to deal with it for future projects. I am also trying to monitor orchard health over time and having good controlled imagery will help me tremendously with comparing tree to tree over time as opposed to having to re-digitize or adjust tree crown polygons due to shifts in the imagery from year to year. As you observed, there are no reliable CORS stations in this area and no reliable known locations from our National Reference System (Hawaii is kind of backwards that way) and that is why I’m trying to set up a location I can return to over several months and use that as my known point. I’m assuming after I have the known point worked out I can set my base station up over that point and get accurate GCPs using either RTK or PPK. That actually brings me to another question:
Question 2:
If I am using RTK and getting a “fixed” correction over LoRa, I’m assuming I don’t need to run it through RTKPost to get more corrections? If I have a well controlled point from NOAA OPUS PPP and carefully set my base station up over that point, my RTK corrections should all be cm accurate, is that correct? Or is it better to run the base and rover data through PPK in RTKPost anyway?
Oh, another thing… how do I know what vertical datum I should be using? And this may sound like a newbie question, but should I be setting things up using ellipsoid height or ortho height? OPUS gives me both.
Thanks to all who are reading this and responding. It’s been 20 years since my last Geodesy course in Graduate School and GNSS technology has changed a bit since then. Geodesy was never my strongest topic to begin with, so I appreciate all your constructive feedback and I’m excited to be re-learning.
Hi Scott,
Welcome to our community!
My plan is to use your strategy of returning to the field multiple times and that is why I’m trying to set up a new “known location” through NRCan.
As I see, the log you tried to process in NRCAN is deleted now. Is there a chance that you can share it one more time so that I can take a closer look at the data? In case you have a UBX log from the same survey, please send it to me as well.
So when I set up my base station over this OPUS derived point, do I need to first do a transformation from the opus provided NAD83(PA11) or ITRF2014 coordinates to WGS84 and use that transformed coordinate as my known point?
Each coordinate system in ReachView 3 has a corresponding datum. In order to apply the projection correctly, base coordinates should be entered in LLH in the same datum. When you create a new project in ReachView 3, you can see a note about the datum required for the base:
If I am using RTK and getting a “fixed” correction over LoRa, I’m assuming I don’t need to run it through RTKPost to get more corrections?
PPP services allow you to get absolute base coordinates. If you set the base with absolute accuracy, the rover will determine its position with absolute accuracy in RTK. So, you will not need to post-process the data afterward.
should I be setting things up using ellipsoid height or ortho height?
It may depend on the needs and requirements of the project. GPS uses WGS84 as the reference coordinate system, which is convenient since ellipsoid is a mathematical approximation of the Earth’s surface. However, the actual Earth’s surface differs from the ellipsoid significantly in many areas.
A geoid is a locally calculated representation of the actual shape of the earth which is based on gravitational data. So, even though both ellipsoidal and orthometric coordinates are precise, in most cases, orthometric heights are more practical for fieldwork.
If you would like to use orthometric heights in a project based on the NAD83(PA11) datum, I’d suggest choosing the ASVD02 height vertical datum based on the GEOID12B. You can learn more about the setup we recommend for the USA in this guide.
Thank you for the help Kseniia. Here is the link to the zipped file I originally shared in this post:
I’ve sort of abandoned NRCan for the time being and started using OPUS, but my question about setting up the base station is the same regardless of what PPP service I’m using. I think I understand now, but I feel the wording, “Make sure your base or NTRIP is in NAD83(PA11)” is very confusing. This lead me to believe I need to find a setting in the base mode to change the datum from WGS 84 to NAD83. Now I understand I don’t need to change any datum settings in base mode, I just need to make sure I add the LLH using the coordinates provided by OPUS in NAD83 when setting up my survey project in that datum. Perhaps the statement of caution should say something like, “when using manual mode with a this datum, be sure the coordinates entered are in NAD83(PA11), not in WGS84” or something to that effect. Or at least that should be explained in more detail in your docs. Thanks again for the help!
Oh yes, I also tried setting up a survey project set to NAD83(PA11) with vertical datum set to ASVD02, but when I tried collecting points it refused to record anything and gave me some sort of “out of bounds” error. When I changed it back to ellipsoid height it then allowed me to collect points.
Hi Scott,
Thanks for sharing the log! I’ll check it and write back.
Now I understand I don’t need to change any datum settings in base mode, I just need to make sure I add the LLH using the coordinates provided by OPUS in NAD83 when setting up my survey project in that datum.
Yes, that’s right.
The main purpose of the short note in the ReachView 3 app is only to remember the required base datum. For a more detailed description of how the base coordinates should be entered, you can check the Base Setup section for your country.
I also tried setting up a survey project set to NAD83(PA11) with vertical datum set to ASVD02, but when I tried collecting points it refused to record anything and gave me some sort of “out of bounds” error
Sorry, I missed that you are in Hawaii. The “out of bounds” error is shown if your current location is out of the bound set for the chosen coordinate system or vertical datum. As I can see from the NOAA site, the GEOID12B model covers the United States and its territories, with the exception of Hawaii where there is no official vertical datum.
Hi Scott,
I’ve processed the log in NRCAN and got the same warning. As I can see, it appears because the approximate position in the RINEX header differs from the solution that NRCAN can calculate from the satellite data.
I’ve checked that the Single solution obtained with Emlid Studio significantly differs from the RINEX header position as well. So, it looks like the issue is not on the NRCAN side.
Usually, such issues may happen if the receiver was moved during the log collection. Do I understand correctly that the whole log was recorded while the receiver was standing at the same point? If there is a chance you have a position log from this test, it would be great if you can share it with us.
Thank you for checking Kseniia. I have not run into that issue since and it was one of my first tests, so I am guessing it was probably user error. If I get a warning message like that in the future I will be sure to keep the logs and forward to Emlid.
Hi Scott,
Thanks for the details! That’s good news that you can process logs fine in NRCAN. In case you face anything similar again, please let us know.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
