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.