Time stamping photon arrival times

[wbilll]

Hi,

I am trying to use almost exact the same setting suggested above to record photon arrival time by count edge task on PCI 6602. The digital output is used to synchronize a shutter open with the start of photon counting.

But I keep getting the error -200141: "Data was overwritten before it could be read by the system." Seems like it is because the data was not transfered fast enough from FIFO to PC memory?  I also observe the higher the photon count rate, the faster the error appears. If the photon counting is about 3k count/s, the reading from the "intensity" go down to zero after ~1s; if the counting is about 100 count/s, it go down to zero after ~1min. In both case the error appear when I stop the task. I don't think the sampling rate is too high here but don't know how to fix this. Any help would be appreciated!

[Kevin_Price]

I think the essential problem is that your photon burst rate must sometimes greatly exceed the sample rate of 5000 you fed to DAQmx Timing.  Part of the reason this is a problem is because of the way DAQmx automatically sizes the acquisition buffer for continuous tasks. See this link.  Your acquisition buffer is 10k samples.  If you claimed a sample rate >10000, you'd get a much bigger buffer of 100k samples.

The other contributor to the problem is your 100 msec loop rate.  Apparently, you must have photon burst rates that overfill your 10k buffer during that 100 msec.

The solution is probably a combo of a bigger acquisition buffer, and extra care to be sure that the loop iterates fast enough to pull data from the buffer before it overfills.  You should be able to figure that out from your max burst rate and the buffer size.

-Kevin P

[wbilll]

Hi Kevin,

Thanks a lot for your suggestions. I try to play with the sampling rate and loop rate but the error still occur. (increase the sampling rate up tp 20M still the same). Also, when I remove the while loop and change it to "finite sample", the same error occur if I set the "sample per channel" larger than 30k, no matter how high the sampling rate is. Still trying to fix it... 

[Kevin_Price]

Sorry, I was thinking of a different error code for when the PC's task memory gets overrun by too much data coming in and not enough "DAQmx Read's" to keep up.  

There's a lot of info on the site about your error -200141.  Unfortunately, about the only thing you *might* be able to do to help is to set up input filtering on the 6602.  But if that doesn't solve it, you're probably pretty stuck due to the itty bitty 2-sample FIFO on the 6602.  In that case, your best bet is to use a different board with a bigger FIFO for counter tasks.  I believe that would include most any X-series board, the newer 6612 counter/timer, and some USB M-series boards.

-Kevin P

[wbilll]

Hi Kevin, 

Thanks for your suggestion, I go ahead and play with digital filter and the signal quite a bit. And also use oscilloscope to check the signal quality. Here are some observations and question:

1. The TTL signal from my APD detector show a very clean square waveform, I don't know why that would possibly being detected as multiple egdes (I know this is speculation though).

2. I test the 6602 card with a pulse generator, it can handle up to 200kHz pulse, and the same 200141 error occurs when the pulse rate reach 400~500 kHz, which is much higher than my photon rate from APD (the error pop up at about 2~3 kHz photon rate). No idea why that would be the case...

3. I try to implement digital filter by using photon signal to trigger an on borad counter output, and use that output as sample clock in a CI Count Edge task. But it doesn't seem to be reliable, I haven't totally figured out yet, but it seem to change to counting numbers.

4. In terms of CI Period task, I notice that if I use the photon signal as the period input terminal, and internal 80/20MHz clock as timebase, the 200141 will occur; but if I use the internal output from another counter as period input, photon signal as timebase(count a fix pulse in terms of ticks of photon signal), it will count properly and that error will not show up. Why is that...?

Thanks you so much!

[Kevin_Price]

1. good to confirm clean signal, can move on to other suspects

2. can't say for sure, but suspect it relates to a brief high-freq burst of photons.  Isn't it true that delta times between consecutive photons will be a distribution with a pretty high variance?   The small FIFO makes the 6602 very susceptible to a small # of near-simultaneous photon arrivals, even if the average interval is easily handled.

3. this approach is one way to apply a rate-limiting filter to the incoming APD pulses.  If you have a 4 microsec total pulse time, then once you've triggered off an incoming APD pulse, you will block any additional pulses arriving within the next 4 microsec.  This approach *should* give you a shot at characterizing pulses arriving at intervals greater than 4 microsec.  It will *not* inform you of how many pulses are blocked / ignored due to the filtering action so it will add some error & uncertainty to your measurements.

4. this approach has often been settled on in previous threads I've been in -- using APD pulses as the timebase with a fixed rate sample clock.  This establishes time bins for counting #'s of pulses per bin (rather than interval between pulses per pulse). 

   The reason this approach works is that now APD pulses merely increment the count register.  Sampling and transfer over PCI bus and FIFO issues are now governed by the fixed-rate sample clock coming from another counter.  You just choose a supportable and useful rate.

   One last thing to watch for is the possibility that you *may* need to configure a property known as "Duplicate Count Prevention".   You'll find more info here by searching on that phrase.

-Kevin P

[wbilll]

Hi Kevin, 

Thanks again for your detail explanation. I think I would temporarily go for digital filter. Two more questions about using counter pulse ouuput triggered by photon signal as "digital filter":

1. How is the delay between the arrival of photon signal and the rising edge of generated pulse? Is the delay consistent from pulse to pulse?

2. If I want to synchronize two APDs, should I also arm start trigger the accompanied two counter output pulse channel?(something like below, shown one APD only) 

[Kevin_Price]

1. There are some boards and counter types where the delay from the 1st trigger will be different than subsequent triggers.  Some also support a deeply nested property that make such behavior configurable.  I don't recall exactly which boards are which way, I just figure that if/when the time comes to need to deal with it, I'll experiment to see what happens.

   Many times, one can wire the same value to "low time" and "initial delay" as a workaround to get the same delay behavior for all triggers. I note that you're requesting 80 nanosec on your 6602.  You should note that you'll actually get integer multiples of 12.5 nanosec as the board uses its max timebase of 80 MHz.   Maybe you should request 75 nanosec for initial delay, low time, and high time?

2. No need to precisely sync up the output counters whose job is to filter the incoming APD pulses.  Just make sure they're started and running before the counter input measurement tasks.

   You probably *will* want to arm start trigger both input tasks off a common signal.

-Kevin P