Re: Geoid models in GPS receivers

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

>> I am continuing to measure things and evaluate an F9P.   It's working
>> remarkably well with MaCORS, and I am feeling like I'm getting
>> repeatability at the small numbers of cm level (just not sure exactly
>> how many yet).
>
> My NTRIP is 1km away and I have trouble getting more than a few meters.
> The long term wander is better than the 8-series, the big win is the
> much reduced short term fuzz in the fix.

That's really interesting that you are having such a worse outcome.  I
am using the ardusimple calibrated dual-frequency multiconstellation
antenna.  I am getting high-precision NMEA output that looks like only
cm-level fuzz over a minute or so, and repeatability day to day close to
that, or at least not more than 10 cm.

MaCORS is outputting MSM4 for all 4 constellations, so my receiver is
getting to use a huge number of signals.  I am using a mountpoint with
"IMAX", so the network (Leica) is computing a VRS for me.  I should also
experiment with the single-station mountpoint; that's about 20 km away.
1km is certainly considered quite close in RTK terms.

From power on, my output gets within several meters (of my previous
fixed solutions) quickly as the 'NO RTK" light goes out, about 60s after
powerup.  I then see slow wander, generally toward the right place.
After another 30s to several minutes, it snaps to a new position usually
less than a meter from where it was, and thereafter has only cm-level
wander.  That's pretty obviously the RTK FLOAT to RTK FIX transition.
Sounds like yours is not managing to go into fix mode.

I've also done trail mapping in wooded areas, and find that I get about
0.5m agreement between the tracks going in and out on access trails
(eg. 1h20m separated in time).  This includes my trail centering error
as I'm walking and any non-alignment of the antenna with my own
centerline (due to how it's mounted on a backpack), plus all the actual
RTK errors.

>> MaCORS is in "NAD83(2011) epoch 2010.0" which is I think normal for US
>> reference networks.
>
> Not to be confused with WGS84.

Indeed.

>> Because the receiver doesn't know that, it's processing solutions as
>> if they were in WGS84(G1762), and taking the HAE and applying a geoid
>> correction to give me something, which ought to be "EGM2008 height" as
>> proj calls it.
>
> A fine mess.

True.  But I would hope that because the receiver took XYZ to LLH and
then did a geoid model lookup to get LL(altitude) then if you take
altitude and back out the reported geoid offset you are back to the LLH
it had.

And yes, i realize that taking XYZ or LLH from receiver binary and not
NMEA avoids all of that.

>> Looking at geographiclib and NGA's Fortran code for EGM2008 (thanks
>> Javier if you are listening here), I found the geoid separation for
>> 42.5 -71.5, which is the canonical round number for "halfway from
>> Boston to Worcester", more or less, and I got -28.772 m which I
>> believe.  EGM96 is only 10 cm different.
>
> Out here on the West coast, the error goes up to 2 meters.  10x that
> in Hawaii.

Nominal Pacific northwest coords:
  
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=46+-123&option=Submit
  The difference between EGM2008 and EGM96 is ~43cm.  (I am not
  considering EGM84, which is 2m off; AIUI the public version of EGM84
  had significantly reduced precision on purpose.)

Nominal Hawaii
  
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=21+-158&option=Submit
  50cm from EGM2008 to EGM96. EGM84 is only ~2.7m different from EGM2008.

>> On an android phone, I'm seeing a geoid offset in internal NMEA (via
>> GPSTest) as -33.0m.  I'm also seeing -33.2ish from Vespucci using the
>> F9P over wifi, getting high-precision NMEA.  These values are pretty
>> stable over 10s of km; there is no geoid slope of 4m in 20km around
>> here!
>
> No, there is a geoid slope, but your phone does not have the 165MB data
> base to do it right.  Get it here:
>
> https://sourceforge.net/projects/geographiclib/files/geoids-distrib/

I realize there is a slope, but if I plug in points that are 0.1 degree
different into geographiclib's online calculator, I see only 10-15 cm
change for 0.1 degree change in lat or lan.  What I meant is that if you
move 20km, the geoid change is nowhere near 4m.  It's maybe 20cm.  So
yes, if being precise you need to pay attention to that, but the theory
"the -33 value is explained by a huge geoid slope" doesn't make sense to
me.

And by 'phone', I'm pretty sure this is coming from the embedded GPSr
portion vs the phone-is-a-computer portion.

>> I'm still digging into this and have more investigating to do, but my
>> question is:  Does anybody have any experience with the geoid models
>> in u-blox receivers as  exposed over NMEA?  Do they do the right
>> thing? Any clues?
>
> Not enough ROM to do it right.

So you are basically saying that they have compressed the model so badly
that they are producing a value which is 4m off.   And interesting that
the chip in my phone (  Qualcomm MSM8996 Snapdragon 821) has what appears to be
the same reduced model as the F9P.

My memory is that things like the Garmin GPS II+ and V had much better
geoid models and I was seeing -29 locally, which is getting into the 10s
of cm range.

> If you really care, take the ECEF
> position and compute the geoid offline.  If you want a really accurate
> geoid, go here:
>         https://geographiclib.sourceforge.io
>
> gpsd uses those two to compute a much cut down database that approximates
> well.

Sure, I understand how to do it from XYZ, or LLH, but I am finding the
errors far larger than make sense.  It's not like the F9P has no
processing power and storage -- it's doing RTK.


For a less fuzzy datapoing, yesterday I went to a town boundary marker:
  https://www.openstreetmap.org/#map=19/42.39002/-71.47270

and the recorded geoid height (in Vespucci, android OSM editor) was
  -33.230

geographiclib says
  
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=42.3900197+-71.4726657&option=Submit

  -28.9841 (EGM2008, with max fuzz among models 6 cm)
     which is 21cm different from my canonical point

So yes, the geoid slope is bigger than I initially thought -- thanks for
provoking me into looking up more points -- but it's still only 5% of
the difference from EGM2008 to what the receiver is doing.

Poking around more, I guess a theory that the receiver models are using
a grid of 10deg x 10 deg, and not interpolating, and just picking the
closests value, might fit the observations.  But I have a hard time
believing that's what the receiver is doing.  Even if you want to put
the data in 10kB (e.g. 5x5 grid of values, 32-bit float), surely you'd
still do a basic linear interpolation over the 4 points.

I observed 5 boundary markers.  Each of the coordinates, when rounded to
0.1deg, ends up 42.4 -71.5.  The F9P is reporting different geoid values:
  -33.187
  -33.211
  -33.230
  -33.233
  -33.240

on points taken over an area that is somewhere arond 7km x 7 km.  So it
certainly looks like it is doing something more than picking the nearest
coarse grid point.

I'll report back if I actually figure anything out, as this seems likely
at least dimly interesting to others.

signature.asc
Description: PGP signature