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

[Pavel Kirienko]

So, shall I submit a patch that fixes EPC values when a receiver
provides climb velocity, or we will leave as it is now?
As I said before, this wouldn't fix all the issues related to error
modelling, but anyway.

On Sun, Dec 1, 2013 at 5:11 PM, Pavel Kirienko
<address@hidden> wrote:
>> 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"