I wrote a program called tboltd that does just that. You have the option of having it write the time to shared memory and using NTP's SHM driver. You can get it at http://topoatlas.com/tboltd/tboltd.gz. It compiles on FreeBSD, not sure about Linux. tboltd allows LH to connect while it does its thing.
Ralph AB4RS > >> 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. > _______________________________________________ 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.
