Multiple edge separation measurement

[leigh42]

I wondered if someone could tell me if this was possible or how I might set it up if it were. I want to do a variation of Two-Edge Separation measurement with an NI PCI 6602 and DAQ-mx, but with multi-stop capability. What I'm basically trying to do is create a simple multi-stop time to digital converter (TDC). I'm looking at events happening on a millisecond time scale.

What I would like to have happen is to arm a counter in response to a digital start trigger on one line, counting ticks from the onboard clock (80MHz for the 6602 I think). I want the counter to log to a buffer tick count each time a "stop" trigger appears on a different line. However, there are potentially multiple stops that can occur on each cycle. So, for example, I might arm the counter and 3 digital triggers occur on the stop line after (say) 2, 6 and 7 ms. The task itself should stop after a timeout (say 10 ms from the start trigger). On issuing a Read command after the timeout I would like to return an array with those 3 values (or the proportional number of ticks) which is then histogrammed over multiple cycles.

Is that possible/straightforward?

[Kevin_Price]

Is there, can there be, or must there be any gap time between one 10 msec interval and the next?

An approach with *no* gap time would simply run continuously and break down the data into 10 msec intervals during post-processing.  That's gonna be the most straightforward method.  All it needs to be is an edge-counting task where you configure the 80 MHz clock as the edge count terminal and the "stop line" signal as the sample clock.  Each sample will record the # of ticks up until that assertion of the stop line.  Triggering needs to be set up as an "Arm Start" trigger rather than the more commonplace Start trigger.  In LabVIEW, this can only be done through a DAQmx Trigger property node.  You need to define Trigger Type, Source, and Edge.

Other methods will probably get difficult because the ones that come to mind would depend on things like retriggering or pause triggering.  However, you can't retrigger the "Arm Start" trigger needed for counter measurement tasks, nor can you have both Arm Start and Pause Triggering active at the same time.  Any workaround is liable to get pretty convoluted.

-Kevin P

[leigh42]

I don't think that works, but I think you've lead me to the right answer. If I understand you, you're basically just doing buffered event counting, with the clock as the source and the stop line to the gate. The issue is how to get that to work with a start trigger. I think your solution times everything to one common trigger? What I need is once on 10ms cycle is over, look for another start trigger to indicate commencement of the next 10ms cycle, and so on for each cycle. However, where I think I have an advantage is the timeout can be a bit sloppy (I wouldn't care if one cycle was 10ms and the next 11ms, say), and if there's some time between resetting between each cycle that also doesn't matter. The only thing that matters is events within a cycle are timed accurately back to the trigger that starts each cycle.

So I could do something like, configure a regular Start Trigger (rather than an Arm Start) at the start of the code, then run a while loop that goes: 1) Issue START command (the Start trigger means counting only starts when the trigger is found), 2) Issue STOP command some time later, 3) Read out buffer and stick it in the histogram, 4) go back to 1).

The issue is that the START command is not synchronized to when the task actually starts. So a simple software delay of 10ms between START and STOP wouldn't work, the task may not have started at all. So then a workaround could be to have a dedicated counter that is running a task that is somehow configured to take 10ms, say count the clock until the count reaches 800,000, and looking for the same Start Trigger. Issue both tasks their Start Commands at the same time and then use the "wait until done" VI on the timer (or just poll that counter until it reaches 800,000), and when that's finished stop the other channel, read out the data and then restart both counters for the next cycle.

Does that seem right to you? Thanks kindly, I think that solved it.

[Kevin_Price · Accepted solution]

1. Yes, I was basically describing buffered event counting.  And my suggestion would time everything to a single trigger.

   Your need to retrigger repeatedly is going to complicate things unless you can live with software timing between triggers and thus, possibly missing some.  The idea you described is one such approach that sounds basically viable.

2. The good news is that the 6602 has enough counters that you can at least entertain some of these more complicated scenarios.

3. The next simplest pure hardware approach would be to set up 2 buffered event counting (a.k.a. edge counting) tasks that are both "Arm Start" triggered by the same signal, probably a signal you control programmatically.  The 80 MHz clock will be the edge count terminal for both.  One task uses the "stop line" signal as the sample clock, the other task uses the original trigger signal as the sample clock.

   You still have post-processing to do, but you'll have hardware-precise capture of *all* events without a chance of missing any.  You essentially end up with individual timestamps for every stop and every trigger, all referenced to the same t0 trigger time, and you'll be able to find all the values for "time from most recent trigger" with a some fairly simple code.

   Depending on how long you measure, you may need to be aware of counter rollover.  At 80 MHz, the count registers will rollover back to 0 in less than a minute.  Again, this should be easy enough to identify and correct during post-processing when you know to watch for it.  It'll help if your first step in post-processing is to convert your u32 count arrays to u64.

4. Another approach is more complicated to configure but takes less post-processing.  It also has some elements of software timing, so it may not offer many advantages over the method you already proposed.  Nevertheless, here goes.

   The idea is to pair up 2 other counters to act as an intermittent timebase that substitutes for the internal 80 MHz clock.   Counter A would be a continuous pulse train at the max (actually only *sort of* the max) freq of 20 MHz.  It is set to be pause-triggered by the output of counter B, configured to pause when low.  Your buffered event counting counter will use the output of counter A as the edge count terminal.

   Then counter B is configured as a retriggerable single pulse with a 10 msec high time and a low idle state.  It's triggered by your original trigger signal.

   The software timing element is that you would start counter B, wait for it to complete, and as soon as it's done you would stop and restart your buffered event counting task.  (Note: in this mode, the event counting task no longer needs to be triggered, and possibly shouldn't.)

   One potential glitch here is that I'm not 100% sure how the "Wait for Task Done" vi interacts with a retriggerable single pulse.  It may not behave the way you'd need it.  In such a case, you'd just change to a regular one-time triggered pulse and when *IT* is done, you'd restart the event counting task first and then the single-triggered pulse task.

But like I said, there are software timing elements at work there, so it may not offer an advantage over your simpler proposal.  Item #3 above should give you the most complete data set, all hardware precise and no misses.  You just have to do some post-processing work.

-Kevin P

[leigh42]

 Thanks kindly Kevin,

I see what you're doing with option #3, that's a clever idea. My data accumulation period is going to be hours or days, rather than seconds, so that might be an issue. But I'm happy either your suggestion 4 (which I think I follow) or my suggestion are viable options.

Cheers!