discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] fast parallel filtering


From: Andy Walls
Subject: Re: [Discuss-gnuradio] fast parallel filtering
Date: Sun, 26 Mar 2017 20:49:55 -0400

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

Attachment: implant_pulse_detect_5.grc
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]