Autocorrelation function using counting module PCI 6602

[phuongmai]

Hello everyone,

Thanks to anyone who can give me help. I just starting with Counter/Timer applications and I am trying to set up new system for my lab. 

My hardware consist of a photon-counting APD (SPCM-AQRH-13-FC, Perkin-Elmer) whose output was a stream of transistor-transistor logic (TTL) pulses. The TTL
output generated by the APD was connected to the 32-bit, eight input channel counter/timer board with the maximum input rate of 80 MHz (PCI-6602, National Instruments).which means the fastest input pulses that can be counted are 12.5 ns (1∕80; 000; 000 s) apart. The counter can count the events continuously and store the data in the buffer.

I expected to have data acquistion with have " queue" structure to link “producer” loop and the “consumer” loop, which were in charge of reading photon counts and writing results to a file. Of couse 2 loop can work paralell.

Simultaneously, another labview program detected the latest written photon-counting file and calculated the auto-correlation function by FFT( fast and furious transform)  algorithm.

I take a look some example and this code in attached file can show the counter incresing but the problem is overwritten too fast and I can not handle or hole the photon count signal to apply the autocorrelation calculation. 

I am a newbie in Labview programming so I thanks to anyone who can help me with vi code or whatever. I am really appreciate it.

Regards,

Phuong

[phuongmai]

Hello everyone,

I added autocorrelation function for previous code that I posted. Until now I do not know how to count the events continously and and write photon counting to the file. 

Anyone can help me to handle the part that can be continued to count the events without overwritten. I go through some reference to increase the buffer size but it still didnt work well. The buffer overwritten too fast and stopped the count value so that the autocorrelation function calculated is wrong. 

I am really appreciate any help and comment for my research.

Please check the vi code in attached file.

Thanks for all the help

Phuongmai

[Kevin_Price]

Your code looks generally reasonable.  The overwriting problem is probably related to your data acq device which has a very small (2 samples I believe) FIFO for delivering from the card to system RAM.  Any fast burst of APD pulses is prone to produce this error.

Much better count streaming behavior is available with newer devices which have a much larger onboard FIFO, capable of handling such bursts of activity.  There are some benchmarks on the site somewhere, by memory I want to say that the 6602 tops out in the 100's of kHz sustained data rate while the X-series can handle many MHz.

...Just looked a little closer at the code.  I see that you're currently using another counter to simulate the pulses from an APD.  So you can control that rate, which makes the buffer overrun more puzzling.   But then I noticed the little comment "value not used" next to your sample rate setting.  That may only be *almost* true.    In continuous acquisition tasks, DAQmx tends to use your buffer size input as a request and not a command.  I know it can sometimes choose to give you a larger buffer than requested, I'm not certain if it might also sometimes give you a smaller one.  It's a feature meant to help newer users I think, where DAQmx tries to auto-size the buffer based on the sample rate.  

The (possible) problem arises when you use an external signal as the sample clock.  I vaguely recall getting similar undesired and unexpected behavior in the past when I, too, tried feeding a dummy value like 1 to the sample rate when I was using an external clock.  (Mentailly thinking of the 1 to simply mean "1 sample per clock cycle").   Try feeding in a nice big sample rate value like 100 kHz and see if it helps.  The hardware and counting behavior are unaffected by the value you feed in, only the default buffer size and timeouts might get affected.

An alternative is to call the DAQmx Buffer property node directly after setting up the sample clock.  The direct call is treated as a command and not just a suggestion.

-Kevin P