[LEAPSECS] embedded data loggers?

[Warner Losh]

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 <seaman at noao.edu> 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 <seaman at lpl.arizona.edu>
> *Subject: **embedded data loggers?*
> *Date: *January 10, 2016 at 3:03:49 PM MST
> *To: *Leap Second Discussion List <leapsecs at leapsecond.com>
>
> 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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20160110/9b8c6e2e/attachment.html>