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 > On Oct 29, 2018, at 2:38 AM, Ferran Valdés <van...@hotmail.com> wrote: > > > > 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-nuts@lists.febo.com > 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-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
