Help with Single photon counter (SPCM AQR 15) for fluorescence detection and trigger a solenoid valve by labview

[MatthewTang]

Hi all,

Recently I am building a fast fluorescence detection setup with a single photon counter (SPCM AQR 15) and I would like to use the fluoresence signal to trigger a solenoid valve using Labview 2012. I would like to ask:

(1) Do I need a DAQ Card (or even more?) for my hardware communication?

(2) How to monitor the signal real time (if possible?) in labview?

(3) Is there any VIs compatible with the photon counter?

Thank you so much and really appreciate for your comments!

Matthew

[Prickly_Pear]

I did a search for this device and I found this page: http://www.optics.rochester.edu/workgroups/lukishova/QuantumOpticsLab/homepage/apd_spcm_aqr.PDF

Is this what you are working with?

If so it says that it outputs an electrical pulse each time a photon is detected. This pulse could go into one of our DAQ devices, specifically a digital input device. These devices can detect the pulse and keep track of the total number of pulses using a built-in hardware counter. LabVIEW can display the current value of the counter on the user interface.

You can look for some example VIs in LabVIEW that demonstrate this principle. Open the NI Example Finder and search for "Counter - Count Edges.vi" . Note, you will only be able to use this VI if you have a DAQ device that supports counters. You will also need to install the DAQmx driver.

You say that you want to be able to trigger a solenoid when you detect a photon. How quickly do you need to react to the pulse in order to activate the solenoid? If you need to do this within 1-10 ms, then PC application written in LabVIEW would be able to detect the pulse and activate the solenoid. If you need to be able to react to the pulse within 10-50 microseconds, you would need a real-time controller such as a Compact RIO device to control the trigger. You might also be able to get a fast reaction time if you use a hardware trigger on a conventional DAQ device. The fastest reaction times are possible with an FPGA device. This will allow you to output a signal to the solenoid within nanoseconds of the photon being detected. This might be excessive for your project.

Jeremy P.

[MatthewTang]

Hi Jeremy,

Thanks for your reply! That's exactly what I have!

Currently I have a PCI-6251 DAQ Card, do you think this is enough to sample the photon counter? My fluorescent beads would not flow in ns scale, maybe in micron to milli-second scale!

Best,

Matthew

[Prickly_Pear]

I looked on the specs page for the 6251 DAQ card. It is able to acquire at a rate of 1.25 MS/s (million samples per second). That means that each acquisition window is about 667 nanoseconds long. The product page for the detector said that each pulse is 30 nanoseconds wide (also, each pulse is 2.5 V high). Because the pulse is much smaller than the acquisition window, you will not be able to detect the pulses with the 6251. You will need to acquire voltage samples at a rate of about 34 MS/s.

I believe that the NI PCI-6537B is the least expensive device that would acquire the data fast enough for your application. It can sample at a rate of 50MS/s. It also uses the DAQmx driver like we had talked about before. You can also configure this device to use a 2.5 V logic level.

Jeremy P.

[John_P1]

---

@Prickly_Pear wrote:

I looked on the specs page for the 6251 DAQ card. It is able to acquire at a rate of 1.25 MS/s (million samples per second). That means that each acquisition window is about 667 nanoseconds long. The product page for the detector said that each pulse is 30 nanoseconds wide (also, each pulse is 2.5 V high). Because the pulse is much smaller than the acquisition window, you will not be able to detect the pulses with the 6251. You will need to acquire voltage samples at a rate of about 34 MS/s.

I believe that the NI PCI-6537B is the least expensive device that would acquire the data fast enough for your application. It can sample at a rate of 50MS/s. It also uses the DAQmx driver like we had talked about before. You can also configure this device to use a 2.5 V logic level.

Jeremy P.

---

What?

The 6251 has an analog acquisition rate of 1.25 MHz.  The 6537B doesn't have any analog inputs.  This isn't a good comparison at all.

The counters on the 6251 should be capable of detecting a 30 ns TTL pulse (2.5 V from the spec is assuming the recommended 50 Ohm input impedance, but the inputs on the 6251 are high impedance).  If the goal is to timestamp the photons (it seems to be a common request around here) then the 6251 would give even better resolution than the 6537B since it uses an 80 MHz timebase.

Best Regards,

[Prickly_Pear]

Hi John,

Thanks for catching my mistake.

 The counters should be able to periods that are at least 1/frequency of time base. The 6251 has a 80 MHz clock, so you can detect periods that are at least 12.5 nanoseconds long. I believe that a period would be twice the length of the pulse (since a period has a high time and a low time) which means that you would be able to detect pulses that are 6.25 ns. The M series manual confirms this on page B-40 https://www.ni.com/docs/en-US/bundle/pci-pcie-pxi-pxie-usb-62xx-features/resource/371022l.pdf.

I apologize that I was wrong.

Jeremy P.

