gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Meaning of negative PPS offset?


From: Greg Troxel
Subject: Re: [gpsd-dev] Meaning of negative PPS offset?
Date: Tue, 26 Aug 2014 14:12:52 -0400
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix)

"Eric S. Raymond" <address@hidden> writes:

> Greg Troxel <address@hidden>:
>> 
>>   3. When doing 2, gpsd looks at the last timestamp received in the
>>   GPS datastream, assumes it went with the *previous* reporting cycle,
>>   and increments the second part by one second.  This is assumed to be the
>>   base clock second for the *current* reporting cycle.
>> 
>> I think this is an unwarranted assumption and the root of the issue.
>
> What assumption would you make instead?  This has to be something we can 
> put in code.

[all my numbers are notional.  Add w.l.o.g. as needed!]

Well, you are assuming that the phase of the PPS relative to the NMEA
arrival is >=0.0s and < 1.0s.   That seems not really true.   So one
could look at

   p = system timestamp of pps edge

   n = system timestamp of most recent nmea sentence with time (or first
   in a cycle, if we can separate those?)

   N = nmea timestamp (always .0000000s?)

So presumably we expect, when things are ok

   n - N = a about 300 ms

   p - n = about 700 ms

   associate p as being the time for edge (N+1)

which is I think what you are saying.   So the bug is that in cases we
are saying.

   n - N = -40ms

in which case we should associate p as being the time for edge N.


So two thoughts:

  We really need to know how each device behaves, unless they are all
  close enough.

  Instead of assuming that p > n, we can assume
    n + 0.1 > p > n - 0.9
  so that we find the right edge for p.   Hence we say that if p-n is <=
  100ms, we just take N for the PPS.  And if p-n > 900 ms, we add 1.

The real rub is that we have to know if it's more likely that the NMEA
sentence is 100 ms early or 900 ms late.  Which is necessarily device
specific.   An alternative view is that any device outside those bounds
is broken.


A totally alternate approach is to assume that the system clock is
within 500 ms, and to disamiguate the PPS edge by finding the nearest
second.  Or perhaps even to only capture PPS when it's within 200 ms of
the system clock.  Basically this ignores PPS until the clock is close,
which sort of makes sense.

Attachment: pgp_ljXvyMmBr.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]