I am using with SW Maps on an Android Tablet. Everything seems to be working great, except the elevation is incorrect (it says -35ft when it should be around 125ft) both in float and when using it with a web based NTRIP connection through SW Maps. It moves up and down correctly, but is as if an offset has been set somewhere for elevation?
How are you obtaining what the elevation should be?
The default altitude output by most GNSS receivers (including the RTK line) is HAE or height above ellipsoid. This will vary from altitude above sea level.
Please see this tutorial (https://docs.sparkfun.com/SparkFun_RTK_ ⌠ification/) on how to obtain a local reference NGS monument and verify your setup against a known good point.
I was curious about this as well. I was just comparing to Google Earth and noticed a large discrepancy.
How would I go about to converting these numbers to height above MSL? May of the geophysical logs I am comparing to the logs at our positions in the field reference MSL.
To elaborate on @sparkyâs post:
There was a recent thread on this topic and what the SparkFun units are doing here:
That page helps explain orthometric height (H), ellipsoid height (HAE or h), and geoid separation (N). There are many excellent web resources to explain this topic.
TLDR:
To compare the height displayed by your software (SWMaps) and your field logs:
-
You need to figure out what vertical reference datum your field logs use. Hopefully the author of the field logs documented it and the logs are consistent.
-
You need to figure out what type of âelevationsâ your software is displaying elevation in.
-
Youâll need a good RTK Fixed solution, and youâll need to be careful with your instrument heights and GNSS receiver antenna models.
Details, detailsâŚ
ONE:
Youâll need to find out what reference your field logs used for MSL. There is no one standard for âMean Sea Levelâ. If youâre in the US, common vertical reference datums include NAVD88 and NGVD29. The term âMSLâ is vague, itâs considered imprecise. Itâs more precise to specify the vertical datum you are using. There are many vertical datums throughout the worldâs various countries and throughout history. Here is info on the two commonly used in the US:
https://www.ngs.noaa.gov/datums/vertica ⌠1988.shtml
https://www.ngs.noaa.gov/datums/vertica ⌠1929.shtml
NAVD88 is implemented via a Geoid Model. This is a mathematical model of a lumpy spheroid that represents what used to be called âMean Sea Levelâ. That is, the geoid approximates where 0â above mean sea level would be in imprecise terminology. There are multiple geoids, and the National Geodetic Survey updates the geoids as they collect and refine their data.
TWO:
GNSS receivers internally calculate the height above the ellipsoid (HAE), but often they have an imprecise, almost crude, geoid model built in to approximate orthometric height. The NMEA specification is that the GNSS receivers output the orthometric height and any geoid correction that the receiver has built-in to determine the orthometric elevation from the HAE. The software that interprets and display the âheightâ could be doing three things:
-
Display the âcrudeâ orthometric elevation based on the built-in crude geoid model.
-
Calculate the HAE by backing out the crude geoid model to determine HAE.
-
Do #2 above and then apply a different, hopefully more accurate, geoid model chosen by the software and the user of the software.
When I look at the âGNSS Statusâ in SWMaps (iOS), SWMaps is very clear about what it is doing. It provides three different elevations:
a. âEllipsoid Heightâ, or HAE. It is almost certainly doing #2 above to calculate this.
b. "Orthometric Height (GPS). This is almost certainly #1 above.
c. âOrthometric Height (Geoid)â. This is almost certainly #3 above
I commend SWMaps for being very clear about how itâs displaying the elevation info. This is rare among GP, mapping, and hiking applications.
You can manually calculate your geoid-ellipsoid separate (N) here: https://geodesy.noaa.gov/GEOID/GEOID18/computation.html
THREE:
GNSS elevations are very sensitive to the operating and field conditions. You can have great northings and eastings and not-so-great elevations.
âYouâll want a clear view of the sky, a good RTK Fix, and check your PDOPs.
âYouâll want to keep the baseline (distance) to the network reference station (âbaseâ) short. People have different ideas of short, but I start to keep a close eye on things if my baseline is more than 10-20 miles.
-Youâll want to go back an hour or two later, or the next day, measure again, and compare the measurements to be sure you arenât getting bad RTK Fixes. They happen.
Itâs also important to accurately account for the elevations of your GNSS receiver antenna above the mark on the ground you are checking the elevation for. I doubt this is causing a 160â discrepancy, but it could be 6â of it. Surveyors use rods that have the instrument height marked on them, and they check the height with a tape measure routinely.
Hope that helps,
Tony.
1 Like