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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> >>>>> >> 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 <[email protected]> >>>>> >>> 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 <[email protected]> >>>>> >>>> wrote: >>>>> >>>>> On Tue, 2017-03-14 at 12:00 -0400, [email protected] >>>>> >>>>> wrote: >>>>> >>>>>> Date: Tue, 14 Mar 2017 15:49:44 +0100 >>>>> >>>>>> From: Marcus M?ller <[email protected]> >>>>> >>>>>> To: [email protected] >>>>> >>>>>> 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 >>>>> >>>>>> > [email protected] >>>>> >>>>>> > 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
