[time-nuts] Re: Validating GPSDO control loop with simulation and measurement. Is this amount of difference between measurement and simulation to be expected?
Hi Erik, On 2022-02-26 17:36, Erik Kaashoek wrote: Magnus, Bob, Thanks for the replies. @Magnus, I need to study your input a bit longer. What I currently fail to understand is : Should there be a low pass filter with a 1/100 s corner frequency in series with the Vtune when the ADEV of the VC-TCXO and the PPS intersect at 100 s? Why not have a Kp of 0.01 instead of an additional low pass filter? I understand how the low pass filter can help reduce noise from the DAC if needed or is there another reason? The reason I did so was that the modulation, which always occurs as you step back and forth to interpolate, was intentionally moved to as high frequency as possible to make it as easy to filter out variations from as possible. This way the filter to remove most of that noise can have a bandwidth higher than the loop bandwidth, which is needed for loop stability. When they come near each other, this third pole may create unwanted pole-splitting moving a pole-pair into the forbiden/unstable region (right-hand side of Laplace domain or outside the unity circle of the z-transform-domain). Hope it makes sense. Cheers, Magnus @Bob, the reason for not converging may be some infrequent disturbances of the control loop caused by something not yet identified. Need to do some investigation into the cause. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Validating GPSDO control loop with simulation and measurement. Is this amount of difference between measurement and simulation to be expected?
HI > On Feb 26, 2022, at 11:36 AM, Erik Kaashoek wrote: > > Magnus, Bob, > Thanks for the replies. > @Magnus, I need to study your input a bit longer. What I currently fail to > understand is : Should there be a low pass filter with a 1/100 s corner > frequency in series with the Vtune when the ADEV of the VC-TCXO and the PPS > intersect at 100 s? Why not have a Kp of 0.01 instead of an additional low > pass filter? I understand how the low pass filter can help reduce noise from > the DAC if needed or is there another reason? Another way to look at damping is to call it phase margin. The more phase shift you have in your loop the less damping you get. The less damping you have, the more peaking there is. Stuffing a filter inside the loop is very likely to add phase shift to the loop …. What sort of phase margin? It is not uncommon to look at “ideal” as 90 degrees in this sort of loop. Targets like > 89 degrees do indeed get used. That’s not much added phase shift ….. > @Bob, the reason for not converging may be some infrequent disturbances of > the control loop caused by something not yet identified. Need to do some > investigation into the cause. One way to track that is to look at the actual phase plot rather than the ADEV. If you have a bunch of step functions then … yup .. there’s something else. You still will need a longer data run to get enough of a view of what’s what. One additional gotcha: The gain and phase that let you achieve “lock in” from a cold start may be way beyond what you want to use once locked. It is very common to scale things as the GPSDO process moves along. Just how you do this and how well it works is yet another rabbit hole …. Bob > Erik. > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Validating GPSDO control loop with simulation and measurement. Is this amount of difference between measurement and simulation to be expected?
Magnus, Bob, Thanks for the replies. @Magnus, I need to study your input a bit longer. What I currently fail to understand is : Should there be a low pass filter with a 1/100 s corner frequency in series with the Vtune when the ADEV of the VC-TCXO and the PPS intersect at 100 s? Why not have a Kp of 0.01 instead of an additional low pass filter? I understand how the low pass filter can help reduce noise from the DAC if needed or is there another reason? @Bob, the reason for not converging may be some infrequent disturbances of the control loop caused by something not yet identified. Need to do some investigation into the cause. Erik. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: Validating GPSDO control loop with simulation and measurement. Is this amount of difference between measurement and simulation to be expected?
Hi Erik, A few comments and suggestions on the way. Please note that for a PLL, a PID is equivalent to a PI regulator. Turns out that the P and D factors of the PID sums to form the P of the PI regulator, while the I transfer right over. I have seen no benefit in real implementation of adding the D factor, it did not add any magic to convergence. Also note that P is proportional to f0*d and I is proportional to f0^2 where f0 is the PLL resonance-frequency/cut-over-frequency and d is the damping factor. This is trival to derive and I usually do it on a white board or a single sheet of A4 paper. I strongly advice you to use f0 and d as your steering parameters rather than P and I, it will make the work better. Also, I recommend to keep d at least to 3 to avoid jitter peaking issues. The actual formulas contain a little more details with a few constants here and there, but those can be lumped into a single aggregate constant for each of the P and I, and knowing the basic relationship allows for quick test and tweak. I've taught this to several colleagues and they ended up testing their way to production values without too much effort, they simply tweak them until they are satisfied with all the tests readings. The gpsdo simulator tool is very fun and educational to learn from. I've written several similar simulation tools and they have proven very useful. I recommend to do tests to validate that the model and the actual implementation match up. One technique to decide f0 (or it's reciprocal the timeconstant) is to plot the phase-noise of the reference and the controlled oscillator and simply choose f0 to be at the intercept point of the two graphs. A similar approach have been used on ADEV plots, in which case it is called the Allan intercept point. The Allan intercept point is maybe a little less well founded than the phase-noise variants, but try both and see how you end up, it will be a learning experience. For a PI PLL, you can usually test overshot reaction to a phase or frequency step. The amount of overshot is directly related to the actual damping factor, so that is easy to validate. Further, forcing it into a low damping factor, you get a high Q so if you stress the loop with a phase or frequency step, the period of the resulting ringing will disclose the actual f0 of the loop. Using these two measurements, you can fairly trivially establish the actual constants of this equation system: P = Kp * f0 * d I = Ki * f0^2 Anyway, knowing the actual f0 and d for your implementation and being able to control those through the above equations will be of immense help as you then aim to optimize performance. Notice that scaling factor includes EFC input sensitivity, so if you have different oscillators, break out that as the Ko factor and set it properly for each oscillator. It is actually fairly simple to measure the actual sensitivity by intentionally steer the EFC and see how much frequency change, and you will trivially calculate the steering factor Ko. With a little bit of work, one can make it self-calibrate this for the oscillator. As for your question, for your simulation and your implementation to match up, you need to validate that your model of your implementation match up and have know scale factors. Spending time to make sure things work as you expect then saves you tons of work and you can use this knowledge to simulate and then verify in actual implementation (which tends to be slow) only a few times. Cheers, Magnus On 2022-02-25 16:18, Erik Kaashoek wrote: Inspired by the gpsdo simulator written by Tom Van Baak I am trying to use simulation to validate the PID loop parameters for a cheap and simple GPS referenced timer/counter I'm building. The following one hour measurements where done using a Rbd reference as input to the timer counter(see Timelab.gif plot attached) 1: Open loop (P=0, I=0) VC-TCXO versus the Rbd reference (green trace) 2: PPS of the internal GPS versus the Rbd reference. (PPS trace) 3: Rbd reference versus the closed loop (P=0.02, I=0) VC-TCXO (dark blue trace) 4: Rbd reference versus the closed loop (P=0.01, I=0,5) VC-TCXO (red trace) All .tim files also attached. The performance of the TCXO was remarkably good for a sub 1$ device, great care went into a stable, low noise, Vtune. The noisy supply did not have a big influence The open loop TCXO frequencies where divided by 1e7 (SW PICdiv)and together with the raw PPS frequencies loaded into an Excel speadsheet (see attached) An identical PID controller (P=0.01, I=0.0005) was implemented in Excel that took as input the frequency difference between the PPS and the TCXO and calculated a correction for the TCXO frequency. The corrected TCXO frequencies was exported from excel (PID output) and imported in Timelab (PID, light blue trace) As can be seen in the Timelab plot the controller implemented in Excel did a better job then the controller
[time-nuts] Re: Validating GPSDO control loop with simulation and measurement. Is this amount of difference between measurement and simulation to be expected?
Hi > On Feb 25, 2022, at 10:18 AM, Erik Kaashoek wrote: > > Inspired by the gpsdo simulator written by Tom Van Baak I am trying to use > simulation to validate the PID loop parameters for a cheap and simple GPS > referenced timer/counter I'm building. > The following one hour measurements where done using a Rbd reference as input > to the timer counter(see Timelab.gif plot attached) > 1: Open loop (P=0, I=0) VC-TCXO versus the Rbd reference (green trace) > 2: PPS of the internal GPS versus the Rbd reference. (PPS trace) > 3: Rbd reference versus the closed loop (P=0.02, I=0) VC-TCXO (dark blue > trace) > 4: Rbd reference versus the closed loop (P=0.01, I=0,5) VC-TCXO (red > trace) > All .tim files also attached. > The performance of the TCXO was remarkably good for a sub 1$ device, great > care went into a stable, low noise, Vtune. The noisy supply did not have a > big influence > The open loop TCXO frequencies where divided by 1e7 (SW PICdiv)and together > with the raw PPS frequencies loaded into an Excel speadsheet (see attached) > An identical PID controller (P=0.01, I=0.0005) was implemented in Excel that > took as input the frequency difference between the PPS and the TCXO and > calculated a correction for the TCXO frequency. The corrected TCXO > frequencies was exported from excel (PID output) and imported in Timelab > (PID, light blue trace) > As can be seen in the Timelab plot the controller implemented in Excel did a > better job then the controller in the timer/counter but the two actual closed > loop measurements used difference GPS and TCXO data (I do not own sufficient > good frequency counters to measure all frequencies at the same time). > The timer/counter was open on a table with minimum thermal isolation and > during the measurements some draft through door opening/closing could occur > My question: is the difference between the measured loop performance and the > simulated loop performance to be expected or am I making a big mistake > somewhere? The TCXO *should* converge to match the PPS. It should do that at some point past the few hundred seconds range on your loop. You would need a longer data run to really know if this is happening or not. Something > 10 hours ( so overnight works well …) would be better. Another thing to look into: You can likely improve the performance of the PPS by 4X or more by using the sawtooth correction process. That would shift the whole graph to the left and turn a couple hundred seconds into sorta kinda a hundred seconds. Overnight runs would then become closer to a couple hours. Another check on things: The PPS should roughly drop off as 1/tau. It will depart from this once you get out a ways. Over the range you are looking at, that’s a pretty good approximation. Wobbles in the line might indicate some sort of gotcha in the data collection or (maybe) issues somewhere else. Bob > Feel free to ask more info or more measurement data > > Erik. > > > > > > GPS locked P=0.01, I=0.5.tim> output.tim>___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
