Counting photomultplier TTLs per ms using the 6602

[Max 90]

Hello all,

I have a question that seems related to Paul's (falkpl) (Or that he may know the answer to 😃
http://forums.ni.com/ni/board/message?board.id=40&message.id=1883

I am trying to use the 6602 to make a histogram of continuous events in bins of 1ms.
As the subject of the post indicates, the events are TTL pulses from a photomultiplier tube. (variable frequency)
A key requirement would be to not miss any TTLs in between counts.

I've seen the timer examples and have picked up a lot from reading related posts like Pauls.
I am wondering if anyone knows the most accurate/precise way to implement this counting "setup"?

- Do I need an external gate to set the counter or is there a way I can use the 6602 to set 1ms counting bins?
- How do I ensure that the 1ms counting bins are as contigous as possible?
- I will probably need to change the timebase of counting so that it is not to fast (i.e. not counting noise) but is fast enough to satisfy the Nyquist criteria for these pulses. I am assuming this is easy.

I'm not sure if I need to use an internal or external gate to specify the beginnings and ends of the 1ms bins I'm counting with. I can also envision that I might instruct a counter to count for 1ms repeatedly, taking time only to read the counter value before starting again? I also realize that this is a frequency analysis of sorts, but I want to make sure I don't miss any pulses in between counts.

Somehow, I get the feeling this is a trivial question, as I would expect that this type of "frequency analysis" is used quite frequently.

Any ideas?

Thanks in advance,
Max

[Sean_C.]

Hello Max,

I am not sure that I understand what you mean by "bins of 1 ms." Do you mean that you want to count how many events have occurred every millisecond? If so, you might want to do a continuous buffered event counting. This would help ensure that you don't miss counts (like you would if you had to stop the counter task and restart it for every count read). You could even use one counter to set an internal gate pulse train with a period of 1 ms. Then it would be a simple matter of subtracting previous count element from the current element to determine how many events had occurred in that millisecond.

Does this answer you question? If I have misunderstood you, or you have any further questions, please let me know.

Sincerely,
Sean C.

[Max 90]

Sean,

Yes, I do want to count how many events have occurred each millisecond and yes, you have answered my question.
I'm going to try using the continuous buffered event counting approach that you recommend. I like the idea of using one of my counters to set an internal gate pulse train with a period of 1 ms too. Will give it a try and let you know if I have any questions, or am successful.

Thanks a lot,
Max

[Kevin_Price]

Max 90,

Sean's suggestion about buffered edge counting should work well and will be particularly handy if you want to know "at a glance" the cumulative total # of TTL pulses that have come in. You can find the pulses per 1 msec bin by doing a simple finite difference. Everything will be hw-timed, and you won't miss any pulses between bins.

Another possibility is to do buffered period measurement with the DAQmx units set to "Ticks." This would directly store the # of pulses during each 1 msec bin time.

Either way, you'll probably need to set the "Duplicate Count Prevention" property (buried down deep in the DAQmx Channel property node). I think the right setting is "True", but you can always try both True and False to see which works properly. One setting will actually store 0 values during 1 msec bins with no incoming TTL pulses, the other setting will simply ignore such intervals and only store a value during the intervals where there are 1+ pulses.

Finally a comment about your mention of "Nyquist criteria" in your original post. For most counter tasks, you wouldn't generally consider Nyquist criteria the way you would in an analog task. Consider your app: your 1 msec bins are the same as sampling at 1 kHz. However, it's apparent that you expect several TTL pulses to occur within some of those 1 msec bin times. So your signal can come in as fast as (perhaps) 5 kHz or more. If you automatically think of Nyquist, you might too quickly decide to sample at >10 kHz, which is both unnecessary and actually unhelpful for your app.

-Kevin P.

[SteveP]

Does buffered edge counting sufer from the same issue as buffered period measurement in that the first value in the buffer is incorrect due to counting beginning at an indeterminite position in the gate window ? See Document ID: 2HA8SCN5
http://digital.ni.com/public.nsf/allkb/8579D7E5CD494D9F86256B3E005798C2

