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

[Magnus Danielson]

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

>
> On 5-8-2022 22:28, Magnus Danielson wrote:
>> Erik,
>>
>> Which algorithm of linear regression do you use? Describe the 
>> cancellation details.
>>
>> I just want to be sure we talk the same language here.
>>
>> Have you seen this? https://arxiv.org/abs/1604.01004
>>
>> Cheers,
>> Magnus
>>
>> On 8/4/22 20:04, Erik Kaashoek wrote:
>>> Bob, Magnus,
>>>
>>> Using a second counter (my famous Picotest U6200A) locked to the 
>>> reference output of the DIY counter and measuring the output of the 
>>> signal generator and also set to gate of 10 s it is confirmed that 
>>> the frequency pulling (if any) is below 1E-11 (not more digits on 
>>> the display of the U6200A)
>>> Generator is set to 10.000,000,000,2 MHz and is measured as such by 
>>> the U6200A
>>> As there seems to be no frequency pulling I went back to the 
>>> simulation of the linear regression algorithm and discovered that 
>>> when there is a integer  divide/multiply relation between the 
>>> internal reference and the measured frequency the regression looses 
>>> some accuracy.
>>> For sure if the reference is close to an integer multiple of the 
>>> measured frequency (10 Mhz measured -> 200 MHz reference) the 
>>> regression collapses completely in accuracy. I hoped that by 
>>> creating a fractional relation this collapse would not happen at 10 
>>> MHz but is still there, although much smaller. For this test I'm 
>>> using a "div 3 times 64 e.g. 213.333,333,333,333... MHz" internal 
>>> reference frequency derived from the external 10MHz reference. Ton 
>>> van Baak warned me against using fractional relations in a counter 
>>> but otherwise it is impossible to measure a 10 MHz input signal with 
>>> any accuracy without a HW time to digital as the interpolation no 
>>> longer works. I can switch dynamically to 200 MHz or 245 MHz 
>>> reference and these produce much much worse results.
>>> I realize this test only measures if the TCXO used as reference in 
>>> the DIY counter does not show frequency pulling but it does not show 
>>> if the PLL used to convert the 10MHz to 213.333333333... MHz for the 
>>> internal counters shows any frequency pulling.
>>> NOt
>>> Erik.
>