gpsd-users
[Top][All Lists]
Advanced

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

Re: ppp averaging and circular error of probability


From: Greg Troxel
Subject: Re: ppp averaging and circular error of probability
Date: Sat, 10 Sep 2022 06:09:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

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.

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

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!

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.

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.

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

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