<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Erik KM2G</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 8:23 AM, Tom McDermott <span dir="ltr"><<a href="mailto:tom.n5eg@gmail.com" target="_blank">tom.n5eg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Erik - <br><br></div>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.<br>
<br></div>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.<br>
<br></div>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.<br>
<br></div>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.<br>
<br><br></div>-- Tom, N5EG<br><br><div><div><br><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 10:38 PM, Erik Anderson <span dir="ltr"><<a href="mailto:erikba@odysseus.anderson.name" target="_blank">erikba@odysseus.anderson.name</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">***** High Performance Software Defined Radio Discussion List *****<div><div class="h5"><br>
<br>
<br><div dir="ltr">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.<div>
<br></div><div>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:</div><div><br></div><div>
(*) 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.</div>
<div><br></div><div>(*) I have found a hand-optimized assembly FIR implementation that assumes a 16-tap (single-precision) symmetric kernel ( <a href="http://www.virtualdub.org/blog/pivot/entry.php?id=307" target="_blank">http://www.virtualdub.org/blog/pivot/entry.php?id=307</a> ). 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.</div>
<div><br></div><div>(*) 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?</div>
<div><br></div><div>(*) 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.</div>
<div><br></div><div>Thanks as always for your help and enthusiasm in all this :-)</div><div><br></div><div>Erik KM2G</div></div>
<br></div></div>_______________________________________________<br>
HPSDR Discussion List<br>
To post msg: <a href="mailto:hpsdr@openhpsdr.org" target="_blank">hpsdr@openhpsdr.org</a><br>
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" target="_blank">http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org</a><br>
HPSDR web page: <a href="http://openhpsdr.org" target="_blank">http://openhpsdr.org</a><br>
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" target="_blank">http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/</a><br></blockquote></div><br></div>
</blockquote></div><br></div>