Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

NI 6259 photon counter min pulse detection

Solved!
Go to solution

Hello,

 

I have a PCI 6259 DAQ card which I'm using as a counter. Is there a limit to the minimum pulse width it can count while operating as a counter? My photon counter gives out TTL pulses with widths of 50ns which I think is below what the counter can read unless I am mistaken. I'm using the 100kHz internal clock as the clock source. Is there anyway to get the counter to pick up such small pulses?

 

Would the NI PCI 6120 DAQ card be a better choice for this type of measurement? I should be able to get my hands on one shortly.

 

Thanks for your time,

Mark.

0 Kudos
Message 1 of 10
(9,505 Views)

A 50 ns pulse corresponds to a 20 MHz freq.  You should be able to capture/measure such a TTL pulse with a 6259, but I don't think you'll really want to be measuring pulse *widths*.   You'd only be able to get a nominal count of 4 timebase edges per width with a possible +/- 1 count uncertainty, i.e., 25% measurement error.

 

More likely, you'd either want to:

        1. measure the period/frequency of successive rising edges of these 50 ns pulses, effectively timestamping every detected photon.   Brief fast bursts of photons may produce an unrecoverable FIFO error.   A newer X-series device with a bigger counter FIFO would be a better choice if this is an issue.

OR

        2. perform "binning" by counting the # of these 50 ns pulses that occur during equal time intervals.   Here you are pretty immunce to brief bursts of photons, but you need to sustain long-term throughput over the PCI bus.  You're probably pretty safe sampling at <= 100 kHz or so, but if you need better precision on the bins & thus faster sustained throughput, I'd again recommend a PCIe X-series board. 

   You might also have to watch out for a feature known as "Duplicate Count Prevention" which could impact your measurement data if you ever have 0 photons in a given interval.  The faster you sample, the more likely this is to come up.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 10
(9,496 Views)

Actually the width doesn't matter, I'm only interesting in counting the edges. However, to test this I've hooked the card up to a frequency generator, once I go past about 1.5MHz it stops counting. This corresponds to a width of a few hundred ns.

 

Am I doing something wrong? I'm using the 100kHz timebase as the clock source, but this should only affect my bin size right not the resoultion for the edge counting?

0 Kudos
Message 3 of 10
(9,488 Views)

When I say the width doesn't matter I mean I don't want to measure it. The Perkin Elmer counter we have emits a 50ns pulse everything a photon is received, this is what I wish to count.

0 Kudos
Message 4 of 10
(9,476 Views)

How exactly are you configuring your counter(s)?  Can you post a snippet or screenshot?  Do you get an error message from your DAQ functions?  In exactly what way does your task "stop counting" when you push your freq generator past 1.5 MHz?

 

Of the 2 approaches I outlined before, the 1st is simpler to configure but much less robust to sudden bursts of data.  The 2nd takes a little more work to configure correctly, and will probably require a "dummy" task to supply a sample clock.

 

I don't have much time now, but if you search here on the counter/timer board for things like photon counting, binning, APD's you should find quite a bit more info.

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 10
(9,467 Views)

Hello again,

 

Thanks for the reply. I've set up a pretty basic program which pretty much follows exactly the format given here:

https://decibel.ni.com/content/docs/DOC-11681 My source is selected as the 100kHzTimebase. If I go to one of the higher source clock rates (20Mhz and 80MHz) I don't seem to be able to take the data from the buffer fast enough. Mine isn't set to loop though, it just runs once and takes X sample.

 

I can't send the one I'm using at the moment. I can attach it Monday though.

 

It works perfectly up to around 1.5MHz on the 100kHz timebase i.e. if I set it to 900kHz I'll get 9 counts every period. However around 1.5MHz it stops reading counts at all and all I get is an array filled with zeroes. I thought it might be due to the sampling rate which is said to be 1MS/s for the NI 6259.

0 Kudos
Message 6 of 10
(9,464 Views)
Solution
Accepted by topic author mark.daly

Well I just learned something new -- I hadn't previously realized that the 100 kHz timebase could be used directly as a sample clock for counter tasks as described here.

 

The counter task should be able to count incoming edges at rates well into the 10's of MHz.  If you stop registering edge counts when your fn generator hits 1.5 MHz, I'll bet it's because the pulses are getting too rounded and/or too low in amplitude to be recognized as TTL transitions. 

 

Try inserting a DAQmx Channel property node between the task creation and start.  Select the property "Counter Input->Count Edges->Input Terminal".  Make it a write property, and create a terminal constant.  Right click the constant, select "Browse..." and choose either the 20MHz or 80 MHz timebase.  Run it and verify that you consistently get 200 or 800 counts per interval.

 

If using the internal timebase works as expected, you'll need to focus on the pulse integrity from your fn generator and your actual instrument. 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 7 of 10
(9,458 Views)

Hello!

 

Thanks! I got it working. It would seem that the rounding of the waveform was the problem. I got it working today. Now all I need to do is tidy the program up a bit and I'm done.

 

Thanks for all your help!

Mark.

0 Kudos
Message 8 of 10
(9,441 Views)

Hello there.

 

I am trying to measure APD pulses as well so that I can do some lifetime measurements.

 

Unfortunately I have not been able to succesfully produced the expected lifetime curves, meaning that I must be doing something wrong with the TTL data acqusition.

 

Would you mind sharing some of your code/experience?

 

Thanks,

 

 

0 Kudos
Message 9 of 10
(7,917 Views)

What kind of lifetime curves are you trying to generate, i.e., what kind of relationship are you plotting and what are the units for the axes?

 

Also, can you post the code you've put together so far along with some description of what you intend it to do?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 10
(7,912 Views)