[hpsdr] FIR filtering and HPSDR

Tue Sep 2 12:43:09 PDT 2014

Okay, from what I'm hearing you say a 16-tap FIR implementation may be
about as many taps as I would ever want to use in a FIR; any more than that
and an FFT waveshape would be a better model.  Using a FIR with 1M+ taps...
sounds less like a fir FIR and more like an excuse for a waveshape.  Do you
actually bother to calculate the FIR kernel parameters at that point? I
apologize if I'm missing something obvious there.

I recognize that the parameters for a FIR (or any analog or digital filter)
are based on a tradeoff on the size of the transition band, sidelobe
height, passband ripples, and latency.  Assuming all implementations are
optimized enough to run at-speed, an FFT would have issues with a latency
related to the size of the frame: smaller frames would reduce latency at
the cost of frequency discrimination, larger frames improve discrimination
at the cost of latency and the ability to read more-transient signals.

Are there real-world examples of FIRs in use that I can get ideas about?
 The textbooks I'm reading all use examples of small-numbered odd symmetric
kernels.

Erik KM2G

On Tue, Sep 2, 2014 at 8:23 AM, Tom McDermott <tom.n5eg at gmail.com> wrote:

> 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/3932f3cc/attachment-0003.htm>