06-12-2012 06:09 PM
Hi!
I'm trying to "hack" the annemometer from a cheap weather station. The thing spins with the wind and creates pulses. I first attempted to just get a direct frequency measurement but kept getting an error... so now I'm trying to do edge counting and math to figure out the frequency. What is frusterating though is that the numbers I'm getting in my LabVIEW program don't match the numbers I'm getting on my O-Scope.
My O-Scope is indicated about 7-10hz from edge-to-edge. I've confirmed this with the cursors.
My LabVIEW program is indicating between about 30 to 90 hz. I'm really baffled by this...I've checked my math and am not sure what the issue is and I fear that the issue may be noise related.... With the anemometer not moving at all, I get a flatline of 0hz (so at least I believe that....).
Although tempted to just calibrate what I have, I'm worried that if this is noise I need to fix it before doing any calibration.
I'm using counter 0 on a PCI-6025E card. Thanks for your input/help.
Here is a snippet of my code:
06-12-2012 06:14 PM - edited 06-12-2012 06:21 PM
Have you considered using a "frequency" type for the DAQ read and letting it do everything for you? Also, you don't know when your "milliseconds to wait" is executing which could be throwing something off.
Edit: that's probably your issue...the wait is not being factored into your time you are using to calculate, the rate yet the counter is still counting during that wait. Factoring this in would increase the time you are dividing by, thus lowering your rate.
06-12-2012 06:25 PM
Thank you for your reply.
Yes, I've tried to use the frequency counter and the values are more agreeable than my O-Scope, but it always seems to eventually crash with this message:
"Two consecutive active edges of the input signal occurred without a counter timebase edge. Use a faster counter timebase."
I suppose I could just configure it to re-start whenever it gets that message. I'm not sure what the "faster counter timebase" is. The annemometer isn't going to ever sync with my DAQ clock ;).
The "milliseconds to wait" VI is throttling the loop down to something reasonable (like once a second). I'm using that OpenG "Tick Count (ms)" vi w/ error terms in order to get a more accurate measurement of time between measurements.
06-12-2012 06:29 PM
In response to your edit:
Are you sure? The output of the difference between my current "Tick Count (ms)" and the last "Tick Count (ms)" (through the shift register) is giving me 1000ms which is what my Milliseconds to Wait VI is set to. There should be two threads going on too, so the execution should be in parallel.
06-13-2012 09:42 AM - edited 06-13-2012 09:43 AM
I connected the input of my counter and O-Scope directly into my functionality. The calculation from my code and from the O-Scope are agreeable.
So now I think the problem is probably noise related and am chasing that.
It would be good to know more about how the counter counts edges I think.
06-13-2012 10:00 AM
In addition have a close look at your output signal. Is is bouncing?
Some debounce features are included in the DAQmx ....
06-13-2012 10:22 AM
It looks pretty clean on my O-Scope from what I can tell... at least as clean as my function generator is anyway.
What kind of debouncing funcitonality does DAQmx have for counters?