[time-nuts] PLL Math Question
Daniel Mendes
dmendesf at gmail.com
Thu Mar 13 00:13:43 EDT 2014
This is a FIR x IIR question...
moving average = FIR filter with all N coeficients equalling 1/N
exponential average = using a simple rule to make an IIR filter
Daniel
Em 13/03/2014 00:55, Bob Stewart escreveu:
> Hal says: "For exponential smoothing, a_avg will be a fraction. Let's pick a_avg to be 1/8. That's a right shift by 3 bits. I don't think there is anything magic about shifting, but that makes a particular case easy to spot and discuss."
>
> Hi Hal,
>
> Yeah, I've been sitting here manually running some sample data and I haven't been happy with my efforts so far. I think I'll just stay with what I know for now: moving averages. I've got a number of places I can reduce memory usage when I run a bit shorter, so I think it'll work out. And I suspect I'm being far too conservative; i.e. averaging way too long If not, maybe there will be a good gain value that will be convenient to code the exponential average.
>
> Thanks for the help,
>
> Bob
>
>
>
>> ________________________________
>> From: Hal Murray <hmurray at megapathdsl.net>
>> To: Bob Stewart <bob at evoria.net>; Discussion of precise time and frequency measurement <time-nuts at febo.com>
>> Cc: hmurray at megapathdsl.net
>> Sent: Wednesday, March 12, 2014 10:08 PM
>> Subject: Re: [time-nuts] PLL Math Question
>>
>>
>>
>> bob at evoria.net said:
>>> In the moving averages I'm doing, I'm saving the last bit to be shifted out
>>> and if it's a 1 (i.e. 0.5) I increase the result by 1.
>> That's just rounding up at an important place. It's probably a good idea,
>> but doesn't cover the area I was trying to point out. Let me try again...
>>
>> Suppose you are doing:
>> x_avg = x_avg + (x - x_avg) * a_avg;
>>
>> For exponential smoothing, a_avg will be a fraction. Let's pick a_avg to be
>> 1/8. That's a right shift by 3 bits. I don't think there is anything magic
>> about shifting, but that makes a particular case easy to spot and discuss.
>>
>> Suppose x_avg is 0 and x has been 0 for a while. Everything is stable. Now change x to 2. (x - x_avg) is 2, the shift kicks it off the edge, so x_avg doesn't change. (It went 2 bits off, so your round up doesn't catch it.) The response to small steps is to ignore them.
>>
>> If you have noisy data, things probably work out OK. If you need to process low level (very) low frequency changes (which seems desirable for a GPSDO) you probably want some fractional bits. For me, the easy way to do that is to use
>> y = x * k
>> Let's use k = 16, a 4 bit left shift.
>> For the same step of x=2, y= 32, (y - y_avg) is 32, shifted right by 3 that's 4, so y_avg is 4.
>>
>> I'm sure this is all business-as-usual for the people who write control loops in small CPUs using fixed point arithmethic. Of course, you have to worry about shifting too far left (overflow) and things like that.
>>
>> If you have enough cycles, you can use floating point. :)
>>
>>
>> --
>> These are my opinions. I hate spam.
>>
>>
>>
>>
>>
>>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts
mailing list