[ntp:questions] ntp version 4.2.7p257-o

[Mark C. Stephens]

Hi Dave,


Not being a mind reader you wouldn't know I am using a HP GPS.
I am still looking at ordering a Sure, but I am stuck between:
A Garmin 18LV, A Sure GPS Mk I or a Sure GPS Mk II or this:
http://www.twig.com.au/store/product_info.php?products_id=108&osCsid=f1b73789c789ab97bd81813764de5d69

Someone help me make up my mind so I can order something already!


The HP GPS RX doesn't append a checksum to ZDA sentences.

However, I am pretty pleased with its performance, sits there with no jitter, gets selected over the acutime gold:

[root at NTP ~]# ntpq -c peers -c version -c kern -c sysinfo -c rv -c cv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+GPS_PALISADE(2) .GPS.            0 l    7   16  377    0.000    0.031   0.002
oGPS_NMEA(0)     .GPS.            0 l    6   16  377    0.000    0.002   0.002
+time.non-stop.c .GPS.            1 u    6   64  377    0.244    8.713   0.080
-csiro-nml.physi .ATOM.           1 u   23   64  377  251.998   98.597 172.209
-ntp.sydney.nmi. .ATOM.           1 u   34   64  377  156.837   68.858 181.184
+ntp.adelaide.nm 223.252.32.9     2 u   54   64  377   54.725    7.676 251.064
ntpq 4.2.7p256 at 1.2483-o Fri Feb 10 06:36:34 UTC 2012 (3)
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
pll offset:            0.01087
pll frequency:         112.449
maximum error:         0.002
estimated error:       3e-06
kernel status:         pll ppsfreq ppstime ppssignal nano
pll time constant:     4
precision:             1e-06
frequency tolerance:   495.911
pps frequency:         112.449
pps stability:         0.0180969
pps jitter:            0.002
calibration interval   256
calibration cycles:    501
jitter exceeded:       2044
stability exceeded:    3
calibration errors:    6 
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
system peer:        GPS_NMEA(0)
system peer mode:   client
leap indicator:     00
stratum:            1
log2 precision:     -19
root delay:         0.000
root dispersion:    1.015
reference ID:       GPS
reference time:     d2ed6897.6976bd33  Tue, Feb 21 2012 11:49:27.411
system jitter:      0.002
clock jitter:       0.002
clock wander:       0.006
broadcast delay:    0.000
symm. auth. delay:  0.000
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
version="ntpd 4.2.7p256 at 1.2483-o Fri Feb 10 06:35:57 UTC 2012 (3)",
processor="i386", system="FreeBSD/8.2-RELEASE-p6", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.195, refid=GPS,
reftime=d2ed6957.699c71c4  Tue, Feb 21 2012 11:52:39.412,
clock=d2ed6964.e87fbdbe  Tue, Feb 21 2012 11:52:52.908, peer=15109, tc=4,
mintc=3, offset=0.001, frequency=112.433, sys_jitter=0.002,
clk_jitter=0.003, clk_wander=0.004
associd=0 status=0012 1 event, clk_bad_format,
device="NMEA GPS Clock", timecode="$GPZDA,005253,21,02,2012,+00,00",
poll=5779, noreply=0, badformat=1, baddata=0, fudgetime2=-480.000,
stratum=0, refid=GPS, flags=5

[root at NTP ~]# uname -a
FreeBSD NTP 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #2: Tue Feb  7 03:51:49 EST 2012     root at NTP:/usr/obj/usr/src/sys/PPS  i386

A feature request: NTPD uptime in hh:mm:ss?

I just wish we could get it to work under windows...

Mark

> -----Original Message-----
> From: Dave Hart [mailto:hart at ntp.org]
> Sent: Tuesday, 21 February 2012 7:35 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] ntp version 4.2.7p257-o
> 
> On Mon, Feb 20, 2012 at 17:34, unruh <unruh at invalid.ca> wrote:
> > On 2012-02-20, Dave Hart <hart at ntp.org> wrote:
> >> On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <marks at non-
> stop.com.au> wrote:
> >>> Why I say this is that that it's not related to the serial input as per:
> >>>
> >>> C:\Documents and Settings\Administrator>ntpq -c clockvar
> >>> associd=0 status=0011 1 event, clk_no_reply, device="NMEA GPS
> >>> Clock", timecode="$GPZDA,044739,20,02,2012,+00,00",
> >>> poll=564, noreply=1, badformat=0, baddata=0, fudgetime2=-480.000,
> >>> stratum=0, refid=GPS, flags=1
> >>>
> >>> the timecode looks great there, as does clockstats:
> >>
> >> It doesn't look great to me.  I'd expect a checksum on the end of the
> >> sentence consisting of a * and two hex digits 0-9/A-F.  I'm
> >> disappointed the Sure isn't generating the checksum, as is
> >> computationally trivial and serial transmission is far from
> >> inherently error-free.  Earlier NMEA specification versions require
> >> the checksum only for $GPRMC, but the latest NMEA version mandates
> >> checksum on all sentences.
> >
> > Lets not jump overboard to swim with assumptions. Sure DOES generate
> > checksums.
> >
> > Here is from my Sure board
> > $GPGSV,4,3,14,19,16,316,18,27,07,083,17,29,06,156,,30,03,233,*7B
> >
> > Now, ntpq -c clockvar may be stripping them off, but do not blame Sure
> > for that.
> 
> We've seen thanks to David Taylor $GPGGA checksums and thanks to you a
> $GPGSV checksum, which are both encouraging.  I admit there's a possibility
> of truncation in the quoted timecode, but it wouldn't be due to ntpq in all
> likelihood, but ntpd and in particular http://bugs.ntp.org/2140.  However, the
> evidence is also consistent with the default Sure config not emitting a
> checksum with $GPZDA, though I sure hope it's not true.
> 
> Cheers,
> Dave Hart