[hpsdr] FIR filtering and HPSDR

[Tom McDermott]

Hi Erik -

1. The computational effort of FIR is Order(N squared) while the
computational complexity of FFT is Order(N log2 N). So, for large enough
filters, the amount of raw computation need to implement FFT filter is a
lot less than FIR. In Gnuradio, the crossover is under 20 taps, meaning a
20-tap FFT filter will require less CPU compute cycles than an FIR filter.
This is because FFT is extremely efficient.

2. The number of filter taps required is proportional to several things.
The steeper the filter roll-off, the more filter taps needed. The greater
the stop-band attenuation, the more taps needed.  The lower the fractional
BW, the more filter taps required.  For example, a decimator that reduces
the sample rate to 1/50 of the input rate needs a very low BW LPF at the
input, cutoff of 1/100 the sample rate. Assuming 60 dB stop band
attenuation, it needs about 650 taps.  For decimation there's a special
class of filters called CIC that reduce the complexity at the expense of
passband droop. You can play with filter shape vs. taps in any of several
different filter design programs. I use Gnuradio filter designer.

3. For matched-filter responses (for special applications) the number of
taps can be quite large. I'm currently using a matched filter with
1,048,576 taps. It is able to run in real-time on a PC at 384 ksps by using
an FFT filter. An FIR implementation would run slower by a factor of
roughly 100,000.

4. An FIR filter can have even or odd number of taps. There is a certain
class of applications such as baud-rate sampled filters where odd-taps is
very convenient. Other cases, even-number of taps is more convenient.


-- Tom, N5EG





On Mon, Sep 1, 2014 at 10:38 PM, Erik Anderson <
erikba at odysseus.anderson.name> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
>
> I haven't had time to keep up on this list for a while so I may have
> missed something, but with the long weekend I've had a little time to
> re-open my radio development project and push the ball forward a bit.
>
> My current focus is on FIR filter development and implementation (focused
> on signal extraction), and I do have some some questions from those that
> have been down this road regularly:
>
> (*) When I last mentioned FIR filters, I was told it would be faster to
> filter using FFT + mask + iFFT.  I'm not convinced where this is coming
> from; with an acceptable implementation the minimum latency is the decode
> latency (half an ethernet frame for me) plus the FFT latency (which could
> easily run 4k samples).  With a FIR the latency is decode plus the tap
> count.
>
> (*) I have found a hand-optimized assembly FIR implementation that assumes
> a 16-tap (single-precision) symmetric kernel (
> http://www.virtualdub.org/blog/pivot/entry.php?id=307 ).  I will likely
> break the symmetry so I can support a smaller (odd?) number of taps.  Is 16
> taps enough for most purposes?  I can't "double the recipe" here to get
> more taps without running out of x86 registers.
>
> (*) There is a FIR in Mercury that I'm assuming filters the results to fit
> within the specified frequency window.  Is there value in dividing my first
> FFT results by the Mercury filter's kernel, possibly canceling its effects
> and removing the need to clip the edges of the waterfall?
>
> (*) I'm curious as to what the kernel for the FIR in Mercury is, how many
> taps it uses, what windowing function was used to develop it, etc.  Mostly
> as an example to get an idea of what kind of deep water I'm getting myself
> into here.
>
> Thanks as always for your help and enthusiasm in all this :-)
>
> Erik KM2G
>
> _______________________________________________
> 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/20140902/5669a795/attachment-0003.htm>