No problem! Like Marcus says I definitely have to think hard about the implementation and benchmark... But it's an interesting special case. Would be neat with a special block for it that also calculates the coefficients.
--Albin
On Wed, Apr 24, 2019, 10:39 Derek Kozel <derek@bitstovolts.com> wrote:
Oops, accidentally went direct rather than through the list._______________________________________________
It would be a good addition to gr-filter to be able to use the CPU operations optimized halfband out of the box.
==== Previous message ====
Hi Albin,
The Filter Design Tool will generate Halfband taps that can be loaded into the FIR filter block, no need to write one.
The implementation is here:
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python/filter/design/fir_design.py#L161
What would be an excellent addition would be to move the implementation for half-band creation to the firdes class and then have the filter design tool call the function, as it does for most (all?) of the other filter classes.
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/include/gnuradio/filter/firdes.h#L60
Regards,
Derek
====
On 24/04/2019 09:04, Müller, Marcus (CEL) wrote:
Hi Albin, Don't know what Derek suggested, but be aware that our "straight" FIR filter decimators are already polyphase implementations, and use SIMD (through VOLK) heavily (run volk_profile if you want to make maximum use of that advantage); it might be that on paper, the number of operations are unnecessarily high, but in CPU practice, some cures are worse than the disease. For example, I haven't tried, but it's thoroughly possible that albeit the classical case of "half your tap memory by only storing one half of your symmetrical FIR" performs worse than just working with the full (half redundant) tap vector, simply because doing so avoids nonlinear memory access patterns. Best regards, Marcus On Tue, 2019-04-23 at 19:06 +0200, Albin Stigö wrote:Thanks for the reply Marcus. Interesting approach for sure! Will have to think about it... Derek, your solution works but it will be 4 times slower than the example I linked to. --Albin On Tue, Apr 23, 2019, 18:24 Müller, Marcus (CEL) <mueller@kit.edu> wrote:Hi Albin, I'm very very tired right now, but me and Felix came to the following conclusions on our *Whiteboard Of Wisdom, Smarts, Expertise, Rationality and Science* (WOWSERS): 1. A Nyquist-M bandpass filter, esp. a halfband, has zeros on every other tap – except for the one center tap, which is at the maximum of the sinc that you window your prototype filter with. 2. you'd thus implement that filter as polyphase filter with two different polyphase components: 1. one polyphase component that contains all the zeros, and the single center tap that's not 2. one component that contains all the non-zero taps 3. you'd thus need to "deinterleave" your input stream into two: 1. Delay by half the number of taps (and multiply by the maximum 2. filter with all the non-zero taps 4. sum up the results So, for all this, we already have blocks – yay! Best regards, Marcus On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote:Just checking before I write one, is there a half band decimator/interpolator in gnuradio I haven't been able to find... Optimized like this: http://liquidsdr.org/doc/resamp2/ Or is there an even better option for interpolation by 2? --Albin _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment