USB-6211 for single photon counting

[MiddleAge]

Hello,

I am planning to use the USB-6211 to sweep an analog output across a 2D raster pattern based on this example by John_P1 for single photon counting. I am wondering whether the USB-6211 could replace this high resolution timing module that is provided also with LabVIEW drivers. The tech specs of the USB-6211 and the TDC seems to overlap and it would be good to use the inputs of the DAQ for the clock (approx. 20MHz) and the signal from the detector with a laser pulse width around 10ns. In addition to this, as I understand, the analog output from the detector would need to be converted to a TTL one. Any suggestion?

Am I being too naive and/or missing something?

Thanks

[Kevin_Price]

Can't give you a definitive answer, here are some things to consider:

1. I'd be reluctant to rely on a USB device due to various problems of latency, throughput, and other occasional quirks (PC power-saving modes that turn off USB ports, etc.).   A desktop PC and a PCIe card would be better.  Following the example thread you linked, it seems the PCIe-6353 might be a good choice.

2. Cannot comment on the TDC you linked for any kind of comparison.

3. If the 20 MHz you mention is intended to be your sample clock rate, that's even more reason to look to a PCIe card.  That'll make for quite a high data rate, and I'm doubtful a USB board would sustain it.

4.  NI's DAQ board counters will need a TTL pulse from the detector and it'll probably need to be wider than 10 ns.  Spec sheet for various boards will tell you the min pulse width.

-Kevin P

[MiddleAge]

Thank you Kevin P, I am very glad that I asked.

1) I agree with you that a PCIe card would definitely provide a better stability, however I'd still prefer an USB module for its portability as for the TDC above.

2) & 3) Looking at this image from the TDC's manual, I guess that some NI USB DAQ module has the same capabilities in terms of speed and operations. It would be great to use a single box to automatise the control of the mirrors and the data processing with LabVIEW instead of two different USB units.

4) I didn't see a number directly stating the minimum pulse for the PCIe-6353, whereas for a different board, such as the 6602, it is given (6.25 ns). Yes, the output from the detector is an analog voltage, and I would appreciate any suggestions on the best way to convert it to either a LVTTL or 5 V TTL.

Best regards

[Kevin_Price]

Sorry, I have no real experience in the domain of converting short analog pulses into digital.  Hopefully someone else can add some pointers here.

The TDC device appears to be purpose built for photon timing & binning measurements.  Some capabilities might not be so easy to replicate.  On the other hand, syncing 2 different devices can be troublesome as well.

What do you need from a signal and timing perspective?  I gather that you want correlation between the AO raster sweep and the photon measurements.  What do you intend as an AO sample rate?  Will you use the same clock to sample your photon counts?  How long will a given test run last?   Does the AO signal pattern repeat or does it change on the fly?

-Kevin P

[MiddleAge]

No problem, thank you very much for your assistance in this matter. 

About timing: the only correlation between the AO to control the mirrors and the input from the detector is that the former has to be done after the latter, i.e. move one mirror for each pixel to obtain a 2D raster pattern and acquire the result from each pixel that would be plot in real time on the front panel. I think that the workflow is quite similar to the example from John_P1 linked my first post. Thus, the AO would be updated every 100ms which corresponds approximately to the per-pixel dwell time for the detector. Of course, the total test would run for the total number of pixel times the acquisition time. For example, 60 pixels x 60 pixels x 0.1 sec/pixel = 6 minutes.

It is probably worth noting that usually the count rate at the detector is maximum 5% of the laser excitation rate, so that the assumption of single photon statistics remains valid. In other words, the clock used for the detector stage (in the MHz regime) is not related to the clock of the mirrors, which will be rotated every 100 ms (10 Hz) perhaps, even if this is just an educated guess at the moment.

[Kevin_Price]

Ok, so the AO sample clock rate will be roughly 10 Hz and the same clock will be used to drive period measurement on a counter.  If I follow you now, the earlier mentions of 20 MHz and laser excitation are not things you're controlling or explicitly syncing to your DAQ tasks.

Based on the linked example, the detector pulses (after they've been converted to TTL with sufficient pulse width) will act as the timebase for the task.  So the counter task will end up directly measuring counts of detector pulses per pixel.  The config is a little inside-out from normal thinking in that the variable signal you're characterizing is used as a timebase while the constant-rate AO sample clock signal is treated as the thing whose period you're measuring.  This is one of the ways that counters offer some interesting flexibility for timing measurements, once you learn to wrap your head around what happens when the two signals swap roles.

One other thing you may end up needing is to set a DAQmx property called "Duplicate Count Prevention".  It's meant for situations where you might get consecutive "sample clock" signals with no "timebase" signals in between.

With your low effective sampling rate of ~10 Hz, the USB device should be fine.  The MHz-realm detector pulses merely make the count register increment in hardware, it's the slower sample clock that relates to the speed of moving data over USB to system memory.

-Kevin P