I assume the above reference is for traditional NIDAQ. Does the same issue exist with DAQmx ?

[Kevin_Price]

SteveP,

As far as I know, the behavior is the same under both DAQmx and traditional NI-DAQ. And yes, the first value of a buffered edge counting task would be similarly inaccurate for this type of app.

Most of the time I prefer to use period measurement, especially if there's a chance that edge counting would lead to counter rollover. In such cases, I can easily re-create the values I would have obtained with edge counting by doing a cumulative sum, after converting the integer count to a floating point value that won't roll over.

-Kevin P.

[SteveP]

Kevin,

For my app, counter overflow will not be an issue. But I do need to have counts per bin rather than a cumulative sum, so the period approach would avoid the subtraction step. But does period measurement give the total number of pulses that occur within each time bin or does it give the times (period) between successive pulses. My pulses in the bins occur at random times at random numbers of pulses per bin.

I actually wish to perform this counting for a limited duration or specified number of counting bins, repeat this and sum together the counts per specific time bin, and be able to digitally trigger the start of each count cycle. It looks like Gen Digital Pulse Train - Finite- retriggerable.vi can be used to accomplish this.


Steve

[Kevin_Price]

SteveP asked, "does period measurement give the total number of pulses that occur within each time bin or does it give the times (period) between successive pulses".

Good question. And the answer is, "that depends." What it depends on is which signal you use as your Source and which as your Sample Clock (aka Gate in traditional NI-DAQ).

In the app we've been discussing, the variable freq external signal is treated as a Source and a constant frequency of 1 kHz is the Sample Clock. This way you count the # of external pulses that occur within each constant-time bin.

However, the "normal" way to perform period measurement is to use a constant frequency (such as the internal 20 MHz or 80 MHz timebase) as the Source and the external variable frequency as the Sample Clock. This way you would count time between successive pulses.

Aren't counters cool?

You should be able to do what you want if you've got a 6602 (or even a 6601) because it sounds like you'll need 3 counters. One to perform the measurement, and 2 to generate the retriggerable finite pulse train that acts as the Sample Clock. Good luck!

-Kevin P.

[SteveP]

Kevin P. replied "In the app we've been discussing, the variable freq external signal is treated as a Source and a constant frequency of 1 kHz is the Sample Clock. "

Can you point me to an example or explain how to do this ?

I saw your reply on 3-24-05 to the thread "How to specify gate and source using QAQmx on LabView 7.0" at
http://forums.ni.com/ni/board/message?board.id=40&message.id=1938&view=by_threading&page=4

where you state "Try changing the DAQmx Create Channel vi to be Counter Input-->Period. You may want to set the "Units" input to be "Ticks". (You'll also need to update the channel property node where you specify the input terminal for the source signal by selecting it from the Counter Input-->Period menu.)"

I'm guessing it's the later part of this response that is important.

I tried taking the Meas Dig Period - Low Freq 1 Ctr.vi example and inserting a DAQmx Timing property node with SampClk.Src after its Create Channel. Setting this property to a PFI line did not chnage the value of the period being read back. It still seems to be using the internal clock as its source. This is on a MIO-16E-4 board.

Steve

[Kevin_Price]

SteveP,

I think you've basically got it, except for some terminology that's a bit confusing. The property SampClk.Src should be thought of as "what is the source of the signal to use as a Sample Clock, i.e., where do I find the Sample Clock signal?" The point is that it refers to the Sample Clock signal (aka the counter's Gate under traditional NI-DAQ.)

I don't have LV on this network pc so I can't double check exact syntax, but there's a different place to define the counter's Source signal, i.e. the signal that will cause the count to increment. You need to use a DAQmx Channel property node rather than a Timing property node. Look for a property with a name like "Source terminal" or "Input Terminal" under the Counter Input menu of the DAQmx Channel property node.

If this doesn't help, post back & I'll try to whip up a simple example when I get back to the lab later.

-Kevin P.