Hoi Ruslan,
On Sat, 5 Nov 2016 14:30:18 -0400
Ruslan Nabioullin <rnabioul...@gmail.com> wrote:
> On 11/03/2016 06:10 PM, Attila Kinali wrote:
> > You don't need a hardware project for this, as long as a paper clock
> > is enough for you. Just buy a couple of kiwi-sdr (or anything similar),
> > provide all of them with a common clock source and you get a comparison
> > of all your atomic clocks with minimum effort and can build from that
> > a paper clock easily. The paper clock can than be used for the measurement
> > you do, using one of the atomic clocks (preferably the one with the lowest
> > phase noise) as reference.
>
> If it's so relatively straightforward, then why not establish such a
> project instead of reinventing the wheel by attempting to perform atomic
> standard R&D and fabrication on a shoestring?
Could it be that you didn't see my small note on "paper clock"?
A paper clock is a virtual clock, one which only exists as list of
numbers in a computer. One that comes only into existence after the fact.
You create it by measuring all the clocks against each other, run your
ensemble algorithm on it and then you have a list that shows how each
clock deviated from the ensemble time.
This is the prefered over steering a clock for many reasons, but sometimes
a real physical realization of an ensemble clock is needed.
But even if you have a lot of atomic clocks, and a paper clock is all
you need, building an ensemble is not an easy task and there are lots
of little traps that one can fall into. One that is easy to see is, if
your clocks have a common source of instability, that is the same for all,
then this instability will not average out. The most common of these
instabilities is temperature variations, which affects especially Rb vapor
cells. Easy to keep stable you say? How about atmospheric pressure?
Humidity? Magnetic fields? The second trap most people fall into is
that adding and removing a clock from the ensemble causes a jump in
phase unless you do special adjustments. How to do them is definitely
not obvious.
I recommend reading at least Monographie 1994-1[1]. If you are interested
in building your own time scale, I can recommend you reading the papers
by Patrizia Tavella and Judah Levine in general. They give good overviews
of what the state of the art and its problems is and how to possibly
improve it.
Measuring the phase differences between the clocks is the easiest part
of it. Be it with some SDR setup that does everything in digital, or
with an almost completely analog DMDT setup. For a hobbyist grade system,
where ps to 100fs level of synchronization is sufficient, I would go
with a simple high-speed ADC based system that does everything in
an FPGA. The paper by Sherman and Jördens[2] tells you what you need
to do. And the book "Understanding Digital Signal Processing" by Loyds
contains all the information you need to actually implement it.
> It should be much more
> practical, even considering the fact that one will obtain diminishing
> returns on the ensemble's n, and furthermore should be extremely
> successful---apparently only a single Russian company holds a global
> monopoly on this product, apart from custom-fabricated setups in
> national metrology labs, and numerous people would benefit (why purchase
> an exorbitantly-expensive and short-lifespan cesium standard when one
> can fuse a redundant ensemble of rubidium standards?
They do not hold a monopoly on this kind of thing. It is more like
that the economics of such a product are that you will probably not
make any money from developing it. Beside the national labs that have
to produce a physical representation of UTC for one reason or other,
there are very few people who actually need something like this.
For most people a single GPS stabilized Rb standard is way better than
they require. Heck, I know of one guy who lost the GPS on his Rb-GPSDO
and didn't bother to replace it because "it wont lose more than a couple
of ms per year anyways".
And for those who need a physical realization of an clock ensemble, the
requirements can differ wastly. To the point that a single product might
not be able to fullfill the requirements of more than one or two labs.
Hence a lot of national labs build there own, from a time difference
measurement system and a phase/frequency microstepper, with some
computer inbetween that implements the algorithm (usually their own algorithm).
Besides, as I wrote before, creating a real-time realization of an
ensemble clock is not trivial at all. Neither phyisically/electronically
nor algorithmically. Do not underestimate the number of problems you
might run into when trying to do that.
A small annectode regarding this:
At an EFTF a couple of years ago, there was a presentation on the current
state of the GPS system, how they were doing things and how they planned
to improve it. The topic of the local GPS-time timescale got mentioned
and they said that they switched from a physical representation to a pure
paper clock some years ago. Apparently, the problems a physical representation
created were not easy to overcome and it didn't give much added value
over a paper clock. They also mentioned, due to the experience they had,
that they cannot understand why Galileo insists on having a phyical
representation.
And these are probably the two time labs with the largest available budget.
> Or for
> lower-budget and/or higher-MTBF setups, the same for a rubidium standard
> and OCXO standards, resp.)
I think you got your MTBF backwards. Adding more clock decreases MTBF.
The more components you have, the more likely it is that anyone of
those will fail. For a nice and easy to understand description of this,
google for MTBF on RAID systems.
If you insist on doing a fault-tolerant ensemble algorithm, then I welcome
you to a nice field of research, where basically nothing exists yet.
(There exist faul-tolerant clock syncrhonization systems, but none of
them have been analyzed with ensembles in mind and often have very low
synchornization capabilities)
> Another project, much simpler in comparison but even more useful, would
> be a rack-mount standard for an OCXO or rubidium physics package, which
> should consist of just a chassis, power supply, thermal structure, and a
> monitoring subsystem with interfaces (LEDs, an LCD display, and
> RS-232/USB/GPIB/Ethernet). The used market is flooded with cheap
> physics packages, yet actual standards are uncommon and expensive.
What do you mean by a "rack-mount standard"? A simple oscillator
in a rack-mount chassis with some electronics around it? What makes
this different from all the contraptions we usually build?
Attila Kinali
[1] "Time Scales", BIPM Monographie 1994-1, by Thomas, Woldf and Tavella
http://www.bipm.org/utils/common/pdf/monographies-misc/Monographie1994-1.pdf
[2] "Oscillator metrology with software defined Radio",
by Sherman and Jördens, 2016
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
_______________________________________________
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.
