Re: Geoid models in GPS receivers

[Gary E. Miller]

Yo Greg!

On Sun, 22 Nov 2020 09:56:32 -0500
Greg Troxel <gdt@lexort.com> wrote:

> "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.

I would like to see your gpsprof scatterplot.  NTRIP goes bad quikcly
as the baseline increases.

> MaCORS is outputting MSM4 for all 4 constellations, so my receiver is
> getting to use a huge number of signals.

Most people report better results with GPS only.

>  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.

I have not gottne gpsd to work with any virtual base station NTRIP
yet.  That GGA things.

> 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.

Dunno, not looked at it thaht closely.

> >> 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.

Sadly not always the case, depending on the receiver and firmwmare.

> 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.)

Assuming your receiver has the very large database rquired to make the
calulations properly.  I know of known.

> 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.

Yeah, but look at the slope there.  Quite large.  Without the full
database you will lose a lot of precision.

> > 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.

The slope is non-linear.  Very steep in clome places, where nearby not
so much.  Try to find a chart of the effect.

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

Yes.  And that compuer does not have the 164MB geoid database.

> > 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.

I make no assertion of the relative size of the many possible errors.
The geoid is one, fundamental trig another, ionosphere and troposphere
delays are also large.

> And
> interesting that the chip in my phone (       Qualcomm MSM8996
> Snapdragon 821) has what appears to be the same reduced model as the
> F9P.

All the Qaulcomm  I know of are SiRF V.  A different beast.  Why would
Qualcomm use u-blox when they own SiRF?

> 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.

I just see randomness between models.  And older models which match up to
older surveyed height better because they used the same model version.
 
> > 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.

Everyone I know pretty much feels the same way.

> 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.

SiRF doc is almost non-existent now.  No way to know what is going on
inside.

> 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.

Can you compare your phone geoid separation to the gpsd one?

> 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.

Yet another question for u-blox.  Too bad they do not answer questions.

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

Some of us will follow you down the rabbit hole.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp5Y9Ubvoos3.pgp
Description: OpenPGP digital signature