[EMAIL PROTECTED] said: > I've created a ntpd refclock driver for the Fury GPS receiver. The > refclock is based on the NMEA driver.
Neat/thanks. There is currently a major reluctance to add new drivers to the main ntpd source pool. I think we should add this logic to the hpgps driver. > The driver was created because the Fury does not fully implement the > ptime:tcode? T2 string. The output is not on-time and the status > fields are always 0. So, it is not going to work with the hpgps > refclock. As it turns out the T2 string is rather limiting anyways. Said: Can you make the T2 string be "on time" and/or fix the status fields? Would it be better to invent a T3 string that had everything needed to tell time and also everything people are likely to want logged? Is "everything" a sensible concept? Would that be too much for most people and still not enough for a few? Maybe a mode in the Fury would solve that? Or bit mask? The driver would just log everything after the date/time/status so it doesn't care. (as long as it isn't too long) There is currently a bug/oversight in the hpgps driver. It only gets one sample per poll interval rather than 1 per second. (The refclock interface has a FIFO and code to discard outliers and average the rest.) Fixing this is high on my list. The hpgps driver currently logs a 24x80 status screen if you ask for clock statistics. I'd like an option to record just the interesting parameters. Of course, I have to do this without breaking anything for people who use the current setup. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
