Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??

[Charles Swiger]

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.

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.


--Chuck