Count Digital Events low count rate threshold

[heglex]

Hello,

I am trying to use the Count Digital Events.vi example of the DAQmx examples to count pulses from a photon counter.  As long as the light level is high enough, this works just fine. But, when the light level drops below a threshold, no counts are read. I have verified this is not due to the photon counter by testing with an independent instrument.

It seems like it might have something to do with the rate at which counted events are offloaded from the hardware (PCIe-6321) to the computer, i.e., there is a minimum threshold of counts before such a data transfer takes place. I am polling for the number of counts every 100ms.

Any help would be appreciated.

Thanks,

Alex

[heglex]

More insight into my problem:

If I use the PFI input as the counter source, the counter increments properly until the rate at which edges appear at the input is less than ~300 Hz (I tested this with a pulse generator).  I do not see this behavior if I use the AI Sample Clock as my edge source-- I tested it down to 0.5 Hz, and the counter increments once every two seconds. Thus, I am inclined to think that the problem lies somewhere in the PFI. Right now it seems as if the PFI is not properly sending edges to the counter if there is more than 3.2 ms between each edge.

[John_P1]

Hi Alex,

The PFI line just routes directly to the counter and doesn't have any logic associated with it that might prevent it from passing your slower signal to the counter.  I'd expect you to see problems at higher frequencies (>25 MHz) due to the front-end bandwidth of the PFI lines on your board, but at low frequencies bandwidth isn't an issue.  PFI lines also support digital filtering, but this is disabled by default--in any case, filtering is used to remove short pulses (for example, those that occur due to the "bouncing" of mechanical relays) and doesn't really apply to the problem you are seeing.

Furthermore, the data transfer shouldn't be the issue either--the example you linked just polls the value of the count register.  The software call to DAQmx Read initiates the data transfer which is independent of your external signal.  If you don't have anything connected, you should see the loop continue to iterate with the read returning "0" indefinitely (until something is connected).

I'm more inclined to think the issue is with the signal itself.  Do you have a link to a datasheet or specifications page for the signal source (photon counter)?  Could you elaborate on the testing you did with another instrument?  What is the voltage and pulse width of the output of the photon counter?  Does the counter just suddenly stop working at ~300 Hz, or is there a transition region where some pulses are counted and others are not?

Best Regards,

[heglex]

Hello John,

Thanks for the help. I have isolated the signal problem to the signal passing through the BNC breakout box (BNC2110), through the 5m connector cable to the PCIe-6321 in the computer. I did this in the following way: I added to the Count Digital Events.vi a provision to generate continuous digital pulses with selectable high and low times. If I set the counter input  terminal to the pulse output terminal (so the loopback is performed on the PCIe-6321 itself), there is no problem. If I let the pulse signal travel through the cable, out of the BNC breakout, and then looped back through another PFI terminal, this is when I see problems I've been seeing.

Even just observing the pulse output signal on an oscilloscope (without any other connections), I see that the pulse height decreases as I increase pulse low time. As expected, when I connect this pulse output to the counter BNC (again without any other connections present), increasing pulse low time causes the pulse height to fall below a detection threshold and I do not count any pulses.

I'm not sure why I am seeing this behavior, or what I can do to remedy it...

-Alex

[heglex]

Hello again John,

Some more information which may be of interest. If I just use a frequency generation test panel in MAX, set to a 50% duty cycle, and I observe the output on an external oscilloscope (after it passes through the 5m cable and the BNC-2110), I see a strange non-linear relationship. If I can understand this relationship, I think I will understand the problem in general.

The negative-going edge of the square wave is always sharp. The positive-going edge of the square wave increases sharply to a certain value, then it increases slowly to ~2.5V. The value it increases to quickly is between 0V and 2.5V and depends on the frequency. The greater the frequency, the closer it is to 2.5V. If the frequency is less then say 1kHz (roughly) then the square wave has to charge slowly from 0V up to 2.5V.  Hence the problem I am observing: at low frequencies and with a short pulse width, the "slow" part of the charging curve is not long enough for the pulse to gain any appreciable amplitude, and it is not detected by the counter input.

-Alex

[John_P1]

Hi Alex,

I'm not exactly sure I follow what your signal looks like, could you provide screenshots?  It does sound like you've found the source of the problem (i.e. the pulses are too narrow at lower frequencies). 

The input high threshold for TTL is 2.2 Volts.  The input low threshold is 0.8V.  You'll want to ensure that you are passing these values (as seen by the counter).

Best Regards,

[heglex]

Hi John,

