[time-nuts] Question about the PLL of Trimble Thunderbold

[Ferran Valdés]

Hello everyone ! I am new in here. I got referred to time-nuts by a colleague, and after reading a bit, I think that is the right place for this kind of questions :)

I have in mind a project which consists in synchronizing two or more stable clocks (OCXO) disciplined by GPS.

However, would be great to have the option to disable the GPS on both sides at a given time and to synchronize them in a Master-Slave or directly by means of a protocol they could correct each other and synchronize themselves.

After some research, the Trimble Thunderbold board got my attention, as has everything I need to get the project started.

Before getting a pair of the boards, on the datasheet is explained that one can get the unit on a disconnected state and adjust the ADC which drives the OCXO directly (that’s one of the desired capabilities !).

The question is: does anybody know if the phase difference (input of the PLL) can be read, in order to know how to steer the ADC ??

Alternatively, could you please suggest another board that would fulfil the following?

- GPS can be disabled.
- has a serial com port, so commands can be sent to the unit and information can be retrieved.
- provides 1PPS and 10MHz signals.

Thank you very much for your attention,
Ferran
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow

[Bob kb8tq]

Hi

The Thunderbolt actually is not a real good solution if you want to synchronize to something other than GPS. It
depends on direct phase data from its internal GPS chip set to do the GPSDO magic. A board that has a PPS
signal between the GPS and “PLL” probably is a better way to go.

Even with a board that has a PPS internally, it’s not going to like an abrupt phase change between GPS and “something
else”. It needs some customization of the firmware to handle this kind of transition. That makes your project more of a
“from scratch” kind of thing ….

Bob

Post by Ferran Valdés
Hello everyone ! I am new in here. I got referred to time-nuts by a colleague, and after reading a bit, I think that is the right place for this kind of questions :)
I have in mind a project which consists in synchronizing two or more stable clocks (OCXO) disciplined by GPS.
However, would be great to have the option to disable the GPS on both sides at a given time and to synchronize them in a Master-Slave or directly by means of a protocol they could correct each other and synchronize themselves.
After some research, the Trimble Thunderbold board got my attention, as has everything I need to get the project started.
Before getting a pair of the boards, on the datasheet is explained that one can get the unit on a disconnected state and adjust the ADC which drives the OCXO directly (that’s one of the desired capabilities !).
The question is: does anybody know if the phase difference (input of the PLL) can be read, in order to know how to steer the ADC ??
Alternatively, could you please suggest another board that would fulfil the following?
- GPS can be disabled.
- has a serial com port, so commands can be sent to the unit and information can be retrieved.
- provides 1PPS and 10MHz signals.
Thank you very much for your attention,
Ferran
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow th

[ew via time-nuts]

There are a couple of questions that have to be answereda what do you want to synchronize, 1 pps , 10 MHz or bothb what will you distribute 1 pps, 10 MHz or bothc what accuracy are you looking ford off the shelf or own assembly
e how cost sensitiveBert Kehren
In a message dated 10/24/2018 5:10:46 PM Eastern Standard Time, ***@hotmail.com writes:


Hello everyone ! I am new in here. I got referred to time-nuts by a colleague, and after reading a bit, I think that is the right place for this kind of questions :)
I have in mind a project which consists in synchronizing two or more stable clocks (OCXO) disciplined by GPS.
However, would be great to have the option to disable the GPS on both sides at a given time and to synchronize them in a Master-Slave or directly by means of a protocol they could correct each other and synchronize themselves.
After some research, the Trimble Thunderbold board got my attention, as has everything I need to get the project started.
Before getting a pair of the boards, on the datasheet is explained that one can get the unit on a disconnected state and adjust the ADC which drives the OCXO directly (that’s one of the desired capabilities !).
The question is: does anybody know if the phase difference (input of the PLL) can be read, in order to know how to steer the ADC ??
Alternatively, could you please suggest another board that would fulfil the following?
- GPS can be disabled.- has a serial com port, so commands can be sent to the unit and information can be retrieved.- provides 1PPS and 10MHz signals.
Thank you very much for your attention,Ferran_______________________________________________time-nuts mailing list -- time-***@lists.febo.comTo unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.comand follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_li

[Tom Van Baak]

Post by Ferran Valdés
I have in mind a project which consists in synchronizing two
or more stable clocks (OCXO) disciplined by GPS.

