Excess counts when photon counting

[chem_matt]

Hi all,

I'm trying to count TTL pulses coming out of a APD, using PCI-6014, BNC-2110 breakout box and LabView 7.0.  Pulses come out of the dark detector at ~8Hz, though may go much higher when exposed to light.  Using CountDigitalEvents.vi or the Buffered version of CountingDigitalEvents on the dark detector yields an excessively high count-rate (something like 10,000 Hz).  My oscilloscope shows counts of around 8Hz, as expected.  The count rate does go up when I expose the detector to light, so it is responding, just giving way too many counts.

I've tried counting through ctr0 directly (wired in to USER1 BNC connector), or using ctr0 as an external clock source and counting through ctr1, but it still gives excess counts.  I think the counter should be able to handle the count rate, but I'm getting false counts. 

Any thoughts or suggestions would be gladly received!

- Matt.P.

[J_Thomas]

Hi Matt,

After reading your response it wasn’t clear to me, how you had your counter signal connected.  According to the NI 6013/6014 Family Specifications, on page 2 in Table 1 PFI 8 is also the CTR 0 Source.

If using a wire to connect the counter input signal from the ADP, the wire should be connected to PFI 8/P2.0 on the Spring Terminal Block for the BNC 2110.  If using a BNC connector for the counter input signal from the ADP, then instructions in the BNC-2110 Installation Guide say that to access the PFI 8 signal from a BNC, you need to connect USER 2 on the spring terminal block to PFI 8/P2.0 with a wire as shown in the diagram in Figure 5 of the manual.

It may also be helpful to set up a frequency measurement to determine the actual frequency of the input signal.  Several good examples can be found in the Example Finder under Hardware Input and Output >> DAQmx >> Counter Measurements >> Digital Frequency

[chem_matt]

---

Hi J,

Thanks for the reply.  The system was wired exactly as you've written here (PFI8 on spring terminal connected to USER2, and the BNC output of the detector connected to USER2).  As an additional test, I've tried  replacing the detector with an external source (10 ns TTL pulses from a function generator) and the counter works perfectly.  Not the detector, though, which is still giving ridiculously high count rates.   I tried running several of the frequency measurement examples as you suggested, and these reported a frequency of zero (quite odd, since I can see the pulses on my oscilloscope).  The second result in combination with the first is rather baffling.

Any other thoughts?

Cheers,

- Matt.

[J_Thomas]

Hi Matt,

I agree that the behavior is strange.  I was glad to hear that you were able to correctly read a 10ns TTL signal from a function generator.  That helps us to know that everything with the signal configuration is configured properly.

Here are a couple of ideas of things you could try to figure out what is going on:

1. This is just a simple check, but if you disconnect the photon detector (so no signal is connected) does the count still increment?
2. If you reconnect the function generator, will the count rate speed up or slow down if you were to change the rate of the generated pulse?
3. Try counting the edges of a signal with a really slow rate (something on the order of the single digit Hz rate that you say you are expecting from the photon detector). If your signal generator can’t generate a signal that slow, you could generate it with a digital output line on your DAQ card using a test panel in Measurement & Automation Explorer (MAX).  In the MAX test panel you should be able to manually turn on and off the digital output and see the count increase accordingly in your LabVIEW VI.
4. This may sound silly, but I had colleague of mine tell me that he once made this simple mistake…his oscilloscope reading did not match the reading he was expecting, and he later realized he was reading the signal off the oscilloscope with the wrong timebase (he was reading in milliseconds instead of seconds). Some of the other APD I have seen operate in the kHz – MHz range.  Is it possible that the count really is that high?  Just a thought.

If you can successfully read a signal with a slow rate from another source, then the issue must be with the detector signal itself (noise in the signal, TTL compatibility, ????).

[chem_matt]

Hi again J, and thanks for the reply,