Of course, screenshots will help. Below please see screenshots of a test I did. If I can understand this, I think I can understand my problem.  Again, my setup is as follows: PCIe-6321 <-> 5m cable <-> BNC-2110 <-> BNC cable <-> o-scope. I've narrowed the problem down to the BNC-2110 by swapping all cables and doing a loopback test on the PCIe-6321 itself.

I used the test panel shown in MAX to generate a 50% duty cycle square wave at different frequencies, as shown in the screenshot. I show both the positive edge and negative edge of the square wave (note here that the amplitude is now 5V, rather than 2.5 V, because I am using high-impedance coupling). Maybe the strange charging behavior I described in the last post will make more sense; I'd like to know why the positive-going edge isn't always as sharp as the negative-going edge.

For low duty cycle pulses at low frequencies, one could imagine by looking at these plots that the pulses are not long enough to gain appreciable amplitude and thus will not cross the TTL detection threshold.

-Alex

[John_P1]

Hi Alex,

Interesting test, but I'm not sure how exactly it might relate to the orignal problem.  From my understanding:

Original Problem:

Photon Counter >> BNC Cable >> BNC-2110 >> SHC-68-68-EPM >> 6321 (counter input)

Test Case:

6321 (counter output ) >> SHC-68-68-EPM >> BNC-2110 >> BNC Cable >> Oscilloscope

As to the original problem, the counter inputs are high impedance so should see the full 5V.  Do you have something else in parallel that is pulling the signal from the photon counter down to 2.5V?  I'm still not sure I have a clear picture of your external connections or where the signal is coming from.

Best Regards,

[heglex]

Hi John,

I will try to relate this test to the original problem.

Original Problem:

Photon Counter >> BNC Cable >> BNC-2110 >> SHC-68-68-EPM >> 6321 (counter input)

Equivalent problem (to generate deterministically timed pulses):

External digital pulse generator >> BNC Cable >> BNC-2110 >> SHC-68-68-EPM >> 6321 (counter input)

Test 1:

I generate 20 ns pulses with my pulse generator and count them using this test panel:

From 0 to 59 us between pulses, all pulses are counted. From 60 us onward, no pulses are counted.  If I look at the pulse height with an oscilloscope (Oscilloscope <-> External digital pulse generator >> BNC Cable >> BNC-2110 >> SHC-68-68-EPM >> 6321 (counter input)), all the pulses look high enough to be counted (5V); additionally, the pulse height does not change with pulse repetition rate.  Therefore, something is happening further down the line between the pulse generator and the 6321. Unfortunately, I cannot connect my oscilloscope further down the line to see what is going on. Therefore, I ran the following  tests:

Test 2:

6321 (generate pulses) >> 6321 (count pulses): everything works fine.

Test 3:

6321 (generate pulses) >> SHC-68-68-EPM >> BNC-2110 >> BNC Cable >> BNC-2110 >> SHC-68-68-EPM >> 6321 (count pulses)

I used the following VI:

I set the "high time" to 20 ns. Pulses are counted for "low time" less than 115 us, and not counted for "low time" greater than 117 us.  Note this is roughly double the minimum low time for a pulse to be counted after 1 pass through the BNC-2110; I suspect this is because the pulse makes two passes through the BNC-2110. Since I had a hunch that it doesn't matter whether the pulse is going into or out of the BNC-2110 for this behavior to occur, I did a fourth test:

Test 4:

6321 (generate pulses) >> SHC-68-68-EPM >> BNC-2110 >> BNC Cable >> Oscilloscope

The high time is again set to 20 ns. As I decrease the low time, note that the pulse height increases. As low time goes from 60 us to 59 us, I have verified that this is the point at which pulse height increases above 2.2 V, crossing the TTL detection threshold of the counter (as consistent with the threshold observed in Test 1).

Does this help clarify the issue, and relate it to the last series of screenshots I posted (with 50% duty cycle pulses, generated on the DAQ and viewed on the oscilloscope)? Note that pulse height does not change until "low time" is decreased below at least 1 ms.

-Alex

[heglex]

An additional test I performed, similar to Test 3 from the previous post:

6321 (generate pulses) >> SHC-68-68-EPM >> 6321 (counter input)

I jumpered together PFI12 and PFI14 at the end of the cable to form the loopback.  With this method, the upper limit of the pulse "low time" that is detectable is now 182 us (it was previously ~115 us). Therefore, part of the problem is occurring in the cable, and part of the problem is occurring in the BNC-2110. Note changing the length of the cable has not caused my results to vary in the past.

-Alex