Re: [Discuss-gnuradio] fast parallel filtering

[Dirk Gorissen]

Hi Andy,

I have been experimenting with the flowgraphs, tried with some live
data and it all works as expected. Just had to switch the threshold to
2 orders of magnitude smaller when using an airspy.

So thank you again for your time on this, I will ensure to give credit
when the final thing is tested & operational :)

Some comments/questions inline below:

>To get faster lock in, you may want your frequency range of interest to
>be somewhere in between Fs/4 and Fs/2; and not near DC.

Actually my channel is 2khz wide, not 10khz so that does make life a
bit easier. So in this case I should be decimating Fs down to
something like 4k say. Correct?
As you say this should also let me lower the pll bandwidth. Though I
haven't quite grasped the intuition behind this. Experimenting a bit
it seems a bit smaller than you set is better, definitely not larger.
How did you pick your ranges, they dont align with what the docs are
saying ( around pi/200 - 2pi/100).

>b. Once you find some pulses, extract what frequency they were at from
>the PLL's loop filter state at the time it was locked on the pulse.  You
>can then use this exact frequency information for a dedicated
>correlation filter to pull even weaker pulses out of the noise, and
>maintain track.

Yes this is what I had in mind as well. I looked around the carrier
block docs, source code, and wider gr wiki but couldn't find how I can
get my hands on that internal state?

>I wasn't intending to tweak the flowgraph, but today I decided to try
>with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
>method turned out to be inferior to the PLL, so I didn't leave it in
>the flowgraph.

Thats good to know, thats what I was doing originally.

>My gut feeling is that to detect these weak pulses
>in the original file, you're going to have to tolerate a fairly high
>false alarm rate, if you want to detect the pulses.

Agreed. I would probably be somewhat permissive initially and then do
some further filtering in a post processing step.

>Doing things to not allow noise into the system in the first place,
>such as a VHF bandpass filter before the SDR unit,

Indeed. Actually for the second dataset there was a preamp & filter in place

>and proper adjustment of the SDR's LNA and IF gains for best noise performance
>would help.

Yes, something I could optimise a bit more. My understanding here
though is that there isnt much of a science, just manual fiddling of
the lna/if/mixer gains in sdr# while listening to the signal of
interest (?)

Final question is a more general one. I have a fairly tight
computational budget and need to drop down the sample rate quite a
bit. Im assuming the most efficient way to do this is decimate &
filter over 3 stages. In each stage the decimation factor reduces and
the filter order increases.

Cheers
Dirk

