I am a newbie, but after one week of reading i got very good and stable values with reachview beta. I bought your starting set. I always get a fix for the rover and it works really nice with high accurency. Here is my Setup and my problem.
Base(reach with reachview beta):
Single w fix&hold. All gnss on. No glossnass AR. All 5hz. Good skyview. Most of the time 7 sats green.
Rover(reach with reachview beta):
Kinematic w fix&hold. TCP client to base. 5hz
I always get a fix after a few minutes…So reach works and of course i have a ground plate.
My problem is the height values. In the view and logs of the rover and the base i receive wrong height values. I know a controlpoint a few meters next to the base. It is about 530m over NN. It an official measurement point.
The gps values i receive are always about 575m. The value is very stable but wrong…and i get it everytime wrong. Do I have to the base to manual and edit the height? What shold i do?
The ellipsoid height is the problem. Can i adjustment it to the right value? Is this value also corrected on the rover?
I found a different post in the forum but obviously it is not the same problem.
If you have known coordinates for the location, then use them.
However, if you only have known height and nothing else, then manually enter your average longitude and latitude, and also your known height for the location.
Hi, and welcome
Reach work and currently only display ellipsoid height. So a known height somewhere in the terrain is probably in MSL or orthometric value and natural you could get great offset. Only way to correct this is by post process (Currently).
For me, i use an app called SKtrans i have download from national mapservice and it recalculates ellipsoid height to my local HREF height (orthometric height) model by typing in position coordinates and current ellipsoid value
Some apps display MSL and can be adjusted, like mobile topograph.
Yes, the output is the ellipsoid height. Orthometric height is what elevation benchmarks usually read. Orthometric height relative to ellipsoid height can vary a whole lot from location to location because gravity is different from one spot to another thus the geoid can vary from location to location (approximate theoretical mean sea level below any land point based on gravity) . You have to use a Geoid model calculator to figure the Geoid Height for the Lat. and Lon. for the exact location you want (for example GEOID12B), and then subtract that from the Ellipsoid height reach shows. To be correct for reach, ellipsoid height should be entered if you manually enter I believe.
The satellites use an even reference ellipsoid around the Earth to get the ellipsoid height, they don’t use any single sea level spot which again can very all over the earth because of gravity differences from one spot to another.
I haven’t wrapped my head around the height problem quite yet, but I can understand the need to do those conversions in the name of accuracy.
However, for the guy who is doing some RTK within a few km of his base, and he wants his heights to be relative to a local known altitude, how far off do you think the variation between the ortho and geoid altitudes could be? (assuming that you entered your ortho height in the base coordinates)
All gps work on ellipsoid height. But they usually have geoid correction data loaded to the survey field data unit that outputs orthometric height on the fly.
I have been searching through several post and I know this one is old, but I would rather use it than start another spin-off. Can someone please post a link or outline the best way to go from the data I am getting natively from the Reach RS+ to local surface (orthometric) elevations. I am thinking I might need to start by learning some post-processing? I am a Topcon user so I have never had to do this before… spoiled. Thank you!
I know when using MicroSurvey FieldGenius9, which is similar to SurvCE/PC and Topcon MAGNET Field Layout, I can select a GEOID (GEOID12B) for my region to get orthometric vertical height in realtime (versus PPK later) instead of JUST the usual default WGS84 vertical ellipsoid height. (I would assume if one did not load the GEOID file, you could just go off the default vertical WGS84 collected data and post process after the fact to take GEOID into consideration?) Maybe see about this in your Topcon software?
ReachView Survey / Point Stake just doesn’t have this at the moment, but really needs this if you cannot or do not want to use other 3rd party options.
Thanks @timd1971. When I say I use Topcon I mean the whole solution including Hiper V base/rover which already shoot in GEOID, but in a localization of a network of known points. The horizontal from the Emlid is great as it matches my raw drone data, but I need to use the local surface elevations (via RPLS vertical datum) on the GCP’s, not the GPS height. This is because I am tuning the drone survey for comparison to design documents. I know most people aren’t doing this and are more likely just comparing drone flight against the last drone flight. I am realizing how unique what I am doing is and it is pretty evident in the drone community as well, so maybe I just have to keep doing what I am doing with the Topcon for now and wait for the industry to get it.
I wonder if I hook this up to my Magnet data collector if it would let me do the localization? I’ll keep researching.
I tried my FC-500 and Magnet and it doesn’t allow for Localization so no closer to the optimal solution. Looks like I am going to have to try some of these 3rd party solutions that enable GEOID and then do some manual calculation to interpret to surface elevations. I had much higher hopes, but at least I only wasted $1500 instead of $30k…
I do not think you wasted anything with Emlid. You just need to find the solution that “works” best for you which at the moment probably 3rd party survey software. I am not sure Emlid even advertises GEOID, orthometric, surface height, etc… just standard WGS84 ellipsoid height… anything more than that, you’ll have to implement on your own… which I understand is what you are trying to do. Yes, it’s frustrating the immediate solution isn’t provided like as if you purchased a turnkey Trimble setup for an ungodly amount of cash.
It’s surprising Topcon Magnet Field Layout doesn’t offer localization also? I thought I saw a youtube video on how to do this? I know FieldGenius9 and SurvCE/PC do this is something pretty standard.
I would download the fully operational 30 point FieldGenius9 demo to your FC-500 and download the GEOID files and go from there to see if that gets what your after.
It’s really not the fault of the Emlid receivers, it’s just 1 important part of it all to get your data you need.
Reach RS+ does not provide localisation. It works on WGS84 ellipsoidal datum. Any datum you would like to use aside form wgs84 can be implemented on 3rd party software. Example. to usemagnet set your base in Known WGS coordinates point. enter the value in reachview. select appropriate configuration. in you rover, set the Reach RS rover to outpot position in Bluetooth (nmea format) then you can used any datum. I believe the topcon software provide realtime conversion from wgs to any other datum. Dont think that you wasted a 1500 dollar. You can give it to other surveyor who really in need, consider it as a charity works. I will be very happy to accept it at no cost
Magnet does use a localization and if you are not localized you can’t do anything else accept collect satellites. I definitely didn’t mean to sound like I thought it was Emlid’s issue so I’m not quite sure where that came from, but thanks for the replies and advice. Back to the search for me.
Localization means you can use any Pre set or assume coordinates of the site. you will calibrate your gps position base on that localized coordinates then apply it to your observation. Big Boys like trimble, LEica and Topcon featured this in their Controller. While Reach RS+ provides only a wgs datum using reachview. on the the communication is only 1 way (from base to rover).
Thank you!