The GPS on 100m seems to be acting weird.  It has signal lock, currently slowing 9 or 10 satellites:

rs G
connecting to inet:localhost.localdomain:30002
connected to inet:localhost.localdomain:30002
sent:"/var/tmp/gps_pty0
"
line="OK"
parameters: 4800 none 8 1 "\n" 1 0 prompted=false
$GPRMC,152515,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*68\r\n
$GPGGA,152515,4003.0021,N,10500.2309,W,2,10,1.0,1690.0,M,-18.0,M,,*46\r\n
$GPRMC,152516,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*6B\r\n
$GPGGA,152516,4003.0021,N,10500.2309,W,2,09,1.0,1690.0,M,-18.0,M,,*4D\r\n
$GPRMC,152517,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*6A\r\n
$GPGGA,152517,4003.0021,N,10500.2309,W,2,08,1.9,1690.0,M,-18.0,M,,*44\r\n

 

But its NTP offset has been wandering around.  I added 50m as an NTP server for it, and the GPS clock on 100m is disagreeing with 50m:

ntpq
 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.5     .GPS.            1 u   45   64  377    0.946  118.340  33.872
 LOCAL(0)        .LOCL.          10 l   64   64    3    0.000    0.000   0.031
oGPS_NMEA(0)     .GPS.            0 l   15   16  377    0.000  -849.69 347.187

 

On flux, chronyc shows that the clock for 100m is off from the others:

chronyc sources
chronyc sources
210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 50m 1 10 377 321 -125ns[ +15us] +/- 733us
^- 100m 1 6 77 35 +90ms[ +90ms] +/- 1570ms
^+ 150m 1 10 377 535 +6715ns[ +20us] +/- 619us
^+ 200m 1 10 377 476 -4792ns[+9000ns] +/- 831us
^+ 250m 1 10 377 497 +4392ns[ +18us] +/- 857us
^+ 300m 1 10 377 252 +2000ns[+2000ns] +/- 656us

Comparing the output of  "data_dump i 2,10 A" on 100m with that from 50m shows intermittent data gaps of 1.269 seconds, whereas with 50m the two GPS records ($GPRMC, and $GPGGA) are reporting at 1 Hz, with quite consistent delta-Ts close to 0.85 and 0.15.  

I updated /etc/ntp.conf, and changed the time2 parameter from 0.8 to 1.2 seconds:

# time2 time
# Specifies the serial end of line time offset calibration factor,
# in seconds and fraction, with default 0.0.

Now the GPS is agreeing with 50m:

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.0.5     .GPS.            1 u   61   64  377    0.941   -0.204   0.056
 LOCAL(0)        .LOCL.          10 l  42m   64    0    0.000    0.000   0.000
oGPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000   -0.118   0.031

So it appears that the serial data from the 100m GPS (which provides the time label for the precise pulse-per-second) was late from time to time, resulting in NTP having to struggle to figure out what time it is.  So, for data up to today, I would not rely on the 100m data to have time-tags with any accuracy below 1 second.  D'oh...

2 Comments

  1. Gordon Maclean AUTHOR

    Checked the software version #s of the GPS's on the tower which are reported with the $PGRMT messages (which had to be enabled on 200 and 100 m).  

    The GPS at 50,150,250 and 300m are all software version 3.70

    $PGRMT,GPS 18x-LVC software ver. 3.70,,,,,,,,*6B\r\n

    The 100m is version 3.60 which may explain its issue.  

    $PGRMT,GPS 18x-LVC software ver. 3.60,,,,,,,,*6A\r\n

    However, the GPS at 200m is software version 3.00!

    $PGRMT,GPS 18x-LVC software ver. 3.00,,,,,,,,*6C\r\n

     

    From the garmin website: https://www8.garmin.com/support/download_details.jsp?id=4055

    GPS 18x PC/LVC software version 3.90

    as of August 28, 2013

    ...

    Changes made from version 3.60 to 3.70:

    • Improved NMEA output timing stability.

  2. Gordon Maclean AUTHOR

    It took a while for chrony on flux to trust the 100m clock, but as of this morning, April 2, it gives it a "+" rating:

    chronyc
    chronyc sources
210 Number of sources = 6
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 50m                           1  10   377  1001    -11us[  -18us] +/-  683us
^+ 100m                          1  10   377   516    -26us[  -26us] +/-  719us
^+ 150m                          1  10   377   106  +9000ns[+9000ns] +/-  632us
^+ 200m                          1  10   377   932  +3000ns[+3000ns] +/-  830us
^+ 250m                          1  10   377   118    +10us[  +10us] +/-  853us
^+ 300m                          1  10   377   970  -2000ns[-2000ns] +/-  741us

    This is what we want to see on flux:  one DSM gets a star '*', in the column under 'S', indicating chrony is synchronized to that source, and the others get '+' ratings, indicating they are acceptable and "are combined with the selected source" (from the chronyc documentation).  Previously 100m received a '-' rating, which "indicates acceptable sources which are excluded by the combining algorithm",  or worse, a 'x' indicates a clock "which 'chronyd' thinks is is a falseticker (i.e. its time is inconsistent with a majority of other sources)".