FFT vs Welch vs STFT: 10Hz Bearing Speed Benchmark

Welch Took 3.4x Longer Than FFT — But Found the Fault

I ran the same 10-second vibration signal through FFT, Welch’s method, and STFT to see which could catch a bearing fault while staying under 100ms latency. FFT finished in 0.8ms. Welch needed 2.7ms. STFT with 256-sample windows hit 5.1ms.

But here’s the twist: FFT’s spectrum was so noisy I couldn’t tell inner race fault peaks from background rumble. Welch smoothed it just enough to see the 162 Hz BPFI modulation riding on a 3600 RPM shaft. STFT showed me when the fault amplitude spiked during load changes — something the other two couldn’t.

This isn’t an academic comparison. It’s what happens when you wire up a MEMS accelerometer to a $40 bearing test rig, sample at 10 kHz, and try to ship a fault detector that runs on a Raspberry Pi 4 without choking.

Why Speed Matters in Vibration Monitoring

Most PHM textbooks skip the compute budget conversation. They show you gorgeous spectrograms from MATLAB, then you try to run the same analysis in a PLC loop and blow your 50ms cycle time.

Real-time bearing monitoring means:
– Edge deployment (Raspberry Pi, Jetson Nano, or worse — a $15 ESP32)
– 10-20 kHz sampling rate (Nyquist demands it for bearing faults above 5 kHz)
– 50-100ms analysis window to catch transients before they disappear
– Multi-channel processing if you’re monitoring more than one bearing

The CWRU bearing dataset everyone benchmarks on? Pre-recorded, clean 12 kHz signals you can batch process overnight. Your production line gives you 16-bit ADC noise, motor hum at 60 Hz, and a plant manager asking why the monitoring system is “laggy.”

I’ve covered sensor setup mistakes that kill spectra in FFT Shows No Peaks: 4 Sensor Setup Mistakes That Kill Spectra — this post assumes you already have decent signals.

The Test Setup: 10 Hz Bearing, 10 kHz Sampling

I used a 6203 deep groove ball bearing on a test bench running at 600 RPM (10 Hz shaft frequency). An ADXL345 MEMS accelerometer mounted radially, sampled at 10 kHz via USB.

Key parameters:
– Bearing: SKF 6203 (7 balls, 8mm diameter, 22.85mm pitch diameter)
– Shaft speed: 600 RPM = 10 Hz
– BPFI (inner race fault): $f_{BPFI} = \frac{n}{2} f_s \left(1 + \frac{d}{D} \cos \alpha \right) = 16.2 \times 10 = 162$ Hz
– BPFO (outer race fault): $f_{BPFO} = \frac{n}{2} f_s \left(1 – \frac{d}{D} \cos \alpha \right) = 10.8 \times 10 = 108$ Hz
– Sampling rate $f_s = 10000$ Hz
– Record length: 10 seconds (100,000 samples)

The bearing had a seeded inner race fault (0.18mm EDM notch). Healthy reference data came from the same rig before fault seeding.

FFT: The Obvious First Try

NumPy’s fft.rfft is the go-to for frequency analysis. One function call, done.

import numpy as np
import time

# Load 10-second vibration signal (100k samples @ 10 kHz)
signal = np.load('bearing_10hz_inner_fault.npy')  # shape: (100000,)
fs = 10000  # Hz

def benchmark_fft(signal, n_runs=100):
    times = []
    for _ in range(n_runs):
        start = time.perf_counter()
        spectrum = np.fft.rfft(signal)
        power = np.abs(spectrum) ** 2
        end = time.perf_counter()
        times.append((end - start) * 1000)  # ms
    return np.mean(times), np.std(times), power

avg_time, std_time, fft_power = benchmark_fft(signal)
print(f"FFT: {avg_time:.2f} ± {std_time:.2f} ms")
# Output: FFT: 0.82 ± 0.09 ms

0.82 milliseconds. That’s 122x faster than my 100ms budget. Problem solved?

Not quite. The raw FFT has $\frac{N}{2} + 1 = 50001$ bins with 0.1 Hz resolution. At low frequencies (0-500 Hz where bearing faults live), the spectrum is a forest of noise spikes. Shaft harmonics at 10 Hz, 20 Hz, 30 Hz blend into belt resonances, motor EMI, and digitization noise.

I couldn’t visually separate the 162 Hz BPFI peak from background garbage. SNR was maybe 3-4 dB. Automated peak detection would drown in false positives.

Welch’s Method: Trading Speed for Clarity

Welch’s method (Welch, 1967) splits the signal into overlapping segments, windows each one, computes FFTs, then averages the power spectra. The averaging kills uncorrelated noise.

The price: multiple FFT calls.

from scipy.signal import welch

def benchmark_welch(signal, fs, nperseg=2048, noverlap=1024, n_runs=100):
    times = []
    for _ in range(n_runs):
        start = time.perf_counter()
        freqs, psd = welch(signal, fs=fs, nperseg=nperseg, 
                           noverlap=noverlap, window='hann')
        end = time.perf_counter()
        times.append((end - start) * 1000)
    return np.mean(times), np.std(times), freqs, psd

avg_time, std_time, freqs, welch_psd = benchmark_welch(signal, fs)
print(f"Welch (2048 samples, 50% overlap): {avg_time:.2f} ± {std_time:.2f} ms")
# Output: Welch (2048 samples, 50% overlap): 2.74 ± 0.18 ms

2.74 milliseconds. 3.3x slower than FFT, but still well under budget.

The Welch PSD had 1025 frequency bins (half of nperseg=2048). At 162 Hz, the BPFI peak stood 12 dB above the noise floor — clear enough for scipy.signal.find_peaks to tag it without tuning threshold gymnastics.

But here’s what I lost: with 50% overlap on 2048-sample segments, I’m averaging ~97 FFT windows. That wipes out any short-duration transients. If the fault only shows up during load spikes (common in gearboxes), Welch would smooth it into oblivion.

STFT: Seeing Faults Evolve Over Time

Short-Time Fourier Transform slides a window across the signal and computes FFT at each step. You get a 2D spectrogram: time on the x-axis, frequency on the y-axis, power as color.

from scipy.signal import stft

def benchmark_stft(signal, fs, nperseg=256, noverlap=192, n_runs=100):
    times = []
    for _ in range(n_runs):
        start = time.perf_counter()
        freqs, times_stft, Zxx = stft(signal, fs=fs, nperseg=nperseg,
                                       noverlap=noverlap, window='hann')
        power = np.abs(Zxx) ** 2
        end = time.perf_counter()
        times.append((end - start) * 1000)
    return np.mean(times), np.std(times), freqs, times_stft, power

avg_time, std_time, freqs, t_stft, stft_power = benchmark_stft(signal, fs)
print(f"STFT (256 samples, 75% overlap): {avg_time:.2f} ± {std_time:.2f} ms")
# Output: STFT (256 samples, 75% overlap): 5.12 ± 0.31 ms

5.12 milliseconds. 6.2x slower than FFT, but still comfortable.

The spectrogram had 129 frequency bins × 1563 time bins. At 162 Hz, I could see the fault amplitude ramp up around t=3.2s and t=7.8s — exactly when the motor controller logs show load current spikes. FFT and Welch averaged those moments away.

STFT’s weakness: frequency resolution. With nperseg=256 at 10 kHz sampling, each bin is $\frac{10000}{256} = 39$ Hz wide. If I had two faults 20 Hz apart (say, BPFI and cage frequency), they’d blur together. Welch’s 2048-sample window gives 4.9 Hz bins — 8x sharper.

The Numbers Side by Side

All benchmarks on Raspberry Pi 4 (1.5 GHz Cortex-A72, single-threaded NumPy 1.24.3, SciPy 1.10.1). No GPU, no SIMD tricks.

When FFT is Enough (And When It Isn’t)

FFT wins if:
– Your signal is stationary (bearing speed constant, no load changes)
– SNR is already high (isolated test bench, low motor noise)
– You need absolute speed (embedded systems with <10ms budgets)
– You’re doing envelope analysis later (bandpass → Hilbert → FFT of envelope)

FFT fails when:
– Noise floor is high and you can’t average (single-shot diagnostics)
– The fault is intermittent or load-dependent (STFT would catch it)
– You’re comparing spectra across conditions (Welch’s variance reduction helps)

I’ve seen FFT-only systems false-alarm on motor startup transients because they couldn’t tell the difference between a 0.1-second vibration spike and steady-state fault energy. STFT would’ve shown the transient as a brief vertical streak.

Welch’s Sweet Spot: Batch Diagnostics

Welch is my default for offline analysis:
– Post-processing test stand data (you have time, want clean spectra)
– Building a baseline PSD library for healthy bearings (variance matters)
– Comparing before/after maintenance (need consistent SNR across runs)

The overlap and windowing choices are black magic. I’ve found:
– 50% overlap (Hann window): standard trade-off, works 80% of the time
– 75% overlap: better for short records (<5 seconds), costs 1.5x compute
– nperseg=fs (1-second segments at 10 kHz): gives 1 Hz bins, great for separating close harmonics
– nperseg=2048: my go-to for 10 kHz data, balances resolution and averaging

One failure mode I hit: using nperseg=8192 on a 2-second record. Welch only averaged 3 windows. Variance reduction was weak, SNR barely improved over raw FFT. You need at least 10-15 segments to see the smoothing benefit.

STFT for Condition-Based Triggers

STFT shines when you need to answer “when did the fault appear?” not just “is there a fault?”

Use cases:
– Start/stop diagnostics: does the bearing fault show up only during acceleration?
– Load-dependent faults: gearbox mesh errors that vanish under light load
– Transient detection: impact events, oil whirl, cage instability
– Feature extraction for ML: feed STFT spectrograms into a CNN (common in PHM competitions)

I’m not entirely sure why, but noverlap=nperseg*3/4 (75% overlap) consistently gives cleaner spectrograms than 50%. My best guess: with shorter windows (256-512 samples), you need denser time sampling to avoid smearing transients across bins.

One gotcha: STFT output is complex-valued. If you forget np.abs(Zxx)**2, you’ll get phase-contaminated garbage. I’ve debugged that twice.

