Photon Counting Using Single Photon Counting Module and PCI-6602

[Myeongsu]

Hello all,

I am currently working on photon couting program using a single photon counting module (Excelitas) and PCI-6602 connected to BNC-2121.

I have taken a look other posts but I still could not solve my problem (or, still I am not so sure whether or not the problem is the hardware specification).

In the program, I am generating a trigger pulse at 1 MHz using one trigger in one separate loop.

Other than that, I have producer-consumer template based loops to acquire the data and do simple subtraction to calculate the number of photons in 1 microsecond.

Depending on the values connected to  'Input.BufSize' of DAQmx Buffer and 'Samples per channel' of DAQmx timing, I could change the looping number that the program does its job properly.

With the values, the program acquires 1 MHz photon counting signls for 139 times.

After that, the program stops and looping number increases very fast.

When I forcifully stop the program while the looping number is increasing very fast, the program pops up 'Error -200141'.

The error says 'Data was overwritten before it could be read by the system. If Data Transfer Mechanism is Interrupts, try using DMA or USB Bulk. Otherwise, divide the input signal before taking the measurement.', even though the counter explictly works in DMA mode when using sample clock.

I wonder there is any way that can solve my problem or still the only solution will be buying a better counter/timer board.

Thank you all for reading this.

I will be very happy with any clue 🙂

Regards,

Myeongsu

[Alexander_Sobolev · Accepted solution]

Yes, the same happens on my system. 

It does not happen with PCIe-6612.

Additional strange things I have found:

When I start reducing frequency, at some point (800kHz) it can fill the buffer, but can not start from the beginning of the buffer. It can go to the beginning of the buffer only at 100kHz for my PC.

Options to solve:

1) PCIe-6612. Seems to work. I tried it transmitting continuously at 10MHz, 5 min - fine.

2) Reduce pulse rate. If your laser supports 100kHz, you are fine.

3) Set up additional synchronous counter at 100kHz. Basically it is hardware average of number of photons per 10 pulses.

4) Read 2 adjacent pulses every 1/50 kHz - then your data transfer will be 100 kHz and you will get number of photons of this 20-th pulse.

Programming issues:

1) remove display of received array, do only data processing and show results if you really need it.

2) Sample clock.vi sets buffer size, if you need to specify buffer size, do it after this vi.

3) I removed unnecessary "generation loop". It is running on hardware and stops when you stop it - after read loop is done. 

[Myeongsu]

I just check this and realized that you replied to my post in June. Sorry for late.

I have had similar issues as you described too when I tried different approaches.

It seems like the only solution to achieve higher frequency will be having a better hardware.

Thank you for your answer and program modification!

Myeongsu

[Kevin_Price · Accepted solution]

Just  a quick followup to Alexander's good advice.  The likely *reason* that the 6612 handles the task so much better is the much much bigger on-board FIFO for its counters.  The 6602 has only a 2-sample FIFO, making it much more prone to get these overwrite errors.

-Kevin P

[Myeongsu]

Thanks Kevin!

Then surely I need to purchase PCIe6612.

[Ionlab20]

Hi There, 

I have a follow up question on your "options to solve" .  I am counting photons on the 6602 as well and have implemented a number of looping options at this point.  Although a few threads have said that setting up a period measurement with 100kHz gate should be doable, I am still missing data in the end. The time it takes to acquire 100kSamples for example is 1.7 seconds instead of 1 second.  Although I am considering buying the 6612 card, I wanted to first ask about your suggestion #3 (setting up an additional synchronous 100kHz counter).  Could you elaborate a bit more on how this would work?  I mainly wanted to see if the average of 10 pulses that you mentioned was assuming a 10 microsecond period (100kHz sampling using the gate) and therefore 10 pulse average =100 microseconds.  (100 microseconds=1 average).  Or this original post was about 1 MHz sampling in which case 10 pulse average = 10 microseconds (10 microseconds=1 average).  

Thanks!

[Kevin_Price]

Can you post your code in version LV 2016 or earlier?   Also, describe exactly what you want to measure in a little more detail?   I don't want to give advice/answers based on wrong assumptions.

The general principle going on here is that photon pulses might possibly come too fast for the board/driver to handle in "normal" period measurement mode (where each photo pulse yields 1 period measurement based on a fast internal timebase such as the 6602's 80 MHz clock).   So the suggestion #3 workaround from Alexander is to use the photo pulses themselves as the timebase signal while measuring "periods" of a fixed frequency signal that the board/driver can handle, such as 100 kHz.   For that particular example, the # of pulses per interval gives an average photon rate over that interval.   Note that you may need to consider the "duplicate count prevention" property to make sure you properly measure intervals with 0 photon pulses.

-Kevin P