[ntp:questions] TrueTime refclock Users?

wa6zvp wa6zvp at gmail.com
Fri Apr 20 18:45:36 UTC 2007


On Apr 19, 8:13 pm, j... at extremeoverclocking.com (Jason Rabel) wrote:
> Dave,
>
> Yes, the driver appears to walk-through several old TrueTime devices, some
> of which I don't think are even functional these days. The 468DC GOES
> receiver will not work (GOES stopped transmitting time back in 05 I think)
> unless you use a special antenna that converts a GPS signal into something
> the unit can read. But that's another story.
>
> One of the reasons the driver did not work for me was the code is too
> generic when checking for a TrueTime device. It just assumes anything with a
> string "TRUETIME Mk III" is a GPS model and sends a F50 & F51 code to get
> some GPS specific satellite info. Since those codes are specific to GPS
> models only, my receiver sends back a "ERROR 05 NO SUCH FUNCTION" which
> throws the code into a different state making it impossible to proceed with
> the time-output. Those two codes that are sent (F50 & F51) are never checked
> against anything in the code to ensure satellite validity and such, I guess
> the somebody started the implementation but never got around to finishing
> it.
>
> I was hoping someone with a GPS model would be able to post their version
> string and see if it was different from mine, also it would be nice to get
> the GPS info to complete those checks. A little less elaborate method could
> be used by assuming if the Truetime string passes, but the F50 & F51 strings
> fail then it has to be a IRIG or PPS model. Or the whole F50 & F51 strings
> could be skipped entirely since they don't actually do anything.
>
> I noticed too if I first start the once-a-second time output from the NTS
> serial port then start NTP, it works just fine. The debug shows it stops at
> the first receiver check (Omega I believe) and since it's receiving time in
> a format it can parse (just falls through the code until the time parse
> routine) it is happy.
>
> Anyhow, I'm not complaining or anything, the whole experience of
> communicating through the NTS serial port was just a "for fun" experiment.
> Anyone using this method would have to adjust their offset slightly, but the
> jitter is quite reasonable. In the end though, it's not really a practical
> means of a time source for the NTS series since they have a built-in NTP
> server and even a PPS output.
>
> Jason

Jason (and Kevin)

It looks like you ran into much of the same thing that I did when I
attached an
old TrueTime WWV clock.  The driver can end up in a couple of
different states
when dealing with a clock it doesn't know about.  One is that it might
get
lucky, and see a string it knows how to decode and work fine, and the
other
usually ended in a core dump of ntpd because abort was called.

I modified the driver such that it can never abort, and added code to
see
if it was the clock I have.  This involved sending a 'pps off code (in
case it
already on) and then after ID, it turns it back on.  I did not remove
any of
the modes that support other clocks, including the stuff that works
with
the (now dead) GOES clocks.  It should work fine with anything that
it had supported before.

I will be working with Harlan to get it incorporated with the
mainstream
code.  If either of you would be willing to try it with existing
clocks,
that would be super.  I can supply the diff code or the whole source
if you want.

I'm also interested in adding some additional logging in places that
used to abort, so if anyone has recommendations on the right way
to do that, it would be appreciated. (That is, which calls to use.)

Roger




More information about the questions mailing list