What did I do wrong?
I setup a project using NAD83 & NAVD88 Geoid12B
I set base station on known coordinates on the same system as the project. (I.e. Known point coordinates is also NAD83/NAVD88.). Thus, I entered known LLH from the NAD83 and did NOT enter WGS84/Ellipsoid elevation.
Connected the Base to the Rover via LoRa for corrections.
Then, I used RS2 rover to collect points. Got fix on all of them.
I ended up with a substantial differences in elevation and several ft differences in XY.
Should Iāve done everything in WSG84 and ignored the new NAD83 feature in Reachview 3?
Although I donāt know anything about the Reach view 3 data collection ( I use my M2ās for static), I thought it didnāt matter whether it was from WGS84 coords or any Lat/Long system, it should output the solutions from any geographic system started out with from what Iāve read here on the forum. I may be wrong though.
I think if Emlid is going to have a following from professional land surveyors, they need to concentrate on their base setup proceduresā¦ too much room for confusion. Every professional GNSS system Iāve used either has a known coordinate entering procedure using any defined datum/projection or āhereā position method for the base setup. Select the proper coordinate system and go from there. Using WGS84 is fine for us seasoned users, but for users not knowing the details in understanding projection systems, datums and proper conversion routines, Emlid will be lagging behind in professional GNSS tools for the land surveying community. Too many Surveyors not knowing the difference and selecting lower priced systems will be disappointed and frustrated with their purchase.
Our firm uses Javad equipment and have used various different GNSS systems in the past starting off with Trimble back in the late 80ās. I bought my M2ās just for use as basic static receivers due to their cost and ease of use. They are great receivers for that purpose for my uses. I have been hesitant in purchasing the LoRa radios for the reason Salagha stated above. Too much room for error in Emlidās approach to such a simple issue.
From what I understand you enter the NAD83 LL and the ellipsoid height into Reachview 2 and then setup your Reachview 3 project with your EPSG code and Geoid and the program automatically computes the orthometric height when the points are collected. The problem here is that you would have to have that NAD83 LL up front or do an averaging and convert the WGS84 LL to NAD83 and then manually enter it. Of course with averaging you would need another known point that you can get the coordinate for later to shift everything and make the averaged base point reflect its real position. I think the way their system is setup right now is much more conducive to NTRIP use than a local base. This is why we use FieldGenius right now, although we did recently start using NTRIP and stopped using localizations for all of our drone work so the corrections are done in CAD. Maybe now that we are using NTRIP I should go back and try it with Reachview 3 for simply setting GCPās. Either way I still have to apply best practices and shoot the local benchmarks to be relative.
Thank you for your reply.
Actually, I entered NAD83 LL and orthometric height for the base station. This appears to be a mistake. The system expected an ellipsoid height for the base. I presumed since Reachview 3 data collection is using local NAD83 and Geoid12b, then same coordinate system will apply to the Base station. Apparently, the software uses or expect different coordinates systems for the base station from the Rover.
To summarize for the benefit of the group:
1- Set up the Base on known ground elevation and NAD83 coordinates.
2- Convert the existing ground elevation to ellipsoid.
3- Enter the ellipsoid height for the base.
4- Verify that the Reachview 3 and RS2 conversion algorithm for Geoid12B is re-producing the known ground elevation.
5- Make adjustments if there is a difference.
6- Proceed with the Rover survey using the adjusted, verified process above.
Can Emlid experts verify or comment on the workflow above.
I am in agreement with Bryan. It would provide parity with other Professional GPS devices if the base setup is as simple as :
Setup -> Pick your Unit System -> Pick Horizontal Datum -> Pick Vertical Datum -> Input Northing, Easting and Height (Orthometric)
or
The āHEREā function Bryan refers to, For those unfamiliar, it is like the averaging coordinate point currently but it will spit out data in the units and coordinates the user prefers
I would advise switching back to pure WGS84 for GPS and then occupying known state plane GPS benchmarks for horizontal and city benchmarks for vertical. Then use a least square adjustment to translate/scale/adjust to state plane.
It takes the potential for catastrophic setup errors/discrepancies out of the equation. You can really hurt your project budget the more times you have to return to the site to double check a cp or shot.
The hardware and software have come an incredibly long way, and I was able to start a small business thanks to this equipment and Emlid. I have no doubts they will get to that point given more time, especially how rapidly they have already built up Reachview just in the last year.
Iām sure Emlid will sort things outā¦ I look forward to them approaching the level of the big guys. In a way after thinking about their process, it makes sense in the approach theyāve taken. All GNSS systems, datums and projection coords are based on the WGS84 system. Itās that it is not a familiar method to the ordinary land surveyor. Weāve been spoiled by the big guys in the ease of their systems. A friend of mine has been frustrated using Emlidās system as he has no knowledge using any GNSS tools or even the basics in land surveying. Itās been frustrating for me as he is hesitant in learning and expects to start mapping out of the box. He doesnāt realize he needs to learn the basics before beginning any aerial mapping.
I think anyone planning on using any GNSS system needs to understand the basics in datums and projections before they start out. All of my knowledge is from college mapping courses from the late 70ās and real world use when GPS was just a possible dream for the Surveyor. I was fortunate as we were one of the first surveying firms in SC to employ GPS in the late 80ās.
Visit the NGS ( National Geodetic Survey ) website
I think the other thing to keep in mind is that the larger manufacturers especially Topcon and Trimble have spent an inordinate amount of money on software development as their ecosystems extend well past standard survey use. They tie to design systems, GPS machine control and data processing so they pass the buck to us when we spend $15k on a receiver and data collection hardware and software. The data collector and software licensing alone is easily $4-5k. The ability to use a free software and sub-$300 mobile device is appealing enough that we should have our expectations set fairly. Reachview has come leaps and bounds even in the 2-3 years that I have been a user and I canāt wait to see what this year brings.
That said we do perform full survey functions and being used to spending the amount we do on āhigher endā gear made it an easy decision for us to substantiate the use of Microsurvey FieldGenius which takes the Emlid devices to a new level and even on par with those larger manufacturers with the exception of the larger ecosystem they have built.
It is not easy to understand if one does not know about terrestrial reference systems and frames.
The simplest is what Chascoadmin mentions.
Convert coordinates in WGS 84 to NAD 83 and keep the ellipsoidal height to enter the base, then Rechview 3 (Rover) will do its job to determine projected coordinates in NAD 83 and the selected orthometric height. I would do a control with some known coordinate point in the projected system. The difference between wgs 84 and nad 83 currently varies by 2 meters depending on the speeds of the time of calculation. At higher geodesy level it is much more difficult than this simple explanation nad 83 and wgs have different ellipsoid parameters
Thanks for your suggestions! We strive to make our devices and software as easy to use as possible. So, weāll think about how to make the process more intuitive in the future.
Let me explain the whole process not to get confused:
Create a project in NAD83 & NAVD88
Enter the base coordinates in NAD83 and the base antenna height offset. Please note that the height entered for the base should be measured above the NAD83 GRS80 ellipsoid.
Enter the roverās antenna height
You can collect a known point to check if the position matches the one you know
Proceed collecting points with the rover
If you have any questions about the workflow, please let me know.
What about when coordinates for Survey Mark or Control Points you have are Projected Coordinates and Orthometric Height. What do I do about the height in that case?
At the moment, our software supports only ellipsoidal base station heights. If you know only the baseās orthometric height, you may transform it to the ellipsoidal one with 3rd-party software or online tools. The required coordinate system of the base is shown in ReachView 3:
I got good results using the following workflow:
1- Created a project using NAD83/NAVD88 coordinates
2- I set the RS2 at the base location and obtained RS2 generated ellipsoid height and compare it to my orthometric height. (To calculate the difference between the two heights)
3- For verification, I calculated the geoid12B height using NGS web page and added grid to ground correction to check if I get the same ellipsoid height as RS2.
4- I entered the ellipsoid height generated from the RS2 gps fix to conduct the survey.
5- Results were good and within acceptable range.
what if i setup a base on other location near the BM/Control Point
Average position, and input that position, alt and height (manually) on Base
Start RTK/PPK survey and occupied the BM/Control Point also other GCP point.
When finished, then i 3Dmove/shift all the survey result base on the surveyed value of BM/Control point to the original of the known positionā¦
What do you think?
How has the Microsurvey product been working out for you?
I have been experiencing similar issues with elevations being off, and consistently off(2.5ā) the same amount in the horizontal. Seems like FieldGenius may facilitate faster and more intuitive setup and production of results.
It depends on what kind of work you do, but for our needs (drone mapping) itās a different level than Reachview. You still use Reachview for the configuration of the receivers, but after that you just setup a new project and the first run you get all of your typical settings done. After that you just pick your horizontal datum and your geoid. You also have the option to do a localization if needed. I donāt need it for my department, but our surveyors setup control for construction based on localizations of the CAD files compared to what is actually on the ground. When I check into their localized network which has a vertical based on ground benchmarks I am almost almost within 0.2ā of their elevations. I can localize and be spot on, but all I really need to do is adjust my verticals a little in CAD and it works for what the drone does. We recently started using NTRIP and I had no idea. Now I get on site, turn on my hotspot, turn on the RS2, boot up FieldGenius and start collecting points within 5-10 minutes.
If you have a known point nearby, Iād suggest placing the base on it and manually inputting its coordinates. In this case, you will get the coordinates of all GCPs with absolute accuracy, and there will be no need to apply any shifts.
