Repository navigation
Conversation
|
I'm not sure the maths still works correctly with alternate window sizes. |
|
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: 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. |
|
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. |
|
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: 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. |
"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%.