ni.com is currently experiencing unexpected issues.
Some services may be unavailable at this time.
03-04-2013
03:58 AM
- last edited on
03-25-2025
12:15 PM
by
Content Cleaner
In a nutshell: How can I measure a TTL signal reliably also when the frequency is low or even 0 using Labview?
I have a PCIe-6259 DAQ card with two counters. I am trying to measure a TTL signal from an amplified photo multiplier tube output with a specified integration time, where each count indicates a photon.
The range of this TTL signal is from 0 (when off) to ~300Hz (dark current) to 1 MHz (approximate saturation limit), where a typical signal is in the range of 0.01–1MHz. The integration time is in the range of 5–50ms.
To solve this problem I tried the to measure the signal using a CI Frequency task (from DAQmx Read.vi) using two counters to measure the high frequency signal reliably, because the timebase available on my card is 20 MHz. This works fine for the normal signal frequencies mentioned above. The relevant part of my VI is shown here (unfortunately not all VIs display correctly because of some library issues).
The problem I have is that low frequencies are not measured properly. What I want is that the task returns 0 for signals that are too slow to detect, but instead the Labview code stops and gives a warning/error something like 'The signal is too slow for the specified integration time'. This stops the VI execution and I have to restart the task, which is undesirable.
Also, when there are no counts at all, the task does not register anything, and instead times out. Also in this case I want it to return 0 as there are no counts, and therefore the frequency is 0.
I want to use Labview in these cases as well for alignment: it's a bit annoying to align the system if the VI stops when the signal is too low.
How can I measure my TTL signal reliably also when the frequency is low or even 0 using Labview?
I looked at "Counting TTL pulses within specified integration time ", but I'd rather not use an external signal generator as clock and do everything onboard.
Thanks!
03-04-2013 07:45 AM
You should use counting pulses with a specific integration time. The integration time can be generated from one counter and the second counter can be used to count the pulses. I have done this with NI counters to create a photon counter using a PMT. So counter 1 generates an integration clock and counter 2 countes between integration counting edges. Inside the loop you can read the integration signal and process it.
you can even create retriggerable integration clocks if you want to synchronize experiments with external events such as a laser pulse.
03-05-2013 08:08 AM
Hello Tim,
Have you tried Paul's advice to create an on-board integration clock?
03-14-2013
07:25 AM
- last edited on
03-25-2025
12:15 PM
by
Content Cleaner
Thanks for your suggestion! I implemented edge counting which works as expected:
However, one problem I have now is that the counter is cumulative and I subtract each previous value from the current value to get the counts in one bin. Is there a way for the counter to return only the count in the current bin?
I've looked in the Labview examples under 'counter' and 'reset', but the examples only show how to reset the counter at a fixed value, which is not what I want. I've also seen https://forums.ni.com/t5/LabVIEW/Reset-clock-count-encoder-counts/td-p/137494 and https://forums.ni.com/t5/Example-Code/Count-Digital-Events-with-Option-to-Reset-Counter-Using-DAQmx/... but that is not what I'm looking for.
Thanks again in advance!
03-15-2013 05:10 AM
Hello Tim,
It's a bit unclear for me what you're looking for:
Can you elaborate a bit more on this sentence?
"However, one problem I have now is that the counter is cumulative and I subtract each previous value from the current value to get the counts in one bin. Is there a way for the counter to return only the count in the current bin?"
Can you define what your definition of bin is and how I should link it to the visible diagram?
The problem is that I don't see any subtraction in you BD, so I don't see where the problem is that you want to solve.
03-15-2013 05:58 AM
I have a pulsed signal coming in from a PMT. I want to measure the amount of pulses during a certain time interval, the 'dwell time', which is the bin I mentioned. I use one counter (ctr1) to generate a square wave at the frequency 1/dwell time, and count pulses between rising edges of this counter using a second counter (ctr0).
The issue I have is that when I read the samples from ctr1, I get the cumulative number of counts for each bin, and not the number of counts in each bin. Instead of [6, 5, 4, 7, 4, 5, 4, 4] I get [6, 11, 15, 22, 26, 31, 35, 39].
I added code to the VI to calculate the counts per bin instead of cumulative sum (not shown in this VI), but I would like to do it in the hardware itself if possible. Is it possible to reset the counter after each bin?
03-15-2013 10:41 AM
Make sure your CI.countEdge.CountReset.Enable = True on the property node, this should reset the PMT count on eachbin edge.
03-18-2013 09:44 AM
Thanks for your suggestion, Paul.
I tried to use CI.countEdge.CountReset.Enable = True, however this property seems to be incompatible with the Sample Clock timing I'm using. I need the Sample Clock to count edges with a specific frequency and with a finite number of bins.
When I run another counter at a certain sampling interval, I can use that one to reset the counter with a certain frequency (i.e. with CI.countEdge.CountReset.Term), but I cannot use it simultaneously to set the sampling interval of the first counter.
The best solution I have now is to take the cumulative data and manually take the difference, which works but is a bit cumbersome. Is there a way to reset the counter automatically, while taking a finite number of measurements with a specific integration time?
03-18-2013 01:58 PM
I made a very similar application and was able to do this (it has been many years since I did it so my memory might be off).
This is what I did.
1. Counter 0 was a retrigerrable finite pules train set for the number of bins I wanted and had a period of the bin duration, configurable from software
2. Counter 1 was a simple count PMT pulses (the source of the count) which would buffer a coun t on the rising edge of the clock. The clock was of course the output of counter 0.
So when a trigger was inputted on counter 0 trigger line, I would get buffered N bins of some specified durration each bin contained the number of photons for the duration.
One issue is on older cards I think the finite pulse train actually used 2 counters (dont think this is the case anymore)
03-18-2013 03:21 PM
@falkpl wrote:
This is what I did.
1. Counter 0 was a retrigerrable finite pules train set for the number of bins I wanted and had a period of the bin duration, configurable from software
2. Counter 1 was a simple count PMT pulses (the source of the count) which would buffer a coun t on the rising edge of the clock. The clock was of course the output of counter 0.
Thanks, I think this is what I also have, see my screenshot above from 03-14-2013 07:25 AM. The issue I have now is that the bin count on counter 1 is cumulative, while I would like the number of counts per individual bin instead. Do you remember if you had a similar issue in the case you mentioned above?