I think the answer to this is probably no but it would make a nice project. I say no because your GPSDO will already be benefiting the from the clocks in GPS constellation that are being steered, probably indirectly) by the UTC(NIST) clocks, steered by the AT1 time scale, created from a whole bunch of cesium , maser and optical clocks  , so your GPSDO is the equivalent of a master clock. This means that you only need one…well three to verify that one is not going on the blink. A GPSDO or Rubidium stability will probably be in the range of a few parts in 10^11 - 10^12.
Measuring the phase offsets of a bunch go those and applying corrections to a another free running clock might buy you a zero but it is questionable I think. You are probably constrained by the quality of the chosen ‘master’. If there was a distinct advantage I would expect to see products on the market using this approach. I haven’t heard of any.

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin

Hi

The answer is (of course) yes. The somewhat more detailed answer is that it actually is a practical basement sort of thing if
you have the space. I was headed off to do this and changed course. That’s just my lack of focus rather than it being an
un-doable sort of thing. What’s below is sort of a random walk through doing it.

The first thing you need (after all the standards) is a way to do precision comparisons of all your devices. There are an infinite
number of ways to do this. Let’s say you buy 26 TICC’s to do the job ( TAPPR needs 25 ordered to get the next batch going
so that would solve two problems at once :) ). A PPS from a single source with good short term stability (maybe an OCXO) goes
into one side of all of them. A pps from a DUT goes in the other side (yes there are other ways …TAPPR needs that order ….).
You then have 26 devices each reporting how a single standard compares to the “main OCXO”.

As. this chugs along you get a whole bunch of timestamps telling you how far your main OCXO is from each and every one of your
“standards”. Since 10 of them are GPSDO’s they likely will be doing some very similar things. For the moment let’s ignore that
and assume they are independent / uncorrelated sources. Since things like the Rb’s are free running data comes in spread out
over the second, collecting data and comparing it isn’t exact.

Once a second, you round up all the data and make a guess about what is correct. If everything is independent and equally
noisy and … and … and … your guess could be sqrt(N) better than any individual source. With 26 sources, you would be a bit
over 5X better than what you started with. You then diddle the EFC on an OCXO to put it inline with that estimate (yes that
may mean a 27th TICC).

Stepping back, there was a bit of hand waving going on there :

One assumption is that the TICC measurement noise at one second is better than the noise of the sources. That probably is
only true at much longer time spans (say >100 seconds). You can either upgrade the measurement or accept the longer time
span. (TICC is about 1x10^-10 at 1 sec, 1x10^-12 at 100 sec, and 1x10^-13 at 1,000 sec)

The “independent / uncorrelated sources” part is very suspect with a group of (possibly same manufacture) GPSDO’s in the mix.
A burp here or there in the way GPS L1 (I’m guessing they are L1) is behaving can easily swing them all at the same time.. Things
like temperature (Rb’s have temperature dependence) also can get into the mix.

One alternate that might actually be easier to deal with: Run 10 free running OCXO’s and the 16 Rb’s. Add some number of
GPS modules (with PPS outputs) to the mix. That way you will not be constantly fighting the unknown loop dynamics of the
GPSDO’s.

Next, somebody is likely to raise their hand and ask if the noise really is gaussian (and thus goes down as fast as the square root).
The same things that get into making the sources correlated (and some other things) contribute to them being non-gaussian in
this regard. Simple answer is you likely will not quite get to the 5X improvement advertised above. One thing you can do for
some effects is try to learn them via cross comparison. That gets into the guts of your software and how you decide to do this.

What the final result is at any specific tau will be very much a “that depends” sort of thing. The Rb’s have an ADEV curve that
should drop by sqrt(tau). ( 10X better ADEV at 100X tau). Most GPSDO’s fairly flat ADEV out to some “hump” and then they
follow GPS down from that point. If you actually steer an OCXO, the control loop will get into the act as well.