[MatthewTang]

Dear all,

Thanks for all your advice! I tried running a quick test on a USB 6251 which I could only have now. The signal I got with a oscilloscope is around 18Hz (Please see the photo). 

When I collect the data using the DAQ, I used "DAQ assistant" in labview, I tried a sample rate of 1.25M, with continous sample of 1.25M. However, excel couldn't digest more than 1M data. 

So I tried 100k sample rate and samples instead. I got the data (Please see the excel)

Here is my concern:

(1) Is there any way that I could continue to do data loggin with excel?

(2) The data I got with the DAQ is so different from the signal I got from a oscilloscope, is it becase it undergones a ADC? 

(3) from the excel file, do you think this USB 6251 is enough for logging the signal?

Thank you so much!

Best,

Matthew

[Prickly_Pear]

You are going to want to create a Counter Input task, not an Analog Input. I am sorry that I was confusing you about this before. I suggest that you start with using the example VIs that install with LabVIEW. In LabVIEW, click Help>>Find Examples. A new window called the NI Example Finder will open up. Navigate to Hardware Input and Output>>DAQmx>>Counter Input. There are several examples there.

Are you planning on collecting this data over a specific amount of time? If so, I suggest you look at the Count Edges (Finite Clock) example. Do you want the VI to continue to collect data until the user click on a stop button? If so, I suggest that you look at the Count Edges (Continuous Clock).

Let me give you a brief description of what is going on when you use this example.

The 6251 card has two special pieces of hardware called counters. These counters are designed to count the number of pulse edges and store the total count in its internal register. Because all this is done on a hardware level using very small microelectronics, the counter is capable of counting pulses at a very fast rate. The actual count is stored in the internal register of the counter, so DAQ board actually needs to poll this counter so that it can transfer the information to the computer. Each one of these pieces of data is called a sample. The sample rate is the frequency at which the DAQ board polls the counter to find out the current count. The counter is always keeping a running total of the count, but you need to decide how often you need to find out and record that count.

Once the samples are transfered to the PC they are stored in a temporary buffer location in memory. At this point, the samples haven't entered the LabVIEW enviroment. The DAQmx Read VI is where the samples are actually pulled out of the buffer and can be used in LabVIEW.

The problem that could potentially happen is if the buffer fills up with samples faster than you can remove them with the DAQmx Read VI. If the buffer gets completely filled with data then it is called a buffer overflow error and the DAQ task will be forced to stop.

When you specify that you want to take a finite number of samples, the LabVIEW creates the memory buffer equal to that number of samples in order to avoid a buffer overflow error. In your case, when you specify that you want to take a finite number of samples and that number is 1.25 million, then the PC will attempt to reserve enough memory in the buffer to accomodate 1.25 million samples. That is going to take up a lot of memory on your PC and it is possible that you will not have enough RAM or that your operating system will not allow you to use that much memory.

When you specify continuous sampling, then LabVIEW will create a moderately large memory buffer. Once the task starts, the 6251 will create samples and start putting them into the buffer until you stop the task. You will need to make sure to call the DAQmx Read VI fairly often so that the buffer won't overflow. However, in this configuration, you could conceivably acquire as much data as you possibly want before stopping. In this configuration, the 6251 could count the edges, poll the counter register, put the samples in the buffer, read them into LabVIEW, and then save them to the hard drive--all in a continuous manner. The only limitation would be the speed at which LabVIEW can read the buffer and the hard drive write speed.

So, you have a few options. You will need to decide how often you need to sample and if you want to use the finite or continuous options.

Jeremy P.

[MatthewTang]

Sorry I think I didn't make my problem clear...

For my application, I have fluorescent beads passing through a laser slit which excites a fluorescent emission and my single photon counter to received the signal. What I expect is that when the fluorescent signal is collected by my counter, the voltage signal increases.

From the oscilloscope, the signal is continous like a sine wave when fluorescent beads excited by the laser slit. However, the signal I got in Labview through the DAQ Card becomes spike. That's not what I expect.

The signal I would like to get is more like a square wave: While the voltage from the signal is above a threshold during the "on" of the square wave, this will trigger a boolean to "True" and activate my valve. However, since the signal is now composed of spikes, which means the boolean is "On and Off" for many times during the "True" case. 

Do you think that's because of the hardward limitation? 

[John_P1]

---

@MatthewTang wrote:

What I expect is that when the fluorescent signal is collected by my counter, the voltage signal increases.

From the oscilloscope, the signal is continous like a sine wave when fluorescent beads excited by the laser slit. However, the signal I got in Labview through the DAQ Card becomes spike. That's not what I expect.

---

That doesn't make any sense given the datasheet linked earlier for the photon counter.  The photon counter shoud issue discrete 30 ns pulses for each photon.  You can measure the rate of these pulses using the counter on the 6251.

Best Regards,