If the OCXO are disciplined by GPS then you have a GPSDO. There is no need, then, to synchronize the OCXO directly; they are all synchronized indirectly through GPS. Or perhaps I don't understand what you're actually trying to do.

It would also help, particularly on this list, to tell us if your synchronization goals are at the ms or us or ns level.

Post by Ferran Valdés
However, would be great to have the option to disable the GPS on both sides
at a given time and to synchronize them in a Master-Slave or directly by means
of a protocol they could correct each other and synchronize themselves.

It's easy to disable GPS. Choose one of:

1) Remove the gps antenna connector, or
2) Cover the antenna with a RF shield, or
3) Use a RF relay inline with the GPS antenna feed, or
4) Kill the power to the antenna, or
5) Hack the PCB and disable the 1PPS from the receiver, or
6) Use s/w commands to disable the discipline loop. The Trimble TBolt has such a feature. It's very handy.

Post by Ferran Valdés
After some research, the Trimble Thunderbold board got my attention, as has everything I need to get the project started.

Yes, the Thunderbolt, aka TBolt, is a favorite. I assume you're talking about getting used ones on eBay rather than buying new from Trimble?

Post by Ferran Valdés
Before getting a pair of the boards, on the datasheet is explained that one can
get the unit on a disconnected state and adjust the ADC which drives the OCXO
directly (that’s one of the desired capabilities !).

Yes, there are several states you can configure. And yes, you can jam sync or set the DAC manually if you wish. There is no ADC; is that a typo or are you thinking there's something to read from the OCXO?

Post by Ferran Valdés
The question is: does anybody know if the phase difference (input of the PLL)
can be read, in order to know how to steer the ADC ??

Yes, the phase difference, often called TI (as in Time Interval), is reported by the TBolt. This is the recent delta between the GPS/1PPS and the OCXO/1Hz. Most GPSDO give you this information. You could then do your own steering using the DAC commands to close the loop. You won't match native performance but it's fine for testing & playing.

For the TBolt you can play with all of this using:

1) Trimble's TBoltmon.exe program, a simple GUI that let's you read/write any modes and settings.
2) Mark Sim's Heather program, a "feature rich" tool that many on this list use.
3) Roll your own command using TSIP, the serial protocol that Trimble uses. Sample code on the web.

Post by Ferran Valdés
Alternatively, could you please suggest another board that would fulfil the following?
- GPS can be disabled.
- has a serial com port, so commands can be sent to the unit and information can be retrieved.
- provides 1PPS and 10MHz signals.

Most GPSDO will do this. If you want something cheap, simple, and direct control over everything inside consider one of the Arduino-based GPSDO kits/products. That way you get source code and can do anything you want to the s/w.

And again, let us know if your synchronization goals are at the ms or us or ns level. Or perhaps describe in technical detail what problem you're working on, and what your constraints are.

Thanks,
/tvb


_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and fol

[Mark Sims]

Lady Heather has an "alternative discipling" routine that "manually" controls the DAC to discipline the oscillator. It was developed with the help of Warren Sarkison. It's performance can exceed the Thunderbolt's native disciplining algorithm.

-----------------

Post by Tom Van Baak
Yes, the phase difference, often called TI (as in Time Interval), is reported by the TBolt. This is the recent delta between the GPS/1PPS and the OCXO/1Hz. Most GPSDO give you this information. You could then do your own steering using the DAC commands to close the loop. You won't match native performance but it's fine for testing & playing.

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

[Ferran Valdés]

Thanks everybody for your answers.



@ Bob kb8tq



Due to a development time constraint, I am looking for a board which has all the implemented hardware In order to have a good starting point. My aim is to let the oscillator to be disciplined by the GPS in normal operation, and at a given moment, an algorithm to take over the adjusting process without upsetting the PLL. My idea is to develop the control loop which will be able to synchronize one oscillator to another.



@ ew



A 1 PPS will be exchanged in between nodes (each node would have a GPSDO).



@ Tom Van Baak



Yes, a GPSDO is already self adjusting, but for my project, I would like to either use a GPS or to synchronize one node’s oscillator on another.



The synchronization goal is in the order of ps level.



@ Mark Sims



I have just taken a brief look at Lady Heater. I will go through the manual and get back to it. But what this program does is similar to what I am intending to do, so that’s quite nice to know that the Trimble Thunderbolt is a suitable board !