You might also look into ganging up the TICC’s to run 4 channels in one block. Unfortunately that would get the total order
below what TAPPR needs … :) That would let you compare three standards against the master in one block and cut the
total down to nine “pods” of two each.

Indeed a fun project. There are a lot of papers out there on various aspects of it. Jim Barnes and David Allan authored a lot
of them, either together or independently. Since they both worked at NIST, the papers are in the public domain.

Have fun !!!!

Bob

Anton
Others will reply but my sense is that there is little advantage in doing
that.
Assuming everything is the same in all 10 systems then you would be
measuring the receiver behaviors at a given moment. I simply am unclear
that there is an advantage.
Regards
Paul.

On Sat, Mar 16, 2019 at 11:00 PM Anton Moehammad via time-nuts <
time-nuts@lists.febo.com> wrote:

Just a couple of other measurement options on top of Bob's excellent
description.

You could half the number of TICCs by using them in timestamp mode with
a common 10 MHz clock serving as the reference -- in that mode you can
do two simultaneous measurements with each TICC.  There are some
hardware and software hooks built into the TICC to allow multiple units
to operate synchronously.  (But we still need 25 orders :-) ).

Second, as Bob mentions any PPS measurment is likely to be noisier at 1,
10, or 100 seconds than the sources you want to measure.  If you decide
to do one round of measurements every 1000 seconds, it's thoroughly
practical to use some sort of switch matrix to measure each of the DUT
in turn with a single TICC or other counter.  In other words, once each
1000 seconds switch each DUT in turn to the TICC START input long enough
to get one measurement.

That's what I designed the TAPR TASS coax switch system for -- it lets
you switch 8 DUT to one common output under USB control, and the
controller supports up to 4 switches so you can make a really big matrix
if you want (my setup at home has jacks for 24 DUT and 8 references).

A project like this is ripe for all sorts of hardware hackery!

John

On 3/17/19 10:58 AM, Bob kb8tq wrote:

Anton,

The rule-of-thumb is that, under the right conditions, N clocks will perform sqrt(N) better than 1 clock.

So yes, NIST, USNO, PTB, BIPM -- all the big boys -- use ensemble techniques. But the key is that they mostly use cesium clocks, not OCXO or Rb clocks from eBay. Laboratory cesium standards don't suffer from frequency drift. The other key is that the clocks are independent. Under these conditions one can obtain sqrt(N) advantage.

The problem with using cheap OCXO or Rb clocks is that they drift, and this drift may depend on make / model / environment; all of which are possibly common mode for you. This means the full sqrt(N) assumption is likely not valid.

The problem with using GPSDO is that they are not independent clocks. In fact, they aren't clocks at all: they are just noisy radio receivers, implementing "time transfer" from the USNO GPS master clock, which is related to but not equal to UTC(USNO) which is related to but not equal to UTC itself. There's a lot of common mode error amongst a set of GPSDO. This means the full sqrt(N) assumption is likely not valid.

Those who use GPS for highest accuracy tend not to use GPSDO. Instead they just collect raw timing information and post-process it some hours to weeks later. That is, they want to know
what time-it-was-precisely
rather than
what time-it-is-approximately.
A GPSDO only does the latter.

/tvb

On Sun, 17 Mar 2019 12:00:11 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:

Most of the Cs beam standards contributing to TAI are 5071s.
And, unfortunately, they do drift. As do almost all of the
atomic clocks contributing to TAI. There are a handful of
labs (IIRC 8) that run "the primary standards" which have
a low enough uncertainty of influences to be considered
non-drifting. IIRC all of them are are Cs fountains.
Also unfortunately, most of these cannot or are not operated
continuously. But according to METAS they don't need to be
as the 5071s are stable enough that measuring their frequency
once a month is enough to keep the uncertainty below what
time and frequncy transfer can deliver today.

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

