[Top][All Lists]

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

Re: Getting PDOP, VDOP and HDOP in C

From: David Taylor
Subject: Re: Getting PDOP, VDOP and HDOP in C
Date: Wed, 30 Mar 2022 15:52:51 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

On 30/03/2022 12:28, Greg Troxel wrote:

David Taylor <> writes:

I find DOP*1000 really awkward.   Maybe your graphing scheme can't cope,
but it's something I have never seen before.

I'm happy with the NAME "DOP" as it's widely used, but I don't know
whether "Error estimate" is the description you would like for the epX
values. Possibly "uncertainty"?

The problems are

   this is some kind of error estimate that came from some unclear
   method.   So "estimated error" conveys that without sounding more
   precise than it is.

   error estimates are given in various forms:
     value that is exceeded 50% of the time
     value that is exceeded 95% of the time
   and more; not trying to be exhaustive.  Coupled with this are whether
   the error estimate is relative to a long-term average (which may or
   may not be correct) or to the true value, and whether there are
   assumptions of a normal distribution baked into the estimation scheme.

It would be nice to at least precisely define all this in terms of what
the gpsd return values are supposed to be.  That doesn't change what
gets reported, but it opens the door to characterizing receivers and
transforming their estimates into a standard form.

I suggest you really read gps.h

You'll find

   * Error estimates are at 95% confidence.  Except when they are not.

   /* GPS error estimates are all over the map, and often unspecified.
    * try for 1-sigma if we can... */

   double epy;         /* Latitude position uncertainty, meters */
   double epx;         /* Longitude position uncertainty, meters */

   /* estimated position error horizontal (2D). Meters, maybe 50%, maybe 95% */
   /* aka estimated position error (epe) */
   double eph;         /* estimated position error horizontal (2D) */

   /* spherical error probability, 3D. Meters, maybe 50%, maybe 95% */
   /* Garmin, not gpsd, calls this estimated position error (epe) */
   double sep;

It would be interesting for you to examine the relationship of
epx/epy/eph.   One might expect eph^2 = epx^2 + epy^2.

I dimly recall some notion of UERE, User Expected Range Error,
describing the error in a single pseudorange, and some notion like
   eph = uere * hdop

If that's really in the ICD, then surely UERE has a definition, and the
above could be adjusted into those terms, and then it would be a bug in
a driver not to translate, and a bug in a device to report it wrong in
NMEA, perhaps fixed by a quirk in the code.

It would also be good to use the ICD language if that's not misleading.


Yes, I'm (mis)using MRTG, and that deals in integers! There is a way of scaling so I'll try that and add graphs. Maybe it will be OK?

Estimated position error sounds good, so I'll check the wording. I'm afraid for this exercise it's not really justified to go into great depths. What is of passing interest is how well the HDOP and EPEH (etc.) correlate.

I do appreciate your input.

SatSignal Software - Quality software for you
Twitter: @gm8arv

reply via email to

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