[time-nuts] FW: Question about the PLL of Trimble Thunderbold
vantta at hotmail.com
Tue Oct 30 16:22:03 EDT 2018
Thank you all for your answers,
I do have an additional question. Did anybody install an external 1PPS/10MHz input to the Trimble Thunderbolt board ??
With the idea that, when the adjustment loop is deactivated, an external signal can be supplied to the Thunderbolt, and the Time Interval circuit could show the difference in between this signal and the feedback of the VCO.
@ Bob kb8tq
The aim of this project has no commercial purposes and the project itself is to develop the algorithm which will be in charge of adjusting the clocks. Also is yet to be determined the information that will be exchanged in between nodes in order to achieve as accurate synchronization as possible.
>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 ?.
Could you please share a link/name of the paper ? All information is welcome !
The method that you've developed, synchronizes 4 local clocks in reference to one, or they keep a certain difference all together in between themselves ?? Which FPGA are you using ?
>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
Lets say that the objective is to reach 50ps. Of course is not an easy to achieve goal, but that's the purpose of the project, to try to achieve as best synchronization as possible within an strict time frame.
Part of the project will consist in taking into account the propagation delay in between the medium used, be it a cable, fiber or radio link. Still to be determined, but most likely it will be a cable.
Nice tips on the cables, I will do a documentation research to learn further.
>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.
@Tom Van Baak
>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.
Well, I did a research in order to find suitable boards, and the ones on eBay got my attention, because they were quite affordable and were using used GPSDO's from Trimble or Symmetricon. And I saw some people getting good results with them, so I had to ask.
>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, the GPS is intended to provide a “coarse” adjustment, but even in the case that there's no GPS signal at all, the nodes will need to synchronize in between themselves without an external reference but in respect to a single node. As the method that all the nodes exchange information and correct with each other, would increase the complexity of the project notably.
>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:
>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.
Thanks for the plots !! For the moment is enough just to see how good the thunderbolt performs.
>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.
Yes, is ambitious, we will see where do I get.
>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?
The idea of using 1PPS is for compatibility reasons, but the 10MHz signal sounds like a good idea.
At the beginning, the oscillators will be maximum 5 meters apart, but at a later stage, the distance would be increased, depends on how the development advances.
More information about the time-nuts