Re: [chrony-users] GPS / Chrony NTP server config questions

[Paul J R <me@xxxxxx>]

I thought i might add my own $0.02 as this is something i've been working on for some time (i.e. trying to figure out which gps module is best for my OSH project).

The MTK3339 is ok, but my current round of hardware design has been putting the neo6m, Quectel L80 and MTK3339 up against each other and the MTK3339 is the worst performer of the lot (which is not to say its bad), but the jitter is higher and the sensitivity lower. To be fair, the neo has a better antenna then the other two as im using these modules:

https://cdn-shop.adafruit.com/1200x900/790-03.jpg
http://media.rs-online.com/t_large/F9084085-01.jpg

which are the same size for the L80 and MTK, but for the neo i have something like this:

http://img.dxcdn.com/productimages/sku_312527_1.jpg

The neo does the best (its also amazingly configurable), followed by the L80 then the MTK in terms of how jittery they are, but the biggest issue is the MTK3339 is more prone to dropping out where the other two continue to maintain a gps signal (some of this can possibly be blamed on my board design, however both the L80 and MTK use a nearly identical board design).

Having said all that, when it comes to the time clients, they will often slighly prefer the neo based unit (and if i take that away its the L80), but the difference once you hit the network is insignificant (unless the MTK looses its fix). If your to presume the module goes somewhere with a good skyview, theres not alot to split the three. The L80 is harder to get where the neo and mtk are readily available from a million sources (but i cant get the neo in a form factor that i like for my project).

I've also put these three up against commercial units with interesting results, but thats another story.

Regards, Paul


On 17/11/17 05:21, Joe Smith wrote:

I'm not too concerned about the accuracy of the PPS. This particular GPS receiver is pretty high quality. https://learn.adafruit.com/adafruit-ultimate-gps/overview  It delivers the NMEA data and the PPS. A number of online resources describing similar projects and the GPSD Time Service HOWTO page all speak highly of it. I just wasn't sure if there was a way to get an idea of the clock accuracy using chronyc. Mainly just to be sure I didn't do anything wrong with the settings.

On Thu, Nov 16, 2017 at 12:57 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Thu, 16 Nov 2017, Joe Smith wrote:

I'm trying to determine the best way to get an idea of my clock accuracy now that I'm
getting the PPS signals. Is that "chronyc tracking"? When I do "chronyc sources" or "chronyc
sourcestats" those seem to indicate NMEA offsets that are on the order of 40-60ms.

NMEA is a prety terrible clock. a) the receiver decodes and composes the nmea
sentances when it is not busy doing something else. The sentences are delivers
at something like 30Kbaud, ( which is about 3000 bytes per second) The sentences
are about 50 bytes long, so just getting in a sentence takes about a 30ms of
a second. And each sentence has a slightly different length so the arrival of
the end of the sentence varies with its length. All of these things mean that
nmea is useless for accruracy better than about 10ms even if you compensate
for the average time delay.

You cannot estimate the accuracy of the PPS from the nmea sentences. It is
like trying to estimate the accuracy of a stopwatch by using a water clock.

debian@beaglebone:~$ chronyc sources
210 Number of sources = 2
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#? NMEA                          0   4   377    14    -59ms[  -59ms] +/-  107ms
#* PPS                           0   4   377    12  -1985ns[-2545ns] +/- 1792ns
debian@beaglebone:~$ chronyc sourcestats
210 Number of sources = 2
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
NMEA                       64  29  1009     -8.352     14.888    -48ms  9366us
PPS                        10   3   145     -0.000      0.136     -2ns  3981ns
debian@beaglebone:~$ chronyc tracking
Reference ID    : 50505300 (PPS)
Stratum         : 1
Ref time (UTC)  : Thu Nov 16 13:04:35 2017
System time     : 0.000000898 seconds slow of NTP time
Last offset     : -0.000000564 seconds
RMS offset      : 0.000011269 seconds
Frequency       : 39.580 ppm fast
Residual freq   : -0.000 ppm
Skew            : 0.138 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000025743 seconds
Update interval : 16.0 seconds
Leap status     : Normal

The "chronyc tracking" output seems to indicate (if I'm understanding the documentation
correctly) that the accuracy is pretty good. Am I interpreting this correctly?

The PPS accuracy is largely determined by the interrupt handling time, which
is something like a usec. It depends, so that if the the pps comes in when the
computer is reading a disk (which used non-interruptable interrupts) it will
be delayed by many microseconds.  But yes, the PPS should be pretty good. as
tracking says it has a rms offset of about 10us. Most of that is delay, so the
accuracy is probably about 10us, The precision is much better, in the hundreds
of ns range.

