[hpsdr] FFT latency

Simon Brown simon at sdr-radio.com
Tue Apr 7 01:06:38 PDT 2015


Peter,

You don't have to perform FWD / INV FFT in the demodulation path at all.
Essentially there are two IQ paths in a generic design:

1) For the waterfall / spectrum display,
2) For demodulation.

Demodulation can get down to < 20ms on Windows if you're careful, using
WASAPI audio API helps a lot :) .

Simon Brown G4ELI
http://v2.sdr-radio.com

-----Original Message-----
From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of G3XJP
Sent: 07 April 2015 08:21
To: Jay Salsburg
Cc: Hpsdr at lists.openhpsdr.org
Subject: Re: [hpsdr] FFT latency

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

Jay, this is the bit I don't get.  I think maybe this concern is what 
prompted me to ask the original question.   If the delay in an FFT is 
unavoidable and inherent, how does throwing more, better or dedicated 
hardware at it help in any way?   I can see how it would help release 
resources so you don't add to that inevitable delay.  cheers, Peter G3XJP

Jay Salsburg wrote:
> Yes, there is an unavoidable delay. What the SDR Software does is 
> perform the FFT on the Data stream coming from the Analog to Digital
Converters.
> Then, to hear the stream, an Inverse FFT is performed and sent to the 
> audio device. This delay may be reduced with better hardware and 
> dedicated SDR hardware to pre-process the data stream.
_______________________________________________
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/


 1428393998.0


More information about the Hpsdr mailing list