Basic Buffered Edge Counting

[cghuebner]

Thanks Kevin for the continued interest in my application. Maybe I should add another peace of motivation why not to use 2 counters, where one should be sufficient. The X-series DAQ cards all have 4 counters, rendering them very attractive to build a whole instrument with just one DAQ device (scanner control, photon counting). Since we are typically using 4 detectors, in this case the only chance is to find a solution with one counter per detector.

From the documentation: "Prescaling allows the counter to count a signal that is faster than the maximum timebase of the counter. The TIO counters offer 8X and 2X prescaling on each counter. You can disable prescaling. Each prescaler consists of a small, simple counter that counts to eight (or two) and rolls over. This counter is specifically designed for this application and can count signals that are faster than the general purpose counters. The CtrN source signal on the general purpose counter is the divided signal from the simple counter."

As far as I understand this, the prescaler is a counter that is counting up to two or eight _within_ one timebase period. Otherwise to me the sentence "Prescaling allows the counter to count a signal that is faster than the maximum timebase of the counter." does not really make sense. But again it might be that the documentation is just misleading.

In my application, the detector is connected to the gate. So if prescaling works as I suppose it to do, it should act on the source signal. 

First, I tested the prescaling with an old 6602 from the shelf. I used a detector with 20 ns long pulses, where after pulses can occur 80 ns after the real pulse. With 8x prescaling on the 80 MHz timebase, the period (if the prescaler divides the source frequency down) would be 100 ns, so I'd expect that the error of duplicate gate pulses within one source period should occur. Did not happen. 

Unfortunately, when I finally set out to test the prescaling on our production system, there was an error message stating the prescaling is not possible with that counter (6612 PCIe)?? Really? The newer device does not allow for prescaling? Now I am even more confused.

I am not sure if your proposed test  setting will help in my case, as again source and gate are used in opposite to my application. 

Christian

[cghuebner]

Here is the error message:

Possible reason(s):

Prescaler value requested is not supported by this device, given the requested Input Terminal.

Set Prescaler to 1, or change the Input Terminal.

Property: CI.Prescaler

Value: 2

Property: CI.CountEdges.Term

Value: /Dev2/100MHzTimebase

[cghuebner]

Eventually, I've found the important information on prescaling in the X-Series manual. You're right, it acts like a frequency divider. Plus, it is also stated that prescaling is not available for internal timebase sources. Interestingly, for the 6602, I do not receive an error when I use prescaling by a factor of 2.

"Prescaling

Prescaling allows the counter to count a signal that is faster than the maximum timebase of the counter, as shown in Figure 7-39. X Series devices offer 8X and 2X prescaling on each counter (prescaling can be disabled). Each prescaler consists of a small, simple counter that counts to eight (or two) and rolls over. This counter can run faster than the larger counters, which simply count the rollovers of this smaller counter. Thus, the prescaler acts as a frequency divider on the Source and puts out a frequency that is one-eighth (or one-half) of what it is accepting.

Figure 7-39. Prescaling

Prescaling is intended to be used for frequency measurement where the measurement is made on a continuous, repetitive signal. The prescaling counter cannot be read; therefore, you cannot determine how many edges have occurred since the previous rollover. Prescaling can be used for event counting provided it is acceptable to have an error of up to seven (or one) ticks. Prescaling can be used when the counter Source is an external signal. Prescaling is not available if the counter Source is one of the internal timebases (100MHzTimebase, 20MHzTimebase, or 100kHzTimebase)."

[Kevin_Price]

Can you post your config code?  I think we keep talking past each other regarding Source, Gate, signal function, etc.

Meanwhile, further comment on an excerpted quote:

... Each prescaler consists of a small, simple counter that counts to eight (or two) and rolls over. This counter is specifically designed for this application and can count signals that are faster than the general purpose counters. The CtrN source signal on the general purpose counter is the divided signal from the simple counter."...

As far as I understand this, the prescaler is a counter that is counting up to two or eight _within_ one timebase period.

I am not sure if your proposed test  setting will help in my case, as again source and gate are used in opposite to my application. 

---

No!  The prescaler DIVIDES the raw incoming signal by 2 or 8.  The rollover event is what passes out and acts as the regular counter's Source input.  It takes 2 or 8 raw pulses to produce 1 pulse that the counter will, um, count.   Read through the doc again -- it talks about dealing with signals that are *too fast* for the general purpose counter.  The prescaler *reduces* the frequency by a factor of 2 or 8 before passing it through.

