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 <dgoris...@gmail.com> 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 <a...@silverblocksystems.net> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
