Showing results for 
Search instead for 
Did you mean: 

Measuring Time Between Pulses

Problem: Measurement of time between photon arrivals.

Hardware/Software: Hamamatsu PMT, NI 6612 Counter/Timer, LabView 2015


I am attempting to measure the time elapsed between subsequent photon arrivals to my Hamamatsu PMT. Previously, I have connected the PMT to the NI 6612 counter/timer, and written a program to count the number of photons incident on the PMT, and then back-calculate to find the photon arrival times. That program had a few issues with sampling time / frequency, so that I was unable to acquire data about photon arrival times. I was advised to measure the time between the pulses, so that there would be less data to acquire. I am looking for a way to acquire a data array of time durations between incident photons.


So far I have three ideas on how to do this: 

- Use a rising edge on the first counter(signifying the arrival of a photon) to trigger another counter to start counting ticks. The next rising edge would reset the counter to 0, and it would begin counting ticks again. I was unable to figure out how to use the first counter as a trigger, and therefore input the number of ticks from the second counter into an array.

- Use pulse-width or semi-period measurements. As I understand it, pulse width only measures the time that the signal is high, and I would be unable to measure the total time until the next rising edge. Additionally, my pulses would not be coming with regular frequency, so I do not know if a period measurement would be appropriate.

- Write a variation on the "two-signal edge separation task". This task looks perfect for what I wish to do, except that my signal is coming in on only one line.


I am very new at LabVIEW, and have spent a lot of time reading through the forums, but must admit that I didn't understand many of the problems/solutions that were similar in nature to mine. I hope that my question is clear. Thanks for any help in advance.

0 Kudos
Message 1 of 4

There's a more direct way than any of the ideas you've tried or proposed.  Start by configuring the counter to measure *periods* between consecutive photon pulses.  Once you have the individual periods, you can easily make a timestamp by performing a cumulative sum.


Below is a LV 2013 snippet to illustrate how to get started.  I set the default value of the signal whose period to measure to be an internal 100 kHz clock.  That way it's always present, it's steady, and you can confirm basic functionality.



-Kevin P


P.S.  Came back to attach the snippet image and vi in case snippet functionality is still broken here on the forum


PMT periods and timestamps.png

Download All
0 Kudos
Message 2 of 4

Hi Kevin,


Thanks very much for your help! I was able to get the VI working for test signals with frequencies higher than 100Hz (which is close to the dark count I'm working with), but when I test signals with low frequencies around 10Hz, I do not get as many samples as I request.


I think this is because Implicit Timing uses the 100MHz timebase on my counter by default, and when the signal frequency is low, there are too many timebase pulses per period of my signal. 


Is there a way to make sure my program stops running after a certain elapsed time even if not all the samples I've requested have been collected? At the moment, when I test low frequency signals, the VI stops after an error pops up (I'll attach a screenshot where the test signal was at 10Hz).





0 Kudos
Message 3 of 4

That's normally a straightforward error to avoid.   The best way to avoid it depends quite a bit on the actual needs of your app.   Here's what's going on:


In period measurement mode, the signal being measured ends up setting the effective sample rate.  If it's a low frequency, it'll take a longer time to accumulate a particular number of samples.


The default value for timing out on a DAQmx Read is 10 seconds.  That only gives you time to accumulate about 100 samples at 10 Hz.  If you're asking for 1000 samples within 10 seconds, you'll get the error you see.


You could solve this by wiring a really long timeout, but I'd rather put the DAQmx Read in a loop and read samples a little at a time.  Then the loop can check for errors or user-requested stops and the app can be responsive.



-Kevin P

0 Kudos
Message 4 of 4