Millisecond is easy. Any system that has a clock and latch mode can do much, much better (since the event is latched in hardware, the real time ness of the system doesn't matter and you get one clock cycle of precision and accuracy). Generally the clock is fed by some frequency standard. Most OSes have facilities to also use the same clock to pace system time, and that's where NTP steering comes in handy. With a real reference clock, you can have a PPS and frequency standard, so you don't really need NTP. If you don't have a PPS then you'll need NTP for phase adjustments, but with a good frequency standard, you won't need it to steer frequency. I've seen setups like this on a good wired LAN get below 1us of synchronization.
The basics of clock translation that you'll need for this isn't too terrible. Even without NTP the basics are you need to trigger clock count latches at known times. Once you have the calibration, the math is simple, especially for the level you are talking about. Of course, leap second are a total pain in the back side in this environment if you must have UTC all the time, but I digress. Most of the SoCs I dealt with over the years can latch things. The driver reads the latch in some kind of interrupt routine. It's only when the interrupt latency rivals the pulse spacing that you run into trouble since the driver queues the events for the application to read at its leisure. I've also seen this done with a simple FPGA, but then calibrating the different clock domains becomes more of a challenge. Having said all that, your best bet is to get a data logging scope and just interface to it. They've solved all these silly math problems and often have real-time event logging that you can read over a socket. It's a bit pricy if you don't happen to have one of these in the lab, or need to build a number of such setups. But if you have one of these, for a one-off thing, the price can be right. Lots of people also swear by labview. I never got into it much though. Then again, there's a number of USB data loggers. The key thing to google for is "pulse data logger" and you'll get a variety of things. Most of them are designed to be put in the field, record its thing, and then read off. But many of these have a real-time mode. For example, http://www.onsetcomp.com/products/data-loggers/ux120-017 is one such product, though I haven't read through the data sheets enough for you needs. It all boils down to do you want to spend $100 to $200 for a solution someone else has done, or hoke together something with $35 computers and a bunch of your time, especially in calibration and testing. IF you are doing zillions of these, the latter may make sense. If it's just a few, the former is easier and gives faster time to deployment. Warner On Sun, Jan 10, 2016 at 7:59 PM, Rob Seaman <[email protected]> wrote: > Don’t know if this got through using my new email address. > > Have been rummaging around looking at Arduino and/or Raspberry Pi hacks, > but the former seems under-powered to run a full NTP instance and the > latter is not real-time. Surely there must be an off-the-shelf dohickey > that can return (via a unix-style service, for instance) a reliable > ~millisecond timestamp corresponding to a trigger? > > Or does everybody do rule-of-thumb or after-the-fact calibration of a > stream of relative ticks? (The project is intended to get away from such an > instance.) Just to be clear, this question is pretty much independent of > timescale. Given an event in the real world (for simplicity corresponding > to an electrical pulse or high-lo/lo-high transition with some perfectly > reasonable amplitude and time constant), what are best practices for > associating a well-tempered timestamp? > > Rob > — > > Begin forwarded message: > > *From: *Rob Seaman <[email protected]> > *Subject: **embedded data loggers?* > *Date: *January 10, 2016 at 3:03:49 PM MST > *To: *Leap Second Discussion List <[email protected]> > > Howdy, > > Any suggestions for simple (read: inexpensive) components that can be > embedded in an electronic device to grab timestamps corresponding to pulses > or signal transitions? Pulses will occur every few seconds for hours in a > row. The basic workflow is that something running under Linux commands an > action that later asynchronously causes a pulse, the precise timing of that > pulse (milliseconds would be sufficient) should be captured in some fashion > that can easily be read, again by Linux, before the next pulse. I’m > imagining a sample-and-hold feature, but am open to suggestion. The > logger’s clock might be synchronized via NTP, but again, whatever gets the > job done. > > Thoughts? > > Rob > > > > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs > >
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
