timestamping asynchronous digital inputs

[IUBwork]

I'm interested in timestamping digital input events (TTL signals) relative to a start trigger for acquisition.  I require ~10 micrsecond accuracy in the timestampsing, so I'm expecting I'll need to use onboard counters and record the counter state when a digital input arrives (rising edge detection).  I'm new to using NI counters so in looking through the MF DAQ manuals I've noticed a number of features for period detection, counting the number of events, ... However, what facilities are available for recording a counter's 'count'? Therefore to record to file the counter's state when a digital signal arrives.

thanks

[Brian F.]

Hello IUBwork.

Thank you for contacting National Instruments.

There are a couple ways to record timestamps for incoming digital signals.  The first way is to use LabVIEW VI's that are in the Timing functions palette.  However, the resolution that these VI's offer isn't on the microsecond level that you desire.  The second way is to use a counter to count the number of events.  This will effectively give you a relative time.  A VI that is helpful is the 'Count Digital Events' VI that can be located at:

NI-DAQmx: Count Digital Events

http://zone.ni.com/devzone/cda/epd/p/id/5011

I hooked up a square wave to the counter 0 source input and was able to count how many periods in the square wave had occured.  This will give you a highly accurate count and I have tested the VI to verify this fact. 

Let me know if you have any other questions or if my statements require additional clarification.  Good luck on your application and have a great day!

Brian F

Applications Engineer

National Instruments

[Kevin_Price]

It sounds to me like you need a buffered measurement so you can produce an array of timestamps, right?  If you can bear with me I'll get back to that, but first a little journey into the counter hardware itself. 

The DAQmx terminology for counter measurements tends to obscure what's really going on in the hardware.  On balance, this is probably pretty helpful to the majority of users who aren't terribly familiar with counters.  However, once you want to start doing some intermediate-level stuff (such as buffered timestamps relative to a trigger), you wind up a little stranded on the rocks of the API.   Namely, there is no "timestamp" task listed so which of the other modes offered by the API should you use?

Well, here's how the hardware works.  The counter has a Source input and a Gate input.  Active edges on the Source cause the count register value to increment.  In buffered data acq tasks, active edges on the Gate cause the instantaneous count value to be buffered.  There, that's it in a nutshell.

So for your app, you would want to feed a constant time-keeping clock signal into the Source input and the signal you desire to timestamp would go to the Gate input.  The count value will simply keep on incrementing regularly due to the Source signal, thereby keeping track of cumulative time.  Meanwhile, on each active edge of your measured signal at the Gate, the instantaneous "timestamp" will be buffered.

1. Under DAQmx, this would be configured as an "Edge Counting" task.  When you specify the signal whose edges you're going to count, select one of the board's internal timebase clocks, such as 20 MHz or 100 kHz.  In hardware, this becomes the Source signal to your counter.

2. Call DAQmx Timing, and wire the input for "Sample Clock Source".  Despite the word "source", this actually acts as a Gate signal at the hardware level.  Here you specify the signal whose edges you'd like to record timestamps for.

3. For counter input tasks like this one, you can't use the regular Digital Start Trigger.  Instead, you need to use a DAQmx Trigger property node and configure the trigger type to be an "Arm Start" trigger.

4. Be aware that if you choose the 20 MHz internal timebase as a source, you get better precision on your timestamps but you risk overflowing the count register.  On E-series boards, the count value is a 24-bit register and overflow occurs in less than a second.  M-series boards and the 660x counter boards use a 32-bit count register which won't overflow for something like 3.5 minutes.

Note: overflow is NOT a showstopper of a problem, there are ways to handle it if needed.  Using the coarser 100 kHz clock will increase your time-to-overflow by a factor of 200.  There are also both hardware and software methods for monitoring overflow and counting how many times it occurs.

-Kevin P.

[kgupta]

Hi Kevin,

Thanks for that post, it was incredibly helpful. I just had a follow-up question:  I'm a little confused on how exactly to set up the counter. You say: "When you specify the signal whose edges you're going to count, select one of the board's internal timebase clocks, such as 20 MHz or 100 kHz." Does this mean we need to provide a signal to act as the clock, or that the device is using an internal clock?

Thanks!

[kgupta]

Also, I should mention I'm using a PCI-6602 card.

[Kevin_Price]

From the "picture is worth 1000 words"  dept., start with something like this:

You kinda use the functions sideways here, treating a real constant timebase clock as the item to count while treating your external signal as a timebase.  The end result is an array of buffered cumulative timestamps for

edges on the external signal in question.  Divide the count by your timebase freq (count/20 MHz) to get actual

time in seconds.

-Kevin P

[kgupta]

Thanks so much, that worked! 😄