The only way you could estimate more accurately is to run the PPS to a scope,
and have the system send out a pulse say on the parallel port at a
predetermined time (say 100 usec after the top of the hour using polling of
the clock to say when to send out that pulse) and see what the actual offset
is on the scope.

On Wed, Nov 15, 2017 at 11:48 AM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:


      William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
      Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
      UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
      Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

      On Wed, 15 Nov 2017, Joe Smith wrote:

            Thank you so much!! With the lock NMEA it is no longer ignoring the
            pulses. I should be able
            to make adjustments to the offset and whatnot to get the clock
            accuracy down to where I need
            it.


      NMEA can never give better than 10s of ms accuracy. The problem is that when
      the gps receiver sends out an NMEA sentence is arbitrary and even the length
      of the sentence is to an extent arbitrary. To get better accuracy, it is the
      PPS that gives it. However the pps conveys only the information of when the
      turnover of the second occurs, not which second that is. That is what the NMEA
      is needed for. (and once the system has that once , it really no longer needs
      the NMEA) since the system clock is sufficiently regular that it can figure
      out which second the pulse belongs to for at least many hours, and usually for
      months.

      Thus: chrony is switched on. Chrony uses the NMEA sentences ( or infomation
      from network ntp servers) to get the system clock disciplined to 10's of ms.
      The PPS now takes over, and the clock then gets disciplined to microsecond
      accuracy. If the PPS is interrupted for some reason, the system clock carries
      over the seconds information for hours to days until the PPS works again.



            On Wed, Nov 15, 2017 at 2:02 AM, Miroslav Lichvar
            <mlichvar@xxxxxxxxxx> wrote:
                  On Tue, Nov 14, 2017 at 03:45:41PM -0500, Joe Smith wrote:
                  > I rebuilt chrony with --enable-debug and ran with -d -d 
            Below is some
                  > output although I'm not 100% sure what it means. Tried
            looking at the
                  > source code to see if I could ascertain the cause but I was
            unable. I let
                  > it run for a bit and here's some sample output. The pattern
            just seems to
                  > repeat over and over.

                  The "sync=0 dist=1.5" part says the system clock is not
            synchronized,
                  which suggests it's not trying to lock to the NMEA source.
            Looking at
                  your config again, I see now that the PPS refclock is missing
            "lock
                  NMEA".

                  Alternatively, you could try to remove noselect from the NMEA
            line, so
                  chronyd can synchronize the clock to the NMEA source first and
            then
                  it can switch to PPS.

                  > 2017-11-14T20:34:22Z refclock.c:520:(RCL_AddCookedPulse)
            refclock pulse
                  > ignored offset=0.003559951 sync=0 dist=1.500000000
                  > 2017-11-14T20:34:23Z refclock_shm.c:104:(shm_poll) SHM
            sample ignored
                  > mode=1 count=1202324 valid=0
                  > 2017-11-14T20:34:23Z sources.c:356:(SRC_AccumulateSample)
            ip=[NMEA]
                  > t=1510691656.723338336 ofs=0.080481 del=0.200000
            disp=0.009623 str=0
                  > 2017-11-14T20:34:23Z sourcestats.c:583:(SST_DoNewRegression)
                  > off=1.007180e-01 freq=6.636850e-05 skew=3.159318e-04 n=16
            bs=0 runs=10
                  > asym=0.000000 arun=0
                  >
                  > On Tue, Nov 14, 2017 at 10:36 AM, Miroslav Lichvar
            <mlichvar@xxxxxxxxxx>
                  > wrote:
                  >
                  > > On Tue, Nov 14, 2017 at 07:40:33AM -0500, Joe Smith wrote:
                  > > > Thank you for the quick response Bill... The PPS is
            coming in on
                  > > /dev/pps1
                  > > > which is what I have in the refclock entry in my
            chrony.conf file. When
                  > > run
                  > > > the cat command corresponding to that device I get:
                  > > >
                  > > > debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat
                  > > > /sys/devices/virtual/pps/pps1/assert
                  > > > 1510661769.997836084#571264
                  > >
                  > > That looks good. The configuration also looks good. I
            guess the only
                  > > thing that could be wrong is the offset value on the SHM
            line. Does
                  > > the machine have an internet connection? It might help if
            you could
                  > > configure it with an NTP server and remove the lock option
            from PPS to
                  > > see if it works that way and to see if the offset of the
            NMEA source
                  > > needs to be adjusted.
                  > >
                  > > If that doesn't work, recompiling chrony with debug
            support
                  > > (--enable-debug) and running chronyd with -d -d should
            show why it's
                  > > ignoring the PPS samples.