<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">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>