Timestamp for each TTL signal input

[GollumGTH]

I have a NI cDAQ-9174 Chassis with a NI-9402 plugged into it.  I have a device that will be outputting TTL logic signals to this NI chassis.  I would like to be able to timestamp each of these logic signals (or at least get a number of clock ticks since some reference).  I would like it to work such that each time the signal goes high (or low, I don't care) the current time is saved to buffer and my program simply reads this buffer.

At this point I am confused as to how to set this up, and am concerned about the internal clock rolling over since these measurements will take place over many minutes.  I would appreciate it if anyone could give me some guidance or an example, thank you.

[Kevin_F]

Hey GollumGTH,

How you can timestamp your data will depend on how accurate you need the timestamps to be and how you are collecting the data.  If you don't need a great deal of accuracy (can be off by more than 100ms) you can use the built in timestamp functions in LabVIEW and timestamp your data in software.  This can be done using the method described in this KnowledgeBase article:http://digital.ni.com/public.nsf/allkb/EE0668C8F6CE617686256C920065EC52.  In your data aquisition loop you could just have logic to check for when the state of your TTL signal changed and then write the current timestamp to file.  If you wanted better accuracy using this type of software timed setup you could use a deterministic operating system to perform your data aquistion.  Alternatively to using software timing you could use a digital input task and set the sampling rate to something appropriate for your signal.  You can then get an array of all the digital values at the end of the aquisition and you know that the time each reading occurred is equal to array index times sampling rate.  You can then process that array looking for transitions to find the relative time each transition occured.  Please post back if you have any additional questions.

[John_P1]

The best way should be to use the 50 ppm timebase (80 MHz, 20 MHz, or 100 kHz) on the 9174 to timestamp your signal.  You can configure an edge count task, use one of the timebases as the edge count terminal, and use your external signal as the sample clock.  This way, on every edge of the external signal, the current value of the count register (in terms of timebase ticks) would be sampled into the buffer.  If you have some reference that you want to use to start the counter (t=0), you can configure an Arm Start Trigger, which will enable the counter to start incrementing based off of an external TTL signal.

Using the 100 kHz timebase as your counter source, you would have a 10 us timestamp resolution, and the counter would roll over after just under 12 hours.  This is probably the easiest way as you wouldn't have to account for the rollover (unless you will be running for around 12 hours), but you wouldn't have as much resolution on your timestamps.

The 80 MHz timebase would give a 12.5 ns timestamp resolution but the counter would roll over after about 53.69 seconds, so you would have to handle the rollover case.  If you can guarantee that the events do not occur more than 53.69 seconds apart from one another, you could handle the rollover as follows:

1.  Start at the beginning of the array. 

2.  Compare the current value A[n] with the next value A[n+1]

3.  If A[n+1] < A[n], add 2^32 to all values in the array starting at index n+1 (you'll have to cast the array of U32 data to U64 before doing this).

4.  Increment n and go back to step 2.  You'll repeat this until you have checked every value in the array.

If the events might be spaced out more than the amount of time it takes the counter to rollover, you can't rely on looking at the event timestamps to determine when the rollover has occurred (i.e. you might miss a rollover).  You would have to configure a 2nd counter to count the rollover occurrences (an edge count task will by default emit a pulse on the counter output terminal when it rolls over) and sample both counters together.  You could then just combine the two U32 samples into a single U64 sample (e.g. using the Join Numbers function in LabVIEW).

A compromise might be the 20 MHz timebase, which rolls over after about 3 and a half minutes.  If you will be running longer than this though, you'd still have to account for the rollover so you might as well go up to the 80 MHz timebase.

Best Regards,

[GollumGTH]

To start I should specify that software timing is not acceptable.  The entire reason I bought the NI cDAQ-9174 Chassis with a NI-9402 was to avoid trying to estimate the times.  I'm looking for timing accuracy of at least 1 ms (but I want as good as I can possibly achieve with this hardware).  I should also be clear that what really matters to me is time since a reference (i.e. the first pulse) and not absolute time.

After looking through some manuals I was wondering if it would be possible to use the period measurement to do this.  In others words could I have it continuously grab period measurements and simply add the current measurement to the sum of all previous measurements to obtain the time since the first pulse?

A more basic question, when doing a period measurement does this card return the time since the last pulse or does it always need a pair of pulses to return a single measurement?  In other words, if there are four pulses input, would it return 3 period measurements or just 2? 

It seems like if I can get this approach to work I can get the best of both worlds in that I can use a very accurate time base but measure all day long without worrying about rollover since the time I'm measuring is that between two pulses and not the time of the total test.  Am I looking at this right?

Thanks for all your help.

[John_P1]

The suggestion in my post doesn't use software timing.  I had suggested using an edge count task with a sample clock, which ends up being similar to a period measurement task except the result would be a running count instead of a series of times that you would have to add together to get the total.  Either method would be acceptable.  I suppose the period measurement task is nice in that you wouldn't have to worry about the rollover (as long as you got an event at least every ~53 seconds), but then again on the edge count task you don't have to sum the samples to get the current timestamp.

If there are 4 pulses input you would actually receive 3 period measurements.  The counter can return a sample on every pulse (use "Implicit Timing"), but on the 9174 the first pulse is discarded (since it represents the time between the arming of the counter and the first pulse, which is not a complete period).  Some other NI products (e.g. the legacy 9172 cDAQ chassis) do not discard the first sample, and 4 pulses would result in 4 period measurements (with the first sample not actually representing a complete period).

You can get the same accuracy with either a period measurement task or with a count edges task (using the external event as the sample clock for the edge count task).  The only difference is that if using the period measurement task you would have to sum up all of the values, and if using the count edges task you would have to account for the rollover (I explained how you might do this in my previous post).  If there is no guarantee of at least one pulse during the amount of time that it takes the counter to roll over, then the period measurement task won't work (but the edge count task could still work if you use a 2nd counter to keep track of rollovers).

Best Regards,

[GollumGTH]

Out of curiosity, could you do the period measurement and still account for rollovers with a second counter?  Wouldn't this allow for the longest time between pulses as well as the longest total test time for any given clock?

Could you point me towards an example of how to use a second counter to count the roll overs?  I'm not sure how to set this up.  Thanks for all your help.

P.S. My comment about software time was in regard to the first response, also I know I'm probably looking at accuracies way beyond what is actually needed but this software is being used for research so I have no clue what kind of tests they may want to do with it a year from now and when I give them limits on what is possible I want to make sure it is hardware and not software which is the only limitation.

[John_P1]

Hi GollumGTH,

The total test time doesn't really become a factor if you're using the 2nd counter anyway, as even with the edge count method the rollover will take longer than 7000 years using the 80 MHz timebase with the two counters cascaded (which essentially makes a single 64-bit counter).

But... if it makes more sense to you to do a period measurement on the first task, this should be possible.  I don't believe an error should be thrown when the period measurement rolls over.  The 2nd counter has to be configured as an edge count task though.  So:

ctr A:  Period Measurement Task, Implicit Timing.  Read back data as U32.

ctr B:  Count Edges Task. Sample Clocked off of your external signal.  Input terminal is the internal output of ctr A.  Also read back data as U32.

Or... ctr A could be an edge count task with sample clock timing.  The 80 MHz timebase would be the input terminal, and the external signal would be the sample clock.

Combine the result of the 2 counters to get the 64-bit sample.

If you run into issues with any of those particular steps please let me know and I can put something together.

Best Regards,

[John_P1]

I almost forgot...

If you're using the period measurement, you would want to reset the 2nd counter after each measurement.  There is a count reset functionality that you should be able to use.  However, I still think it's more straightforward to do edge count tasks on both counters.

Best Regards,

[GollumGTH]

I think you have convinced me and I'll go with the first method you mentioned.  Can you point me towards an example for setting this up?  Also, if I was going to use a second counter for the rollover can this all be done in software or do I need to have a physical connection between an output and an input on the card (i.e. a BNC connector between two terminals of my NI 9402)?

Thanks again for all your help.

[John_P1]

You can make the routing internally between counters.  See the attached example (written in LabVIEW, let me know if you're using a different ADE).

The counters must be armed at the same time if your events are free-running (that is, if they may be occurring while the tasks are being started).  The arm start signal must come from another source--this can be external or from a number of other internal sources such as the output of one of the other counters (the attached example shows an external arm start to keep things simple).  You have to guarantee that both edge count counters are started in software before sending the Arm Start Signal.

If the events are not being generated until after the counters have been started in software, then you would not need to worry about an arm start trigger.

You might also consider adding digital filtering in case the events are noisy and result in duplicate edges during the transition from high to low or vice versa.  This feature is only available in DAQmx 9.4 (and in any upcoming future releases) however.

Best Regards,