On Fri, Mar 17, 2006 at 11:06:00AM -0500, Charles Swiger wrote: > On Thu, 2006-03-16 at 19:55 -0500, Robert McGwier wrote: > > > phase is ALWAYS computed in an NCO by phase = phase + freq so this says that > > > > phase_new = (phase_old + GAIN_FOR_PHASE*measured-phase-err) + > > NewFrequency. SO Something is amiss. You just turned your second > > order phase locked loop into a first order loop. It is NOT a typo. > > > > > >>>> It's way over my head but is d_freq supposed to be in the d_phase > > >>>> calculation, 2nd line? phase is mod_2pi but freq can be a very big > > >>>> number, like mod_2pi(100000 + 1.572849). That is I'm USING very big > > >>>> numbers for max_freq and min_freq - don't suppose they're normalized > > >>>> somehow. > > >>>> > > >>> OK. I can see why that would be a problem. mod_2pi is optimized for > > >>> the expected "close in case" (symmetric around zero), thus the phase > > >>> isn't *really* getting folded down to [-pi,pi]. > > >>> > > >>> Try changing mod_2pi to make the bounds check and then compute the > > >>> modulus if it needs to using division, floor, multiplication and > > >>> subtraction. It's not cheap, but it'll probably compute the right > > >>> answer. > > >>> > > >>> > > > Ok, I start to see - d_phase is an accumulator in (supposedly) mod_2pi > bounds - so d_freq would indeed be the derivitive of phase (the steeper > the phase, the greater the frequency) - and a 2nd order control loop has > a proportional and a derivitive component. Then d_phase is converted > to sin/cos for output. > > It just seeemd strange to me that a very large number, d_freq, which is > bounds limited to between d_min_freq and d_max_freq, is inside a > function trying to limit it's output to between +PI and -PI.
Chuck, let me try again. The function has the right name, mod_2pi, but the wrong implementation ;) These are commonly called bugs ;) Hence my comments above about doing the mod the right way. > if(100e3 > M_PI) > return(100e3-M_TWOPI) > > or 99993.7168... error can get close to zero, but frequency will > never be less than d_freq_min. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
