> On Jan 12, 2016, at 4:20 PM, Chris Caudle <ch...@chriscaudle.org> wrote: > >>> On Jan 12, 2016, at 7:17 AM, Chris Caudle <ch...@chriscaudle.org> wrote: >>> Can ntpd using a Thunderbolt as a time source run cooperatively with LH >>> accessing the same Thunderbolt over ser2net? That seems like the best > > On Tue, January 12, 2016 4:01 pm, Nick Sayer via time-nuts wrote: >> I'm going to guess no, because only one thing can connect to the >> ser2net socket at a time. > > No, ntpd would be getting time from the serial port, not from the network > socket.
You’re right. I may be wrong, but I would expect that either gapd or ser2net would want to open the serial device exclusively, which would spoil things. > The idea would be that ntpd was getting the clock time from the > serial port, but the time messages would be interleaved with whatever data > the Thunderbolt was sending back in request to the LH commands. You might investigate whether you could make some sort of intermediate service that could be a client of gpsd and provide the listening socket for LH. If you’re fortunate, LH may be able to just connect up to gpsd directly. gpsd has the wherewithal to interleave client access, if I am not mistaken. > > LH would also be seeing the time messages, but it sees those anyway, so I > think the only concern would be the behavior of ntpd when all the data > from LH commands is going by. Possibly a second concern of whether ntpd > sends any commands to the Thunderbolt that might cause LH to be confused > by responses to commands LH did not send. > >> If I were going to do it, what I might do is connect up the PPS output of >> the tbolt to a GPIO pin of the RPi and configure that pin for the pps >> device and set up ntpd for that. > > You still have to get wall clock time from somewhere, PPS just delineates > the seconds, it doesn't name the seconds. Of course. You just have ordinary ntp peers for that. > For some cases you could have ntpd get the starting time from another > network source and just use PPS to keep track of the seconds after that, > but then you would still have corner cases of knowing when leap seconds > occurred, maybe others. Well ntp ostensibly takes care of that too. > And of course if you relied on network access to other time servers you > could not operate on an isolated network. That’s true. My goal, though, was just to contribute to the ntp pool, so connectivity is assumed. > >> That way, LH can have the serial >> interface all to itself. I've done this with a far more ordinary GPS >> module to make a public stratum 1 server out of a Pi Zero for the NTP pool >> (ntp.kfu.com). >> > > How did it get the correct time set at startup? Did it have to query > other network servers to set the time, then the PPS controlled the clock > after that? Yup. > Can it be a "stratum 1" server if it has to rely on another server to get > the correct time when it starts up? I guess it could if it doesn't serve > time until it has checked with other stratum 1 servers to make sure the > time is correct. That’s exactly right - it doesn’t claim stratum 1 until it gets an ntp lock over the network (at which point it can claim stratum 2 normally), and then it starts to take the pps updates and claims stratum 1. > > Sorry, didn't mean to go off into those weeds, but that isn't the system I > want. > I want a machine which can get the correct current time without reference > to another system, which means that ntpd must get the time information > from somewhere, either by directly reading the serial port, or passed > through from gpsd which is reading the serial port, or some similar setup. > The PPS driver would be connected directly to ntpd. The issue with the serial data stream in my case is that there’s no synchronization in it that’s sub-second accurate. That is, there’s no way to know which leading edge of which bit in the NMEA sentence is lined up with the start of the GPS second. And even if you get that, the serial driver doesn’t have any mechanism to accurately time-stamp the incoming characters - at least not nearly as well as the pps device. Now, that may not be the case with the tbolt, but with the module that that server’s using, trying to actually sync acceptably with gpsd is an exercise in futility. It’s much faster to just ignore the serial data and get synced initially over the network. > > -- > Chris Caudle > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
