<div dir="ltr">I'm still learning when it comes to DSP (as is evident from other threads in this list), but this is what I understand of FFT. Most of the "may"s are likely thought experiments that I haven't yet confirmed here or in textbooks.<div>
<br></div><div>(*) An FFT is fundamentally calculating an approximation (average intensity of a frequency over the frame) so there is some information loss when calculating an FFT.</div><div>(*) The larger the size of the FFT the more time it represents, but the more frequencies it can display (1 sec = 1 Hz). A larger FFT frame will be more sensitive to slower/longer signals, a shorter FFT frame will see more transient signals.</div>
<div>(*) You *may* be able to average multiple FFTs together to get an FFT representing a longer time period (no extra frequency discrimination though).</div><div>(*) You *may* be able to subtract two overlapped FFTs from each other to get one representing a shorter period of time (as long as you don't use a window function, or use one built assuming you will be subtracting the FFT results)</div>
<div>(*) Averaging bins together *may* not have the intended effect of enlarging bins; intra-bin frequencies don't behave as you would expect.<br></div><div>(*) Frequencies that occur between two different "bins" in an FFT operation are smeared across *several* neighboring bins, possibly a significant chunk of the results. Window functions are applied before the FFT operation to reduce the appearance of frequencies that are introduced by breaking a continuous stream into frames. Keep in mind that signals before the beginning and after end of the frame you're passing into the FFT are zero, window functions are there to avoid calculating the frequencies of a square wave<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 9:23 AM, David Bridgham <span dir="ltr"><<a href="mailto:dab@froghouse.org" target="_blank">dab@froghouse.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">***** High Performance Software Defined Radio Discussion List *****<br>
<br>
<br>
<div bgcolor="#FFFFFF" text="#000000">
<font face="Times New Roman, Times, serif">I've been mulling over
this idea of using the Jetson board to do an FFT of the entire
(mostly) sample stream to then make the frequency-domain signal
available to applications. Seems very intriguing and I love
hearing about entirely new ways of approaching problems.<br>
<br>
I'm curious though. When designing a codec, one chooses the
parameters for the FFT very carefully. The sampling rate is given
to you by the sample stream coming in (though you may decimate to
change that) but you pick the size of the FFT, the overlap between
blocks, and the window function all to make the FFT bins show up
just how you want them.<br>
<br>
With this new architecture, all those choices are made up front
and all the codecs running behind it have to use them. So my
question is, is there a way in the frequency domain to convert
from one to another? Can you simply average a bunch of FFT bins
together to get larger bin sizes and interpolate between bins if
you want smaller? Or do you have to do an IFFT back to the time
domain and then FFT again to change anything?<br>
<br>
I usually get about halfway through a DSP book before I get bogged
down so maybe this is all covered in later chapters.<br>
<br>
</font>
</div>
<br>_______________________________________________<br>
HPSDR Discussion List<br>
To post msg: <a href="mailto:hpsdr@openhpsdr.org">hpsdr@openhpsdr.org</a><br>
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" target="_blank">http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org</a><br>
HPSDR web page: <a href="http://openhpsdr.org" target="_blank">http://openhpsdr.org</a><br>
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" target="_blank">http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/</a><br></blockquote></div><br></div>