I am searching for the time interval, but I have not seen the parameter yet.



This is the command to set the DAC value --> 0x8E-A0 | Set/Request DAC values | 0x8F-A0



Within the Report Packet 0x8F-AC, the bytes 16-19 indicate “Estimate of UTC/GPS offset”, is this the time difference ?





I have seen that on eBay, there are listed some GPSDO modules, which claim to have a “trimble” or “symmetricon” GPSDO inside, and they provide a hardware platform to get access to the GPSDO parameters, however, it depends on the board which is mounted inside if the adjustment loop can be externally governed. Anybody got any experience with any of those boards?



Kind regards,

Ferran
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo

[Tom Van Baak]

Ferran,

Post by Ferran Valdés
The synchronization goal is in the order of ps level.

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?

Post by Ferran Valdés
Within the Report Packet 0x8F-AC, the bytes 16-19 indicate “Estimate of UTC/GPS offset”, is this the time difference ?

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.

Post by Ferran Valdés
My idea is to develop the control loop which will be able to synchronize one oscillator to another.

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

[Bob kb8tq]

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

Post by Ferran Valdés
Thanks everybody for your answers.
@ Bob kb8tq
Due to a development time constraint, I am looking for a board which has all the implemented hardware In order to have a good starting point. My aim is to let the oscillator to be disciplined by the GPS in normal operation, and at a given moment, an algorithm to take over the adjusting process without upsetting the PLL. My idea is to develop the control loop which will be able to synchronize one oscillator to another.
@ ew
A 1 PPS will be exchanged in between nodes (each node would have a GPSDO).
@ Tom Van Baak
Yes, a GPSDO is already self adjusting, but for my project, I would like to either use a GPS or to synchronize one node’s oscillator on another.
The synchronization goal is in the order of ps level.
@ Mark Sims
I have just taken a brief look at Lady Heater. I will go through the manual and get back to it. But what this program does is similar to what I am intending to do, so that’s quite nice to know that the Trimble Thunderbolt is a suitable board !
I am searching for the time interval, but I have not seen the parameter yet.
This is the command to set the DAC value --> 0x8E-A0 | Set/Request DAC values | 0x8F-A0
Within the Report Packet 0x8F-AC, the bytes 16-19 indicate “Estimate of UTC/GPS offset”, is this the time difference ?
I have seen that on eBay, there are listed some GPSDO modules, which claim to have a “trimble” or “symmetricon” GPSDO inside, and they provide a hardware platform to get access to the GPSDO parameters, however, it depends on the board which is mounted inside if the adjustment loop can be externally governed. Anybody got any experience with any of those boards?
Kind regards,
Ferran
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-n

[Attila Kinali]

On Mon, 29 Oct 2018 06:38:03 +0000

Post by Ferran Valdés
Yes, a GPSDO is already self adjusting, but for my project, I would like to either use a GPS or to synchronize one node’s oscillator on another.
The synchronization goal is in the order of ps level

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

[Attila Kinali]

On Mon, 29 Oct 2018 12:03:25 -0700

If I go looking for good cables, do they specify temperature coefficient? I
don't remember ever seeing it when scanning specs, but I probably wasn't
looking for it so I could have skimmed over something.

Yes. The key word here is "phase stable coax." If you search for that,
several cables will pop up. They wont be cheap, though.

What determines the dispersion of a cable? Is it as simple as bigger wire
(more copper) is better?

For us, it's mostly the frequency dependence of the dielectric.
If you go for higher frequencies, it also becomes a matter of
the different modes a cable supports, which all have different
velocities. The latter is the reason, why GHz cables and connectors
are becomming thinner and thinner as we go up in frequency.

Why do I care about the dispersion as long as all cables match?

Because it degrades the slew rate of the pulse. If you have
a very bad case of dispersion (combined with long cables),
the rising slope will look more like a jagged mountain range
than a step (though it's unlikely you hit that with modern
cables, unless you go for several km of cable). Attached is
a picture of what it might look like.

If you remember the old telegraph and telephone lines, they
all used to have inductors placed on them every few km, to
compensate the dispersion. As most of our communication these
days is digital and we have relative short lengths before a
regeneration step happens, there isn't much need for dispersion
compensation anymore. Unless you go for submarine cables or
optical fibers, both of which have elements with negative
dispersion inserted.

Attila Kinali

[Bob kb8tq]

