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@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 [email protected] 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 [email protected] 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@NTP ~]# uname -a FreeBSD NTP 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #2: Tue Feb 7 03:51:49 EST 2012 root@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:[email protected]] > Sent: Tuesday, 21 February 2012 7:35 AM > To: [email protected] > Subject: Re: [ntp:questions] ntp version 4.2.7p257-o > > On Mon, Feb 20, 2012 at 17:34, unruh <[email protected]> wrote: > > On 2012-02-20, Dave Hart <[email protected]> wrote: > >> On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <marks@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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
