Re: [Discuss-gnuradio] fast parallel filtering

[Martin Braun]

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 <address@hidden> 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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> 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
> 
> 
>