Re: [Discuss-gnuradio] fast parallel filtering

[Marcus Müller]

Hi Andy,

Dirk's problem was the low SNR in his recording, so he'd like to take
the shape of his pulse into consideration, but he doesn't know the
spectral position of the same – Dirk, can you confirm?

Dirk, thinking about this, the relation of the spectral uncertainty to
the bandwidth of the pulse would be interesting  – can you refresh our
memory? I think the pulse was 10ms long (so, pretty long) but I forgot
how it looked like.

Having slept about this a couple of times: What you really care about is
that there's a *tone* for about 8ms < t < 12ms where there is none else
(to rule out detection of spurs and other interference), is that right?

Maybe we've been focussing too much on filter-based detection. What if
we just *use* that feature of the signal being periodic for a duration
of t, and not else? A PLL would be able to "lock" on the tone (much like
an FM Radio with a PLL will lock on the station's carrier), and if we
observe the phase error being limited for t, we can derive there was a
pulse.

Andy, does that sound like a feasible approach?

Cheers,

Marcus


On 14.03.2017 14:18, Andy Walls wrote:
> If there is no information on the signal, why not just do a straight
> energy detector:
>
> source -> complex bandpass filter -> complex to mag -> burst/energy detector 
> -> QT Time sink (triggering on start of burst tag)
>
> The complex bandpass filter just has to catch all the frequencies of
> interest.  (A complex bandpass filter does not have a symmetrical image
> around DC.)
>
> The burst/energy detector has to detect some minimum number of time
> domain samples contiguously above some noise/signal threshold that you
> set, and tag the pulse.  It also has to detect when the time domain
> samples fall below the threshold.  The burst/energy detector can work
> with a preset noise/signal threshold, or you could periodically
> re-estimate that threshold.
>
> GNURadio does not have a stock block that does burst/energy detection,
> so you'll have to find one on the 'Net or write one yourself.
>
> -Andy
>
>
> Dirk Gorissen wrote:
>> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio