[hpsdr] FFT latency

[Jay Salsburg]

There is a different way to do the time/frequency thing.

It is Spectrum Magnification. When Science and Engineering Applications
require accurate Frequency Spectrum, (time to frequency conversion), the
Fourier transform is chosen, usually by default because the Libraries and
Apps are so readily available. These tools use the discrete Fourier
transform (DFT) carried out by the now famous fast Fourier transform (FFT).
For many applications this may have adequate resolution, however, there are
applications especially in Radio and RADAR where determining spectral peaks
require great accuracy, the DFT is inadequate for this task. The typical
solution of increasing resolution using the FFT is to pad the samples at the
end of the sequence with extra zeros; is hampered by practical limitations.
This technique may allow the analysis to zoom in on tiny intervals of
interest, but at the cost of increased computations and aliasing
difficulties.

The desired analyzer is one that allows parametric resolution only over the
desired frequency range, allowing the display to move across the spectrum
with variable resolution, and bandwidth. Applying Euler's identity, a
recursive algorithm allows subspectrum analysis over a very small frequency
range at an arbitrary high resolution without zooming and aliasing problems.

This algorithm provides the following parametric interface:

F1 = starting frequency
F2 = ending frequency
Nf = number of frequency points
N = number of samples
SPS = samples per second

This techniques is not more efficient than the FFT in many applications,
especially when quickly processing (and displaying) wide bandwidth (50,000
foot view), but it is far more efficient, accurate, and faster (less
latency) when processing microscopic views, allowing accurate views of
peaks, valleys, and slopes without missing detail otherwise missed by the
FFT. The more narrow the frequency range, the more attractive is this
technique over the FFT. This is the technique you see being used in those
$100,000 analyzers.


-----Original Message-----
From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Jim
Barber
Sent: Sunday, April 5, 2015 11:44 AM
To: G3XJP at RhodesG3XJP.plus.com; Hpsdr at lists.openhpsdr.org
Subject: Re: [hpsdr] FFT latency

***** High Performance Software Defined Radio Discussion List *****

Oops... Make that "256-tap linear-phase FIR filter" in the below.

Jim N7CXI

On 4/5/2015 9:35 AM, Jim Barber wrote:
> The actual latency introduced by an FFT will depend on the overlap 
> used between frames.
> For very long FFT's with substantial overlaps it can be burdensome, yes.
>
> The reasons the FFT is used are for the most part performance, 
> convenience and sometimes because that's the "way that the other guys 
> did it". There are also algorithms that are inconvenient or difficult 
> to execute in the "time domain" - spectral subtraction noise reduction 
> being one.
>
> You can, of course perform filtering, demodulation and processing 
> routines strictly in the time domain. If you use linear-phase FIR 
> filters, the additional latency or delay for each filter added to the 
> chain is very close to N/2 samples. So for example, a 256-tap 
> linear-phase FFT filter in the audio section of the DSP @ Fs=48 kHz 
> will add
> ((256/2) / 48000) = 2.7ms delay.
> The equivalent delay using an FFT to execute the filter will be 
> longer. Specifying it exactly will start arguments, but it will indeed 
> be substantially longer.
>
> So... The first question that comes up is can you afford the 
> additional processing overhead?
> That calculation isn't simple, and is subject to implementation tweaks.
>
> Another thing you can do is use IIR filters where appropriate - audio 
> EQ's for speaker output channels and the like. They are 
> computationally efficient and add almost no delay - at the expense of 
> non-linear phase response, which you may or may not care about at a 
> given stage.
>
> My .02,
>
> Jim N7CXI
>
>
> On 4/5/2015 3:54 AM, G3XJP wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> I need your collective wisdom!  Is it not an inescapable fact that 
>> any serious FFT in the real-time path between your antenna and your 
>> ears must introduce an inherent and inevitable delay that will 
>> preclude a conversational VOX/QSK QSO?  I can see that it would not 
>> preclude listening to a monologue - or to watching spectral pictures 
>> on a display.  But anything more than about 1/5 sec is doomed to feel 
>> like Skype on a bad day - where you often end up having to say 
>> "over".  As a generality, am I missing something fundamental here?
>> Peter G3XJP
>> _______________________________________________
>> 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/
>

_______________________________________________
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/


 1428265259.0