Re: [Discuss-gnuradio] fast parallel filtering

[Dirk Gorissen]

 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



-- 
_________________________________________
Dr. Dirk Gorissen
Mob: +44-7763-806-809
Web: dirkgorissen.com
Skype: dirk.gorissen
Twitter  : twitter.com/dirkgor
LinkedIn: linkedin.com/in/dirkgorissen