Re: TrueTime refclock Users?

On Apr 19, 8:13 pm, j...@xxxxxxxxxxxxxxxxxxxxxxx (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

.

Relevant Pages