Photon counting buffer problem Ni-6221

[VictorClaessen]

Hello,

we're using Labview to acquire photon arrival times from our photo detectors (APD) via a buffered period measurement against

an internal clock timebase.

We used to do this for one APD on one channel on a PCI-6036E car using traditional daq drivers. Recently we wanted to expand

our setup to include a second detector. Unfortunately our DAQ card only had one DMA channel available, and could not write

its data into the memory quickly enough using interrupts, so we could not use this card to acquire date from two detectors.

We therefore looked for a new DAQ card and ended up choosing the M-series 6221, seeing as it had multiple DMA channels, two

counters and an 80 MHz-timebase (which was also a slight improvement compared to out 6036E which had a 20 MHz timebase).

The first set-back was that this 6221 card apparently does not support the traditional daq drivers. So we started working on

figuring out how to do a buffered period measurement with the DAQ-mx drivers. After a while we figured out how to set up a

virtual channel to get out our data. Attached is a working sample VI that gives a signal intensity output graph for one APD.

We're having problems with error -200141. We get this error all the time, at virtually every count intensity. The frequency

with which this error occurs increases with increasing signal intensity. Also the problem is more severe when listening for

APD pulses than it is when we hook up a frequency generator. The frequency generator of course produces nicely spaced and

periodical pulses and the APD gives a signal with a poissonian distribution of the inter-photon-times. Also, the pulses from

the pulse generator are

The error points to a sort of "buffer overflow": Data was overwritten by the system before it could be read. Even if we allow

the task to overwrite unread data, we still get the error. Also, it is hard for me to imagine that a APD signal with a mean

of 2500 counts / second can overflow a buffer of 100k samples every few seconds. I also tried setting the buffer size to 4M

samples and that helps somewhat but the task still crashes every few seconds when we feed it an APD signal with a mean of

~5000 counts.

It sounds to me more that the hardware buffer on the card is at least partly to blame. But we're not really sure what the real underlying problem is...

So the questions are:
1) Is it really not possible to use tradional drivers with our PCA-6221 daq card?
2) Are we overlooking something?
3) how big is the hardware buffer (FIFO?) on our card for counting purposes?
4) Is this going to work with this card?
5) Should we consider buying another card, and if so, which?

[Kevin_Price]

  There have been a lot of threads here about photo counting and time-stamping.  Here's a few of my thoughts and you can do some searches to find a whole lot more ideas.  Sorry, I don't have LV handy to be able to look at the code now.

  The error is pretty likely due to the board's hardware FIFO getting overrun before the driver can transfer the data to system RAM.  The FIFO is only 1 or 2 samples deep.  2 or 3 consecutive photon pulse edges that arrive too close together can produce this error.  Two likely causes are somewhat noisy photon pulses, or brief bursts of pulses at a very high rate.   Among the possible noise workarounds are board-level features to digitally filter the incoming pulses.  To work around bursts of pulses, I would point you to one of the USB-based M-series boards that has a much larger counter FIFO of 1024 samples.  I think it's the 6210.

  These general thoughts are only partly consistent with your symptoms though.  The fact that the problem is more severe with the real APD than with a function generator is probably a key clue that either noise or brief high-freq bursts from the APD are a factor.  The fact that the problem doesn't entirely disappear with a func gen is a clue that you may have more than one root cause.

  I'm a bit surprised that calling out a larger system RAM buffer also helped a little.  It could be that *some* of the error codes are caused by the board's hardware FIFO while others are caused by overwriting the system RAM buffer.

-Kevin