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).
but the jitter is higher and the sensitivity lower. To be fair, the neo
board design).
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
(but i cant get the neo in a form factor that i like for my project).
results, but thats another story.
Post by Joe SmithI'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.
+1(604)822-3273 <tel:%2B1%28604%29822-3273>
+1(604)822-5324 <tel:%2B1%28604%29822-5324>
UBC, Vancouver,BC _|_ Program in Cosmology |____
Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/ <http://www.theory.physics.ubc.ca/>
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.
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
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
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
+1(604)822-3273 <tel:%2B1%28604%29822-3273>
+1(604)822-5324 <tel:%2B1%28604%29822-5324>
   UBC, Vancouver,BC _|_ Program in Cosmology |____
   Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/ <http://www.theory.physics.ubc.ca/>
      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
         On Tue, Nov 14, 2017 at 03:45:41PM -0500,
         > 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
         >
         > > On Tue, Nov 14, 2017 at 07:40:33AM
         > > > 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
         > > >
         > > >
         > > > /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.
