reducing noise of incoming data

[sayndesyn]

Thank you very much for the help Jim.  Seeing examples like that are a great way to learn.  I understand what you did and it may actually work for my application.  My original idea was to get one median point for every 1334 readings, and then one median point for the next 1334 readings and so on instead of having the median float as each row is replaced.  The machine operator would not notice any real time lag and instead of seeing jagged ups and downs he would see something a bit more smoothed out.  Mathematically I'm not sure which one would be more acccurate since the time period is going to be in ms.  I would think that your method would tend to lag behind a bit since as the wall thickness starts to climb and the numbers start to rise, until the larger numbers reach the halfway point the median would essentially remain the same.  Like I said though, this may not matter for this time period.  Gotta get it tested.  Thanks a ton, will post once I have some feedback.  Sam

[sayndesyn]

Although some more testing needs to be done, initial dry runs show that this is going to be an improvement for the operator of the drill.  I will chalk this one up as "solved".  Thank you very much for all of the help, it was invaluable.

[109865]

Hi sayndesyn,

   I am new to LabView and I have the similar problems to reduce the noise of the incoming data and averaging.I am interested to have a look on the attachement that posted by Jim few months ago. However,I could not find the attachment. Would you mind to post the example here again?It will be a big help from you.

Thank you.

Sue

[JeffL]

It seems to have been removed for some reason. We may be out of luck unless Jim posts back....

[WCR]

Sue,

A VI to compute a running median is attached, along with 2 sample input data files.  Set the "order" on front panel, then run VI.  The width of the moving window from which the median is computed is 2*order+1.  If you select input file "spiky_data.txt" you see that the median is not pulled off track by spikes in the data, the way the mean would be.  This is why the median is considered a more robust estimator.  Rerun the VI to see the effect of changing the order.  The block diagram shows that I convert the arrays to waveforms, and timeshift (advance) the median-filtered waveform by "order" samples before plotting.  This is to compensate for the delay introduced by the filter.  This would, of course, be impossible in a real-time application, since it is non-causal, i.e. it requires seeing into the future.  You can see that this compensation works by using the example data file straightline.txt: note that the filtered and unfiltered waveforms are aligned. If you change the block diagram to make the timeshift=0 instead of "-order", then rerun, using straightline.txt as input, you can see the effect of uncompensated delay in the median-filtered waveform.

Bill 

[WCR]

Sue ,

I should have said "rank" in place of "order" in previous post.  A screenshot of a simpler version of the previiously-attached VI is attached.  This simpler VI does not have delay compensation and therefore the arrays are not converted to waveforms.

Bill