[hpsdr] new architecture - FFT front-end

[Erik Anderson]

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.

(*) 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.
(*) 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.
(*) You *may* be able to average multiple FFTs together to get an FFT
representing a longer time period (no extra frequency discrimination
though).
(*) 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)
(*) Averaging bins together *may* not have the intended effect of enlarging
bins; intra-bin frequencies don't behave as you would expect.
(*) 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


On Thu, Sep 4, 2014 at 9:23 AM, David Bridgham <dab at froghouse.org> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
>
>  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.
>
> 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.
>
> 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?
>
> I usually get about halfway through a DSP book before I get bogged down so
> maybe this is all covered in later chapters.
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help:
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20140904/a1f5e91d/attachment-0003.htm>