[ntp:questions] timing issue with a HP 58534A

Mark C. Stephens marks at non-stop.com.au
Mon Feb 6 13:06:09 UTC 2012


Yes, GPZDA is doing the trick. You know I tried other sentences before but a) probably wasn't patient enough and b) I have found the fudging time2 value is critical - Time2 is now 560 to get the NMEA refclock to stop being false ticker. Surely that shouldn't be a critical value? 

As a footnote, I have a number of GPS rx lying around from various gpsdo projects. I am tempted to try some of them out as well and see if the time2 is really touchy. Hmm, Actually, I have a thunderbolt and a GCRU (scpi gpsdo) I can hook in to my test ntp server too. The secret to planning projects is make em so big they will never get started ;) Anyway, there I go raving again..

Thanks Dave

>It's the only one that matters here.  refclock_nmea.c treats both as valid timecodes, but the timing mode GGA output tells it the GPS Quality >Indicator is 0, meaning "Fix not available or invalid."  That makes some sense in that it's not attempting to provide position fixes in timing mode, >but the NMEA driver can't distinguish that from "I've just started and have no clue if my time code is synchronized to UTC."

>Perhaps instructing the driver to use a different NMEA sentence will cure it?


> Footnote:
> To further complicate matters, I wired up a tee cable and sent the NMEA to another NTP server here running windows NTPD 4.2.7p238-o.
> NMEA works fine on that server in either mode.

GPGGA I kid you not, it's in clockstats...
>Which NMEA sentence is the Windows ntpd showing in ntpq clockvar (cv) output?

Cheers,
Dave Hart




More information about the questions mailing list