[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