6602 buffered event counting needs synchronous mode?

[idleroux]

My lab is using a PCI-6602 to record the signal coming in from a single-photon counter,
whose output frequency can vary over a huge range.  In particular, it can be low enough
not to send any pulses between gate edges, and high enough to exceed the limit for
reliable operation in synchronous counting mode.  The following excerpt from the User's
Manual gave me hope:

If you are unable to use the synchronous counting mode for
buffered periodic event counting and cannot guarantee at least
one source edge between successive gates edges, you should
use buffered event counting and use software to calculate the
count in each interval.
-- NI-6601/6602 manual, p3-31

I've tried operating the card in buffered event counting mode and doing appropriate
software conversion.  However, the cumulative counts returned by the card when the
count rate is low and with synchronous counting mode disabled are clearly in error: the
traces are shorter than the total number of gate pulses, which never happens when the
count rates are high or when synchronous counting mode is enabled.

Is this expected behaviour in buffered event counting mode?  Are any
solutions/fixes/workarounds available that deal with low-frequency signals reliably while
still allowing high count rates?  By high count rates I mean 10-15 MHz, whereas synchronous
counting mode gives unreliable results above 6.5MHz.  Where may I submit an
update/clarification to the User's Manual so that others don't get bitten by this?

Thanks.

[Kevin_Price]

I've used the 6602 a lot and I'm not aware of any problems with buffered event counting.  Can you clarify what you mean by the following:

"the traces are shorter than the total number of gate pulses, which never happens when the
count rates are high or when synchronous counting mode is enabled"

What does "traces are shorter" mean -- is it that you have fewer source edges than gate edges?  Or that you have fewer values buffered than the # of gate edges?  Generally, can you give some more details about the unexpected behavior, i.e., what is the result under each of several scenarios (synchronous counting enabled vs. disabled, buffered period vs. buffered event, what is the freq of the Source signal and the Gate signal, etc.).  I think I get the gist of the problem, but some specifics would help steer my thinking better.

Also, can you use DAQmx?  It renames the "synchronous counting" feature as "duplicate count prevention", but more importantly the implementation is better.

-Kevin P.

[idleroux]

The problem may well be with my understanding and not the board. Here are four scenarios and their observed behaviours.

