Fast simultaneous edge counting without stopping the task

[lancaster27]

Hi all,

I am trying to do edge counting with two counters simultaneously. The idea is to use them for photon counting application with two detectors. For this I use the third counter for synchronization. I configure it to generate single square pulse, and update the duration with my acquisition time for every measurement with DAQmxSetPulseHighTime function. The measurement counters are configured to use the rising edge of this pulse as arm start trigger (to start counting) and the low level of the pulse as pause trigger (to stop counting). And this works nicely.

However I noticed that Starting/Stopping tasks every time takes about 120 ms, so for acquisition time of, say, 100 ms this adds a considerable delay which I would like to avoid. I tried to keep the counting tasks running, but then the counter does not reset to zero, which obviously makes the results incorrect. I tried to reset the counters at the rising edge of the same pulse with DAQmxSetCICountEdgesCountReset but then it does not allow me to use the pause trigger, so that the counters do not stop counting when the pulse ends.

The only working solution that I was able to derive is to read the counter value before starting the trigger pulse, and then subtract this value from the counter value but this of course is nasty and I don't know what happens when the counter buffer overflows.

Is there a better way to achieve this goal?

The other thing is that in the future I would like to do the gated counting, meaning that there would be a hardware gate present when the laser pulse is present, so that the counting task would only run for a number of hardware gates (without resetting the count to 0) within a larger hardware gate that defines the acquisition time.

My board is NI USB-6366. The code is written in python but directly accesses DAQmx C functions so the question relates to ANSI C library.

Thanks,

Anton

[Kevin_Price]

First off, yes there's very likely a better way.  Do some searching here and you'll find dozens and dozens of prior discussions about photon counting apps.  By and large they don't depend on pause triggering but rather on edge-based modes such as period measurement or resettable edge counting.

A problem with pause-triggered operations is that there is nothing about the measurement values in the buffer that can tell you where the pausing starts and stops.  You get a data record that *looks* continuous, but the actual measurement represents a bunch of discontinuous chunks of time.

What's typically better is to do a specially configured version of pulse width measurement where the photon signal is configured as the timebase while the known clock is configured as the signal to measure.  You're still counting only when the clock signal is high, the big difference is that this way, there's a one-to-one correspondence between a single high pulse and a single sample value.  The pause-triggered method produces no such correspondence.

I program in LabVIEW and can't really help with the text API syntax.  Your future plan to add more "gating" may make things trickier, but it isn't clear to me *exactly* what you'll be looking to do in terms of timing, sync, and specific data to capture.

-Kevin P

P.S.  There's a way to reduce overhead related to stopping and restarting a task.  It starts by understanding the DAQmx is architected on a state machine model (please note, the diagram is a pretty good overall illustration of the behavior but is *not* the final word.  More searches here will reveal more details).   There's a function with a name similar to DAQmx Control Task you can call with the action "commit" prior to starting your task.  When you do so, any subsequent Stop and Start will have the minimum possible overhead.  Here's a benchmark that illustrates the dramatic improvement possible.

[lancaster27]

Thank you Kevin,

I added task commits to tasks which reduced the overhead from 120 ms to 31 ms which is definitely a huge improvement. If I combine this with my dirty solution of reading and subtracting data it is improved to 18 ms. I will keep looking into this as you suggested.

Meanwhile can you please clarify what are the drawbacks of the solution with pause trigger as compared with the pulse width measurement? The goal is to measure the number of photons that arrive to two detectors in a given time (say, 1 second, or 100 ms). From my point of view the counters are armed once the trigger pulse arrives and are stopped when it ends  so I do not understand what additional errors may I expect with this approach and what is their source.

Thanks,

Anton

[Kevin_Price]

I guess I had assumed you were taking buffered measurements to get a look at the dynamics of photon emission.  That's been the predominant approach I've seen discussed here for photon counting.

If indeed you are generating a single pulse with the leading edge acting as an arm start trigger, your method using "pause triggering" is a simpler way to get the same data I talked about with an oddly-configured pulse width measurement.   The method I suggested would only be advantageous if you were taking a buffered measurement that was governed by a pulse *train*.

-Kevin P