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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
