[time-nuts] Question about frequency counter testing

Bob kb8tq kb8tq at n1k.org
Mon May 14 19:15:18 UTC 2018


Hi

> On May 14, 2018, at 1:50 PM, Oleg Skydan <olegskydan at gmail.com> wrote:
> 
> Hi!
> 
> From: "Bob kb8tq" <kb8tq at n1k.org>
>>> If such conditions detected, I avoid problem by changing the counter clock. But it does not solve the effects at "about OCXO" * N or "about OCXO" / M. It is related to HW and I can probably control it only partially. I will try to improve clock and reference isolation in the "normal" HW and of cause I will thoroughly test such frequencies when that HW will be ready.
>> 
>> It’s a very common problem in this sort of counter. The “experts” have a lot of trouble with it
>> on their designs. One answer with simple enough hardware could be to run *two* clocks
>> all the time. Digitize them both and process the results from both.
> 
> I thought about such solution, unfortunately it can not be implemented because of HW limitations. Switching 400MHz clock is also not ideal solution, cause it will make trouble to GPS correction calculations, the latter can be fixed in software, but it is not an elegant solution. It all still needs some polishing...
> 
>> still have the issue of a frequency that is a multiple (or sub multiple) of both clocks.
> 
> The clocks (if we are talking about 400MHz) has very interesting values like 397501220.703Hz or 395001831.055Hz , so it will really occur very rarely. Also I am not limited by two or three values, so clock switching should solve the problem, but not in elegant way, cause it breaks normal work of GPS frequency correction algorithm, so additional steps to fix that will be required :-\.
> 

What I’m suggesting is that if the hardware is very simple and very cheap, simply put two chips on the board.
One runs at Clock A and the other runs at Clock B. At some point in the process you move the decimated data
from B over to A and finish out all the math there ….


> BTW, after quick check of the GPS module specs and OCXO's one it looks like a very simple algorithm can be used for frequency correction. OCXO frequency can be measured against GPS for a long enough period (some thousands of seconds, LR algorithm can be used here also) and we have got a correction coefficient. It can be updated at a rate of one second (probably we do not need to do it as fast). I do not believe it can be as simple. I feel I missed something :)…

That is one way it is done. A lot depends on the accuracy of the GPS PPS on your module. It is unfortunately fairly easy to find
modules that are in the 10’s of ns error on a second to second basis. Sawtooth correction can help this a bit. OCXO’s have warmup
characteristics that also can move them a bit in the first hours of use. 

More or less, with a thousand second observation time you will likely get below parts in 10^-10, but maybe not to the 1x10^-11 level.

Bob

> 
> All the best!
> Oleg 
> _______________________________________________
> 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_lists.febo.com mailing list