Re: ppp averaging and circular error of probability

[Hans Mayer]

Hi Greg,


On 10.09.22 12:09, Greg Troxel wrote:
> gpsd--- via<gpsd-users@nongnu.org>  writes:
>
> > I run PPP in averaging mode several times as described in
> > https://gpsd.gitlab.io/gpsd/ppp-howto.html  or "man gpsprof" with
> > different number of fixes. I did it for 6 hours, 1 day and 2 days.
> Beware that this page uses multiple terms:
>
>    Precise Point Positioning (what I think of as PPP)
>
>    Post Processed Positions (words that make sense but that I don't
>    associate with an acronym)
>
> It is sensible to average navigation solutions, but IMHO this is not at
> all "PPP".  The first essence of PPP is to use more accurate clock and
> orbit data.  A second seems to be to use carrier phase measurements and
> resolve the integer ambiguities, and I don't yet understand how that
> works without being differential.
>
> > When I display the result is see for example results like this:
> >
> > CEP 50% = 0.6m , CEP 95% = 1.1m , CEP 99% = 1.9 m
> >
> > So far all fine.
> As the HOWTO says, CEP is the radius of a circle centered at the mean of
> the data points that includes 50% of the points.  It is a measure of
> consistency of the data set, and is not a measure of absolute accuracy.
> If all your points were 10m north of the true position, you could still
> have a low CEP.  However in practice it's a great way to tell how you're
> doing, and without an external source of truth for a point, you can't do
> any better.
>
> I think it would be great for gpsprof to be able to read a known
> position and calculate relative to that, but
>
>    - that's not how CEP is defined, even though "radius of circle centered
>      at true position that includes x% of the samples" is obviusly useful
>    - when I suggested it, I was quite reasonably told ENOPATCH
>
> > Recently I run it for 3 days and I got a strange result:
> >
> > CEP 50% = 0.595m , CEP 95% = 1.469m , CEP 99% = 1.423m
> >
> > How can it be that the probability for 99% is smaller than for 95% ?
> > In a sense of statistics not possible.
> This looks wrong.  I wonder if there is some overflow in the
> calculation.  I bet when you send the raw data to Gary he'll figure that
> out fast.
>
> A nit: these really are not probabilities.  They are distances that
> contain a fraction of points in a data set.  So in the analysis, there
> is no probability involved at all; it's just counting.   But you are
> correct that CEP95% must be <= CEP99%.
>
> The word probable shows up because this is a method to estimate the
> underlying probability distribution of the measurement process.

But isn't it that a new measured point would fall into the circle CEP99% 
with a possibility of 99% ?

So it's a probability, isn't it ? Maybe my English is too bad to 
understand this.


> > I also calculated the distance between the different results. They are
> > all below 4 cm. So I am not sure if this CEP gives a useful
> > information at all.
> Presumably "result" means "average position".
>
> I find it interesting (and reassuring) that your 6h position mean is
> that close to the 3 day mean, but I am not surprised it's within 20 cm.
>
> Ignoring the 3 day CEPs for now as suspect, the CEP50 is saying that
> half the observed points are within 0.6m of the mean.   That's actually
> great.  You are using a dual-frequency receiver, and I'm guessing have
> an outside antenna -- but you didn't explain antenna and sky view:
> please do.

As antenna I use the recommended multi-band active gnss antenna 
HAB-ANN-MB-00-00 with SMA Connector from ublox.

It's fix mounted on the top of the roof of my house.

If I look for satellites with an elevation <= 1 degree I see some of 
them over a 24 h period.

So it seems I can look quite near the horizon

> I think you should be able to cat the logs together and process
> 6h+1d+2d+3d all at once to get an average over 6.25 days.  Except the
> apparent bug will probably happen, but hang onto that data!

See my other e-mail.

> What you don't know is the actual antenna position relative to your
> calculated means.  I don't think you can conclude it's within 4cm from
> the data you have.
>
> There's also the question of datum.  You didn't explain what mode you
> are running the receiver in.  Recent F9P firmware will default to at
> least GPS, GLONASS and at least one of Galileo and BeiDou (fuzzy memory)
> and I think SBAS.  Without SBAS, the receiver is probably transforming
> the 4 systems to a common frame, and like outputting positions in
> WGS84(G2139).  With SBAS, the outputs are in the SBAS reference frame,
> which is probably ITRF2008 or ITRF2014 -- but it's surprisingly
> difficult to find that information.


|UBX-CFG-GNSS: |

|msgVer 0 numTrkChHw 60 numTrkChUse 60 numConfigBlocks 6 gnssId 0 TrkCh 
8 maxTrCh 16 reserved 0 Flags x11110001 GPS L1C/A L2C enabled gnssId 1 
TrkCh 3 maxTrCh 3 reserved 0 Flags x01010001 SBAS L1C/A enabled gnssId 2 
TrkCh 10 maxTrCh 18 reserved 0 Flags x21210001 Galileo E1 E5b enabled 
gnssId 3 TrkCh 2 maxTrCh 5 reserved 0 Flags x11110001 BeiDou B1I B2I 
enabled gnssId 5 TrkCh 0 maxTrCh 4 reserved 0 Flags x15110001 QZSS L1C/A 
L2C enabled gnssId 6 TrkCh 8 maxTrCh 12 reserved 0 Flags x11110001 
GLONASS L1 L2 enabled |



> I would suggest that you record a day or so of raw data, convert to
> RINEX, and submit to CSRS-PPP to both get a position, and look at the
> error statistics.  Before you do, make sure that you have a stable or
> repeatable antenna position, where it's stable to better than 1 cm.  You
> also may want to pay attention to the "North Reference Point" (see
> https://www.ngs.noaa.gov/ANTCAL/FAQ.xhtml  ) if you have a more serious
> antenna, and make one up if not for repeatability.


Thanks for this hint.  I will look for the antenna diagram

> You should also be able to process RINEX with NGS's OPUS if you are in
> the US or nearby.   If you are in .at, that won't work, but there may be
> some European equivalent service.



Kind regards

Hans