gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] RC for DRIFT message


From: Hal Murray
Subject: Re: [gpsd-dev] RC for DRIFT message
Date: Sun, 22 Feb 2015 14:42:46 -0800

You didn't mention "JSON", but I think the context of your message assumed 
that.

I'd like to review the whole tangle of how to pass info from gpsd (or 
similar) to ntpd.  Currently, we have implementations for one version of 
shared memory and JSON over TCP.  Getting a good/clean shared memory 
implementation is high on my list.  Message Queues have been suggested.  How 
about pipes?

I think you said you were going to think about this area.  I hope that grows 
into a good web page explaining all the tradeoffs and problems.  I'm still 
slightly surprised that there isn't a good web page describing how to use 
shared memory for the environment we have: either side can start first and 
either side can crash or restart at any time.

I'd be happy to support more than one way if which-is-best depends on the 
environment.

We should consider writing simple debugging/testing tools too.


> Almost everything about this feature is easy to specify.  We can call it
> DRIFT or CLOCKDRIFT and it can have the same members PPS does - second and
> nanosecond parts for real (GPS) and CPU clock time. 

Drift is a poor choice of words.  It's already well known in the ntp context 
as the frequency offset rather than a time offset.  If the frequency is off, 
your clock will drift.

I'd also like to see some indication of quality.  I don't have any good 
ideas.  A real simple one is the number of satellites.  Another is offset 
from a known location (which doesn't work if the receiver is in time mode).  
Is there a DOP for time?  What fraction of devices provide it?


> The question is when it should be emitted.

Whatever gives the best result.

It's common (or at least not uncommon) for a default NMEA setup to send the 
satellite info every 5 seconds.  If that stuff comes before the first message 
with time in it, there might be a lot of jitter.  It might be appropriate to 
use the start time of the first message in the clump but delay sending 
anything until you actually receive a message with time and a valid flag.


-- 
These are my opinions.  I hate spam.






reply via email to

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