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

[Pavel Kirienko]

> 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.
This is only correct if the climb rate is derived from the altitude,
and it's not true if climb rate is provided by receiver.
I should have stated this explicitly.

On Sun, Dec 1, 2013 at 2:34 PM, Terje Mathisen <address@hidden> wrote:
> 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"