Re: [gpsd-dev] Note on climb error modelling

[Terje Mathisen]

Pavel Kirienko wrote:> Sure.
> Here is how it is being computed now:
>
> epc = (epv_old + epv_new) / dt
>
> Obviously this equation implies that EPC depends on the solution
> update rate (inversely), and it is unclear why. Assuming that most
> (all?) receivers have no gradual accuracy drop with higher update
> rates, this equation looks invalid.

I think it is OK:

Climb rate is the derivative of altitude, right?

Assuming that the altitude error is more or less independent of the
update rate, this obviously means that the longer the time between
measurements, the lower the error.

The normal method to reduce the error from a GPS is to employ more or
less filtering, i.e. averaging multiple measurements.

For higher update rates, say 5 Hz, you might get slightly better results
from averaging all 5 measurements, or for rate calculations, using
linear interpolation over six measurements instead of just two.

Terje

> I am aware that a similar approach is used for EPS computation and I
> consider it incorrect too, but so far I have no better ideas to
> offer so let's stick to EPC only.
>
> My approach assumes that EPC is always close to EPS for any given
> instant, because this holds for EPV and EPX/Y.
>
> Pavel.
>
> On Sat, Nov 30, 2013 at 9:31 PM, Eric S. Raymond <address@hidden>
> wrote:
> > Pavel Kirienko <address@hidden>:
> > > Seems that usually gpsd's error modelling logic yields too high
> > > EPC values if compared to the typical GPS speed precision;
> > > especially in cases when the solution update frequency is higher
> > > than 1 Hz (for reference, EPC is currently being computed as
> > > (old_epv + new_epv) / dt).
> > >
> > > I can't propose a better approach for error modelling now, but we
> > > can reuse EPS for EPC. I.e. if a receiver provides EPS and not
> > > EPC, assumption EPS = EPC seems to be justifiable.
> >
> > Before I change yjthe error modeling, break all our regression
> > tests, and break backwards compatibility, I will need to see a
> > *principled
reason*
> > for the change - not just an ad-hoc patch.
> >
> > That is, you need to argue that the new formula is physically and
> > geometrically reasonable. -- <a
> > href="http://www.catb.org/~esr/";>Eric S. Raymond</a>


--
- <address@hidden>
"almost all programming can be viewed as an exercise in caching"