High sample rate counter acquisition (and understanding the datasheet)

[BertMcMahan]

I have an application that requires some very high resolution data reading from a PCIe-6612 card (or other, if this card is insufficient). I have done high speed analog before but not high speed counter, and not with a dedicated counter card. I want to make sure I'm reading the spec sheet right.

The application involves edge counting of a very fast source and reading out the data at very high rates. For example, there might be a nominally 10 MHz edge source, and he wants to read the number of edges at 1 MHz to see the actual number of pulses in each 1 ms window.

The datasheet (here) mentions a DI Sample Clock frequency of 0-10 MHz in the "Waveform DIO Functionality" section. I think I follow, but am not completely sure due to the nomenclature (it refers to DI/DO, but this is a counter card so I want to make sure I'm interpreting right).

-I assume "Waveform DIO" refers to the ability to read the "Number of samples" value from a given counter, correct? (i.e., I have counter 0 counting edges in task A, and can use task B to read the edge count at a rate of 0 to 10 MHz, presumably using ctr 1 as my sample clock)

-The DI FIFO is 255 samples. What exactly does this value tell me? I can't tell what that number means from any documentation I could find. I was pretty sure DAQmx sets up a DMA to another RAM buffer, which obfuscates this number, right? As long as I set up the right size buffer in LabVIEW before I read, and assuming the bus isn't getting overwhelmed, I can call DAQmx Read at a fairly leisurely pace (say every 100 ms, obtaining 10kS each read).

Like I said, I've done all of this before with multifunction IO cards, but not with the dedicated counter cards, and I'm not quite sure how to read the DI FIFO.

Thanks for any tips you can give.

[Kevin_Price · Accepted solution]

DI/DO specs do *not* apply to counter tasks.  Counters are their own little beasts (specs start on page 4).  The good news?  The 6612 is the best NI device I'm aware of to unleash maximum counter capability.

Each counter has a 127-sample FIFO and you're right that DAQmx and DMA do all the dirty work so you don't really have to think much about it.  Make a decent sized task buffer and read from it at semi-leisure.  (Prior generations of counters had mere 2-sample FIFOs, and sometimes DMA couldn't prevent a hw FIFO buffer overflow.  With PCIe and 127 you'll be fine.)

Counters are very flexible, which can be great, but they're also *unique*, which can sometimes mean "more work".  One example: they can't derive their own sample clock for constant-rate sampling.  I often make a continuous pulse train with one counter so the other counter that I *care* about can use it as a sample clock.

Below is a simple way you could count cycles (technically, active edges) of a 10 MHz signal at 1 MHz.  This will yield a cumulative count that requires a simple finite difference to transform into a rate.  (There's a way to measure this rate directly via "period measurement", but it kinda requires some inside-out thinking that probably isn't an ideal way to get started with counter measurements.)

    You probably won't need to worry about the oddly-named "duplicate count prevention" property, but I included it just in case.  (If you search you'll find that I have a long history of not knowing when it's needed, largely because way back in the early days of DAQmx, the behavior wasn't consistent across different devices or DAQmx versions.)

-Kevin P

[BertMcMahan]

Thank you Kevin, I was hoping you'd chime in 🙂 Your advice is always excellent.

I have used counters plenty of times (if I had a nickel every time I needed to measure an encoder...) but never a dedicated counter only card, so I wanted to make sure I wasn't about to accidentally use a resource that DID exist on a multifunction board but did NOT exist on dedicated boards. I typically use an AO or AI sample clock to read my encoder positions as I'm nearly always doing AI or AO in parallel, and for some of my legacy stuff I only have 2 counters and needed them both for position measurements, hence no routing.

Is there a spec in the datasheet somewhere that says how fast a counter channel can be read? Basically the "max sample rate for analog input" equivalent. Can I read the edge count value at 10 MHz? 50 MHz? This application may need to go quite high. I didn't think the DI sample rate applied, but didn't know this card could do dedicated digital I/O along with counter I/O- hence the confusion.

[Kevin_Price]

I don't think the spec sheet itself declares a max sample rate.  It's more a matter of how fast a clocking signal the device can receive (20-25 MHz from external sources according to the spec sheet) and the ability of the DMA controller to keep delivering data to RAM.

The best resource I know of is some benchmarking info (looks like the article has been updated from what I remembered.  It used to have more info about the test sytem and more verbage about caveats.)

What kind of measurement needs to be made?   When you start getting into hw-sampled edge counting, period measurements, or frequency measurements, there can sometimes be alternative and not-entirely-intuitive ways to approach things.  Encoder measurements are *very* analogous to AI measurements.  Other counter operations less so.  (For example, there often isn't any Nyquist-like criteria to be concerned with.  Actually, that's pretty much true of encoder measurements as well.)

Just like an encoder task can *track* a position that changes must faster than it's being sampled, edge-counting tasks can also track edge counts much faster than they need to be sampled.  It usually isn't necessary to both count *AND* sample at extremely high rates.  Any time you do, you're gonna get incredible quantization effects with counts that vary only among 0,1, and 2.

-Kevin P

[BertMcMahan]

I am still working out the details of the application with the customer, but as I understand it now it's basically calculating pulses per second with increasingly small sample bins.

I will run this by my customer but it might be better to invert this a bit, and run one counter at a very high clock rate and use the input pulses as the sample clock source, thus timestamping when each individual pulse came in.

I can get the first data with the second approach but it involves a little more math. I will need to better understand the application before I can extrapolate too much further.

If you have some non-obvious thoughts on edge counting sampling I'd love to hear them. Thanks again for the input.

Edit: I checked your link and don't see the 6612 in there, it just has info on 63xx and 62xx. I'd guess it's at least comparable to an M series but I'm not certain.

[Kevin_Price]

The best comparison is the X-series 63xx boards.  They and the 6612 are both based around the DAQ-STC3 timing chip.

The "inversion" you talk about can be done directly as a frequency measurement task.  I typically use the so-called "1 counter low frequency" method.  There are a couple of 2-counter methods as well, although all they really do is use up a 2nd helper counter to divide down one of the fast signals on its way toward a regular 1-counter interval measurement.  (Granted, they also set up correct signal routing and measurement scaling, which makes them worthwhile.  But down at the low level, the same kind of interval measurement is happening.)

Even further, this new series of counters also supports a potentially intriguing mode (which I have no personal experience with) that allows for frequency measurement at a constant sample rate.

The desire for very small time interval bins to characterize very high pulse rates will head straight into the nasty quantization realm I was talking about.  In most cases, such a desire can be neither satisfied nor justified -- efforts should focus on educating the customer away from such desires rather than implementing a very poor approximation of what they wrongfully hope they can magically have.

We're in the digital realm and the only time instants available to provide information are digital transitions.  What does it even *mean* to try to take a 1 MHz digital pulse train and sample its frequency at 10 MHz?  1 of the 10 bins will see an active edge, 9 won't.  For every 10 samples, 9 would suggest that the freq is 0, 1 will suggest it's 10 MHz.  What's the point of collecting *that* kind of data?

The grumbling is meant as commiseration.  My advice though is to really press them on that point.  There's usually a conceptual disconnect or a lack of understanding/appreciation about the drastic quantization effects that lurk in such desires.  I think a lot of people are just used to analog sampling where an increase in sample rate gives you a *better* approximation of the analog signal.  When characterizing a digital frequency however, an increase in sample rate can lead to a much *worse* approximation.

Another one of the ways where working with counters is just *different* than regular AI,AO,DI,DO.

More info: Article 1, and Article 2

-Kevin P