[time-nuts] Fury ntp refclock
smace at intt.net
Mon Jul 7 20:07:50 EDT 2008
Maybe just build it into the generic parse refclock? I just needed
to get it up and running and a standalone driver was the path of least resistance.
The neat thing about the gpgga string is that it happens every second and doesn't
rely on ntpd to send a command for it. It gives you a nice trigger to do all the
stats gathering after the timecode has been processed. As long as you do the stats
collection in less than a second... Jitter will never be low enough for it
to be useful without an external pps reference.
It would be nice to have a fully functioning short timecode that was emitted every
second (instead of polled) that contained all the useful bits that NTP needs,
time,sync/lock status, leap status, holdover status. Then add a new command to get
a one-line result for all the interesting non-timecode related info that
could be polled at whatever interval the user wanted.
The gps?,sync?,diag?,meas? results were easier to parse than the system:status?
since everything has a prefix.
I'm not a fan of a the system:status? command, but it would be nice to get
sat signal strength from the gps? command tree.
My driver is not ideal, but it works with what the Fury can do with the current
firmware. More to come.
Hal Murray wrote:
> 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.
> 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.
More information about the time-nuts