Complete FFT re-implementation: (still has bugs)
- FFT assembly routines replaced with “no nonsense” integer C code
- All calculations made in-place (half the memory used)
- Now using 512 samples (256 buckets)
- FFT range boundary painted in blue
Still not exactly sure what you mean. Let’s see if I understand
I’m hiding the first fft bucket which should have the representation of the DC and close to DC components of the signal.
The actual “virtual zero” of the samples is not relevant for the FFT calculation, and I’m actually using all positive (8-bit) samples from the ADC bitshfited (<<3) into a 16bit signed int, which is what is used in the FFT input/output array. (further bitshifting is done in the fft code to avoid overflows).
I also got code working for doing the fft calculations using 8-bit, but the signal-to-noise ratio seems to be too low for good results, although it works. Can’t get a decent scaling working with that.
I thought you did. (From my tests, 8 bit calculations are simply not enough. - I got it working to try to save further memory, but it’s not good enough, so I’ll stick to 16 bits also).
What I don’t understand is when you say:
If you use 1024 samples, you can get 512 frequency buckets to display (one half of the mirror output).
How come you only get 256?
512 real samples can give you 256 FFT frequency buckets…
I actually had the scaling wrong by one bit. I’ll release a fixed version soon.
More FFT fixes
- Better timming (less flicker)
- Drawn over the curve (instead of merge)
- Accurate scalling (was of by one bit)
- All valid FFT buckets now displayed (bucket 1 is back from a vacation)
- Peak frequency marker (chip ripoff)
- Show FFT meters in the upper right corner:
- Nyquist (max range)
- Max: Predominant frequency in the sample
- Div: Frequency range per divison
- T1 : Frequecy at marker T1[/code]