Average of FFT

[MatejCZE]

Hello,

I have spindle vibration measurement data from 1 speed laser probe and 3 accelerometers - time zone recording. Sampling frequency 51.2kHz. Making an FFT from an entire record is easy, but now I need to split the time signal into shorter sections and make them an FFT that will be averaged. Theoretically, noise should be suppressed and only significant frequencies should excel, but unfortunately this is not the case for me, I am losing resolution because I am loading a smaller number of samples.

I would like to achieve this as this gentleman:

https://www.youtube.com/watch?v=PHOwO2ZoDXs&t=155s

Thank you for your advice!

There are a lot of samples, so I apologize for the way I attach the file:

                                      https://www.uschovna.cz/zasilka/TS7N3U33DGX644Z5-UZ9/

[RavensFan]

Of course you'll have lower resolution.  Resolution is a function of the number of samples.  When you break up a longer period of time into multiple shorter periods, there are fewer samples in each one and thus the resolution of the frequency bins is worse.

What is the source of the noise?  Can you apply a filter to it, either in hardware, or software?

If you want to attach something, don't link it to some 3rd party foreign website.  Attach it to your message as a zip file.

[MatejCZE]

I apologize, here's the file with less data.

These are the spindle vibrations of the three-axis machine tool, the source of noise can be a lot of things, as well as important information about the technical condition of bearings contained in the signal, at least what I know (or not?). Vibration of bearings is usually in the whole spectrum of frequencies, so I don't want to add a filter to lose some of them.

[cbutcher]

It might not really be what you want to hear, but you could just decide what resolution you'd like, calculate the appropriate duration of sampling, then repeatedly sample that length?

It will of course take longer, but if you're running this somewhat continuously you're likely to still be able to get nice averaging, no?

[Kevin_Price]

I can't open your file as I'm not on LV 2019 yet.

Is this question purely about using LabVIEW to do post-processing on a data file produced elsewhere?  Or do you have a LabVIEW program that acquires the signals *AND* does the processing?  I know some "sneaky tricks" with DAQmx that might prove useful. 

There are ways to collect data via "sliding window" that overlaps in time with the previous one.   This could allow you to update your FFT calc fairly often while running it on a longer time chunk of data (thus giving you finer freq resolution).

If you want 0.1 hz resolution, you need to operate on 10 sec worth of data.  That's just the FFT math and there's no way around it.  But you *could* retrieve a mostly-overlapping set of 10-second chunks every half second if you'd like.   Realize though that there's no free lunch here.  Each half second update would contain only 5% different data than the previous update.  The effect has some similarity to averaging, though definitely not the same mathematically.

This link (and the one it points to) should help explain and illustrate a bit more.

Actually, you can choose to do the same kind of sliding window if your app is only applying post-processing to data produced elsewhere.

-Kevin P

[MatejCZE]

Yes, I have the LabVIEW program that acquires the signals and does the processing, BUT I prefer achieve sliding window in postprocessing on the data I already have, I will be grateful for the advice (reconnecting VI v2012).

Basically, I want to have the same program as the guy on the video I posted. To allow the user to choose from the length of the time period (hence the number of averages) and sliding window (I call it overlaping in my VI). It's all in the VI that I'm sending.

[Kevin_Price]

I'm finally getting back to this.  I skimmed a brief sample of the linked video and did a couple trial runs of your posted code.

- The way you calculate your overlap seems to be correct from the little bit of spot-testing I did

- Overall, your code is still set up to produce 1 single average FFT across the entire time of capture

- If I understand right, I think you want to produce several distinct average FFT results that give more of a time history of behavior from beginning to end of capture

- As a first step, maybe you can just open your FFT express vi and configure it to do averaging.  Note: I'd recommend RMS averaging, *not* vector averaging.  Use a shift register or feedback node to feed its "averaging done" output back to the "restart averaging" input.   You could also send the spectrum output to a conditional indexing tunnel on the loop, wiring "averaging done" into the conditional.

   That'll give you an array of average FFT's.  I'm not totally sure what you want to do next, but this gives you the data to do it.

-Kevin P