Hi

Post by Attila Kinali
On Mon, 29 Oct 2018 12:03:25 -0700

If I go looking for good cables, do they specify temperature coefficient? I
don't remember ever seeing it when scanning specs, but I probably wasn't
looking for it so I could have skimmed over something.

Yes. The key word here is "phase stable coax." If you search for that,
several cables will pop up. They wont be cheap, though.

What determines the dispersion of a cable? Is it as simple as bigger wire
(more copper) is better?

For us, it's mostly the frequency dependence of the dielectric.
If you go for higher frequencies, it also becomes a matter of
the different modes a cable supports, which all have different
velocities. The latter is the reason, why GHz cables and connectors
are becomming thinner and thinner as we go up in frequency.

Why do I care about the dispersion as long as all cables match?

Because it degrades the slew rate of the pulse. If you have
a very bad case of dispersion (combined with long cables),
the rising slope will look more like a jagged mountain range
than a step (though it's unlikely you hit that with modern
cables, unless you go for several km of cable). Attached is
a picture of what it might look like.
If you remember the old telegraph and telephone lines, they
all used to have inductors placed on them every few km, to
compensate the dispersion. As most of our communication these
days is digital and we have relative short lengths before a
regeneration step happens, there isn't much need for dispersion
compensation anymore. Unless you go for submarine cables or
optical fibers, both of which have elements with negative
dispersion inserted.

Even worse things can happen when you have an air dielectric cable and
evenly spaced supports. Putting a pulse into something like that can
be *very* messy.

Bob

Post by Attila Kinali
Attila Kinali
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
<dispersion.png>_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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

Post by Ferran Valdés
Thanks everybody for your answers.
@ Bob kb8tq
Due to a development time constraint, I am looking for a board which has all the implemented hardware In order to have a good starting point. My aim is to let the oscillator to be disciplined by the GPS in normal operation, and at a given moment, an algorithm to take over the adjusting process without upsetting the PLL. My idea is to develop the control loop which will be able to synchronize one oscillator to another.
@ ew
A 1 PPS will be exchanged in between nodes (each node would have a GPSDO).
@ Tom Van Baak
Yes, a GPSDO is already self adjusting, but for my project, I would like to either use a GPS or to synchronize one node’s oscillator on another.
The synchronization goal is in the order of ps level.
@ Mark Sims
I have just taken a brief look at Lady Heater. I will go through the manual and get back to it. But what this program does is similar to what I am intending to do, so that’s quite nice to know that the Trimble Thunderbolt is a suitable board !
I am searching for the time interval, but I have not seen the parameter yet.
This is the command to set the DAC value --> 0x8E-A0 | Set/Request DAC values | 0x8F-A0
Within the Report Packet 0x8F-AC, the bytes 16-19 indicate “Estimate of UTC/GPS offset”, is this the time difference ?
I have seen that on eBay, there are listed some GPSDO modules, which claim to have a “trimble” or “symmetricon” GPSDO inside, and they provide a hardware platform to get access to the GPSDO parameters, however, it depends on the board which is mounted inside if the adjustment loop can be externally governed. Anybody got any experience with any of those boards?
Kind regards,
Ferran
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow t

[Tom Van Baak]

Post by Ferran Valdés
I have in mind a project which consists in synchronizing two or more stable
clocks (OCXO) disciplined by GPS.
However, would be great to have the option to disable the GPS on both sides
at a given time and to synchronize them in a Master-Slave or directly by means
of a protocol they could correct each other and synchronize themselves.

Given your desire to synchronize the clocks at picosecond levels consider using 10 MHz instead of 1PPS. What you are designing then is just a very tight PLL to keep the oscillators in sync. Leave GPS and 1PPS out of the equation; just focus on the RF signals. Once you have meet your 100 or 10 or couple of ps goal then adding the coarse timing is quite simple. There are several ways to do the UTC/1PPS part:

1) Out of 10 million cycles you pick the cycle that's closest to your best GPS/1PPS. And then steer the synchronized OCXO by +/- 50 ns to match GPS. I don't know how happy the PLL will be sliding 50 ns when it is designed to lock within ps, but I'm sure that's a solvable problem.

2) Out of 10 million cycles you pick the cycle that's closest to your best GPS/1PPS. And then just record the +/- 50 ns offset as data and send it over a serial port to the other oscillators in your ensemble.

