LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Frequency Noise

Solved!
Go to solution

Hi, trying to acquire a frequency from a flow sensor.  I'm trying to figure out why my signal doesn't have a more "flat" line.  I currently believe the Daq card is seeing false triggers.  If I direct couple a function generator to the Daq card I get a flat line with very little ripple.  I have tried several different flow meters all with similar waveforms.  I have tried to provide the flow sensor with steady flow to eliminate flow fluctuations.  I have created a simple program to demonstrate my issue.  DAQ Assistant is configured for a "1 counter Low frequency" measurement method.  I have been averaging the signal and that helps a lot.  I also added a Schmitt trigger circuit before the Daq card.  It had almost no effect on the waveform.  Is there a better way to do this from a software standpoint?  Or hardware?  I have attached a screen shot of the current setup and waveform.

Current setup;

Labview 2010

cDAQ-9178

NI9401

 

Thanks

Ryan

0 Kudos
Message 1 of 14
(3,999 Views)

Hi Ryan,

 

I have been averaging the signal and that helps a lot.

That's not "averaging", when you use the MEDIAN function!

Use a (running) average function instead!

 

I'm trying to figure out why my signal doesn't have a more "flat" line

Why do you think you will get the very same flow value (aka pulse count) from your sensor?

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 14
(3,984 Views)

The LabVIEW corollary of "A Picture is Worth 1000 Words" is "A VI is Worth 1000 Pictures".  Please post your VI.  That will let us see what you are trying to do inside the Dreaded DAQ Assistant.

 

Sometimes when you get results that you don't understand from Data that you also don't understand, it helps to write a simple Simulation, using a random number generator (or one of LabVIEW's Signal Generators) to create a "simple" signal on which you can do analysis.  This can often show you silly mistakes in the analysis (such as the difference between "Mean" and "Median").

 

Bob Schor

Message 3 of 14
(3,955 Views)

Changed the "Median function" to a "Mean function" that was an oversight on my part.

 

As for the varying pulse count I'm not sure exactly what to expect from the flow sensor.  I just wanted to be sure I was doing everything I could on my end.  I was comparing the output values from Labview and an off the shelf flow meter display.  The flow meter display shows less variance in flow rate.  I'm sure the off the shelf flow meter display has filters, etc to help with this at least more so than my simple program in Labview has.

 

So can I conclude this varying pulse count is coming from the flow meter?

 

Thanks again.

Ryan

Message 4 of 14
(3,954 Views)

What kind of flow meter do you use and how can you configure the output?

How often do you need to update the flow value? I think you are updating to often!

 

I work quite a bit with flow meters and Labview.

Ideally I would use a flow meter with a digital bus, ie modbus. 😃

If that is not present, I would use a flow meter with analog output (due to simplicity, given the accuracy of common flow meters this is often enough).

If that is not present, I would use digital signals but then I would use pulses and simply count the pulses. Of course you need to use a sensible update interval and some smoothing. Flow meters with digital indicators often use a couple of seconds themselfs to smooth out the signal. Read the manual and see for yourself.

Message 5 of 14
(3,934 Views)

@ry78 wrote:

As for the varying pulse count I'm not sure exactly what to expect from the flow sensor.


Ryan,

     The above sentence sums up the main issue -- you need to know what to expect from the flow sensor!  Have you looked at the signals with an oscilloscope?  Does the flow meter manual tell you useful things?  I'm guessing (based on how you've set up the Dreaded DAQ Assistant, a.k.a DDA, thanks for providing it) that it produces a TTL Pulse Train ranging from 2 to 300 Hz, right?  Do you need to do anything to transform these frequency values to flow?

 

The other thing is that your code shows a loop wired to two charts.  However, the DDA seems set to give you a single sample each time it is called, and your While loop has no obvious timing control, so who knows how fast these points are going to come in.  I see you are using the DDA's Evil Twin, the Dynamic Wire, so there's another mystery, but if the wire contains a single sample, there's no reason that ... oh, you are doing a Point-by-Point Mean, my mistake.  Do you know about GIGO (Garbage In, Garbage Out)?  [Doesn't quite apply here, I suppose].

 

Bob Schor

Message 6 of 14
(3,933 Views)

perhult, this flow meter has a voltage (0-5 Vdc) and frequency (0-5 Vdc square wave, 0-203 Hz) output.  From the (Analog) oscilloscope the signal looks good although the frequency does vary slightly.  I'm averaging about 6% error in flow rate with the frequency method.  (I haven't tried the voltage side)  I was looking at ways of reducing this error if possible.  This particular flow meter typically averages 1-2% error with my other flow control hardware.  These are my least accurate sensors.  I have tried my more accurate flow meters on this Labview program and average 0.5-1% error.  With those more accurate flow meters I can typically achieve 0.03% error on other dedicated hardware.

 

I'm trying to understand what I have to do to achieve these higher accuracy's in Labview.  I can look at slower update rates.  How would you "smooth" the signal?  I choose an averaging method but maybe that's not going to work.  I'll also try the count pulses method.

 

I created a simple program that uses 2 flow sensor inputs to control 2 pump motors.  Please ignore the first program I was using, that was for diagnostic purposes only.

 

Thanks

Ryan

 

0 Kudos
Message 7 of 14
(3,927 Views)
Solution
Accepted by topic author ry78

Among other things, this is an exercise in understanding the concepts of Precision, Accuracy, and Time-Varying behavior.  Here's what I mean:

  • Suppose you take pulse data for one second.  Since your device delivers pulses from 0 to 203 Hz, if you are "off" by one pulse, you will have an 0.5% error.
  • Now suppose your "signal" is varying very slowly, if at all.  You sample 1 second at a time, so each time point has 0.5% error.  If you are "unlucky" and your signal sits right as the number of pulses goes from, say, 100 to 101 pulses, you will have a "noisy" one-bit signal.
  • You can get rid of some of this "sampling" noise by averaging over longer time periods.  The tradeoff is that averaging tells you the value "averaged over this time interval", i.e. it trades off precision in knowing the value (the "What") for precision in knowing the time (the "When").
  • A reasonable way to decide sampling periods and frequencies is to ask about the expected time variation (and required accuracy) of your signal.  Just remember that the longer your averaging period (which determines the precision with which you make your measurement), the less precise is your estimation of the time variation of your signal.  One way to think about this is to think about your system making a step response (i.e. going from a constant value of X1 to a new constant value of X2).  If you average over a second, you can estimate to the nearest second when the transition occurred, but if you average over a minute (and thus get more accurate estimate of X1 and X2), you'll only know the "When" to the nearest minute.

Bob Schor

Message 8 of 14
(3,883 Views)

Bob,

     After reading your post I looked at a few things differently.  Could I say from my original "Labview Clip" picture the varying frequency I see is not so much "electrical" noise but more or less the variance in wheel speed within the sensor itself + some possible counting error?  If I understand correctly and take it a step further, I see about a 3 hz peak to peak difference in the waveform.  For example 34hz/37hz= approx. 8% wheel speed variance (mechanical error) + possible frequency count error.  If this is true that would explain why my better flow meters show less error. (mechanically better constructed)  

Interesting, have some things to look at now.

 

Thanks

Ryan

0 Kudos
Message 9 of 14
(3,872 Views)

I am used to much larger inductive flowmeters with integrated displays. They always have internal electronics which takes care of the signal processing to produce a stable output signal (whether it is a digital or analog signal)

It sounds like you are using a wheel flow meter without any internal signal conditioning. Then you will need to construct the signal conditioning yourself as Bob has explained.

0 Kudos
Message 10 of 14
(3,853 Views)