[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.
- [gpsd-dev] RC for DRIFT message, Eric S. Raymond, 2015/02/22
- Re: [gpsd-dev] RC for DRIFT message, Gary E. Miller, 2015/02/22
- Re: [gpsd-dev] RC for DRIFT message,
Hal Murray <=
- Re: [gpsd-dev] RC for DRIFT message, Eric S. Raymond, 2015/02/23
- Re: [gpsd-dev] RC for DRIFT message, Hal Murray, 2015/02/23
- Re: [gpsd-dev] RC for DRIFT message, Eric S. Raymond, 2015/02/23
- Re: [gpsd-dev] RC for DRIFT message, Hal Murray, 2015/02/24
- Re: [gpsd-dev] RC for DRIFT message, Eric S. Raymond, 2015/02/24
- Re: [gpsd-dev] RC for DRIFT message, Hal Murray, 2015/02/25
- Re: [gpsd-dev] RC for DRIFT message, Gary E. Miller, 2015/02/25
- Re: [gpsd-dev] RC for DRIFT message, Eric S. Raymond, 2015/02/26
- Re: [gpsd-dev] RC for DRIFT message, Gary E. Miller, 2015/02/23
Re: [gpsd-dev] RC for DRIFT message, Greg Troxel, 2015/02/22