The point is there are two ways to do timing. The hard way is to generate 10 MHz and 1PPS signal that is exactly UTC. The easy way is to generate 10 MHz and 1PPS along with a message telling you what the offset is (or was). It's similar to how saw tooth correction is done; you don't need an exact on-time pulse as long as you are given information to calculate the exact time of the pulse.

----

Question for the list -- who of you have done multi-oscillator PLL's? Can two 10 MHz OCXO be locked to within 10 or 1 ps? For now, ignore cable issues and assume they're right next to each other.

Years ago John Miles did a write-up on Warren Sarkinson's prototype TPLL. [1] If that achieves resolution of 1e-13 @ 1 s would that imply the PLL is locking to sub-ps levels?

Warren -- Are you still on the list? Syncing multiple 10811A oscillators to extreme levels sounds like something you would have tried. Either just for fun, or to create an N-way ensemble of OCXO for the purpose of reducing phase noise.

Rick -- Do you remember the 8-way (?) 10811A phase noise reference standard that Len used in the 5071A lab in Santa Clara?

/tvb

[1] http://www.ke5fx.com/tpll.htm


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

[Attila Kinali]

On Wed, 31 Oct 2018 14:45:06 -0700

Post by Tom Van Baak
Question for the list -- who of you have done multi-oscillator PLL's? Can two
10 MHz OCXO be locked to within 10 or 1 ps? For now, ignore cable issues and > assume they're right next to each other.

I've done that at the beginning of my PhD[1], though it's probably not
exactly what you have in mind. Synchronizing an arbitrary number of clocks
(or oscillators) is pretty easy. The limit of synchronity is given by:
1) uncertainty of delays between nodes
2) uncertainty of measurement at each node
3) length of measurement interval vs stability of local oscillator

If we ignore 1) and assume that the oscillators are stable within
the measurement interval, then 3) can be ignored as well, which
leaves 2) as the only limit of synchronization.

The limit of pulse measurement is, depending on the method used,
between 0.5ps and 2ps. To go below that, one has to use something
that either is able to amplify the phase difference (e.g. DMTD)
or average over multiple measurements to remove some noise.
That said, the long term stability of any of these measurements is,
as far as I am aware of, in the order of a few ps unless path differences
can be constantly measured and calibrated out (e.g. by injecting
a pilot tone into a DMTD system [2]).

There are also commercial multi-input phase comparison systems available,
based on DMTD or DMTD-like systems.

Compared to that, the algorithm part is easy, safe for one point:
There is a slight problem with connvergence of phases, if arbitrary
starting phases are allowed. In that case, it's possible to come up with
situation in which the whole system will never converge, even if all
the nodes are working correctly.
So far, we have not been able to come up with any system/algorithm
that would work always. Fortunately, these situations seem to be
fragile enough that in reality we have never seen this happening.
And if a startup phase is allowed, then it's also pretty easy to
ensure that initial synchronization ensures convergence.

Other than that, the system can be quite considerably simplified
and some of the synchronizatino limits become tighter, if byzantine
fault-tolerance is not required. It's even pretty easy to show
that, if only crash faults are allowed, and all nodes have the same
view (up to noise), then a simple averaging or median works well.

Summa sumarum, what can be done and how it will perform is mostly
a matter of the external conditions of the system, i.e. whether
pulse or sine synchronization can be done, whether there are
dedicated cables between the nodes or synchronization has to
piggy pack on existing protocol on the cables or even whether
it has to be done wirelessly, what the distance is, etc pp

Attila Kinali


[1] "Fault-tolerant Clock Synchronization with High Precision",
by Kinali, Huemer, Lenzen, 2016
http://people.mpi-inf.mpg.de/~adogan/pubs/KHL16precision.pdf

[2] "2π Low Drift Phase Detector for High-Precision Measurements",
by Szymon Jablonski, Krzysztof Czuba, Frank Ludwig, and Holger Schlarb, 2015

[Magnus Danielson]

Hi Tom,

Post by Tom Van Baak

Post by Ferran Valdés
I have in mind a project which consists in synchronizing two or more stable
clocks (OCXO) disciplined by GPS.
However, would be great to have the option to disable the GPS on both sides
at a given time and to synchronize them in a Master-Slave or directly by means
of a protocol they could correct each other and synchronize themselves.

