Assistance with Photon Counting Program in LabVIEW with External Trigger

[Sagiv]

Hello LabVIEW experts,

I need assistance in building a LabVIEW program to perform photon counting with a defined time window and a specific number of samples (intervals). Additionally, the program should wait for an external pulse to initiate the counting process (trigger).

Setup Details:

• Photon Detector: EG&G SPCM-AQR-13-FC (outputs 30 ns TTL pulses, stretched to 160 ns using a multivibrator SN74LS123N).
• Counter: National Instruments PCI-6779.
• Terminal Block: NI BNC-2110 (connects the photon detector to the counter).
• Pulse Generator: PulseBlaster ESR Pro 500 (SpinCore), used to generate the trigger pulse.
• Software: Windows 7, LabVIEW 2015, and the DAQmx library.

I understand that the DAQmx library is essential for configuring the program, but I am unsure how to implement it for this application. The program needs to:

1. Count photons within a defined time window.
2. Repeat the count for a specified number of intervals (samples).
3. Use an external trigger pulse from the PulseBlaster to initiate each counting sequence.

Could someone guide me on how to build this program or provide an example? Any advice on configuring the DAQmx tasks and ensuring synchronization with the external trigger would be greatly appreciated.

Thank you in advance for your help!

[Kevin_Price]

What have you tried?  Have you done any work with counters before?

What you want to do can almost certainly be done well, but the timing requirements need to be defined more precisely.

• How will your "time window" be defined?  Is it the same from trial to trial or will it / can it vary?  Is it under the control of your app or must you react to an external signal?
• Is it sufficient to stop and restart a task between these time windows, even if it causes you to miss an opportunity?   Or must you be continually ready to do more counting when the next time windows starts?
• Do you need hardware-level (sub microsecond) reaction time to the external trigger?  Or would software-level (multi millisecond) reaction time be ok?

Meanwhile, be sure to spend some time with your device manual, DAQmx help, and shipping examples to start getting more familiar with counting tasks.

-Kevin P

[Sagiv]

Hi Kevin,

Thank you for your quick response and for your patience as I worked on understanding my setup. I’ve done some homework and have a VI (CounterReading.vi) that successfully reads photon counts, but it currently lacks a trigger for precise timing.

Let me briefly explain my experiment and then address your questions:

I’m conducting an optics experiment where I use laser and microwave pulses on a diamond sample, then measure the resulting photon emission. The laser pulses are created by sending electrical pulses from the PulseBlaster device to act as a switch for the laser.

The goal is to produce laser pulses lasting between 300 ns to 1 μs while simultaneously counting photons emitted during this illumination period.

1. "What have you tried? Have you done any work with counters before?"

• I haven’t worked with counters before this project.
• In the current VI, I can set the number of samples and the sampling time (time window), and the system reliably reads photon counts.
• From what I understand of the VI:
  • There are two tasks:
    • CI Task (Counter Input): Counts incoming pulses from the photon detector.
    • CO Task (Counter Output): Generates a clock to provide sampling intervals for the system.

2. "How will your 'time window' be defined? Is it the same from trial to trial, or will it vary? Is it under the control of your app, or must you react to an external signal?"

• I need to take a single measurement triggered by an external pulse.
• The time window will be between 300 ns and 1 μs for a single count.
• While I currently envision using just one time window in my experiment, I would like the flexibility to create multiple time windows without needing to stop and restart the task between them.
  
  

  3. "Is it sufficient to stop and restart a task between these time windows, even if it causes you to miss an opportunity? Or must you be continually ready to do more counting when the next time windows start?"
  
  

  • I prefer not to stop and restart the task between time windows, even though I currently plan to use only a single time window in my experiment.
  • This ensures flexibility for future scenarios where multiple time windows might be needed.

4. "Do you need hardware-level (sub-microsecond) reaction time to the external trigger? Or would software-level (multi-millisecond) reaction time be OK?"

• Hardware-level reaction time is crucial.
• During the laser pulse (300 ns to 1 μs), the diamond emits photons, and counting must align with this pulse. Ideally, the counter should respond on the order of tens of nanoseconds.
• I’m open to suggestions or tricks, such as opening the counter earlier and post-processing the data to align it with the pulse timing.

I’d like to add a trigger to my existing code. My understanding is that I can connect the PulseBlaster output to the PFI 0/TRIG BNC connector on the terminal block to serve as the trigger source.

For now, the VI reliably reads counts for 1 sample during a 100 ns time window without errors. My goal is to ensure the VI starts counting only when the external trigger is received.

I also want to clarify that the counter being used is the PCI-6713, not PCI-6779 as I initially mentioned.

Thank you again for your help, and I’d appreciate any advice or examples on adding the trigger functionality to my current setup.

[Kevin_Price]

Do you have any other DAQ device you could use for the counters?   The 6713 is a very old design and its counters are much more limited than newer ones.  It's been probably 20 or more years since I did any serious work with the DAQ-STC counters that I'm pretty sure the 6713 has.  My memory's fuzzy on some of the exact limitations, but they are pretty considerable.

The DAQ-STC3 counters would be a much better alternative.  They're found in X-series devices and many cDAQ chassis introduced within the past decade or so.   I haven't used the even newer 64xx series, but they appear to have similar calibre of counters on board (perhaps STC3, maybe an even newer STC4?)

Let me know if you're stuck with only the 6713, and then I'll try to conjure up some ideas.   At a glance, I think there will be at least some kind of solution available with the 6713, but it might come with some caveats and compromises.

-Kevin P

[Kevin_Price]

Here's something to get started with.  I modified a shipping example a little bit and tried it on a *simulated* 6713 device.  There's no triggering yet b/c your device doesn't seem to support it, at least not directly, for counter input tasks.

What I did is a *little* bit tricky, kinda like faking the counter out.  I've set the task up for continuous pulse width measurements, which is gonna sound wrong, but we make it right with some sneaky tricks.

*Normally*, the way pulse width gets measured is that you identify a pulse signal to measure (the pulse width source terminal) and then the counter will count edges of an internal timebase clock with a known frequency to figure out timing.

Here we're taking advantage of the flexibility offered by counters to:

- choose the units "Ticks" for our measurement.  This is a kinda odd term NI chose to use, basically it's just going to mean raw integer counts

- tell the task that the APD pulses are acting as our timebase clock

- configure the task to measure laser pulse width (while using the APD pulses as a "clock" to count)

So what happens?  Every time there's a laser pulse, the task will count timebase edges seen while the laser pulse is high.  But we configured the task to treat the APD pulses as the timebase.  And then because we read the result in raw counts, each sample is the # of APD pulses seen during a given laser pulse.

Give it a try, tinker a little, and ask further questions as needed.

-Kevin P