High Speed Buffered Event Counting

[otheredward]

Hello,

I am using a 6602 board with LabVIEW DAQmx under Windows XP. I would like to do very fast buffered event counting. I have a light sensitive device that will be detecting photons and I need to count the number received very quickly as we're using a resoant mirror that are fast (about 16kHz). In the typicall fashion I would like to connect my photon counter to the source pin and have pixel clock connected to the gate pin. The clock connected to the gate pin needs to run around 100MHz which I now realize is way beyond the capacity of the 6602 board as detailed elsewhere:

http://forums.ni.com/t5/Counter-Timer/buffer-size-6602/td-p/85985

http://forums.ni.com/t5/Counter-Timer/Photon-Counting-Time-Stamping-and-basic-help-with-how-DAQmx/td...

So what it boils down to is I'd like to write counts to the buffer at around 100MHz, if I could even latch counts at 50MHz I could work with that. Are there any work around for this problem or can anyone recomend a DAQ baord (would prefer something that works with labview) that can do this kind of counting at or around this speed? A person on a different thread recommended a board by Viewpoint Systems for this kind of thing, any reviews?

Thanks,

Ed

[Dave-C]

Hi Ed,

From what I'm understanding, you need a card with a 100 MHz clock and buffered counters.  If that's accurate, I'd recommend looking at the PCIe 6320 (assuming you have a PCIe capability).  It offers a 100 MHz base clock and 4 counter channels.  If I've misinterpreted what you're looking for, please let me know. Similarly, if this looks like it will work for you, I'd appreciate knowing that as well.  

Regards,

-Dave C

[otheredward]

Hi Dave,

Thanks for the recomendation. I think a 100MHz clock would be great but my concern is how quickly the card can latch count values into the buffer when performing buffered event counting. So the clock is 100MHz but how big is the onboard FIFO buffer and once that fills up how fast can data be transfered off the card and into system memory. There is a pretty good post that describes the limitation I believe I'm dealing with on the 6602 board here:

http://forums.ni.com/t5/Counter-Timer/buffer-size-6602/td-p/85985

which is that the 6602 can only store 2 samples in its on board buffer before it has to start moving samples to the computer's memory. If data is being written to the buffer faster than the card can trasfer values to the computer's memory you get this error message:

http://digital.ni.com/public.nsf/allkb/83656593DCF1FB0F862570B6004D7222

which is the error I'm getting right now. So I want to know if National Instruments makes a card that has a lot of buffer space physically on the card that can be populated quickly, i.e. can do very fast buffered even counting.

Thanks,

Ed

[John_P1]

Hi Ed,

As far as latching counts into the count register, this can be done up to 80 MHz according to the specs on the 6602 (maximum source frequency).  The source is the signal that updates the value of the count register.  To be able to count this quickly you must disable duplicate count prevention.

Sampling the value of the count regsiter into the buffer (based off of the gate signal) is where you are running into problems.  At max you can do this at a couple hundred kHz (the exact value would be system dependant) since there is not an on-board FIFO that can buffer up the samples.

From my understanding based on similar applications I've encountered in the past, you'd like to count the number of photons (source) that occur during each period of the pixel clock (gate).  What is the output frequency of the photon counter?  What about the pixel clock? 

If your pixel clock is indeed 100 MHz, sampling on each pixel would result in 400 MB/s of data using a 32-bit counter (well above the maximum theoretical throughput of the PCI bus, even if the 6602 had an adequate buffer).  X Series is also not an option--it can sample the count register at higher rates than the 6602 (still not high enough though), but it does not have as much front-end bandwidth and can only count external signals up to about 25 MHz.

Best Regards,

[otheredward]

Hi John,

Thanks for the good information. The photon counter can't go above 5MHz and its much more likely it will be detecting somewhere in the single digit kHz range so I think the 6602 is more than capable of keeping up with that. We're using resonant scanning mirrors that have a high fixed frequency (about 16kHz) and we'd like to sub divide the period of each mirror oscillation into, at maximum, about a 2000 pixels (bi directional scanning). Our brute force method, which appears is probably not workable, would be to connected the photon counter to the source connection and a pixel clock to the gate connection. WIth the aforementioned mirror rep rate and trying to get about 1000 pixels per line we'd be looking at a pixel clock around 32MHz. But we were hoping to sample faster so we can rebin the data to adjust for nonlinearities in the mirror movement.

I just looked up the specs on the PCI bus and you make a very good point about our data rates being well above the max. Perhaps we will try an alternate approach, thanks very much for your advice. Although it appears PCIe could accommodate these speeds, any chance there is a 6602 equivalent that runs on PCIe?

Thanks,

Ed

[John_P1]

Hi Ed,

So it sounds like the photons actually occur at relatively sparse intervals.  What if you used the pixel clock as the source of the counter?  You could use the photon counter as the sample clock.  This way, each photon that occurs would result in a single sample that shows during which pixel it occurred.

Instead of an array of samples from each pixel clock:
{0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 ... etc.}

You would receive an array of indexes of where the photons occurred:

{12, 26, ... etc}

Now, this still won't work if the photons occur at high rates (say, over a couple hundred kHz), but if you are expecting somewhere in the single digit kHz range then this should certainly be sustainable.  It would be pretty easy to construct the first array from the second (if you needed to).

As far as bus throughput goes, PCIe x1 has a theoretical maximum of 250 MB/s.  X Series devices use this bus, and could likely sustain transfers at the speeds you are talking about (32 MHz * 4 Bytes per sample = 128 MB/s).  However, the digital front-end of X Series only has enough bandwidth to accept external signals up to ~25 MHz, so this would prevent you from using your 32 MHz external signal (as the clock or even as the counter source).  The 6602 (and 6608) are unfortunately the only current NI counter products with enough front-end bandwidth to accept a 32 MHz signal, and they both use the PCI bus.

From what I can tell though, the 6602 should be a viable option given that you can switch the signals you are using for the gate and source and obtain a compressed version of the same information.

Best Regards,