Re: Getting PDOP, VDOP and HDOP in C

[Greg Troxel]

David Taylor <gm8arv@yahoo.co.uk> writes:

>   https://www.satsignal.eu/mrtg/performance_gps_dop.php

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

signature.asc
Description: PGP signature