Re: [time-nuts] Question about the PLL of Trimble Thunderbold
Hi Tom, On 10/31/18 10:45 PM, Tom Van Baak wrote: >> 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. 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. > 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. > 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? 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. > 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
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
Hi Ferran, Here's another idea for your multi-OCXO synchronization project. Normally when we think about synchronized oscillators we imagine two of them in side-by-side or perhaps separated by a few meters of cable. Through some PLL magic they remain in perfect phase (and frequency), either between themselves or also referenced to some third oscillator, like a GPSDO. The question is what are these two OCXO being used for. In the special case that the OCXO are being used as part of some signal measurement or data acquisition system, then consider this idea. Maybe you don't actually need the OCXO to be synchronized. Instead of requiring synchronization, why not just record what their phase relationship is at all times. You still compare the OCXO but you don't bother to steer them. If your application is going to do signal processing based on the OCXO it seems to me that you don't need the OCXO to be synchronized. What you need to know is what their relative phase is. And that offset is just fed into any existing math that you're already doing. This is not unlike how the clocks in GPS are "synchronized". They are not physically sync'd in phase or frequency. Instead each clock is free-running and several correction numbers are sent down as part of the data stream. The a0 and a1 numbers give the phase and frequency offset so that the user can construct virtual clocks that are synchronous. So if your application doesn't actually need physical synchronization but instead would work with virtual synchronization then you don't need to hack a GPSDO. Instead all you need are good OCXO's and high-performance phase comparators. The TAPR TICC is good to about 60 ps and works at 1 PPS. There is another device you may want to look at, the PicoPak [1]. It is good to 6 ps and works at 10 MHz. You could use one or more of these to monitor each OCXO in your ensemble and then use the comparator data stream to construct a virtual clock. Any measurements made from each OCXO could be adjusted in s/w relative to the virtual clock. So you could achieve ps-level virtual coherence in your data analysis without requiring ps-level physical coherence in each OCXO. I'll give you one example. If you wanted to build a ToA (time of arrival) system based on two independent receivers some distance apart you might need them to be highly synchronized. My point is, skip the synchronization, which might difficult at the ps level, and just measure the clocks continuously and precisely at the ps level. Then when you do your ToA math you just factor in the known clock offsets. This method would also help deal with cable propagation issues (e.g., temperature, stress), which you will want to measure (two-way) and factor into your synchronization. /tvb [1] http://www.wriley.com/PicoPak%20App%20Notes%20Links.htm There are 40+ papers in this folder by Bill Riley, who is one of the best T guys out there. Since you're new to time-nuts, you may also enjoy reading everything else written by Mr Riley. See: http://www.wriley.com/ ___ 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.
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
> 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-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2018-October/094520.html Pardon the interruption. If any of our 1800 members uses a Samsung / Galaxy Tab to compose email and can help Bert with his formatting issues, please contact Bert (ewkeh...@aol.com) or me (t...@leapsecond.com) off-list. I normally let stuff like this go, but I'm in a fix-it mood right now. Do not reply to this posting. Contact us off-list. Thanks, /tvb Moderator, www.leapsecond.com/time-nuts.htm ___ 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.
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
I have only worked with the GPS part of the KS system but some time nuts may be able to explore the use of the second half and they are available at areasonabble price Bert KehrenSent from my Galaxy Tab® A Original message From: Bob kb8tq Date: 10/30/18 5:43 PM (GMT-05:00) To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Question about the PLL of Trimble Thunderbold HiThe Trimble Thunderbolt does not have a 1 pps between the GPS chips and the OCXO. It makes the link between the two portions of the system in a different way than the typical GPSDO. It uses the OCXO as the clock reference for the GPS chip set. It then uses phase data on the received signal to “lock” the OCXO. The whole process is very much unique to the Trimble product line. To do a mod and extract a PPS, you would need to find a GPSDO based on something like a uBlox chip set or module. You potentially *could* cut a trace and inject a new PPS. For most devices, you would also have to generate the proper “status” messages that go from the uBox (or other module) to the control loop processor. Some of these messages are in response to specific queries. Others are generated automatically. Bob> On Oct 30, 2018, at 4:22 PM, Ferran Valdés wrote:> > 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.> > > >> 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> > > > @Attila Kinali> > > > > > 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> >> tool.> > > > 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> &g
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
Hi The Trimble Thunderbolt does not have a 1 pps between the GPS chips and the OCXO. It makes the link between the two portions of the system in a different way than the typical GPSDO. It uses the OCXO as the clock reference for the GPS chip set. It then uses phase data on the received signal to “lock” the OCXO. The whole process is very much unique to the Trimble product line. To do a mod and extract a PPS, you would need to find a GPSDO based on something like a uBlox chip set or module. You potentially *could* cut a trace and inject a new PPS. For most devices, you would also have to generate the proper “status” messages that go from the uBox (or other module) to the control loop processor. Some of these messages are in response to specific queries. Others are generated automatically. Bob > On Oct 30, 2018, at 4:22 PM, Ferran Valdés wrote: > > 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. > > > >> 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 > > > > @Attila Kinali > > > > > > 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 > >> tool. > > > > 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. > >> Attila Kinali > > > > > > > > @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
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
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 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 >
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
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 Oct 29, 2018, at 2:38 AM, Ferran Valdés 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.
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
> 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. > 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. > 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? > 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? > 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. > 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-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Question about the PLL of Trimble Thunderbold
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 > On Oct 24, 2018, at 5:02 PM, Ferran Valdés wrote: > > > 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-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.
