Hej Lars,
On 01/03/14 23:09, Lars Walenius wrote:
Hi Magnus
You are correct in a way. The code is more complicated than it should have
been.
Well, there is potential for improvements.
The first row with comment “corr for time” is the I-term.
OK.
The second row that integrates the frequency offset is the P-term and could
have been just proportional to the time offset I understand now (I have thought
of it before but totally forgot it).
Well, as it says now it is
dacValue = dacValue + I_contribution
dacValue = dacValue + P_contribution
rather than
I = I + I_contribution
dacValue = I + P_contribution
The dacValue you create will integrate both the I and P contributions.
However, that's not what your code is doing.
The "P-contribution" is really a frequency input rather than
proportional time/phase input. That is correct to integrate to get
P-ish. A more direct way would be to remove the differentiating of the
input and remove the integration on the output. That would make the code
clearer about what's going on.
As I choosed to work with integers I have to scale the values to avoid
truncation errors (that I still get with large time constants ☹. Probably it
would be better to use floating point calculations.
You need to use long enough integers for it to work. Integer scaling is
a bitch, but if you do it right, it can work very well for you.
Personally, I'm lazy and just throw a ton of bits onto it, turns out it
is cheap and I can worry about other parts of the design, and there is
plenty of those to go around anyway.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