All of these function-generator based tests passed, and the counter stops if you unplug the detector.  However, I do have some other information that might help.  I tried running the detector using a co-worker's USB-6008 (one 5 MHz counter) system, and the detector performs perfectly (8Hz dark count rate, exactly as spec).  Another co-worker's faster PCI board (80 MHz counter) gives the same counts as my board.  This is not a case of missing edges with the slower USB-6008 counter (the count rate on my counter is much too high).  The USB-6008 is counting properly.

I was wondering what the difference in terms of electronics was in terms of how the PCI-6014 and the USB-6008 counters work, and if this might cause the issue?  Might this be related to the pull-up resistor the USB-6008 uses?

Thanks again for all your help!

- Matt.

[hoffiz]

Hi,

I do have a question, it seems to me you are trying to count edges, but from your troubleshooting it seems you are measuring frequency I just want to make sure we are in the same page, so are you counting edges or are you measuring frequency?

If you are measuring frecuency I’m suspecting is that you are overflowing the counter. If you are making a frequency measurement you are basically going to count how many ticks of a known frequency signal are inside yours. So if your signal is 8Hz and it is a 50% duty cycle, 0.0625 s are going to be high and 0.0625 are low. That means that using a 20 MHz time base 50 ns ticks we will have 1.25e6 counts for the time your signal is high. For a more comprehensive explanation take a look at this knowledge base: What Are the Maximum and Minimum Limits for High and Low Pulse Width or Duration on a Counter Operat...

I hope it helps

[chem_matt]

Hi Jaime - thanks for your thoughts. 

To clarify, I am trying to count edges, not frequencies.  When I say the detector should give dark counts of ~8 Hz, what I mean is if I count the number of edges produced by the detector when it's covered up for one second, I expect to count ~8 edges.  I see  this number on an oscilloscope.  The problem is that when I connect the detector to the PCI-6014 and run a measurement, the counter indicates there are orders of magnitude more edges than the detector is actually producing.  I don't think the counter is overflowing, though if I wait long enough with the detector connected, I can see the counter reach its limit and turn over.

I have to admit, I'm running out of ideas!

Cheers,

- Matt.

[hoffiz]

Hi,

So if you are counting edges there is no overflow problem on you configuration. I have an 80 MHz counter reading a 8 Hz signal, probably the same as your co-worker's, what I’m doing is generating from ctr0 an 8 Hz 50% duty cycle square wave and reading it on ctr1 on the same signal through a CB-68. I would like you try these examples with the same setup and tell me if you can get the same result.  See screen shots attach:

The names of the examples are on the title bar for each screenshoot, the last one is just the capture from the scope. After this test if you still get the wrong reading and if you don’t mind, please attach the smallest replica of your code that will give you this erratic behavior and I will get a 6014e to test it myself.

I hope it helps

Message Edited by Jaime F on 02-06-2008 12:29 PM

[chem_matt]

Hi Jaimie,

Those tests work perfectly, with the counter giving exactly the number of edges as expected.  I also tried playing around with the duty cycle to see if I couldn't get the "excess counts" by making the pulse width smaller (no success). 

In case it helps, I've attached a comparison of the pulses from the detector with those generated using  the Gen Dig Pulse Train Continuous routine (sorry about the weird blank space in the trace, I'm still working out how to use the software that came with my scope).  The voltage level is a little lower than 5V but it is within spec of a TTL pulse.

Thanks for your help,

- Matt.

[hoffiz]

Hi,

I think you forgot to attach the comparison and attaching your code. So if the test works, and you are able to generate the pulses from the 6014e and count them with the same card it means that the hardware has no problems.  What confuses me is that you were able to count the pulses from APD with the USB-6009 and the only difference between those cards is like you said before is the 4.7 Ohms pull up resistor.  

The only thing we have to be aware on this test that is not the same when counting from the APD, is that the grounding is not an issue since the counters are sharing the same digital ground. When the signal is coming from the APD the ground of this BNC is been connected to the digital ground. I'm almost positive that what we have here is a grounding issue between the APD and the BNC-2110. If you can post a picture of how your signal looks from the APD in a scope it will help me a lot. 

Waiting for your response.