I donāt understand the behaviour of Pedroās FFT.
I use a 10kHz āsineā from the internal DAC, channel A with 0.5V/div, 100uS/div as an example.
[list]
[*]when I vary the amplitude of the sine, the spectrum changes completely. For example, at amplitudes of about 1.7V, the highest peak is at 20kHz, not 10kHz (and it is more then 2 div higher than the 10kHz)
[*]with an amplitude of 2.1V, the picture changes: now the highest peak is at 10kHz and 2 div higher than the 20kHz
[/list]
Maybe this has to do with the fact that only 256 samples are used, i.e. only about 10 periods and this is not enough - does the FFT only give good results when there is an integer number of periods in the 256 samples? Could this explain why the sines have so many harmonics?
I had another problem, which looks like a bug: when moving the ānavigator Bā, changing between the ātriggerā and the āauto/normā¦ā menus - but not changing anything at the settings - sometimes the FFT result change completely!!!
Two more questions: [list]
[*]if the number of samples is the problem, why not make an FFT with 4096 sample? Why is it more complicated than with 256?
The number of samples influences the resolution (frequency / x scale) of the FFT.
Canāt increase the number of samples at the moment because of the increase in program size/storage needs:
TTF coef_table - about 4KB more
the input and output arrays - about 6KB more
Iāve replaced the Hanning window lookup table with a function to generate the relevant indexed values at request, but that still isnāt enough.
Program size is already somewhat large because GCC does not optimize the code as well as IAR - by far.
Anyway, the functions are in place for using either 256 or 1024 samples, and I can get the 1024 samples FFT running under some circunstances, but donāt think itās relevant enough to spend more of my time with it.
Anybody can compile it with 1024 samples FFT support by changing 2 lines of code and uncommenting the needed coef_table values. The code is all there.
If someone wants a better FFT program, a dedicated FFT build can easily be made without issues, that can use 4096 samples.
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]