Emlid

Community Forum

Getting wonky elevation readings, even after post-processing


(Bryn Letham) #1

Hi everyone, I’m very new to this and still trying to figure out how to get my Reach RS set up and running, so I appreciate all the help I can get in advance!

I’m having problems with the elevations that my receivers are getting: I’m working in an area where I know the elevation to test things out, and getting consistently low (and sometimes quite widely fluctuating) elevations. Horizontal position seems quite good, especially when I get ‘fix’. But, for example, in my front yard which is about 18.5 m asl, it’s saying I’m a couple of meters below sea level. I’ve got a LoRa setup following the Quickstart guide, and connecting to the recievers with a Microsoft Surface tablet through their wifi hotspot, and I have been averaging the base point, but still getting low elevations.

I then questioned if maybe it was normal for the accuracy and precision to be off until post-processing, so I post-processed a test log of data gathered over about an hour, following the Post-Processing tutorial (I did everything the same except I just downloaded the RINEX 3.03 files straight away rather than using RTKCONV). Again, the lat long positioning of the post-processed data looks very nice, but the elevation of the base is still off — its a bit higher: 4.42 m asl, but still nothing close to the real elevation.

Does anyone have any ideas as to what I’m doing wrong here? It’s critical that I get these things set up to record accurate real world elevation within a week!

Thanks so much for any help anyone can give. All the best,
Bryn


#2

Reach is showing you Ellipsoid height. If postprocessing you can apply a simple geoid model, but it can still be of.
Its been asked before here


(Bryn Letham) #3

Hey, thanks - that makes sense. But I tried converting the height using this website: https://www.unavco.org/software/geodetic-utilities/geoid-height-calculator/geoid-height-calculator.html

And got an even more wrong elevation: -9.572 m asl! (proper elevation is about 18.5 m asl, as measured by filtered and corrected LiDAR).

I’m going to go up to a field today and try again, just to see if its something to do with the area I was working in (residential neighbourhood). But in the meantime, I do have some related questions:

1, Is there any way to tell the RTKPOST to post-process the data into orthometric height, rather than having to manually type it into the converter application on websites such as the unavco one?
2. If I use the survey tool to gather points, is there any way to correct those (and/or just those) through post-processing? In the post-processing tutorial the output just seemed to be where I had walked with the Rover, and I was not able to identify the specific points that I had surveyed…
3. is the post-processed file created by RTKPOST (the .pos file) able to be opened in QGIS or converted into a shapefile? I was able to open it in RTKPLOT but only to visualize it - not query the elevations of specific points, etc. When I tried opening a shapefile of my survey points from my test project that I had exported in RTKPLOT, nothing showed up.

Thanks again for any help and advice with my novice questions. I’m really hoping I can sort out what I’m doing before I start my field research!


(Pascal) #4

@bryn.letham :

  1. See option for geodetic height and geoid model in option / output.
  2. Survey points is only an average of coordinates, RTK corrected or not in real time, but not raw observation data subject to process. To have raw data records, you should start and stop rinex records on each point, and process them separately
    3 pos file can easily be formated to be handled by QGIS. Make it a csv or tab delimited from Excel.

#5

I tested it with my own coordinates and the geoid program is of by 1,5m . So its not entirely correct.
How accurate the calculator is depends where you are located.
Also notice the difference between ellipsoid height, geoid height and orthometric height.

Your ellipsoid height is basic start for any calculation of height. This guide is usefull too https://docs.emlid.com/reachrs/common/tutorials/placing-the-base/

1.I havent seen any way rtkpost can process orthometric height yet.
2.I think mobile topograher gives a better geoid conversion on the fly at the moment, it also saves each point as you wish
3. if not you can postprocess it to a .kml or .gpx file and open it with qgis.
But i havent had any luck getting qgis to work with other height models. Ref this thread

Got a tip to creating your own projection and reproject layer to it. Not got around to do this yet


(Bryn Letham) #6

Hi Pascal and TB_RTK,

Thanks for your replies and answers to my questions. I did a new test and I was indeed able to get the geoid height through post-processing, which was definitely the intitial issue. But this of course generated a new related question: I ran a test in a relatively open area, and gathered data for about an hour. I then post-processed using two methods, both with a geoid height output: 1. using RTKPOST, and 2. using the NRCAN PPP web service (I live in Canada - this is a government-service where you can upload RINEX files and they get processed; they send a report and results in various formats — seems very nice). However, now the heights of each corrected point vary between post-processing: my RTKPost-processed base station is supposedly 76.065 m above geodetic sea level (I got this reading from clicking on the base station point in RTKPlot) but my NRCAN Post-processed base station elevation is 68.853 m above geodetic sea level (I got this by averaging all post-processed measurements gathered for my base station over the hour-long period). Any ideas what this discrepancy could be from? (unfortunately, I stupidly tested in an area where I don’t have precise previously measured sea level to compare against, but I know that it’s ~70 m asl, so both outputs are in the right ballpark — but which one might be right?).

