[time-nuts] Re: Testing frequency pulling on a DYI counter

Erik Kaashoek erik at kaashoek.com
Sun Aug 7 06:13:39 UTC 2022


Magnus,
The simulation was incorrect in reflecting the capture synchronization 
to the input edge. This has been corrected.
And I added the option to specify a crude form of phase noise called 
"Freq noise"
Erik


On 6-8-2022 22:09, Magnus Danielson wrote:
> Erik,
>
> On 2022-08-06 09:15, Erik Kaashoek wrote:
>> Magnus,
>>
>> Many thanks for the reference to your article on linear regression. I 
>> will need a lot of time to study this as my math skills have become 
>> very rusty after not having been used for 40 years.
>
> Well, actually you will not need to know much math at all, as I use it 
> only to get rid of it. You only need to understand how to form the 
> sums C and D, and then do the estimations out of that using C, D, N 
> and tau_0.
>
> The linear algebra trick actually jumps behind the linear algebra 
> using the knowledge that measurements is a sequence of tau_0 distance, 
> and that allows significant reduction of the math into a much more 
> benign form. It also creates benign decimation methods that you can 
> apply to any form of your liking.
>
> Shaping the data in C and D summations properly, and you can avoid 
> roundings in that process, and only experience it in the final 
> estimation scaling, but after the cancellations.
>
> The cute thing is that each least square estimation, which is the same 
> as linear regression, done using these methods will strictly respect 
> the least square and not compromise through averaging etc. 
> Accumulation can be done in blocks and then be merged as if it was 
> accumulated in direct sequence. So you could to a small tight 
> decimation for say 1024 samples and then do a more costly decimation 
> for multiples of that.
>
>> Not sure what you meant with "cancelation"
>>
>> What I did is much much more simple.
>> The Excel simulation is an easy way to understand the calculations [1]
>> Let me know if you can not open an Excel file.
>>
>> The input data is in red cells
>> The important output is in blue cells (phase, frequency)
>> The formula are in green cells
>> The "time noise" input was to check if dithering of the interpolation 
>> points over time could improve the outcome, which it did not.
>>
>> The internal ref frequency is derived from a 10MHz reference using a PLL
>>
>> In the real code all sums are calculated in 32 or 64 bit integers. 
>> This limits the maximum gate time to somewhere above 10 seconds.
>> The simulation uses 0.1 ms interval between the interpolation points, 
>> the actual implementation uses 0.05 ms
>> At the gate moment the final divide into a 64 bit double is done, if 
>> sufficient interpolation points, otherwise the direct calculation is 
>> used.
>>
>> As you can see in the Regression error graph the final gate moment 
>> has a big influence on the error which is a pity as the pattern in 
>> the error suggests there is something that can be "interpolated" or 
>> eliminated
>> And the impact of the final gate moment increases when close to an 
>> integer multiply/divide relation to the reference.
>>
>> Hope, once I understand your algorithm, this can be improved.
>>
>> [1] http://athome.kaashoek.com/time-nuts/Regression.xlsx
>
> OK, I will check this. Thanks for providing it.
>
> Cheers,
> Magnus
>




More information about the Time-nuts_lists.febo.com mailing list