Well I might have understood it wrong. Maybe there’s no transformation at all, ever, on the receiver side and that’s why it asks that the base should be in the same datum. In which case yes, the project could be in the correct datum in the first place.
1 Like
Only one way to find out, more points, more checks.
At least now with PPP you can have a personal monument for quick accuracy checks.
1 Like
It’s just cumbersome to use or even see geographic or ellipsoid height values in the field for the land surveyor. As a user in the field, once I select the coordinate system at the base, I want to see plane coordinate values and orthometric heights, i. e. meters or feet, not geographic values or ellipsoid heights being averaged for the base point. The geoid model should automatically be loaded once the coordinate system is selected. If I go beyond radio range, I want to be able to select any field located point and move the base to that point and continue onward collecting data. I want to be able to inverse between points in the field. I want some kind of additional field verification for my RTK collected points, I. e. distance and azimuth to the last point located and some kind of statistical confidence level for my RTK located point.
All this needs to be done in order to attract Land Surveyors to Emlid’s system. As a minimum, these requirements should be implemented for any basic RTK system. COGO routines can be implemented later.
6 Likes
I always learn lots from your posts.
I think only the base coordinates have to be in LLH though.
So orthometric height does that mean 0m being the local desired ground level?
1 Like
Yes. I disagree with you on the geographic coordinates, they are useless for land surveyors in the field surveying. How do you inverse between points using geographic coords ? You have to convert the geographic coordinates to some kind of local projection, then you’ll have a linear system to use (feet or meters).
4 Likes
Welllll… that’s what us Americans prefer…especially surveyors of course! But we are dealing with more of an international product here that utilizes the metric system and ellipsoidal height and has from the start.
Emlid is now catering to the highly requested Coordinate system we all asked for. Which is great!
I “avoid” all that “cumbersome” stuff by just not using the ReachView2 or 3 app for survey work…but instead use a third party solution such as FieldGenius for survey and staking out.
This way it feeds the ellipsoidal height (and shows it so I can see it), but also at the same time gives me the coordinate system of choice (i.e. NAD83) I set the file up as along with orthometric height from a loaded GEOID file i.e. GEOID12 or GEOID18 etc.
3 Likes
My property survey is done in the most bizarre way possible, they give the Base reference point in decimal meters northing and easting. Then the rest is done by chainage from the base in meters and Lat and Long headings, but if you mathematically figure out the points from the chainage you can just go right out to locate them with the GNSS.
You think it would be easier to just give the points. But this is Canada.
1 Like
Wow, some gooood stuff! I am going to have to digest and come back. I’ll throw the other monkey in the wrench later with how we have to handle it in construction with localizations and such. So many ways to get a control point, benchmark and corrections…
3 Likes
How many bananas is that? 
2 Likes
Ok this must be a surveyor inside joke, please explain.
Bananas are shipped here from Guatemala as far as i know
I always learn stuff here too ! Especially your reverse engineering ! You should be working on recovered alien vehicles the military has !!
You, Michael, timd1971, G Geomatics, davehofer1993, of course Emlid support and others have a great deal of knowledge to contribute. I can’t list all who’ve responded to my posts, but y’all know who you are. My brain gets so full of stuff, it’s leaking out by all my grey hairs on my head !
2 Likes
Wow, some really great reading here (Hope I am understanding it all).
So, when using Reachview 2 I should convert the known points coordinates on the datasheet from NAD83 (2011) into EPSG 4326 WGS84 and place it in the Base Manual section.
Then in Pix4D have the GCP and Checks entered in as WGS84 and then output the orthomap into my desired coordinate system.
This is at least my understanding of all of the above.
Thank you! If you know anyone at Area 51, let me know.
I think it is the big race to see how many things we can do with these Emlid units. This level of precision was just an unaffordable dream until very recently. Especially for machine control, which persists on being expensive.
Now its to get precise to the measured and recorded world, and that is a very big subject.
2 Likes
I got burned by this issue the other day during a demo for class I’m teaching. I was trying to demonstrate basics of RTK using both a local base and then using NTRIP. I went into the field with OPUS solution from previous static occupation over a monument - had both NAD83(2011) (EPOCH:2010.0000) and ITRF2014 (EPOCH:2021.33986) coordinates. Set up RS2 base station over mark, measured antenna height, then attempted manual base coordinate entry.
In the field, I tried to search Emlid doc and forum on which coordinates RV is expecting, but couldn’t find a quick reference on the expected coordinate system for manual base setup in RV. I saw “WGS84” on the forums, and assumed ReachView would use ITRF current epoch by default. I didn’t realize there were differences between RV2 and RV3.
For the RTK survey, I was using Washington North state plane coordinate system, NAD83(2011) (ftUS) (EPSG:6597) and NAVD88 (Geoid12B) height (ftUS). New RV3 project coordinate transformation support is nice. I connected to local base via LoRa and proceeded to survey in points. I then switched correction source from LoRa to Washington State Reference Network NTRIP caster (base coordinates in NAD83(2011)) and reoccupied all survey points. My hope was to show the students - “look, you get the same accuracy, without having to buy a second receiver and set up a base station!”
I ended up with 1.5 m horizontal and 0.5 m vertical offset between the two sets of points - I interpret this to be the NAD83 vs ITRF offset in Seattle, WA for current epoch. Positions acquired using NTRIP (with NAD83(2011) base) were within a few cm of “true” positions from the OPUS/CSRS-PPP solutions. The positions acquired using the local base (incorrectly set up using the OPUS ITRF coord) were offset.
The current “Make sure your base is also NAD83(2011)” warning when selecting the survey coordinate system in RV3 is not the most useful, as it appears independent of the location where the base coordinates are entered (a user could already physically be miles away from base station and no longer able to connect to change). Some guidance should be provided in RV menu when entering the base coordinates.
Can Emlid update official “Placing the base” doc with clear instructions/warnings on this? I later tracked down the relevant information at the bottom of the USA page: USA | Emlid Flow and Emlid Flow 360. Would probably be valuable to add a section on how to use output from OPUS and/or PPP services, as I expect many others in the US will go this route.
@PotatoFarmer offered a good summary yesterday: RTK Workflow needed for Known Points in NAD83(2011) - #21 by PotatoFarmer. Maybe some kind of simple decision tree in the base station setup doc would be best, especially for users who have never dealt with all of these issues.
The antenna height doc for manual base setup is also still ambiguous: Placing the base | RTK Modules. The gray box with NOTE is correct about measuring antenna height to ARP. But then the following sentence says “For Reach RS2, consider the antenna height as the distance between the mark and the bottom of Reach RS2 (h on figure 6) plus 134 mm.” - implying that the user should include the ARP to APC offset of 134 mm in when they enter antenna height in RV. Probably makes sense to put RS2 info above RS/RS+, or to centralize as much as possible on setup.
Ultimately, I hope Emlid will add coordinate transformation support for base station coordinates. Allow the user to enter whatever base coordinates they have available (e.g., SPCS with orthometric heights), and then specify the corresponding coordinate system for those coordinates.
3 Likes
I set up my RS2 as a rover connected to NTRIP in las vegas NV. I select epsg 6521 (NAD 83 2011) and NAV88 Vertical Height in ft.
Use RV3. Get my points, download in CSV. them upload into Drone Deploy under epsg 6521. Everything works great. I export in 6521 also.
4 Likes
Look at civil drawing of rim height of man hole. Then look at my point from DD, Compare the two elevations
5 Likes
This is how we do it as well and is how it works when you are on NTRIP and RV3. This post is more specifically about a local base and RV2. The main question that nobody seems to be able to definitively answer is whether or not you can enter a NAD83 LLH into RV2 which would then allow you to use RV3 and SPC’s with a local base.
2 Likes
Spot on! : )
1 Like
Question, If you had no NTRP and no known point. How accurate would it be to set up RS2 as a base for like 30 to 60 min. and using an RS+ as a rover. Would I get relive accuracy? Sorry, don’t mean to high jack the thread, just too many great minds on this one…
I may have an out-of-state job to do. THANKS
1 Like
I “think” that is what the DOCS state… but cm accuracy between the RS2 BASE and the RS+ ROVER via LoRa… but all offsetted by your derived base coords?
1 Like