[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] fast parallel filtering
From: |
Dirk Gorissen |
Subject: |
Re: [Discuss-gnuradio] fast parallel filtering |
Date: |
Tue, 14 Mar 2017 10:19:40 +0000 |
Hi Martin,
The aim is to check for the existence of a 10ms pulse in the incoming
radio signal (from an sdr). The thing is I only know the frequency of
the pulse to within ~1khz.
So a single filter in my case is: generate a synthetic pulse (complex
sin wave) of the same length and with a frequency f. Then take the
reverse of the complex conjugate of this pulse to give me the taps for
a FIR filter.
Repeat the above for each frequency I want to check. E.g., 10 filters
each 100Hz apart.
Then I just take the magnitude of each filter output and push through
a Max to get my final correlations.
I can come up with an algorithm that tries to be clever and with some
accounting tries to find what frequency matters most but I wouldnt be
surprised if there is some theory you can use to do this more
efficiently or even in a single shot. But this is where Im unsure.
Cheers
Dirk
On 14 March 2017 at 01:09, Martin Braun <address@hidden> wrote:
> 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
>>
>>
>>
>
>
> _______________________________________________
> 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
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/14
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/14
- Re: [Discuss-gnuradio] fast parallel filtering, Dirk Gorissen, 2017/03/15
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/15
- Re: [Discuss-gnuradio] fast parallel filtering, Dirk Gorissen, 2017/03/16
- Re: [Discuss-gnuradio] fast parallel filtering, Dirk Gorissen, 2017/03/16
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/16
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/17
- Re: [Discuss-gnuradio] fast parallel filtering, Andy Walls, 2017/03/18