How related are those filters? Is this a candidate for polyphase DSP? -- M
On 03/11/2017 02:01 PM, Dirk Gorissen wrote: > Hi Marcus, > > Sorry, I should have clarified. You may recall an earlier thread from > mine where Im looking to pick out a short pulse from background noise > but I dont know the exact frequency of the pulse. Thought I would > start a new thread with a clear, specific question. > > There is an uncertainty of +/- 1khz. So I can define multiple filters, > correlating for different pulse frequencies across the 1khz range. I > can implement this with different filters running in parallel but I > was looking for a more flexible / efficient way. > > If you think this is out of scope for this list no problem at all, > just let me know. > > Cheers > Dirk > >> On 11 March 2017 at 20:02, Marcus Müller <[email protected]> wrote: >>> Hi Dirk, >>> >>> this is more of a general DSP question than a GNU Radio question: >>> >>> How do these filters relate to each other? >>> >>> My gut feeling is that this gets a lot easier as soon as you tell us why >>> you're doing this, i.e. for what purpose :) >>> >>> Best regards, >>> Marcus >>> >>> On 11.03.2017 19:28, Dirk Gorissen wrote: >>>> Hello all, >>>> >>>> Given a stream of samples I would like to apply n slightly different >>>> filters to it with n being able to be chosen at runtime. Then combine >>>> the results back to a single stream. >>>> >>>> As a test I built a flowgraph with the following chains in parallel for n >>>> = 6 >>>> >>>> | -> decimating fir filter 1 -> complex to mag -> | >>>> stream -> | -> decimating fir filter 2 -> complex to mag -> | -> Max >>>> -> ... >>>> | .... >>>> | >>>> | -> decimating fir filter n -> complex to mag -> | >>>> >>>> So the same stream is sent to each chain (decimation is 1) and the >>>> output of each chain is pushed through a big Max block with 6 inputs. >>>> >>>> This works but not particularly elegant and a bit annoying to change >>>> if I suddenly decide I want to change n. In particular it also does >>>> not seem computationally efficient. >>>> >>>> What I would like is to replace the above by a single block that >>>> >>>> - replicates the input n times >>>> - applies each filter on each replica >>>> - combines the output again to a single stream >>>> - have a tunable n parameter >>>> - is fast >>>> >>>> I did this with an Embedded python block doing essentially this: >>>> >>>> for i in range(n): >>>> out[i] = scipy.signal.lfilter(taps[i], 1, input) >>>> >>>> This is using exactly the same taps as in the chain case. This works >>>> but the output is different and worse than what I get with the >>>> separate chains. As a test, instead of lfilter I tried: >>>> >>>> gnuradio.filter.fir_filter_ccc(1,taps[i]).work(input[0],output) >>>> >>>> Thinking perhaps that is a closer replica. But couldnt get it to work.. >>>> >>>> I suspect there should be an easy / natural way of doing this in >>>> gnuradio. Looked at the filter bank / channelliser blocks but failed >>>> to get anywhere. >>>> >>>> So what is the best way forward to do this? >>>> >>>> Many thanks >>>> Dirk >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> -- >> _________________________________________ >> Dr. Dirk Gorissen >> Mob: +44-7763-806-809 >> Web: dirkgorissen.com >> Skype: dirk.gorissen >> Twitter : twitter.com/dirkgor >> LinkedIn: linkedin.com/in/dirkgorissen > > > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
