Re: [gpsd-dev] Status driver_nmea2000.c

[Hal Murray]

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.

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

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.

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.

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.

Do we want 2 separate sentences for serial time and PPS time?  Or should we 
put both sets of info, if available, into one sentence?  I think one sentence 
will be simpler.  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.  (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.)

How does gpsd handle PPS reports when the receiver goes in and out of valid 
mode?  (I think some Garmin documentation suggests ignoring a few after the 
NMEA mode goes from invalid to valid.)

What other things should we be thinking about?


-- 
These are my opinions.  I hate spam.