[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