Hi Tom, I just had to look this up. If you're in GRC, you have "rationale resampler" and "rational resampler base"; they do basically the same, but if you use the one without "base", and don't specify the taps, GNU Radio just automatically designs a filter that avoids all aliasing and imaging, which is done with a python wrapper around the C++ rational_resampler_base_xxx's make function[1]. That's pretty handy in most use cases, but not too much if you want your own filter for some reason.
If you're using the "base" variant, you /must/ specify the taps yourself, because you directly invoke the C++ block's maker. If you go ahead and just use "[1.0]" as taps, you get the aliased results from my pictures. So if you happen to /want /to specify the taps, because you can integrate the functionality of a downstream filter into the resampler to save CPU cycles, it doesn't make a difference which block you use. Best regards, Marcus [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python/filter/rational_resampler.py On 10.08.2015 13:55, Tom Cook wrote: > > On Mon, 10 Aug 2015 at 12:30 Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>> wrote: > > [snip] > > > Thanks for the very detailed explanation, Marcus. I think quite a bit > of my trouble here is relating GNU Radio terminology to > hazily-remembered signal processing courses I took fifteen years ago > and haven't used a whole lot since. > > So, using a rational resampler at 4x decimation, with no separate > aliasing filter and the 'Filter taps' parameter left empty will mean > that there will be aliasing in the resulting down-sampled data. Have > I understood you right? I need to provide filter taps to get an > anti-aliasing filter as part of the resampler block? > > Thanks again, > Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