What About Real-Time Constraints?

All these benchmarks assume batch processing: you record 10 seconds, then analyze. Real-time CBM is different.

Streaming FFT:
Run FFT on each new buffer (say, 2048 samples = 204ms at 10 kHz). Update a rolling average PSD. This is basically DIY Welch. On a Pi 4, you’d budget ~3ms per buffer, leaving 200ms for other tasks.

Circular buffer STFT:
Keep a sliding 5-second window in RAM. Every 100ms, shift 1000 samples out, slide 1000 new ones in, recompute STFT on the updated window. Heavier (5ms compute every 100ms), but you get near-real-time spectrograms.

Hardware acceleration:
The Jetson Nano’s GPU can FFT 2048-sample chunks in 0.3ms using cuFFT. STFT becomes nearly free. But you pay with power draw (5W vs Pi’s 3W) and cost ($99 vs $35). For a 50-bearing factory line, that’s $3200 vs $1750.

I haven’t tested this at scale, but I suspect the memory bandwidth (shuffling 100k samples/sec from ADC to CPU) becomes the bottleneck before FFT compute does.

The Hybrid Approach I Actually Use

In production, I run a two-stage pipeline:

1. Fast FFT screening (every 200ms):
   Compute FFT on the latest 2048-sample buffer. Check if RMS or peak frequency exceeds a threshold. If clean, discard. If suspicious, flag for stage 2.

2. Welch confirmation (on-demand):
   Buffer 5 seconds of data (50k samples). Run Welch with nperseg=2048, 50% overlap. Extract BPFI/BPFO peaks, compute health index, log to database.

STFT only runs during diagnostics (manual trigger from Slack) because I don’t need time-frequency maps in the monitoring loop. But when a bearing fails and the client asks “when did it start?”, I replay the last hour through STFT and show them the exact moment the fault energy crossed threshold.

This keeps CPU load under 8% average (spikes to 25% during Welch runs). The Pi 4 handles 8 accelerometers this way. Debugging at 2am while the system’s down? Dark Chocolate Espresso Beans keep me functional.

Edge Cases That Break the Benchmarks

Non-stationary speed:
If shaft speed varies (soft starter, belt slip, variable load), FFT bins smear. The 162 Hz BPFI peak becomes a 150-175 Hz hump. Order tracking (resampling to angular domain) is the fix, but that’s a whole other post. Welch and STFT fail the same way.

Aliasing from undersampling:
ISO 10816 says sample at 10x your highest fault frequency. For a 10 kHz roller element, that’s 100 kHz — way beyond most cheap ADCs. If you sample at 20 kHz and the fault is at 25 kHz, it aliases down to 15 kHz and ruins your spectrum. No amount of Welch averaging saves you.

Windowing artifacts:
Hann window has -43 dB sidelobe suppression. If a 10 Hz shaft peak is 50 dB stronger than a 15 Hz fault, the shaft’s sidelobes bury the fault. Blackman-Harris window (-92 dB sidelobes) helps but costs 2x spectral width. I usually stick with Hann unless I’m hunting a weak fault next to a strong tone.

FAQ

Q: Can I use FFT for real-time bearing monitoring on a Raspberry Pi?

Yes, but pair it with something else. Raw FFT is fast (sub-millisecond), but noisy. Run FFT for quick checks, then trigger Welch on suspicious buffers for confirmation. Don’t rely on FFT alone unless your SNR is already excellent (>15 dB).

Q: Why is my STFT spectrogram blurry even with 75% overlap?

Two common causes: (1) Your window (nperseg) is too short — shorter windows = worse frequency resolution. Try doubling it. (2) You’re plotting linear power scale instead of dB. Use 10*np.log10(power) for the colormap — it compresses the dynamic range and makes weak peaks visible.

Q: Does Welch’s method work with non-uniform sampling rates?

No. Welch assumes uniform spacing between samples. If your ADC has jitter or you’re resampling from an encoder (order tracking), use Lomb-Scargle periodogram instead. It’s 10-50x slower but handles irregular timestamps. SciPy has signal.lombscargle, though it’s not well-documented.

When to Pick What

Use FFT if you need the absolute fastest result, have high SNR already, or you’re doing envelope analysis (FFT is just step 1).

Use Welch when noise is a problem, you’re building a baseline library, or you’re comparing spectra across different runs. The 3x speed penalty is worth the 8 dB SNR gain in most industrial settings.

Use STFT if faults are transient, load-dependent, or you need to prove “when” something happened. It’s the slowest but gives you information the other two can’t.

And if you’re deploying on edge hardware, run the lightest method that still catches faults. I’ve seen systems burn 40% CPU on STFT when a simple Welch PSD would’ve worked fine — then the client complains about heat and wants a fan added to the enclosure.

The next thing I want to test: running all three in parallel on a multi-core ARM board (like the Jetson Xavier). In theory, you could FFT-screen on core 0, Welch-confirm on core 1, and log STFT on core 2 — all in real-time. I haven’t tried it because the Pi 4 isn’t beefy enough, but the math says it should work. If anyone’s done this, I’d be curious to see the thread contention results.