Re: [gpsd-dev] Status driver_nmea2000.c

[Gary E. Miller]

Yo Hal!

On Sun, 08 Feb 2015 02:36:06 -0800
Hal Murray <address@hidden> wrote:

> 
> address@hidden said:
> > One other item that might be easy to do.  The ntpd guys would like
> > the TPV JSON message to have the time stamp when the TPV wass
> > receiver.  Which is related to the gpsmon problem in #1 above, but
> > already known in gpsd. It just needs to be added to the TPV, or in
> > another related message.
> 
> I agree that it should be easy to do, but rather than a quick fix, I
> think we should think a bit.  Maybe we can get it closer to right.

Yes.
 
> How does chronyd handle GPS devices without PPS?  (Maybe we are
> overlooking something.)

SHM(0) and SHM(1), just like ntpd.

> What ntpd needs is the clock offset: the difference between the
> system clock and what the GPS receiver says.  I can't find that in
> the TPV sentence.

The TPV message is not really the right place for it.  The first message
with time from the GPS may be other than TPV data.  Some GPS even
emit a time only type message first, just for timekeeping.

I would suggest a new JSON message, off by default, just for shipping the
time in the first time message of each second from the GPS, and the time
it is receiver.  Sadly gpsd knows the time that first message was decodes,
not the tme of the first byte of that message.

> ntpd is setup to do a lot of logging.  It would be handy to have some
> sort of quality indication in addition to the time.  It's often
> useful for debugging and/or glitch chasing.

We only know that from NO-/2D-/3D- FIX.

> There may be two levels of quality: one for the receiver, antenna
> location and satellite geometry, and a second for the communication
> channel from the receiver to gpsd.

The second predominates.  Sometimes by many orders of magnitude.  The
first mostly gives a go/no-go.

> Do we want 2 separate sentences for serial time and PPS time?

Not really a choice.  They come from different threads, combining
would be problematic.

> If we have two, then we need a
> way to decide which one to use, and that requires a recipe to handle
> timeouts and/or we have to include a valid/quality slot in each
> sentence.

Already in the ntpd engine.  Just make each a peer and let the high level
ntpd code juggle the mix.  Do not reinvent a good wheel.

>  (You can avoid the timeout problem if the message is
> always send but says "I'm here but no-good." rather than not being
> sent.)

Not really an option for the PPS thread.  And historically gpsd only
sends what it knows, not gueses about things it does not know.

> How does gpsd handle PPS reports when the receiver goes in and out of
> valid mode?

If just does not send them at all.

>  (I think some Garmin documentation suggests ignoring a
> few after the NMEA mode goes from invalid to valid.)

Sort of, a bit more complicated than that, and differs between vendors.
u-blox in some cases just stop sending PPS.

> What other things should we be thinking about?

I think that does it.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588