[time-nuts] GPSDO Alternatives

SAIDJACK at aol.com SAIDJACK at aol.com
Wed Dec 5 22:50:31 UTC 2012

Good list Bob,
many people underestimate what it takes to make a working,  commercial 
GPSDO, especially one that has to perform in volume and beyond a  single well 
taken care of unit in a Ham shack.
Once you have taken care of items 1) and 2), the real work begins. This is  
where our customers get confused some times, they think items 1) and 2) are 
easy  to do, and all that needs to be done to make a working product, and  
they try themselves.
We just had someone try connecting the CSAC to a GPS receiver themselves,  
and in their setup they spent two months trying to get it to work before 
they  gave up. The GPS behaved such that the CSAC could not lock onto it  
This happens quite often because at first sight it looks simple to do, and  
folks like Shera have come up with solutions that are simple and work well, 
but  don't have any bells or whistles.
One item often overlooked for example is that every OCXO during a  
production run behaves very differently from the OCXO next to it. The retrace  time 
is different. The tempco is different. The EFC sensitivity is specified in  
large ranges such as 1ppm to 10ppm, one crystal may jump, another may have 
EFC  hysterisis etc, and the software/hardware has to be able to handle all 
of these  variations without requiring every unit to be fine-tuned by  hand 
during production. And then the OCXO will actually change it's  behavior over 
time due to aging and deminishing retrace error as the unit  is operated 
It's surprising that we still find room to make major improvements to  our 
software 5 years after we sold the first Fury, for example we recently added 
 things like leapsecond prediction/compensation without having an almanac 
loaded  yet, with the help of a time-nut we found a very obscure bug in the 
NXP ARM  processor that was supposed to be fixed years ago but wasn't, and we 
 continuously keep improving and fine-tuning our algorithms and adding more 
 commands/features to it.
If there is one thing I learned, it is that one is never finished improving 
 the software. That is why we are time-nuts I guess.
In a message dated 12/5/2012 09:29:14 Pacific Standard Time, lists at rtty.us  


If the intent is to come up with something in the same  league as the TBolt
there are a few other things you will need:

1)  Something to compare the two pps signals to within 0.1 ns.
2) A large  amount of code on the control processor (there are a multitude 
special  cases ...)
3) A large amount of code on a PC to monitor it and control it  (like Lady
4) A set of standards to compare it to while you  train and debug it
5) The test gear to collect and analyze the comparison  and debug data with
(you will have many months of data)
6) Some sort of  control over the feature list. The complexity of 2-5 will 
up  significantly each time a nice to have thing is added. 

Once you get  past step one, the rest of that list dwarf's anything like
which D/A to  use. I'm not at all saying it can't be done. Only that the 
of the  effort starts after you have the hardware.  


More information about the time-nuts mailing list