On 20 March 2017 at 00:11, Andy Walls <address@hidden> wrote:
> You're welcome.
>
> I can report, that I can now see/detect pulses in the original I/Q
> file you provided, using the latest flowgraph I provided.  I had to
> set the trigger threshold down to 0.1 (down from my original 0.3).
>
> I know they are pulses and not false alarms, because I can often see
> two correlation peaks spaced at about 1.5 seconds apart.
>
> In a real system, I'd try to dynamically adapt the threshold decision
> point between correlator signal output and noise output for a given
> false alarm rate.  My gut feeling is that to detect these weak pulses
> in the original file, you're going to have to tolerate a fairly high
> false alarm rate, if you want to detect the pulses.
>
> Doing things to not allow noise into the system in the first place,
> such as a VHF bandpass filter before the SDR unit, and proper
> adjustment of the SDR's LNA and IF gains for best noise performance
> would help.
>
> Also being able to narrow down the possible variation in frequencies
> where the signal might be at, say a 2 kHz channel vs. a 10 kHz
> channel, would allow additional noise filtering and lower PLL loop
> bandwidth, so that weaker signals could be pulled out.
>
> Fun stuff.
>
> Regards,
> Andy
>
>
> On Sat, Mar 18, 2017 at 6:30 PM, Dirk Gorissen <address@hidden> wrote:
>> Amazing Andy, thank you for putting this time in. Im still digesting
>> this but will report back
>>
>> On 18 March 2017 at 20:45, Andy Walls <address@hidden> wrote:
>>> Dirk,
>>>
>>> Here is a revised flowgraph, slightly tweaked to reduce the
>>> computational cost of the rotator and the filters.
>>>
>>> I wasn't intending to tweak the flowgraph, but today I decided to try
>>> with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
>>> method turned out to be inferior to the PLL, so I didn't leave it in
>>> the flowgraph.
>>>
>>> Regards,
>>> Andy
>>>
>>> On Fri, Mar 17, 2017 at 11:46 AM, Andy Walls
>>> <address@hidden> wrote:
>>>> On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
>>>>> Hi Dirk,
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Try the attached flowgraph.  The pulse indicator output is a little crude
>>>>> at the moment (it needs some latching persistence for a human to read),
>>>>> but it does the job for a proof of concept.
>>>>>
>>>>> Note that in the future, you really do want to tune such the the SDR's 
>>>>> center
>>>>> freq spike is not in the band of interest.  That will prevent false lock 
>>>>> on the
>>>>> DC spike by the PLL.
>>>>>
>>>>> Regards,
>>>>> Andy
>>>>
>>>> I should also mention a few things:
>>>>
>>>> 1. You could handle multiple channels in one of at least two ways:
>>>>
>>>> a. A polyphase channelizer with each channel having a PLL and Moving
>>>> average filter instance.  (This can get CPU intensive.) Or...
>>>>
>>>> b. Scanning by stepping through and dwelling for a bit on your 10 kHz
>>>> channels of interest.
>>>>
>>>>
>>>> 2. You can get better sensitivity the the PLL+Moving average correlation
>>>> solution by going to a 2 stage process:
>>>>
>>>> a. Use the PLL+Moving Average filter to initially acquire some pulses.
>>>>
>>>> b. Once you find some pulses, extract what frequency they were at from
>>>> the PLL's loop filter state at the time it was locked on the pulse.  You
>>>> can then use this exact frequency information for a dedicated
>>>> correlation filter to pull even weaker pulses out of the noise, and
>>>> maintain track.  You'll have to use the magnitude of the correlation and
>>>> not just the real part (because you'll have an arbitrary phase shift,
>>>> since a straight correlation filter is a phase offset detector and not
>>>> phase tracker like a PLL).
>>>>
>>>> Regards,
>>>> Andy
>>>>
>>>>
>>>>> On Thu, Mar 16, 2017 at 7:12 PM, Dirk Gorissen <address@hidden> wrote:
>>>>> > Hi Andy,
>>>>> >
>>>>> > Very quickly collected some data off a different Tx. First at very
>>>>> > close range, moving away, and then back again. It was quick and
>>>>> > antenna was close to computer so perhaps quite noisy but should
>>>>> > definitely have some strong pulses:
>>>>> >
>>>>> > https://drive.google.com/open?id=0B5dKo9igl8W4WkRkUGQzcVJsQnc
>>>>> >
>>>>> > Havent managed to look at the pll stuff yet. Aim to do so this weekend.
>>>>> > Cheers
>>>>> > Dirk
>>>>> >
>>>>> > On 16 March 2017 at 07:22, Dirk Gorissen <address@hidden> wrote:
>>>>> >> Mmm, thats odd. Those settings should be correct, maybe something went
>>>>> >> wrong with the recording :(  I'll try to check in between things at
>>>>> >> work today else will do so tonight.
>>>>> >> Thanks for taking the time to look though.
>>>>> >>
>>>>> >> On 16 March 2017 at 00:39, Andy Walls <address@hidden> wrote:
>>>>> >>> Hi Dirk:
>>>>> >>>
>>>>> >>> In the IQ data file you provided I can seem to find any pulses of the
>>>>> >>> nominal 10 msec length, no matter how I filter and rotate the
>>>>> >>> spectrum.
>>>>> >>> There is a lot of EMI, which looks like the intermodulation products
>>>>> >>> of a continuously on guy who is drifting/chirping down in frequency.
>>>>> >>>
>>>>> >>> So could you please confirm or clarify the following:
>>>>> >>>
>>>>> >>> 1. The format of the binary data file.  I am assuming 32 bit float I
>>>>> >>> and 32 bit float Q pairs, as that is what the GNURadio file sink would
>>>>> >>> normally create.
>>>>> >>> 2. The sample rate.  I am assuming 1 Msps.
>>>>> >>> 3. The center freq.  I am assuming 150.22 MHz.
>>>>> >>> 4. The pulse duration. I am assuming 10 milliseconds.
>>>>> >>> 5. At what frequency offset, from the center frequency, should the
>>>>> >>> pulse be at?  I'm assuming somewhere withing +/- 5 kHz of the center
>>>>> >>> spike, but there are at least two EMI spikes in that range.
>>>>> >>>
>>>>> >>> Thanks.
>>>>> >>>
>>>>> >>> -Andy
>>>>> >>>
>>>>> >>> On Wed, Mar 15, 2017 at 5:23 AM, Dirk Gorissen <address@hidden> wrote:
>>>>> >>>> Hi Andy, Marcus,
>>>>> >>>>
>>>>> >>>> Thanks very much for taking the time to think about this.
>>>>> >>>>
>>>>> >>>> Just to answer your questions:
>>>>> >>>>
>>>>> >>>>>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?
>>>>> >>>>
>>>>> >>>> Yes, Im dealing with a very weak signal against quite a bit of
>>>>> >>>> background noise so the more prior knowledge I can leverage the
>>>>> >>>> better.
>>>>> >>>>
>>>>> >>>>>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.
>>>>> >>>>
>>>>> >>>> Yes, 10ms long (this is pretty exact), occurring every 1.5 seconds, 
>>>>> >>>> in
>>>>> >>>> the 150MHz range. My input stream is coming from an SDR.
>>>>> >>>> As an aside I actually have multiple transmitters each pulsing at
>>>>> >>>> slightly different frequencies (e.g., 150.10, 150.22, ...) but Im
>>>>> >>>> happy to treat them independently so you can ignore that and assume
>>>>> >>>> there is just one.
>>>>> >>>>
>>>>> >>>> You can see pictures of the pulse (taken a while back, for a specific
>>>>> >>>> tx frequency) here: https://goo.gl/photos/Y3Ea6kJo1ewrcDYM8
>>>>> >>>>
>>>>> >>>> Note though that this is taken with the transmitter very close to the
>>>>> >>>> antenna so the signal is unrealistically strong. So its just to
>>>>> >>>> illustrate.
>>>>> >>>>
>>>>> >>>> I also quickly captured a file with raw IQ samples (File sink) in 
>>>>> >>>> case
>>>>> >>>> anybody is interested. It starts with the transmitter very close to
>>>>> >>>> antenna, moves progressively further until out of range and then 
>>>>> >>>> back.
>>>>> >>>> Its only about a minute or two tops but at 1msps it ended
>>>>> >>>> up as 813 MB though.
>>>>> >>>>
>>>>> >>>> https://drive.google.com/drive/folders/0B5dKo9igl8W4dWpiMmlEYWx3b0k?usp=sharing
>>>>> >>>>
>>>>> >>>>>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?
>>>>> >>>>
>>>>> >>>> Yes. The "tone" happens every 1.5 seconds and I want to catch as many
>>>>> >>>> of those occurrences as possible as the receiver moves through space.
>>>>> >>>> So for every 1.5 seconds I need to make a decision: was there one, or
>>>>> >>>> not.
>>>>> >>>>
>>>>> >>>> Note that the receiver is moving. So perhaps initially I may be well
>>>>> >>>> out of range of the signal and get nothing. But as I move closer as
>>>>> >>>> some point I will start picking up those pulses. The earlier and more
>>>>> >>>> reliably I can pick them up the better.
>>>>> >>>>
>>>>> >>>> I actually did spend some time looking at PLLs & the gnu radio block
>>>>> >>>> at some point. However I readily admit to being a software person not
>>>>> >>>> a DSP/Radio person. I have the day job to deal with today but I will
>>>>> >>>> have a study of the PLL block given Andy's tips and report back.
>>>>> >>>>
>>>>> >>>> Cheers
>>>>> >>>> Dirk
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 14 March 2017 at 16:37, Andy Walls <address@hidden> wrote:
>>>>> >>>>> On Tue, 2017-03-14 at 12:00 -0400, address@hidden
>>>>> >>>>> wrote:
>>>>> >>>>>> Date: Tue, 14 Mar 2017 15:49:44 +0100
>>>>> >>>>>> From: Marcus M?ller <address@hidden>
>>>>> >>>>>> To: address@hidden
>>>>> >>>>>> Subject: Re: [Discuss-gnuradio] fast parallel filtering
>>>>> >>>>>
>>>>> >>>>>> 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?
>>>>> >>>>>
>>>>> >>>>> Ah, OK.
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>> 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?
>>>>> >>>>>
>>>>> >>>>> Yes.  With the added benefit of GNURadio's carrier tracking PLL 
>>>>> >>>>> actually
>>>>> >>>>> performing part of the correlation operation for you, if it works 
>>>>> >>>>> out.
>>>>> >>>>>
>>>>> >>>>> So use the carrier_tracking_pll block.  If it locks onto a good 
>>>>> >>>>> signal,
>>>>> >>>>> it will mix it down to DC.  Then all you need is an averaging 
>>>>> >>>>> filter,
>>>>> >>>>> like the single pole IIR filter block or the moving average filter
>>>>> >>>>> block, operating on the real part of that output.  That will act as 
>>>>> >>>>> a
>>>>> >>>>> lock detector, and, I think, also completes a correlation 
>>>>> >>>>> operation, if
>>>>> >>>>> you use a non-normalized moving average filter (since the carrier
>>>>> >>>>> tracking PLL block gives you a point by point complex multiply with 
>>>>> >>>>> the
>>>>> >>>>> conjugate of the complex carrier tone).
>>>>> >>>>>
>>>>> >>>>> You'll want to set the PLL allowed min and max frequency bounds
>>>>> >>>>> properly; be careful since the input arguments have tricky units.
>>>>> >>>>>
>>>>> >>>>> You'll also want the loop bandwidth set pretty wide, since you want 
>>>>> >>>>> to
>>>>> >>>>> lock-in rapidly.
>>>>> >>>>>
>>>>> >>>>> Also, if I'm thinking about this properly:
>>>>> >>>>> To get faster lock in, you may want your frequency range of 
>>>>> >>>>> interest to
>>>>> >>>>> be somewhere in between Fs/4 and Fs/2; and not near DC.  If you're
>>>>> >>>>> within the lock-in range of the PLL, you'll lock within 1 cycle.  If
>>>>> >>>>> you're in the pull-in range of the PLL, it can take many cycles to 
>>>>> >>>>> get
>>>>> >>>>> into lock.
>>>>> >>>>>
>>>>> >>>>> Regards,
>>>>> >>>>> Andy
>>>>> >>>>>
>>>>> >>>>>> 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
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> _________________________________________
>>>>> >>>> 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
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > _________________________________________
>>>>> > 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



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