Re: [Discuss-gnuradio] fast parallel filtering

[Dirk Gorissen]

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