Ferran,

I'm glad you mentioned your requirements. Note that time synchronization at a "ps level" is 3 to 4 orders of magnitude beyond what the typical commercial or eBay or DIY GPSDO will do.

But as you imply, you're only using GPS to get close (ns levels) and then using your own two-way communication to narrow it down to ps levels, right?

Yes. Section "A.10.31 Report Packet 0x8F-AC Secondary Timing Packet" says:

"PPS Offset: This field carries the offset of the PPS output relative to UTC or GPS as
reported by the GPS receiver in nanoseconds. Positive values indicate that the
ThunderBolt’s PPS is coming out late relative to GPS or UTC."

The range and precision of that time interval value would look something like this:

http://leapsecond.com/pages/tbolt-8d/

I can send you the raw data if you want to play with it. Attached is a histogram. Note the standard deviation is about 2 ns.

Remember that all the ingredients in your system will then need to be stable to ps levels: the oscillator, the DAC, the 1PPS pulse, the cables, the input signal conditioning, and time or phase comparator, etc. That's a pretty tall order but not impossible.

You may want to synchronize using 10 MHz instead of 1PPS to reduce your noise and improve the tight lock. How far apart are your two oscillators?

In case it helps your effort, see https://en.wikipedia.org/wiki/The_White_Rabbit_Project and read the PDF's. It's an open h/w project.

/tvb

Hi

Unfortunately there are no “stock” boards to do this sort of thing. If this is a commercial
requirement, there are companies who do this kind of thing on a custom basis. Figure on
a few thousand dollars NRE and a minimum order of a few hundred to get somebody
interested. At the “couple ps” level, the NRE may be a bit above the few thousand
level. Also expect to supply a full spec requirement when you go shopping ….

Bob

On Mon, 29 Oct 2018 06:38:03 +0000
Ferran Valdés vantta@hotmail.com wrote:

Clock synchronization? Possibly fault tolerant? I think that's my
area of expertise :-)

I have something ready, that can synchronize 4 independent clocks
to eachother at the 180ps level, limited by the FPGA based TDC.
The current incarnation does not allow for an external clock source
to syncrhonize to, but that should be easy to add. That is, if you
don't mind using some half-finished we-have-published-a-paper research
tool.

But going to ps level of synchronization, especially if you mean <10ps,
is not going to be easy. There are not many ways to measure pulses
with this accuracy. If you know what you are doing, about 1-3ps RMS is the
practical limit you can achieve, more likely it'll be in the order of 10-30ps,
for a one-off design. Also keep in mind that ~2mm of cable is already 10ps of
phase shift. Ie you will need to calibrate your cables as well. Cables,
which are of course low dispersion and low temperature coefficient cables.
The dispersion is important so that your pulse remains a sharp pulse.
through the cable and doesn't come out grabled as a weird wave packet,
Quite counter-intuitively, limiting the slew rate might help with this.
The low TC is important if there is any distance between the two
oscillators. Otherwise you can get up to several ps per °C temperature
change and meter cable length for run of the mill cables. If you have
PTFE cables, you also want to keep them well above 25°C or well below 15°C,
for the same reason.

		Attila Kinali

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

Hi

Ok, let’s take a look at this is a bit more detail. Let’s say you have a reference oscillator ( = the source
of sync) and a locked oscillator ( = the target of the sync).

Both devices have jitter. Unfortunately this an ill defined term and we can go on almost forever about what
is or isn’t a valid measure. One way to measure it is ADEV, there are many others. Since ADEV data is
commonly available ( rather than it being a perfect measure), lets use ADEV while understanding that it
is not perfect.

If 1 pps is the base timing exchange point, the jitter we are concerned with will be in the vicinity of 1 second.
A good guess is that a practical control loop will need a few samples to work properly and that you probably
will be still concerned past 10 seconds.

If the net result is going to be “sync to a couple of ps”, then the ADEV on both sources likely needs to be
well below the sync target. How far is going to depend a lot on the other noise sources in the system. A
few ps comes out to a total ADEV below 1x10^-11. If the combination needs to be well below, you may be in
the 1 to 4x10*-12 range.  Coming back to the “ADEV is not ideal”, the range of tau may well get out to the 0.1
second to 100 second range.

Indeed these are all fairly hand waving sorts of arguments. They should be treated more as general limits
than some sort of absolutes. If the sources involved are not at least in the general vicinity of these numbers,
you may  want to re-think things. One example of this is the fact that GPS is nowhere near as good as these
limits.

Simply put, you can’t sync to GPS to the “couple of ps” level. There is no target to hit at the “couple ps level”.
Down there,  it’s just noise.  Locking to noise and calling it “sync” makes no sense. If you build two devices and
compare them, they will not track at the desired level. This is the reason a typical GPSDO runs very long time
constants in it’s control loop and/or accepts a lot more time error than the low ps level. Indeed a many thousands
of dollars GPS will do about 10X better than a low cost unit. Even that device has way more noise that your target.

Another part of the very slow time constants involved in GPSDO’s is that when you switch between sources, there
is a long period of time while things re-align to the new signal (your external pps). The external signal almost
certainly has a time offset relative to GPS. How you handle that is up to you (do you re-align sync output to that
time or not). More subtly, it may have a drift rate. The control loop will need to be able to handle that as well. Various
telecom sync systems handle these issues in different ways. There is no single “right” solution.

Yes, there are a lot of assumptions and more than a few simplifications above.

Lots of fun !!

Bob