1. Buffered semi-periodic event counting, synchronous counting mode enabled: The card returns an array of incremental counts (i.e. counts seen since the previous gate edge). The array length is the same as the "Counts Per Buffer" parameter used in setting up the measurement. Counts are accurate provided the input signal (count) frequency stays below 6.5 MHz, otherwise they are underestimates by a frequency-dependent factor. I don't understand why the upper limit is 6.5 MHz and not 20MHz / 4 = 5 MHz, but that is irrelevant to the current discussion.
2. Buffered semi-periodic event counting, synchronous counting mode disabled: Same behaviour, except that now the counts are accurate at high frequencies, and low-frequency runs where some gate intervals see no counts generate incorrect results. As this mode is explicitly not supported when there is a possibility of no counts occurring between gate edges, I consider this normal behaviour.
3. Buffered event counting, synchronous counting mode enabled: The card returns an array of cumulative counts (i.e. counts seen since some arbitrary origin which I don't care about). The array length is the same as the "Counts Per Buffer" parameter used in setting up the measurement. Counts are accurate provided the input signal frequency stays below 6.5 MHz, otherwise they are underestimates by a frequency-dependent factor.
4. Buffered event counting, synchronous counting mode siabled: The card returns an arry of cumulative counts, and which are accurate at frequencies of up to at least 20MHz. If the source frequency is low enough that some gate intervals see no source counts, the array is typically shorter than the requested "Counts per Buffer". The array will typically be of the form {1,2,3,4,5,6,...}, which suggests that only those gate edges where a count was seen (and the cumulative count increased) are being added to the buffer and returned.

Based on the description in the manual, I had hoped that buffered event counting with synchronous counting mode disabled (the last scenario above) would give accurate results at low frequencies as well as high frequencies. This does not appear to be the case, since the card seems to report the sequence {1,1,1,2,2,3,3,3,3,3,4,4,5,....} as {1,2,3,4,5,...}, dropping the empty gate intervals.

I don't know anything about DAQmx (yet), and will refrain from comment on it until I've done a little research.

-- Ian Leroux

[idleroux]

Re: DAQmx

Thanks for pointing it out to me, I'll have to give serious consideration to rewriting the system to use it. However, that isn't a practical solution in the short term, so I'd still very much appreciate any insights you might have in the context of a traditional NI-DAQ implementation. Basically, I'd like to know if the behaviour I'm seeing in buffered event counting mode w/ synchronous counting disabled (scenario 4 in the previous post) is normal, in which case I'll just have to live with it or work around it, or surprising, in which case I'll keep trying to change it.

-- Ian Leroux

[Kevin_Price]

I *think* the behavior you're seeing is normal, but haven't really exercised the 6602 with external signals in the MHz realm under traditional NI-DAQ.  So if the experienced NI folks say different than me, believe them.  I hadn't responded yet because I wanted to put together a little test example and haven't had a chance yet.  Got anything you can post that'd give me a good headstart?  I'm not sure when I'll get a chance to start from scratch...

One point in particular is that I wasn't even aware of is the 6.5 MHz limitation -- most of my measurements were buffered periods using the internal 80 Mhz timebase as a source and an external gate signal in the 10's (or even 1's) of kHz.   However, I wonder whether the limit is actually governed by something like (timebase / 3) = 6.667 MHz for a 20 MHz timebase.  When doing period mode, have you tried explicitly using the 80 MHz internal clock rather than the 20 MHz?  Maybe there's a chance that'd shift the limit freq up to (80 Mhz / 3) = 26.667 MHz?  If so, you might be able to use scenario 1.  Possibly also 3, but it seems less likely since that scenario doesn't directly use the internal timebase.

Anyway, I understand why buffered event counting (scenarios 3,4) is preferable to buffered period measurement (scenarios 1,2) for you.  Treating the pulses as Source signals lets them increment a hw counter.  Treating them as Gate signals requires transferring a value from the board across the PCI bus into RAM.  As you get into the MHz range, I would expect you to run into a lot of -10920 errors when the pulses are treated as Gate signals.

When you can make the DAQmx switch, period measurement can correctly buffer 0 values for intervals where there were no source edges between 2 gate edges, i.e., source signal freq < gate signal freq.  Similarly, edge counting can correctly buffer duplicate count values for such intervals.  In either case you'd buffer a sensible value for every Gate edge, including intervals containing no source edges.   However I just don't know if "duplicate count prevention" in

DAQmx is subject to the same ~6.5 MHz limit or not.  If forced to guess, I'd venture it probably is -- it "feels" like a circuitry limit rather than a limitation in the driver.

Not much help here, just a probable confirmation that your observations are normal behavior, a small hope that explicitly configuring an 80 MHz internal timebase as Source may help, and longer-term optimism that DAQmx may also help.  But nothing 100% rock-solid sure.

-Kevin P.

[Tom_W_[DE]]

Hi Ian-

The behavior you describe in scenario 4. is indeed the behavior you should expect.  When you disable synchronous counting (or duplicate count prevention) you are telling the hardware to rely on source pulses to physically buffer the reading and continue counting.  If no source pulse occur then no readings are buffered and you will receive the "choppy" data you described.  To avoid this situation, simply enable synchronous counting.  In versions of NI-DAQmx starting with 7.5 and higher the setting is made automatically for you, so you don't even need to worry about it.

I echo Kevin's suggestion- the 6.5MHz limitation is troublesome.  In the case of buffered event counting the rate of the source of your "sample clock" on the gate will be limited by transfer rate limitations.  You say you are counting a >6.5MHz signal, but I didn't catch where the clock signal was coming from.  Is it also running at a high rate?  If so, are you properly monitoring for errors such as the infamous -10920 FIFO overflow?

Hopefully this helps-

[Tom_W_[DE]]

Hello again-

I forgot to mention that while we're troubleshooting it may be interesting to observe the behavior in NI-DAQmx to see if you are still limited to the 6.5MHz counting rate. 

I didn't catch your ADE, but there are plenty of great examples in LabVIEW 7.X/8.0 in the NI Example Finder (Help>>Find Examples) under Hardware Input and Output>>DAQmx>>Counter Measurements.  Equivalent ANSI C examples are available under Program Files>>NI-DAQ>>Examples>>DAQmx ANSI C Examples folder on your HDD.

Hopefully this helps-

[idleroux]

I've checked my notes, and the upper limit in synchronous counting mode is somewhere between 6.5 and 6.6 MHz (a synthesized 6.5 MHz signal gets counted at 6.5 MHz, whereas a 6.6 Mhz signal gets counted at 6.45 MHz). Sadly, this nixes your rather attractive 20 MHz / 3 hypothesis.

I'm afraid I don't currently have a good test case that isn't tightly coupled to the rest of the application. Nor am I completely familiar with the code yet, as I only recently inherited it. However, as far as I can tell all interaction with the counter happens in the two attached VIs, the first setting up the measurement, the second reading off the data. The gate signal comes from an external SRS signal generator and is a square wave, usually around kHz. Data acquisition starts when the SRS signal is switched on by an external trigger. The source signal to be counted consists of 50 ns pulses coming from a photon counter at random intervals. For testing purposes (e.g. figuring out the maximum frequency), this signal is replaced by the square-wave output of another SRS. Hope that helps a bit.

To sum up. Staying with buffered event counting mode is a good idea, using synchronous counting mode is necessary if I want to handle low frequency signals, the 6.5 MHz upper limit I see in this mode is as-yet unexplained and may (possibly) be surmountable, which would turn scenario 3 into an all-round solution. For now I'll continue to enable/disable synchronous mode on a case-by-case basis.

-- Ian Leroux

Message Edited by idleroux on 01-27-2006 08:55 AM

[idleroux]

I'm not entirely clear on what you mean by a "sample clock".  I've given a more detailed description of the setup in my reply to Kevin P.,  if that doesn't answer your question, perhaps you could clarify it?

Thanks for the confirmation that I'm seeing expected behaviour.  This way I won't waste my time trying to fix things that aren't broken.  I'll also take a look at the NI-DAQmx examples and see whether that represents a long-term solution.  I should probably convert to NI-DAQmx at some point anyways, but if it solved the 6.5 Mhz limit that would make it a higher priority.

I'm afraid the code I inherited does no real error-monitoring, so I'll start by hunting for that FIFO overflow error.  If it turns out that -10920 is a common error, is a workaround available?  Since the counter is only active a small fraction of the time (a few tenths of a second every 5-10 seconds), increasing the size of the relevant FIFO might work if that is possible.

-- Ian Leroux

[Tom_W_[DE]]

Hi Ian-

The "sample clock" I am referring to is the signal you apply to your gate to physically buffer the counts.  I didn't see where you mentioned its source in your earlier post.  Unfortunately the device FIFO cannot be increased.  The most reliable method is to decrease the sampling/buffering rate by slowing your gate signal.  All of the Traditional NI-DAQ and NI-DAQmx function calls will return error codes as return values and it's always a good idea to monitor for errors.  Please keep us posted on your troubleshooting-

Thanks-