Re: [Discuss-gnuradio] fixing gr_pll_*_c[cf]

[Eric Blossom]

On Wed, Mar 22, 2006 at 04:14:36PM -0500, Charles Swiger wrote:
> On Thu, 2006-03-16 at 14:39 -0800, Eric Blossom wrote:
> > On Thu, Mar 16, 2006 at 05:24:26PM -0500, Charles Swiger wrote:
> > > On Thu, 2006-03-16 at 12:35 -0800, Eric Blossom wrote:
> > > 
> > > 
> > > Here's the only place they're used:
> > > 
> > >     d_freq = d_freq + d_beta * error;
> > >     d_phase = mod_2pi(d_phase + d_freq + d_alpha * error);
> > > 
> > > 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.
> 
> Does anybody know how to fix this in c++ ? 

Chuck,

It's not broken.  I was wrong.  The "problem" is the lack of
documentation on what *any* of the arguments mean.  In fact, the freq
args are in radians/sample.  Thus it will always fall in +/- pi
and the existing code will keep it in range.

  freq_in_hz * 2 * pi / sample_rate_in_hz --> radians/sample

Matt, will you *please* add doxygen comments to gr_pll_*.h?

Thanks,
Eric