On Sun, 17 Mar 2019 10:58:49 -0400
Bob kb8tq kb8tq@n1k.org wrote:

I would use here a variant of DMTD: Instead of comparing pairs
of standards, have one offset frequency generator feed multiple
mixers, one for each standard. This way, the standards can be
compared to eachother more easily. Downside of this is, that
the precision of this comparison depends on the stability of
the distribution of the offset frequency signal. Though, under
the assumption that ground loops can be kept in check, this
should be easier to ensure than having pair wise comparisons
not drifting away too much. When using TICCs, with their high
measurement rate, I would also go for an offset frequency in
the order of 1kHz instead of the customary 1-10Hz. This will
help getting away from the flicker noise region and also give
a much higher slope of the signal to work with, reducing the
white noise of the measurement. Additonally, this should
also give higher precision at tau = 1s, as the system is now
averaging down from 1ms instead of 100ms (when using 10Hz),
which could potentially give a boost of a factor of sqrt(100ms/1ms) = 10.

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

Hi

TAPPR needs that order for 25 TICC’s …… :)

There are indeed many ways to do it and each has it’s advantages and disadvantages.
With a DMTD sort of system, you can’t grab “off the shelf” hardware to get things up
and running quickly. Also the isolation / ground loop / spur problem is very likely to
get you on a DMTD like system with 20 to 30 devices on the same “party line”.

No ideal answer, just a lot of tradeoff’s.

Bob

Tom,

Thanks for the explanation of clock ensembles.  That answered a few
questions I've had for a while.
Regarding your comments on collecting raw time data from GPS and post
processing it.  Can you provide any reference info, links, etc. with more
detail on that topic?
Clearly I'd need a GPS that outputs the proper raw messaging and the
software for processing it.  I'm somewhat familiar with the techniques
involved to improve GPS position data, but hadn't thought about it as much
for timing.

Thanks,

Rodger

-----Original Message-----
From: time-nuts time-nuts-bounces@lists.febo.com On Behalf Of Tom Van Baak
Sent: Sunday, March 17, 2019 3:00 PM
To: Discussion of precise time and frequency measurement
time-nuts@lists.febo.com
Subject: Re: [time-nuts] Frequency Ensemble

have better stability ?

Anton,

The rule-of-thumb is that, under the right conditions, N clocks will
perform sqrt(N) better than 1 clock.

So yes, NIST, USNO, PTB, BIPM -- all the big boys -- use ensemble
techniques. But the key is that they mostly use cesium clocks, not OCXO or
Rb clocks from eBay. Laboratory cesium standards don't suffer from frequency
drift. The other key is that the clocks are independent. Under these
conditions one can obtain sqrt(N) advantage.

The problem with using cheap OCXO or Rb clocks is that they drift, and this
drift may depend on make / model / environment; all of which are possibly
common mode for you. This means the full sqrt(N) assumption is likely not
valid.

The problem with using GPSDO is that they are not independent clocks. In
fact, they aren't clocks at all: they are just noisy radio receivers,
implementing "time transfer" from the USNO GPS master clock, which is
related to but not equal to UTC(USNO) which is related to but not equal to
UTC itself. There's a lot of common mode error amongst a set of GPSDO. This
means the full sqrt(N) assumption is likely not valid.

Those who use GPS for highest accuracy tend not to use GPSDO. Instead they
just collect raw timing information and post-process it some hours to weeks
later. That is, they want to know
what time-it-was-precisely
rather than
what time-it-is-approximately.
A GPSDO only does the latter.

/tvb

time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Hi

There are a variety of GPS devices that put out a PPS. uBlox makes some, there
are a number of other companies that do so. The PPS comes out modulo the local
timebase. On a precision part, there is a “sawtooth correction” message that also
comes out to further quantify the best guess time of that pulse.

Noise wise, even with correction you are lucky to get a one second ADEV in the
1 to 2 ppb range with a typical L1 receiver. With a L1 / L2 device like the F9P,
you might do a bit better than that.

