Hi > On May 14, 2018, at 1:50 PM, Oleg Skydan <olegsky...@gmail.com> wrote: > > Hi! > > From: "Bob kb8tq" <kb...@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ 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.
