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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
