Jump to content

Measuring frequency that can be 0 Hz.


jlaudie

Recommended Posts

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...

Link to comment

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.

Link to comment

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.

Link to comment

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!

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.