gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up


From: Hal Murray
Subject: Re: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up
Date: Sat, 21 May 2016 03:11:45 -0700

> Why GPSD?
> If you are already familar with ntpd and wonder why this recipe uses gpsd
> through SHM rather than ntpd's native refclock 20 GPS driver, the
> answer is this: when refclock 20 is configured to use 1PPS, it mixes in-band
> time data with 1PPS in a way that causes it to behave badly, and possibly
> get rejected as a falseticker, when 1PPS is only occasionally available. 

That doesn't make sense to me.  It's partly true, but the other part is 
important enough that you can't stop there, but you did.  Here is a dump of 
that area.

There are 4 ways to connect a NMEA+PPS device to ntpd.

refclock 20 + fudge to use PPS
refclock 20 + refclock 22
SHM + GPSD
JSON + GPSD

refclock 20 with fudge to automagially use the PPS has the hard to monitor 
problem.  The driver has two hats: serial and PPS, but there is only one slot 
(the driver number) to record data.  The advantage is that it's easy to 
configure.  Or should be.  I like grubby details and this mode messes that up 
so I haven't paid much attention to it.  (I think it could be made to work, but 
I'm not interested in trying.)

The combination of refclocks 20 and 22 have 2 slots for their two hats.  But 
the PPS slot needs help to number the seconds.  It gets that from a driver 
marked prefer.  Normally, you can mark the serial driver as prefer.  Then you 
have to fudge the offset and tos mindist.  In the long term, we need a decent 
recipe for that, but I've never had any serious problems.  In the short term, 
we need to add reasonable fudge factors for each type of HAT to one of the 
tables.


The results from SHM and JSON are identical.  The setup details are slightly 
different.  The JSON mode defaults to trying to grab the PPS info too, but it's 
easy to tell it not to do that.  They need the same fudge factors.

Note that we need fudge factors for use with both ntpd refclocks and gpsd.  
They may be different.

In that context, "fudge factors" includes "tos mindist" adjusting too.

Some table of HATs should include a column for the chip and a link to the data 
sheet.

-------

Do you want this document to cover the GR-701W?  If so, we need to add it to a 
table that includes the fudge factors.  When used with refclocks, it needs some 
setup.  I put it in /etc/default/ntp

# uBlox, 701W, USB with PPS
if [ ! -e /dev/pps1 ]; then
  ln -s /dev/ttyUSB0 /dev/gps1
  # setserial /dev/ttyUSB0 low_latency
  ldattach 18 /dev/ttyUSB0 & # gets /dev/pps1
  sleep 1
fi

That gets pps1 and uses gps1 because it's running on a system that already has 
a HAT which is using gps0 and pps0.

PPS over USB will be more accurate with a fudge factor.

-------

Your ntp.conf doesn't have any timing fudge factors.  How well does it work?


-- 
These are my opinions.  I hate spam.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]