The ADEV of your other sources at short tau will be much better than the GPS PPS
noise. As you average out over long periods, the GPS will win the race.

Bob

If you search for "GNSS time transfer" you will find a lot of papers etc.
For example these might get you started:
https://www.bipm.org/ws/CCTF/TAI_TRAINING/Allowed/Fundamentals/Training-2012-GNSS-Defraigne.pdf
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7909843

I tried to collect some tools for PPP post-processing on github:
https://github.com/aewallin/ppp-tools
I am not sure what (open) software exists for common-view analysis...
PPP uses satellite clock-corrections and orbit-corrections from an IGS
data-centre. They have "ultra rapid" and "rapid" products (=downloadable
files) that are available with some days or hours of delay.
The "final" products can have up to two weeks (?) of delay.
With a dual-frequency receiver the ionosphere delay can be removed
('ionosphere-free L1/L2 linear combination') and my understanding is the
troposphere-delay (water content) is one of the larger remaining
uncertainties.

AW

On Mon, Mar 18, 2019 at 5:03 PM Rodger via time-nuts <
time-nuts@lists.febo.com> wrote:

On Mon, Mar 18, 2019 at 8:03 AM Rodger via time-nuts
time-nuts@lists.febo.com wrote:

As Bob says, the ublox chipsets from generation 6 onwards are probably
the best value as they can be configured to output the raw
measurements for precise position/time. There is info on configuring
these at OpenStreetMap and rtklibexplorer's wiki and blog respectively
and I also added a howto on my blog on doing this
(https://adventuresinprecision.space/howtos/precise-gps-positions/)

The OpenTTP project has code for capturing the raw data (ublox M8's
are supported right now, I am working on adding support for -6T and
the main developers are looking at adding support for the new ublox F9
chips) and software for doing the GPS Common View processing. I am
just starting to dig into this but need to get the last bit of the
ublox6 support working in order to give it some valid data to play
with. The other easily available GPS receiver that OpenTTP supports is
the Trimble Resolution T which I think has been "end-of-lifed" by
Trimble which has pros of being available cheap on ebay and cons of
not being able to buy a brand new "official" board unlike with the
ublox 8 and 9 receivers.

Cheers,
Tim

Hi

You can access an “NTRIP stream” from various free sites. There is some
mumbo jumbo on some of them to get an account. There are streams dedicated
to “clock and orbit correction”. CLK11 and CLK93 are two fairly common ones.

Since NTRIP is a real time product (as in < 30 seconds delay) it can be used for
“right now” sort of correction. RTKLIB is probably the most common way to get
the local receiver and an NTRIP stream combined.

If you just want to play with it ntrip.itsware.net http://ntrip.itsware.net/ port 2101 is a free / no registration source
of the CLK11 stream. They also have various other “correction product” streams
you can play with.

In theory (though I can in no way prove it yet) you should be able to reduce the
timing errors associated with the broadcast clock and orbit estimates by about an order
of magnitude. It is abundantly unclear what that translates into in nanoseconds due
to a whole lot of layers everything goes through…..

The NTRIP products are all aimed at surveying applications so there is a lot of translation
involved to get to the sort of time numbers we like to deal with. It should help, the big
question is how much (10 is unlikely …. sqrt(10) maybe …. sqrt(10) / 2 … who knows ….).

Bob

This project www.openttp.org provides software for post-processing of raw
data for time-transfer from some currently available single frequency
receivers. It provides CGGTTS and RINEX, the latter for use with the
various PPP services. There are some tools in there too for doing eg common
view and all-in-view comparisons. If you want to try it out, the develop
branch in the GitHub repo is the place to start. I'll be talking about it
at IFCS-EFTF.

Cheers
Michael

On Tue, 19 Mar 2019 at 5:08 am, Anders Wallin anders.e.e.wallin@gmail.com
wrote: