[LinuxPPS] Nmea driver and GPS18LVC

[tlhackque]

On 04-Aug-14 09:03, Paul wrote:
> I guess the configuration is in the title. I am using ntp 4.26p5, with
> NMEA compiled in. Hardware is a GPS18LVC, with no buffering.
>
> I`ll ask the questions as they occurred to me rather than at the end.
>
> First, how can I tell if ntp is locking to the NMEA sentences only,
> which I would expect to be rather inaccurate, or to the NMEA and the PPS?
>
> As soon as I powered up the GPS18 ntpq claimed that it was providing a
> stratum 1 time. (Hmm, so much for careful smoothing algorithms). It
> rapidly went to an offset of 0.011 with a jitter of 0.020. More
> significantly offsets to pool servers were of the order of -2 to -5.
> Believable?
>
> Unfortunately next morning things were much worse. While GPS claimed
> to be at an offset of 0.004, with an jitter of 0.013, the offset to
> the pool servers was in the order of 200.
>
> Do you think I am locked to the NMEA only?
>
> Regards
>
> Paul
>
> _______________________________________________
> discussions mailing list
> discussions at linuxpps.org
> http://www.linuxpps.org/cgi-bin/mailman/listinfo/discussions
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
Oh, I run a GPS18LVC with PPS on this machine, which looks like this:

 ntpq -pn
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
o127.127.20.0    .GPPS.           0 l   46   64  377    0.000    0.002  
0.009
+192.168.208.148 146.51.136.107   2 s   32   64  376    1.242    0.459  
0.055
 192.168.148.10  192.168.148.43   2 s   21   64  377    0.737    0.039  
2.120
 192.168.148.136 192.168.148.43   2 s    1   64  377    0.562    0.081  
0.036
 2.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000  
0.002
 1.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000  
0.002
 3.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000  
0.002
 192.168.148.255 .XFAC.          16 B    -   64    0    0.000    0.000  
0.002
 ff05::101       .XFAC.          16 M    -   64    0    0.000    0.000  
0.002
+64.246.132.14   .CDMA.           1 u   44   64  377   23.688   -1.597  
0.612
+199.102.46.73   .GPS.            1 u   39   64  377   46.286    5.092  
0.744
+199.102.46.77   .GPS.            1 u   19   64  377   43.824    4.293  
0.651
+204.9.54.119    .CDMA.           1 u    7   64  377   39.583   -0.880  
0.252
+199.102.46.80   .GPS.            1 u   60   64  377   43.601    4.664  
0.664
+199.102.46.75   .GPS.            1 u   19   64  377   43.802    5.680  
0.762
+199.102.46.76   .GPS.            1 u    4   64  377   43.585    4.597  
0.576
+199.102.46.79   .GPS.            1 u    8   64  377   46.384    5.050  
0.549
+2607:f058:20::c .CDMA.           1 u   34   64  377   31.304    0.588  
0.555
+74.117.238.11   1.15.132.3       2 u   15   64  377   39.015    6.812  
0.758
+199.102.46.74   .GPS.            1 u   36   64  377   43.706    4.216  
0.533
+162.243.55.105  209.51.161.238   2 u   13   64  377   13.734    1.122  
2.881
+69.55.54.17     128.59.39.48     2 u   40   64  377   16.054    2.523  
0.497
-64.132.226.3    .GPS.            1 u    2   64  377   56.251   -0.536  
0.678

The host is a Raspberry Pi, PPS kernel, I posted the hardware on the RPi
forum - it's simply level shifted to a dedicated UART for the NEMA and a
GPIO pin for PPS.

ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1407163957.999996449, sequence: 9560404 - clear 
0.000000000, sequence: 0
source 0 - assert 1407163958.999997234, sequence: 9560405 - clear 
0.000000000, sequence: 0
source 0 - assert 1407163960.000001017, sequence: 9560406 - clear 
0.000000000, sequence: 0
source 0 - assert 1407163960.999996802, sequence: 9560407 - clear 
0.000000000, sequence: 0

Again, use the right edge of the PPS signal.

-- 
This communication may not represent my employer's views,
if any, on the matters discussed.