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

[Gary E. Miller]

Yo Robin!

On Mon, 15 Aug 2016 13:22:06 +0200
Robin Schwab <address@hidden> wrote:

> 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.

And who runs a time server in a tunne;?

> 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 :-)

gpsd does discard bad time fixes.  It does so using the manufactureres
recommened method, which is to only use time stamps when the GPS has
had 3 valid fixes in a row.

If you can come up with something better, and can prove it with some
graphs, we'd ike to hear about it.

> Would be interesting to see if that solves your problem.

Dunno.  Until I find the problem I don't know what it is not.  Right
now I'm just collecting data, and that is a slow process with something
that may happen once a month.


> > 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.

As always, YMMV.  So run stats and tell us what you see.

> But if you have a GPS clock that is <1us accurate (it has to be
> because otherwise the position would be wrong)

I have lots of scatter plots showing wrong GPS!

> I do not see the
> advantage of correcting that time with a network peer clock that is
> >100 ms away.

Who said 100 mSec?  Not me!  Your strawman is of no use to me.  You
assume away the problem this corrects: bad output from you GPS.  It
happens.  As you said, a bird could land on your antenna.

> You can use those network clocks for statistics and
> >cross-checking but 
> basically you have to trust your own GPS clock.

Trust, but verify.  GPS have a huge failure rate around leap second
time.  Come next January 1st tell me how well standalone time servers
did.  If last time is any guide....

> Of course ntpd
> accounts for the latency over the network

wishful thinking...

> but since the latency is
> big and varies the correction can't be that good.

I get 9 milliSec to NIST in Seattle.  10 microSec or better to my other
local chimers.  The errors on my Pi2/Adafruit tend to be +/1 1 Sec.

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

pgp31mWoucDKb.pgp
Description: OpenPGP digital signature