1) Out of 10 million cycles you pick the cycle that's closest to your best GPS/1PPS. And then steer the synchronized OCXO by +/- 50 ns to match GPS. I don't know how happy the PLL will be sliding 50 ns when it is designed to lock within ps, but I'm sure that's a solvable problem.

Phase-jumping to the nearest transition is the first trick in the bag.
It saves significant amount of time, seems obvious but it is part of the
lock-in procedure of phase.

The trick used then is to separate general lock-in from precision
lock-in. By starting in a wide bandwidth, the general lock-in goes very
quickly, and then to move to a more tightly locked state, one steps to a
tighter bandwidth. This can be done with one or more intermediate steps
for stepwise refinement.

Post by Tom Van Baak
2) Out of 10 million cycles you pick the cycle that's closest to your best GPS/1PPS. And then just record the +/- 50 ns offset as data and send it over a serial port to the other oscillators in your ensemble.
The point is there are two ways to do timing. The hard way is to generate 10 MHz and 1PPS signal that is exactly UTC. The easy way is to generate 10 MHz and 1PPS along with a message telling you what the offset is (or was). It's similar to how saw tooth correction is done; you don't need an exact on-time pulse as long as you are given information to calculate the exact time of the pulse.
----
Question for the list -- who of you have done multi-oscillator PLL's? Can two 10 MHz OCXO be locked to within 10 or 1 ps? For now, ignore cable issues and assume they're right next to each other.

I do similar enough things.

If you have a stable enough common reference, yes.

It's really about making sure you either react similar enough to noise
or have low enough noise that it doesn't care.

It's actually more beneficial to have a wide bandwidth PLL, since it
helps to track in difference in thermal and power before it starts to
create a large enough frequency difference. It boils down to what is
most important, the relative timing between the two clocks or stability
of the clocks.

For one system I have two clocks that acts as redundant clocks, one of
the two gets voted master and the other slave. If difference is too
large, it causes alarms. The trick is that the master has a tight
bandwidth for stability, and the slave has a higher bandwidth to track
the master closely. This produces a clock pair which is very tight for
the application. Where I only needed a few 10ths of ns, similar due care
is needed in any such system. Naturally delay offsets needs to be
compensated, and that is typically done by offsetting the mixers
through-zero point with a DC offset, and then let the PI loop drive it
to zero. The DC-offset is trimmed to have phase alignment.
Not as such. It's more a per-requisit of having enough resolution and
low enough noise (really two different things which has a euhm...
complex interaction it turns out).

With that, you need to be careful to have a good control loop, and my
preference ends up with a well-damped PI-loop. Potentially with an
additional low-pass filter in it.

The reason for it to be well-damped is two-folded, first of all the most
obvious one, the initial step needs to ring out quickly enough or you
have to wait for a minor eternity for it to stabilize and that in itself
makes it relatively unuseful. Secondly, the more undamped loop you have,
the more jitter-peaking you experience at the loop resonance frequency,
and as you aim to push it down to 10 ps or 1 ps this will for sure hurt you.

Post by Tom Van Baak
Warren -- Are you still on the list? Syncing multiple 10811A oscillators to extreme levels sounds like something you would have tried. Either just for fun, or to create an N-way ensemble of OCXO for the purpose of reducing phase noise.

I hope he is still on the list. Miss him.

Physical ensembles is something I have intended to do, but never got
around to do, except of the redundancy ensamble I do.

Post by Tom Van Baak
Rick -- Do you remember the 8-way (?) 10811A phase noise reference standard that Len used in the 5071A lab in Santa Clara?

I don't recall hearing about such a beast at HP, but love to hear more
about it. To achieve the needed effect, the actual phase does not have
to match up all that well, it just needs to become stable. A few ps here
or there does not hurt the mission need for static offsets.

I've considered doing a small board to achieve mutual sync of
oscillators. It would not be too hard to build a hierarchy of these to
form 4-way or 8-way using pair-wise locking.

Cheers,
Magnus

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

[ew via time-nuts]

Weeks ago there was interest in a board we did to test or use OCXO's. I did listen to comments and added inputs. The result are two boards Gerber files are attached. for any one to use. Because of restrictions there will be two postings. First the original boardBert Kehren

[ew via time-nuts]

This board includes recommendations has not been tested but is based on an amp some of us have used. Layout has been reviewed  by others but no guarantee. Most OCXO pin outs and trim pods are the same.Use as you see fitBert Kehren