To fine-tune your measurement plan and tradeoffs, it's important to have a clear understanding of the way NI's counters work. This is part of the counter learning curve -- some things are less obvious due to several ways that counters aren't fully analogous to the other kinds of DAQ I/O (AI, AO, DI, DO).
If you read ZYOng's linked article (and followed some of the links inside), you'll have seen that there are tradeoffs among the different frequency measurement methods when it comes to accuracy, resolution, and sample rate.
A "dirty little secret" that is less publicized is that a simple 1-counter frequency measurement can usually be post-processed to produce the kinds of tradeoffs seen for the 2-counter methods. I cut my teeth on counters when MIO devices only had 2 counters, so I learned to use 1-counter methods whenever possible. However, it isn't always possible.
I know I've written up the tradeoffs between quantization error and sample rate many times over the years, here's one fairly recent example. (And maybe read more of the thread for fuller context).
Another important concept to get really clear about is the difference between "counting speed" and "capture rate". Henrik confirmed a real-life ability for the hardware to register incremental counts at rates in the 10's of MHz. When X-series counter tasks count their own internal clock, they can count at 100 MHz.
But that's *different* from the capture rate your device and data bus can sustain for the lifetime of a task. Capture rate has to do with latching and storing a count value into a DAQ device FIFO, then relying on the hardware and your data bus to deliver those captured values into the task buffer held on your PC. Sustainable capture rate will tend to be reduced for "less direct" data bus connections like USB and Ethernet as compared with PCIe or PXIe.
Pulling it all together, the best measurement approach for you will depend on some things you haven't clearly defined.
- What is the max pulse rate expected from your detectors? (If high relative to the DAQ's 100 MHz clock, this could affect choice of measurement method)
- How many pulses might you get in such a high-rate burst? (If both frequency and quantity are high, your USB data bus may be a limiting factor)
- What's the longest measurement interval you can live with if you have to get an average pulse rate during high-frequency bursts? (For example: would it be sufficient to characterize the average rate across a 10 microsec interval? Or would you truly need to get 10 distinct 1-microsec interval measurements during that 10 microsec interval?)
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