I also notice in my output log for all data gathered by the base station (which I did not move at all during the entire data gathering period) that elevation records vary by up to 10 m around the median. Is this normal (i.e. to have any hope of an accurate elevation, for how long should I let the base gather data… ?because clearly with that much variation, using anything less than the 30 minute maximum for averaging single points for setting the base in ReachView seems like there would be a pretty good chance that the averaged elevation could be way off…

And one final issue that I noticed in my test: when I started out, I wrote down my rover elevation, then walked around a bit testing things, and then returned to my rover starting point — however at this time, ReachView said I was 0.9 m higher. I did not modify the height of my rover at all, and I had ‘Fix’ both times. I was under the impression that once set up, even if ‘real world’ positioning is off, Rover measurements relative to base should be very accurate — so what could explain nearly a meter of difference between the two measurements at the same position?

Again, thanks everyone for your replies and help; this seems like a very supportive community! I feel like I’m getting close and closer to having this thing up and running as it should be, there clearly just a few setup things and some understanding that I am missing…

PS. TB_RTK, what is Mobile Topographer?


#7

Mobile Topographer Pro is an android app. http://www.stgrdev.com/apps/mobile-topographer-pro/


#8

Did you log this test of your. Usually get straight to problem with raw logs.


#9

As note to height conversion, ellipsoid is used and if you get wrong result it is most likely the datum/conversion method used that is causing it.
Also ellipsoid height from same location, output can vary from place to place.


(Bryn Letham) #10

raw_201707161748_ubx.zip (9.5 MB)
raw_201707161803_ubx.zip (7.8 MB)
Here are the raw logs. the first is from the base, and the second is from the rover. Thanks!


#11

At first it looks like you have some multipath and interference on low angel. 40degr and below wich again is not good for measure. I could see fix jump around and if using the wrong setting in combo with satellites you would experience strange measures.
Now, i just processed using random satellites and 40degr mask and got 80% fix and a closer look shows heigh difference between start en end to around 10cm. I think that is fair, not sure you measure at the same level, start and end point were not the same spot. And taking into the account Z= 2 times the horisontal value, this is pretty allright result. But you can get it much better by sorting out setting to use and avoid obstructions and interference from nearby objects.

Hop this give some ideas.
For the record, what setting did you use?
Averaging base would not give accurate readings, to do this kind of measure i would recommend surveing from a known point and use data from there. Averaging would give you only accurat relative values, which i have shown to be ok.
Bottom picture shows height from start to the end.


(Bryn Letham) #12

Hi again TB_RTK, wow, thanks so much. Yes, the 10 cm difference after post-processing is entirely reasonable, because I wasn’t exactly on the same point, and I didn’t bother leveling or anything - was just doing it as a quick test. I guess the lesson is to not put too much into the field readings and wait for post-processed results :slight_smile:

As for my settings, this is all super new to me and my level of comprehension is low, so I am sticking with mostly either the defaults or what is recommended in the Reach RS docs/tutorials.

I’ve got my two units connected by LoRa, Frequency: 1000.0 MhZ, output power: 20 dBm, Air Rate: 9.11 kb/s

In RTK settings for both base and rover I have:
Fix-and-Hold
EV Mask: 15 degrees
SNR Mask: 35
Max Acceleration: 1 m/s2 for both vertical and horizontal
GLONASS AR Mode: off
GNSS Select: GPS, GLONASS, SBAS, QZSS
Update Rate: 5 Hz

In base mode, RTCM Messages are:
GPS L1: 1 Hz
ARP Station: 0.1 Hz
GLONASS L1: 1 Hz
SBAS: 1 Hz

Again, I don’t really understand what these mean, I’m just following the suggestions from the documentation that I read.

What does multipath mean?

I think later today I might write up a detailed description of my field application and the results I am hoping for, and then maybe you guys can provide any tips that you might have for setting up in the area I’m working.

Thanks again! Best, Bryn


#13

@bide showed me a great explanation for multipath

Would guess changing to continuous and set elevation mask to something higher,about 30degr. would help a lot.
Fix&hold could affect and give fals fix. Glonass AR might also helpm but only when you use reach as base.

Other then that, rest your learn as you go. :slight_smile:


(system) closed #14

This topic was automatically closed after 100 days. New replies are no longer allowed.