Skip to content

FilterReview: allow FFT window overlap to be changed for raw logs - #378

Closed
j-w9 wants to merge 1 commit into
ArduPilot:mainfrom
j-w9:filter-review-fft-overlap
Closed

j-w9 wants to merge 1 commit into
ArduPilot:mainfrom
j-w9:filter-review-fft-overlap

Conversation

@j-w9

@j-w9 j-w9 commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

"User configurable window overlap? Currently hard coded to 50%" from #10.

An "Overlap (%)" input in FFT Settings (0 to 90, default 50) sets the window spacing in run_batch_fft. Changing it clears the calculation like the window size does.

It only applies to raw logs, and is disabled for batch logs, which stay at 50%. In batch mode the window size comes from windows per batch and the overlap, and the current steps (1, 3, 7, ...) only give power of two sizes at 50%.

  • At 50% the spectra are identical to main on a raw (SITL) log and a batch log.
  • On the raw log, 25/50/75/90% give 111/166/332/834 windows for gyro 1. The noise floor stays at -99.9 dB and the main peak within 0.5 dB, as expected since each window is normalised.
  • The FFT Settings table now has three compact rows, so the Setup box height is unchanged.

Overlap input

@IamPete1

Copy link
Copy Markdown
Member

I'm not sure the maths still works correctly with alternate window sizes.

@j-w9

j-w9 commented Oct 24, 2026

Copy link
Copy Markdown
Contributor Author

I tried it with a known signal. I swapped the gyro data for a 0.1 amplitude sine at 97.66 Hz (on a bin, 1 kHz, 1024 window) plus white noise with sigma 0.01, and ran it at a few overlaps:

overlap  windows  sine     noise PSD   est. post (20 Hz LPF)
  0%       83     0.0999   -66.94      0.00394
 25%      111     0.0999   -67.01      0.00394
 50%      166     0.0999   -66.98      0.00394
 75%      332     0.0999   -66.97      0.00394
 90%      834     0.0999   -66.98      0.00394

The noise should be -66.99 dB/Hz (2σ²/fs), and 50% is identical to main. The mean is divided by the number of windows and the window correction only depends on the window shape, so overlap just changes how many windows get averaged. Batch logs stay at 50%, since the windows per batch steps only give power of two sizes there.

@IamPete1

Copy link
Copy Markdown
Member

Its been a while since I got into it, but i have in my head that the averaging over windows only gets the correct amplitude.

I guess the other question is if we did want to add support this what is the benefit and how should users use it.

@j-w9

j-w9 commented Oct 24, 2026

Copy link
Copy Markdown
Contributor Author

Fair point. This came from the overlap item on your #10 list, and after looking at it properly I don't think it's worth having. For a steady signal the amplitude is fine at any overlap, but 50% is where Hann windows add up evenly, so every sample counts the same. Go below that and you throw away the window edges, so it gets noisier. Go above it and nothing improves. Same test signal over a 54 s hover with a 1024 window:

overlap  windows  noise floor spread
  0%       53     0.60 dB
 25%       70     0.52 dB
 50%      106     0.43 dB
 75%      211     0.42 dB
 90%      530     0.42 dB

The only thing more overlap gets you is a finer-looking spectrogram, and shrinking the window does that properly anyway. I'll close this one, and I'd suggest taking the item off #10. If auto fit ever needs it, it can just be a function argument.

@j-w9 j-w9 closed this Oct 24, 2026
@IamPete1 IamPete1 mentioned this pull request Oct 24, 2026
9 of 16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants