Counter freezes on PCI-6602 when using photon detector as the gate signal

[Reflex]

Hello,

I am currently using an NI PCI-6602 counter/timer board to measure the arrival times of photons detected by a Perkin Elmer SPCM-AQR series detector.  To do this, I have set up a buffered operation in a 3rd party software program (IGOR) that counts the number of ticks on the 80mhz clock while using the signal from a photon detector as the gate pulse and then plots the counter ticks vs the photon pulses in a graph. 

If I allow enough light into the detector the counter freezes and data transfer abruptly stops...no error message, it just freezes and any other background tasks I have running continue.  In general, the counter will freeze at random, but it definately doesnt like count rates greater than 100000 cps.  I have considered that perhaps my buffer is too large, but when i make it a small number of data points (even as small as 10 bytes), the operation never even starts at count rates higher than ~150000 cps.  I've also tried too methods of data aquisition: one where the data is transfered directly to a graph (or wave in IGOR vernacular) and another method where the data is transfered to a FIFO.  Both of these methods die at about the same count rate.  In addition, I have used 3 different detectors and they all give similar results, though I have noticed that the detector that outputs the smallest pulse width (12.5 ns) seems to be the most successful.  I figure that using a small buffer would be advantageous considering the large amount of data thats happening very quickly when using photon pulses as a gate signal and counting clock ticks on the 80mhz timebase. However, I have observed that it isn't a problem (the counter doesnt freeze) if I use a continuous pulse train as my gate signal (even one as fast as 20mhz) while counting a slightly offset pulse train of almost equal frequency.  In this instance, I get count rates many times higher than what I would get with the photon detector, but it still doesn't stop or even slow down.

My question is, could this be a hardware issue and if so how do I fix it?  The counters have no problem doing simple edge counting or pulse width measurements on any of the detectors, so I doubt compatability is a problem (the detectors each put out 2-5V TTL pulses depending on the model).  The only possibilities I have considered after fighting with it for a while is that either the pulsewidth of the photon detector output is too wide and that somehow confuses/overloads the counter when using a clock signal with a very small period (25ns) or that using photon arrivals as a gate signal is problematic as the arrivals are random and sudden bursts of closely packed photons would overload it.  Or perhaps there is something wrong with the board?

Any suggestions you may have will be greatly appreciated.

Thanks,

Michael G.      

[CharlesD]

Reflex,

First off, what exactly are you trying to measure by wiring your signal into the gate.  Usually this is done to measure the number of ticks of the 80MHz clock has passed while the gate signal is high.  From this you know the amount of time that the signal was high or low and can calculate the frequency of the signal.  In your case however I almost want to say that you want to counter the number of edges of the sensor signal.  To do this you should be wiring the signal into the source of the counter. 

Its pretty intereting that you are getting the best results at 12.5 ns pulse width gate signal.  In general as you can see from the image below you should have a minimum gate pulse width signal of 5ns.  12.5 ns = to the exact inverse of 80MHz and so it is possible that you got ok performance because of simply being lucky.  In general what pulse width do the sensors that crash your system use?  I doubt that the pulse width of your sensor is to wide.  In my opinion if anything the pulse width is too narrow!  You can see that with your 20MHz signal (pulse width = 500ns) we get perfect data.  On the other hand when we use a pulse width much smaller 12.5 ns we get some issues.  

When you specify that your system crashes at rates greater then 100kc/s do you mean that the signal from your photon sensor returns a pulse of "X"ns at a rate of 100kS/s or are you fetching data from your DAQ Buffer at a rate of 100kHz?  

[Reflex]

Thank you for your response!

Actually, when I said 12.5ns produced the best results, I was refering to the pulse width of the generated signal from the photon detector, not the frequency of a waveform.  That is, I have 3 photon detectors I tried, 2 perkin elmers that were mostly the same model and put out a 37.5ns pulse width signal and an ID Quantique brand that generated a 12.5 ns pulse.  I also noticed that using different lengths of BNC wire distorted/elongated the pulse shape when viewed on an oscilloscope, but that didn't seem to affect the crash result.  

Basically I'm just trying to timestamp the photon arrivals, and the only accurate way I have found to do that is to hook the photon detector up as the gate while counting edges on the 80mhz clock that occur between "start" and "stop" triggers from the detector (i.e. the gate).  I have attempted to do high frequency period measurements instead, but that either also crashes my system in the same way or it averages my results too much.  I have a feeling that the card's buffer is overloading.  

When I say it crashes, only the counter used to perform the buffered operation crashes.  Every other counter I use continues to count, which is how I know I'm getting a count rate from the detector of about 100khz.  When you say minimum gate pulse width, is it possible that 2 photons come in so closely together as to appear to the counter to be <5ns in width?

Thanks,

Michael G.

[CharlesD]

Right ok so that is what I figured for the 12.5 ns pulse signal.  It is possible that that you are getting two photons come in too quickly and getting a signal that looks like the pulse width between the pulses is less than 5ns.  However I believe that the worst thing that will happen is that samples will be missed or that the counter will continue to count the number of pulses (ticks of the master timebase) even though it missed it.  Along those same lines could it be that your signal is coming SOOO quickly that the gate is essentially seen as a HIGH or LOW and the counter is continually counting the number of ticks under the gate signal and therefore not returning any value to the buffer.

Have you tried a different Card?  Different Counter? Does it follow any piece of hardware? Could it be how you have programed it with your third party software?