Time-resolved pulse counting measurements

[stephencox]

First of all, I apologize if the title is difficult to understand.  I'm not sure exactly what to call what I am doing, which might be why I am having trouble finding examples and instructions online.

I am setting up a PXI system that includes a pulse counting measurement.  The DAQ I am using is a PXIe-6363, which is installed in a PXIe-1078 chassis with a PXIe-8840 running Labview RT.  I need to count pulses with good timing resolution (1 microsecond bins) during a repeating process that occurs every 50 ms.  So my goal is for the DAQ to receive a 20 Hz trigger, start counting pulses for close to 50 ms, then repeat at the next trigger.  The measurements will be divided up into microsecond bins with between zero and about five pulses recorded during each microsecond.  I need to know that, say, bin number 13400 occurs exactly the same amount of time after the trigger every time that this process repeats, because I need to be able to add up each bin after minutes or hours of measurement.

I don't have all the hardware installed yet to generate these pulses, so I have just been testing with pulses from an AFG.  I think I have figured out a solution, but I feel confident it could be improved.  My first attempt is attached, and I would appreciate any piece of advice.  Specifically, I think I should be storing information on the DAQ board and sampling it less frequently, but I am not sure how to go about doing this while still preserving the time information that I need.

[Henrik_Volkers]

Configure the counter for event counting and sample the counter with 1MSPS ...

trigger your aquisition with the 20Hz signal

read 1MSPS*50ms -x sample, say 49900 sample   , reset counter, start next aquisition

use a producer consumer architecture for the post processing

Where is the 20Hz signal comming from? Can you sync it with your 10MHzPXI-Clock/6363card?

Or use a second timer on the same board to create that signal?  That can reduce 'jitter' errors in the trigger to first sample, since the trigger can arrive at any point between two of your 1µs sampleclock pulses if both timebases arn't the same.

[cody_a]

Let me make sure I understand your goal: You want to know how many edges of a pulse train come in every microsecond for a 50 ms period.  You'll want to repeat that process every 50ms, correct?  If your acquisition window (50ms) is consistent and back-to-back, is there a reason you're not acquiring continuously?

Since you have an X Series (63xx) DAQ card, the count edges counter task supports a buffered sample clock acquisition mode.  You'll have to provide an external sample clock, but you can generate that clock either with another counter or a dummy AI, AO or DIO task.  By using a buffered sample clock acquisition with a 1MHz (1us period) sample clock rate, the device will latch the current edge/pulse count every 1us then store the value in a buffer.  You can then read off tens or hundreds of milliseconds worth of data at each DAQmx Read, with each sample representing the edges in a 1us bin.

If this sounds like it fits what you're trying to do, check out the "Counter - Count Edges (Continuous Clock)" example VI in the Example Finder.  Keep in mind that that example is looking for an external sample clock (on PFI0 by default) that is not in the example currently.  You'll have to add the counter output or dummy task I mentioned for the example to work as I explained above.

[stephencox]

Henrik, I think that is basically what I (am trying to) do with the example I posted.  I am using one counter to generate a 1 MHz pulse that provides a pause trigger to the other, which I set up following an example that I found online somewhere,  Unfortunately this makes it pause during the low period of the pulse rather than just immediately skipping to the next sample, so this was obviously the wrong way to set it up.  My test system is generating a constant frequency pulse train that I am counting, so I didn't notice this until I realized that I could only fit 25000 measurements into 50 ms.  Maybe I need to use an "advance" trigger instead?

The 20 Hz is currently coming from another counter on the same board.

[stephencox]

Cody, that's right.  I am not acquiring continuously because the most important property is the synchronization to the 20 Hz trigger, although maybe it doesn't matter since that comes from the DAQ board as well right now.  The solution that you proposed sounds promising.  If I simply set this up at 1 MHz and then acquire, say, one million samples every second, do I really not have to worry that I will drift off of my position relative to the start of each 20 Hz cycle?  

[Kevin_Price]

Since you're generating the 20 Hz signal from the same board that will do the measurement, then YES, you do NOT need to worry about drifting out of sync if you simply trigger once and acquire continuously.  Unless configured to use external timing signals, all the board's timing operations are ultimately driven by the same on-board oscillator and won't drift relative to one another.   They may (and probably *will*) drift relative to another board or an external signal.

For the more general case of a 20 Hz repeating trigger signal that is generated anywhere other than the same board you're using for measurement, a solution like Henrik's is a better alternative. 

A third idea I've sometimes favored is to sync up an additional measurement of the 20 Hz trigger signal.  You'd use your other task's 1 MHz sample clock as the edge/event to be counted and the 20 Hz signal as the sample clock.  A little simple post processing will help you correlate the "timestamps" capture by this new task with the indices of your original task's samples.  Both tasks would need to be started by the same "Arm Start" trigger signal so you know they share the same t=0.  Your original task can do continuous sampling.  Remember, this approach is only useful if your 20 Hz comes from someplace other than the board doing your original measurement.  Note too that the 20 Hz timestamp will usually land in the midst of one of your 1 MHz time bins and you'll need to consider how to handle that.

-Kevin P

[stephencox]

Based on this discussion and the suggested examples, here is my current solution.  The size of the data array it generates seems to oscillate between 49984 and 50016 samples, but I assume that is jitter of the end of the acquisition period rather than the start.  The 20 Hz signal that starts the acquisition is the same one that triggers the waveform (from an AFG) that ultimately causes pulses to be generated in the experiment, so I think this approach will do a good job of keeping each microsecond bin pegged to the same point on the waveform.  I'll post an update once I think it is in the more or less final form.  Any further comments or suggestions are welcome in the meantime.