Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

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