Go Down

Topic: FHT processing appears VERY noisy (Read 5686 times) previous topic - next topic

jremington

#15
Jan 07, 2015, 05:23 pm Last Edit: Jan 07, 2015, 11:28 pm by jremington
AnalogRead() does nothing other than take the input from the ADC directly, so it is very hard to see how that could possibly yield any different result than the method used the OpenMusicLabs code.
The unrighteous man findeth no place to lay his head.

tmd3

I can't think of any reason that using analogRead(), as opposed to the hardware-clock-triggered free-running ADC, would improve the results of the FFT.  analogRead() triggers each conversion in software, and it's therefore vulnerable to latency while some ISR finishes executing.  At best, it won't have as accurate a timebase as the ADC's hardware clock.  The FFT needs a series of samples very evenly-spaced in time in order to provide accurate results.

Why is noise introduced when using Open Music Labs original code?
I'm still waiting for something quantitative to support that assertion.  Like, some input data and output data, showing a noisy result for a clean input.

aidvllasaliu

I can't think of any reason that using analogRead(), as opposed to the hardware-clock-triggered free-running ADC, would improve the results of the FFT.  analogRead() triggers each conversion in software, and it's therefore vulnerable to latency while some ISR finishes executing.  At best, it won't have as accurate a timebase as the ADC's hardware clock.  The FFT needs a series of samples very evenly-spaced in time in order to provide accurate results.
I'm still waiting for something quantitative to support that assertion.  Like, some input data and output data, showing a noisy result for a clean input.
Please read the old post I made, I have screenshots and videos posted there.

A lot of people seem to get noise.

jremington

#18
Jan 08, 2015, 04:07 am Last Edit: Jan 08, 2015, 05:24 am by jremington
I did read that old thread, and in fact contributed to it.

As far as I can see, nothing useful was gained from that long discussion. Many people misuse FFT routines, fail to use proper input filtering techniques or make other mistakes, then abandon the project and leave other people confused.

In particular, it was NOT shown in that thread that for a clean, properly filtered signal, use of AnalogRead() is "less noisy" than the analog read code built into the OpenMusicLabs routine.
The unrighteous man findeth no place to lay his head.

tmd3

A lot of people seem to get noise.
Maybe.  I still haven't seen anything quantitative and repeatable.

A lot of people seem to think that they get noise, because they:
  • Don't notice that the output data from the example code is logarithmic, rather than linear.  Low values show up a lot better on a logarithmic scale.  I think that users sometimes misinterpret the logarithmic representation of very low values as noise.
  • Don't notice that the example code applies a Hann window to the input data before performing the FFT.  The Hann window reduces spectral leakage for samples whose periods don't fit neatly into the sample frame, at the expense of some sharpness of spectral peaks.
  • Eliminate the windowing function to get sharp peaks, and then interpret spectral leakage in the FFT output as noise.
  • Don't know what spectral leakage is.
  • Think that a single-pole filter with a corner frequency at half the sampling frequency is adequate to eliminate aliasing.
  • Interpret aliased signals as noise.
  • Don't know what aliasing is.
  • Have an understanding of the FFT, the DFT, and the Fourier transform that's based more on folklore than on analysis.

My experience tells me that the Open Music Labs Fourier libraries work well, and provide accurate results within the limits of the fixed-point math they use.  If those libraries are faulty, I'd like to know, and I think that the rest of the community would like to know, too.  Show us unprocessed input data and faulty output output data, and describe what's wrong.  The community will repeat the experiment and verify your results.

Go Up