Continuous frequency measurement : Are frequencies between successive pulses or over a gate duration

[SteveP]

For a DAQmx counter input task in Low Frequency with 1 Counter mode that measures frequency and is configured for Implicit continuous samples, are the frequencies in the DAQmx Read data array the result of converting the time between only two successive input pulses to frequency or are they the result of counting the number of input pulses over some measurement (gate) time and converting counts/time to frequency ?

The DAQmx Read number of samples per channel is set to -1 meaning DAQmx Read reads all the samples currently available in the buffer.

If the result of measuring over some time, how does one know that time ?  Is there a DAQmx property for that ?  Is it then necessary to only perform a DAQmx Read at a rate no faster than that time to ensure a new data value ?

If the task was changed to period measurement instead, does that mode return an array of periods between two successive input pulses ?

My input signal is about 6 Hz.  Create Channel minimum frequency is 2 Hz and maximum is 100 Hz.  USB-6343 X Series

[Kevin_Price]

1. The measured frequencies are times between each pair of 2 adjacent edges of the signal whose freq is being measured.  By default, the time is measured using an internal timebase.  DAQmx will pick a timebase for you based on the values you put in for minimum and maximum [expected] frequency during config.  (You can always override that automatic choice manually if needed.)

   Really, as far as I've ever been able to tell, the actual counter hardware is doing the exact same thing it'd do for period measurement. 

2. Implicit timing, by nature, isn't really knowable or settable ahead of time.  The time period represented by "all available samples" will be a cumulative sum of the individual intervals.

3. If you changed to period measurement, you'd get an array full of the same information about the time between successive input pulses.  DAQmx will just scale it to Hz for a frequency task or to seconds for a period task.  [I suspect, but haven't actually tried this, that if you did your DAQmx Read as a U32 array then you'd get the same exact numbers for either freq or period tasks.]

4. Oh wait, you have an X-series board.  I believe the X-series boards are unique in supporting a new counter measurement mode for frequency, period, or maybe both.  As I recall, you can measure actual intervals on the input signal, but also define a constant sampling rate which will buffer the most recent latched interval measurement.  This is a really neat and useful feature because it lets you sync freq/period measurements with other data acq tasks.  On the other hand, it doesn't suit every app due to the likelihood of missed or redundant freqs in the buffer.

-Kevin P, letting his freq flag fly

[SteveP]

I ended up testing this myself using the DAQmx Counter Measurements example Meas Dig Frequency-Buffered-Cont-High Freq 2 Ctr.vi and modifying it to be Low Frequency with 1 Counter and setting Samples to Read to -1 (so it would read all available samples).  I then used the Gen Dig Pulse Train-Finite.vi example in Generating Digital Pulses to create a fixed number of pulses as the frequency source.  I found that the measured frequencies array did respond to an input of just 2 pulses and gave the correct frequency.  Generating more than 2 pulses resulted in the frequency array containing the correct corresponding number of frequency values.

No timeout error was produced when there were no pulses being inputted.  This contrasts with the non-buffered Meas Dig Frequency-Low Freq 1 Ctr.vi example which did timeout.

I'm not sure if your comment #2 implies that Implicit timing results in only 1 measurement being returned, but my results contained separate individual measurements.  This is in keeping with the information in DAQmx Help under "Configuring a Time-Based Measurement in NI-DAQmx" found by searching for "implicit" which states : "After the acquisition begins, NI-DAQmx measures each consecutive sample of the input signal and stores the measurement in the input buffer."

It further states that some devices (which includes the X series) can return an average of their measurements through use of the EnableAveraging DAQmx Channel property.  This requires that Sample Clock Timing be used instead of Implicit timing.  Sample Clock Timing stores the individual measurements into the buffer upon the active edge of the sample clock.  This contrasts with that storage occurring upon the active edge of the input signal itself when using Implicit timing.

Steve

[Kevin_Price]

Sounds like you've got a good handle on things now.  My comment #2 wasn't meant to suggest that you'd get only 1 measurement, just that the amount of total sampling time represented by whatever # of samples you happened to read

out of the buffer would be the sum of all the interval times being read.   It's just that with implicit timing you couldn't

predict what that sum would be since it's entirely dependent on the incoming signal, which is expected to vary in frequency

or else why measure it?

Thanks for sharing the tidbit about X-series averaging -- I didn't know about that and it sounds like another nice feature.

-Kevin P