On Apr 19, 8:13 pm, [EMAIL PROTECTED] (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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