I tried a couple things on a simulated device.  I *think* your error is because you apparently aren't allowed to apply the prescaler to an internal timebase, only to an external signal.  

My proposed test setting would let you assign whichever signal you want to source and gate.  It'd be a flexible set up to experiment and learn.

-Kevin P

[Kevin_Price]

A followup to the request to post the config code:  can you also describe in more detail what kind of data analysis this measurement needs to support?

I ask because at least *some* discussions I've been involved with were able to avoid similar errors by inverting the configuration.  In other words, send the detector pulses to the Source to be counted while feeding a constant frequency sample clock to the Gate to latch and buffer the counts.  The Source is better able to handle high-speed bursts.  The tradeoff is that your detected pulse rate is quantized more crudely.

With period or frequency measurement, you get excellent timing resolution as you capture intervals between individual detector pulses.  Here the detector pulse acts as the sample clock and while the count is incremented by a fast internal timebase.  The count becomes a precise measure of the interval time.  But as you've found, you can be vulnerable to a fatal task error if you get too fast a burst of pulses.

An alternative is simply count the detector pulses while capturing them with a a constant rate (but slower) sample clock.  In prior threads, this has been referred to as "binning".  For example: according to MAX device routes, a 6612 device can use the internal 100 kHz clock as a counter sample clock.  So you could sample your detector pulse count at 100 kHz to create 10 usec "bins".  You still get a measure of pulse rate, it's just quantized to show you the average rate per 10 usec interval.

In some apps that can be good enough, if you apply a bit of math and curve-fitting after the fact to smooth out the quantization.  And it's a lot less prone to original error you were fighting against.  Plus, if needed, you could make use of prescaling since the troublesome detector pulse is headed toward the counter's Source pin, which the prescalar *can* affect.

-Kevin P

[cghuebner]

 

Since I do not really know how to post config code, I attach a screenshot of the configuration with the buffered event counting sample VI. 
Binning data is not an option, as we have extreme fluctuations in the event frequency, but need to calculate correlation functions down to nanoseconds. 
As I wrote, it is not the case that we have frequent high frequency events. The detectors generate with a very low probability an afterpulse after the detection of a real photon. 
I understand that this is a problem with the counter configuration, because the same source count number would have to be latched twice (two gate pulses within one source period). However, it is not a problem if this second event is just ignored. The sole problem is just that the VI stops on an error. If I could tell the VI not to stop and just to proceed, I would have my solution.

Christian 

[cghuebner]

Update: It *seems* that the problem is *not* the after pulse but rather *was* a pulse reflection in an inappropriately terminated bnc cable. At the moment the counters are running for quite while (roughly one our) without an error.

Actually, taking into account the duration of the detector pulses of 15 ns and the timebase period of 10 ns, the error 

"Multiple Sample Clock pulses were detected within one

period of the input signal"

should not occur(?).

Or is my understanding that "Sample Clock pulses" are the Gate pulses and "input signal" is the source wrong?

[cghuebner]

Attached is the code that is running at the moment. Seems to work.

[cghuebner]

Coming back to the timing: From the 6612 specs, Table 2. Minimum Pulse Width, there are different figures given for different tasks. For frequency measurement, it is 6.25 ns, whereas for all the other cases w/o prescaling it is 20 ns. Given the roughly 15 ns pulses from the detectors, I'm a bit confused that my application actually works. 

[Kevin_Price]

Trying to respond all at once.

1. RE: detector pulse width = 15 ns, timebase period = 10 ns

    Agreed that nominally you shouldn't be able to get 2 detector signal edges without any timebase edges.  However, you recently found a BNC termination problem that seemed to make the signal not-quite-so-well-behaved, which *could* cause 2 such apparent edges too close together.

2. Could not open LV2022 code, I'd need it saved back to 2020 or earlier.  But maybe not important if problem proves to have been solved.

3. RE: pulse width specs

    I see a 10 ns spec for Freq measurement and "Other PFI Lines".  The way the table is labeled, it appears there's a preferential signal path available when the counter gets its Source input (i.e., its timebase) from the default Source PFI line.  It's not 100% clear to me whether the same would apply when the counter gets its Gate input (i.e., its sample clock) from the default Gate PFI line.  But it very well might.  So perhaps the 6.25 ns spec would apply in your case since you *are* using the default Gate PFI line as the sample clock, according to the screencap you posted.   Either way, your 15 ns detector pulse should be wide enough.

-Kevin P