[ntp:questions] GPS/PPS and "enable calibrate"

David Lord snews at lordynet.org
Sun Sep 8 01:41:42 UTC 2013


unruh wrote:
> On 2013-09-07, Horvath Bob-BHORVAT1 <Bob.Horvath at motorolasolutions.com> wrote:
>>
>> -----Original Message-----
>> From: questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org [mailto:questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org] On Behalf Of unruh
>> Sent: Saturday, September 07, 2013 11:20 AM
>> To: questions at lists.ntp.org
>> Subject: Re: GPS/PPS and "enable calibrate"
>>
>> On 2013-09-07, Charles Elliott <elliott.ch at verizon.net> wrote:
>>>
>>> Or use PPS and be accurate to  a microsecond or so.
>> I guess this is the fundamental question I don't understand.  
>>
>> I thought with PPS, which I do have using the Adafruit GPS and a Raspberry Pi, I would be fairly accurate off of the GPS time and PPS together.   Then I started seeing fudge parameters of 0.496 which seem to work well, but seem like a large amount of time to be "fudging" for something that is supposed to already be accurate.  That is in seconds, right? So it is about a half a second?  I am confused what that parameter does, what it needs to be set to, and how one figures out what to set it to, or whether I am just really confused. 
> 
> Teh PPS occurs at the second. The nmea labels those seconds so you know
> which second the PPS occured on. But the nmea sentences occur late by
> something like .1 to .6 (or occasionally with a defective GPS 18x, by
> 1.1 sec) Now you can tell your computer that the nmea occurs say .4 sec
> late. so that its idea of when the nmea sentece comes through is not on
> the second but on the second plus .4 sec. It does not really matter,
> because as long as that labeling is withing 1 sec, ntpd will use PPS to
> determine when the second occured, that the nmea to say which second
> that was. 
> Ie, if you use PPS that fudging does nothing about the time your
> computer shows. So unless your GPS is way out, that parameter is
> irrelevant. 
> If your PPS is not working, then you make your clock accurate to about
> .1 sec by using that parameter, rather than .4 sec late.


Hi

I'd add to that

For my Sure GPS on EPIA-i386 running NetBSD-6, I have to set tos
mindist to a high value to keep gps syncronised otherwise I can't
get gps to sync or eventually lose both gps and pps.

from /etc/ntp.conf:

     tos     minsane 3
     tos     orphan  10
     tos     mindist 0.4
     server  127.127.20.2  mode 18  prefer
     fudge   127.127.20.2  stratum 6  time2 0.417  flag1 0  refid GPSb
##  time2 is set to a high value from when I was initially setting up
##  and could now be reduced to perhaps 0.1s as maximum variation in
##  gps offset (from peer_summary) is about +/- 80 ms
     server  127.127.22.2
     fudge   127.127.22.2  flag2 0  flag3 1  refid PPSb
     server -4  ntp0.lordynet.org.uk    minpoll  6  maxpoll  7  iburst
     server -4  ntp2.lordynet.org.uk    minpoll  6  maxpoll  7  iburst
     server -4  ntp1.lordynet.org       minpoll  6  maxpoll  7  iburst
     server -4  ntp3.lordynet.org       minpoll  6  maxpoll  7  iburst
     server -4  ntp1(my isp)            minpoll  8  maxpoll 10  iburst


from ntp-4.2.6p5/html/miscopt.html:

     mindist mindistance
         Specify the minimum distance used by the selection and
         anticlockhop algorithm. Larger values increase the
         tolerance for outliers; smaller values increase the
         selectivity. The default is .001 s. In some cases, such
         as reference clocks with high jitter and a PPS signal, it
         is useful to increase the value to insure the
         intersection interval is always nonempty.


David



More information about the questions mailing list