[ntp:questions] Using Trimble TSIP under Linux

[Richard B. Gilbert]

On 10/28/2012 4:33 PM, David Taylor wrote:
> On 28/10/2012 16:50, Rob wrote:
> []
>> Sorry I have no idea how to get it to work with a raspberry pi.
>>
>> I think when you have to tinker with drivers anyway, it is better
>> to adapt a driver from ntpd and leave out gpsd.
>> (unless you want to use the positioning information from the receiver
>> for a local app that supports gpsd)
>
> Rob,
>
> Thanks for your comments.  I don't /need/ gpsd, but it does seem to be
> at least partially working.  I've made progress by looking at the
> various Internet sources, and found someone who had recompiled my
> version of Linux to include PPS support.  So now I can:
>
> - use cgps -s to see the output from the GPS via gpsd
> - configure NTP to use the type 28 driver and it sees the GPS time
> - use sudo ppstest /dev/pps0 and see assert pulses coming in
>    (the clear field is always 0 though, perhaps the 150
>     microsecond pulse is too narrow?)
>
> but NTP never connects to the PPS source.  My NTP configuration looks like:
>
> ===========================================
> driftfile /var/lib/ntp/ntp.drift
>
> server 127.127.28.0  minpoll 4 maxpoll 4
> fudge 127.127.28.0 time1 +0.350 refid GPS  stratum 15
>
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid PPS
>
> server 192.168.0.3  minpoll 5 maxpoll 5  iburst prefer
> server 192.168.0.2  minpoll 5 maxpoll 5 iburst
> server 192.168.0.7  minpoll 5 maxpoll 5 iburst
> pool uk.pool.ntp.org  minpoll 10  iburst
> ===========================================
>
> With apologies for the wrap:
> C:\Users\David>ntpq -p 192.168.0.14
>       remote           refid      st t when poll reach   delay   offset
>   jitter
> ==============================================================================
>
> xSHM(0)          .GPS.           15 l    6   16  377    0.000    5.971
> 2.103
>   SHM(1)          .PPS.            0 l    -   16    0    0.000    0.000
>    0.000
> *pixie           .PPS.            1 u    6   32  377    0.495    0.041
> 0.035
> +FEENIX          .PPS.            1 u    8   32  377    0.590    0.040
> 0.025
> +Stamsund        .PPS.            1 u    7   32  377    0.466    0.096
> 0.030
> -server1.terrybu 158.43.192.66    2 u  631 1024    3   21.385    0.887
> 2.009
> -rilynn.me.uk    193.62.22.82     2 u  601 1024    3   27.880   -0.849
> 6.440
> -ntp0.sccis.net  193.62.22.74     2 u  612 1024    3   18.947    1.405
> 4.130
>   resntp-b-vip.lo .INIT.          16 u    - 1024    0    0.000    0.000
>    0.000
>
> C:\Users\David>ntpq -c rv 192.168.0.14
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.6p5 at 1.2349-o Fri May 18 20:30:57 UTC 2012 (1)",
> processor="armv6l", system="Linux/3.2.27-pps-g965b922-dirty", leap=00,
> stratum=2, precision=-20, rootdelay=0.490, rootdisp=2.540,
> refid=192.168.0.3,
> reftime=d438146b.2b1fe219  Sun, Oct 28 2012 20:30:35.168,
> clock=d438146f.b3c26062  Sun, Oct 28 2012 20:30:39.702, peer=22812, tc=5,
> mintc=3, offset=0.042, frequency=-44.915, sys_jitter=0.034,
> clk_jitter=2.397, clk_wander=0.238
>
>
> I can't see anything obviously wrong, but perhaps I'm over-tired after a
> day or two trying to get this working!
>

Lose the "minpoll 4 maxpoll 4 "!
It may not be causing your problems but but I doubt that it's
helping matters any!

The NTP software should pick the best clock(s) from those offered!

NTPD will adjust the polling intervals to suit the current
conditions.  The short poll interval will correct the large errors 
quickly.  The longer poll intervals will be used to "fine tune".