The Linux or BSD pulse per second interface is general enough to work for this. It does not care if the pulses are one per second or 100 per second, or 60.
Al it does it capture a timmer/counter when a pulse comes in. Then fets a flag a user program can read that says "data available". The user level programs reads the device ad gets the captured counter value, the flag is reset. Very simple and very low overhead. I think the counter units are nanoseconds On Tue, Jun 28, 2011 at 1:28 PM, Hal Murray <hmur...@megapathdsl.net> wrote: > >> Then the next step is to use an NTP driver that treats the 60 Hz pulses on >> DTR as the local time/frequency reference. Your PC will then run on "mains >> time" instead of UTC. Not sure how low a stratum that would be. Still, if >> you did this, then your existing NTP tools will give you all the logging and >> plots you need. Your PC is running mains; the rest of the network is UTC, so >> any time drift plots for your server will neatly indicate if TEC is working, >> or not. > > I don't think any of the current drivers in NTP will do the right thing for > this project. > > The PPS driver is a bit tricky. It needs help to figure out which second a > pulse corresponds to. I think there is a filter in there to reject samples > that are too far off from what it thinks is a second boundary. > > > > -- > These are my opinions, not necessarily my employer's. I hate spam. > > > > > _______________________________________________ > 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. > -- Chris Albertson Redondo Beach, California _______________________________________________ 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.
