[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] fixing gr_pll_*_c[cf]
From: |
Charles Swiger |
Subject: |
Re: [Discuss-gnuradio] fixing gr_pll_*_c[cf] |
Date: |
Wed, 22 Mar 2006 16:14:36 -0500 |
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++ ?
In PYTHON there's 'truncating divide' ( // ) where this seems to work:
>>> M_PI = math.pi
>>> M_TWOPI = 2 * math.pi
>>>
>>> def mod_2pi (num):
... if ( n > M_TWOPI ):
... return ( num - M_TWOPI * ( num // M_TWOPI ))
... elif ( n < -M_TWOPI ):
... return ( num + M_TWOPI * ( -num // M_TWOPI ))
... else:
... return num
...
>>> num = 5000 * math.pi + 2.13
>>> mod_2pi(num)
2.1299999999991996
>>> num = 500000 * math.pi + 3.15
>>> mod_2pi(num)
0.0084073462057858706
>>> num = -500000 * math.pi - 3
>>> mod_2pi(num)
-3.0
>>> num = -500000 * math.pi - 3.15
>>> mod_2pi(num)
-0.0084073462057858706
How to translate into effecient C++ is beyond me at the moment (but
googling around for a solution)
--Chuck
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, (continued)
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Charles Swiger, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Eric Blossom, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Charles Swiger, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Charles Swiger, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, ldoolitt, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Eric Blossom, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Charles Swiger, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Matt Ettus, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Robert McGwier, 2006/03/17
- Re: [Discuss-gnuradio] pll_refout_cc - finding optimum alpha & beta ??, Eric Blossom, 2006/03/20
- Re: [Discuss-gnuradio] fixing gr_pll_*_c[cf],
Charles Swiger <=
- Re: [Discuss-gnuradio] fixing gr_pll_*_c[cf], Eric Blossom, 2006/03/22