Hi

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

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:

HI

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 …..

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

After solving various problems ranging from GPS antenna location to
elimination of a rounding problem in the DAC calculation the performance
of the GPSDO starts to improve.
There are still many things to check and much longer measurements to be
done but at least it is going in the right direction. Mostly thanks to
the help of the good people on this list
Attached the ADEV plot, phase plot and TIM files of raw PPS phase and
GPSDO frequencies
Erik.

On 26-2-2022 17:59, Bob kb8tq wrote:

Hi Erik,

On 2022-02-26 17:36, Erik Kaashoek wrote:

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