Re: [Discuss-gnuradio] fast parallel filtering

[Dirk Gorissen]

Better late than never, but massive thanks to Andy, Marcus and the
GnuRadio community:

https://dirkgorissen.com/2019/01/06/wheres-pinoh-tracking-orangutans-with-drones-and-gnu-radio/

On Mon, 27 Mar 2017 at 09:09, Dirk Gorissen <address@hidden> wrote:
>
> Hi Andy,
>
> What can I say, this is amazing... I need to digest this a bit again
> and Im currently working on some hardware bits. Hope to get this
> flying in the next week or two. Will let you know how it goes.
>
> Cheers
> Dirk
>
> On 27 March 2017 at 01:49, Andy Walls <address@hidden> wrote:
> > Hi Dirk:
> >
> > Since you asked about how to set PLL values, I've worked up a version
> > 5 of the flowgraph (attached) to help with that.
> >
> > First you'll need to build and install my OOT NOAA Weather Radio module:
> > https://github.com/awalls-cx18/gr-nwr
> > to get a modified version of the PLL Ref Out block.  The modified PLL
> > Ref Out block has extra input parameters available from the GUI and
> > extra diagnostic output streams.
> >
> > In the new flowgraph you can now modify both the PLL's loop bandwidth
> > and its damping factor.  You can also observe the PLL's internal
> > instantaneous frequency and internal average frequency (both
> > normalized by 10 kHz for the scope), since they are now brought out to
> > optional output streams.  You'll want to pay more attention to the
> > average PLL frequency during a pulse, and you will usually want to
> > ignore the instantaneous PLL frequency during a pulse.
> >
> > So now you can see the effect of setting the loop bandwidth very low.
> > If it is set to 0.01, you can see how much the PLL likes to track an
> > interference spike and not move off of it.  This sluggish PLL response
> > is undesirable for your application of finding short pulses of
> > "unknown" frequency.
> >
> > I left the loop bandwidth at 0.35, because the PLL seemed to be
> > reactive enough to lock on to most of the pulses.  At 0.3 to 0.24, the
> > PLL was still reactive and locked, but sometimes it locked-on "wrong".
> > Instead of being at a stable -1 kHz during a pulse, it would lock at
> > an unstable +2 kHz.  And, as I mentioned before, a very low loop
> > bandwidth made the PLL very non-reactive and useless to quickly find
> > the pulses.  There doesn't seem to be much penalty for setting the
> > loop bandwidth higher, except there do seem to be "dead zones" of
> > values that don't work.
> >
> > Regarding damping factor, I left it at the default of 1/sqrt(2), which
> > results in a maximally flat loop filter response.  FWIW, a damping
> > factor of 1.0 is a critically damped system, and >1.0 is an overdamped
> > system.  For your application, you definitely want an underdamped
> > system.  You might want to experiment with damping factors less than
> > the default.
> >
> > Also, in this flowgraph, I separated the out the final, non-decimating
> > lowpass filter from the final decimating filter stage. It saves some
> > CPU.
> >
> > Regards,
> > Andy
>
>
>
> --
> _________________________________________
> Dr. Dirk Gorissen
> Mob: +44-7763-806-809
> Web: dirkgorissen.com
> Skype: dirk.gorissen
> Twitter  : twitter.com/dirkgor
> LinkedIn: linkedin.com/in/dirkgorissen



-- 
Dirk Gorissen
Mob: +44-7763-806-809
Skype: dirk.gorissen
LinkedIn: linkedin.com/in/dirkgorissen