Re: [gpsd-users] Garmin 18X-5Hz

[Robin Schwab]

Hi Gary

Am 14.08.2016 um 23:14 schrieb Gary E. Miller:
> No, I mean hard fail.  Like loss of signal, no PPS output, so ntpd goes
> free running.  Or worse yet, just a wild hare output., like 14 Aug about
> 16:00 UTC here: https://pi2.rellim.com/day/
>
> Tht one happens every few weeks, driving me crazy to find and fix.

I think you have already seen how inaccurate a GPS can be with poor 
signal i.e. when you come out of a tunnel. There is a huge difference in 
precision between any fix and a good fix.

NMEA Dilution Of Precision (DOP) values are available so I see no point 
in not using them. Ublox modules send even a specific Time DOP signal 
(PUBX,00,…). When you have a bad fix in a stream of good fixes the bad 
fix should get discarded. Maybe just a bird sitting on your antenna :-)

Would be interesting to see if that solves your problem.

> chronyd was designed to handle loss of refclocks.  The authors
> considered intermittent uptime and intermittent fixes.  It has
> techniques to adjust for them and converges fast.
>
> ntpd, by design, is for constant on operation with multiple inputs.  It
> converges very badly and slowly on startup, it uses voting to select
> averages of the best times.
>
> If you are only going to have one input you should be using chronyd.

I'll consider using chrony. I do see the point of NTPd providing a 
robust networks of clocks that are maybe 1s accurate for login purposes.

But if you have a GPS clock that is <1us accurate (it has to be because 
otherwise the position would be wrong) I do not see the advantage of 
correcting that time with a network peer clock that is >100 ms away. You 
can use those network clocks for statistics and cross-checking but 
basically you have to trust your own GPS clock. Of course ntpd accounts 
for the latency over the network but since the latency is big and varies 
the correction can't be that good.

Regards
Robin