[time-nuts] Fury ntp refclock

[Hal Murray]

smace at intt.net 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.