[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Geoid models in GPS receivers

From: Gary E. Miller
Subject: Re: Geoid models in GPS receivers
Date: Sun, 22 Nov 2020 13:39:53 -0800

Yo Greg!

On Sun, 22 Nov 2020 09:56:32 -0500
Greg Troxel <> wrote:

> "Gary E. Miller" <> 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:
>   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
>   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.

> >
> >  
> 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:
> >
> >
> > 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:
> and the recorded geoid height (in Vespucci, android OSM editor) was
>   -33.230
> geographiclib says
>   -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

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

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

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

Attachment: pgp5Y9Ubvoos3.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]