Measuring frequency that can be 0 Hz.

[jlaudie]

Classic problem. Never known the best way to get around this.

If you are measuring using a frequency DAQmx task, and you have a zero-frequency signal (no pulses--high or low the whole time), the DAQmx will wait the timeout and throw an error. What's the best way to deal with this scenario?

1) Ignore the error -- you're still stuck waiting for the timeout...

2) Count events? How would you pull a timestamp to then calculate your own frequency?

I've got to think that there's a slick way to do this and I'm just not aware of what it would be.

Thanks ahead of time...

[crelf]

QUOTE (jlaudie @ Sep 12 2008, 02:27 PM)

If you are measuring using a frequency DAQmx task, and you have a zero-frequency signal (no pulses--high or low the whole time), the DAQmx will wait the timeout and throw an error. What's the best way to deal with this scenario?

Yep - it's an age old problem - you can't measure the frequency of a signal that's period is larger than your timeout I wouldn't so much ignore the error, but filter it and output a number that represents the lowest frequency that your timeout allows.

[jdunham]

QUOTE (crelf @ Sep 12 2008, 12:37 PM)

Yep - it's an age old problem - you can't measure the frequency of a signal that's period is larger than your timeout I wouldn't so much ignore the error, but filter it and output a number that represents the lowest frequency that your timeout allows.

Crelf's implied point is that you should pick a timeout as short as you can, limited by the smallest frequency you care about measuring.

[crelf]

QUOTE (jdunham @ Sep 12 2008, 03:21 PM)

Crelf's implied point is that you should pick a timeout as short as you can, limited by the smallest frequency you care about measuring.

Indeed.

[fhinali]

QUOTE (crelf @ Sep 12 2008, 08:37 PM)

Yep - it's an age old problem - you can't measure the frequency of a signal that's period is larger than your timeout I wouldn't so much ignore the error, but filter it and output a number that represents the lowest frequency that your timeout allows.

A good way, I agree with you!

[Kevin P]

One tiny suggestion: when I've had a need for this kind of thing, there have been 2 or 3 ways to consider handling it.

1a. (Applies to an unbuffered freq measurement task.) Use a short timeout value. On a timeout error, clear the error and report 0 freq for that software query interval. Attempts to report the instantaneous freq *right now*. In absence of pulses, 0 Hz is a reasonable estimate.

1b. (A variation of 1a for certain kinds of apps.) On a timeout error, clear the error and report the most recent successfully-measured freq, which you could store in a shift register. Reports the freq of the most recently observed actual pulse.

2a. (Applies to a buffered freq measurement task with continuous sampling.) More complicated, but has its uses. Sometimes I want to do some averaging or trending across the most recent N freq measurements. I configure the task so that the Read call returns the N most recent samples. If there are no new ones from one loop iteration to the next, I'll end up reporting the same old (stale) average.

2b. (A variation of 2a.) I may choose to query the task for the TotalSamplesAcquired on each pass through the loop. Then I can do different stuff if I notice that value remaining constant over several iterations. In rare cases, I may even combine that total with a query for the software msec tick count as a cruder measure of recent average pulse rate. It can help as a sanity check sometimes.

-Kevin P.