Re: [time-nuts] New Subscriber, DIY GPSDO project (yes, another one)

[Azelio Boriani]

This page indeed has a picture with a rack with 3 HP5071A:

Of course timing.com redirects to Microsemi/Microchip.
Microsemi website->timing&synchronization->synchronization
services->precision time scale services.

On Tue, Mar 17, 2020 at 9:01 PM Attila Kinali  wrote:
>
> Hoi Poul-Henning!
>
> On Tue, 10 Mar 2020 23:42:03 +
> "Poul-Henning Kamp"  wrote:
>
> > And that line of thought brings us to the stochastic-ish model which
> > timing.com used on three 5071A and (three?) GPS's for the LORAN-C
> > modernization.
> >
> > It's a very interesting paper and a very good idea, which works
> > becuase their frequency source "bottoms out" in the MVAR plot:
> > Frequency drift would mean you too many degrees of freedom.
>
> Which paper is this? I couldn't find anything with with what
> you mentioned above.
>
> Attila Kinali
>
> --
> The bad part of Zurich is where the degenerates
> throw DARK chocolate at you.
>
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

Hoi Poul-Henning!

On Tue, 10 Mar 2020 23:42:03 +
"Poul-Henning Kamp"  wrote:

> And that line of thought brings us to the stochastic-ish model which
> timing.com used on three 5071A and (three?) GPS's for the LORAN-C
> modernization.
> 
> It's a very interesting paper and a very good idea, which works
> becuase their frequency source "bottoms out" in the MVAR plot:
> Frequency drift would mean you too many degrees of freedom.

Which paper is this? I couldn't find anything with with what
you mentioned above.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[William H. Fite]

I appreciate this discussion. I'm a statistician, not an engineer. I teach
linear quadratic estimation, of which Kalman is the archetypal example, as
a mathematical exercise without dealing more than very superficially with
practical applications. I've been following these posts with interest.
Thanks, gentlemen.


On Tuesday, March 10, 2020, Poul-Henning Kamp  wrote:

> 
> In message , Magnus
> Danielson
>  writes:
>
> >It should be said that Kalman is kind of optimum for "white" noise
> >(what-ever that is), but we are far from white noise. Variants of Kalman
> >filters use noise-colour compensation of some sort, and that kind of
> >solves some of the issues. It does not fit the problem perfectly. This
> >is why time-scale algorithms is not directly Kalman filters but only
> >Kalman-esque to some degree.
>
> And that line of thought brings us to the stochastic-ish model which
> timing.com used on three 5071A and (three?) GPS's for the LORAN-C
> modernization.
>
> It's a very interesting paper and a very good idea, which works
> becuase their frequency source "bottoms out" in the MVAR plot:
> Frequency drift would mean you too many degrees of freedom.
>
> The only chance I see of doing something like that, would be a Rb
> where the lowest point on the MVAR plot is very close to 12h, or
> even better 24h, where the GPS is similarly optimal.
>
> Que the HP5065A...
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> ___
> 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.
>


-- 
Homo sum humani a me nihil alienum puto.
___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message , Magnus Danielson
 writes:

>It should be said that Kalman is kind of optimum for "white" noise
>(what-ever that is), but we are far from white noise. Variants of Kalman
>filters use noise-colour compensation of some sort, and that kind of
>solves some of the issues. It does not fit the problem perfectly. This
>is why time-scale algorithms is not directly Kalman filters but only
>Kalman-esque to some degree.

And that line of thought brings us to the stochastic-ish model which
timing.com used on three 5071A and (three?) GPS's for the LORAN-C
modernization.

It's a very interesting paper and a very good idea, which works
becuase their frequency source "bottoms out" in the MVAR plot:
Frequency drift would mean you too many degrees of freedom.

The only chance I see of doing something like that, would be a Rb
where the lowest point on the MVAR plot is very close to 12h, or
even better 24h, where the GPS is similarly optimal.

Que the HP5065A...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi,

On 2020-03-10 12:53, Attila Kinali wrote:
> On Tue, 10 Mar 2020 03:38:11 +0100
> Magnus Danielson  wrote:
>
>> Now, to raise the complexity, the state-model of noise does not allow
>> for flicker noise variants. There just isn't a a good way to express
>> that. There is a few articles that give rough estimates, but no
>> half-integrators to be seen and therefore the noise models which is so
>> important in Kalman does not work very well.
> There is a thing called "fractional control" which deals with fractional
> order (integrator/differentiator) control loops. But, what I have seen
> so far was only fractional order in the underlying system model, not in
> the noise. But I have only scratched at the surface of this topic, so
> there is a lot I have not seen yet.
>
> If someone here knows more about fractional control, I would really
> enjoy a chat about the topic.

Yes, but the base point is that it's not off the shelf standard Kalman.
The noise covariance matrix may be sufficient, but I have not been
convinced. Traditional Kalman only speak about white noise, which in our
context becomes white phase modulation noise, but the actual model for
noise uses a co-variance matrix and it becomes trivial to extend it to
white frequency modulation noise, as it would be the noise for the
frequency state. This white frequency modulation noise is not spoken
much of  in traditional literature, but actually fits the model as one
builds a phase/frequency Kalman model. However, a noise model has at
least two more fractional states, but the state model does not, and
expressing that in Kalman matrixes is tricky to say the least. I've seen
some papers touch on the subject, but I have not been convinced on their
approach for the fractional noises.

Cheers,
Magnus



___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

One of the biggest issues in all this is that while a group of OCXO’s
may have some similar characteristics, they most certainly will not all
have the *same* characteristics. This one is at 5x10^-13 at 1 second
and the next one out of the box is at 5x10^-12 at 1 second. 

On top of that, your GPSDO may not have the luxury of continuous 
operation. Most commercial designs are targeted at “this level of 
holdover” after “that number of hours on power”.  You might get
72 hours on power, you also might be required to do it all after 
24 hours.

Finally, the operating environment may be nicely controlled in one 
case and really horrible in the next case. This one is in a nice cave
and the next one is in an unheated garage. 

Very much not a “one size fits all” sort of thing.

Bob

> On Mar 10, 2020, at 7:53 AM, Attila Kinali  wrote:
> 
> On Tue, 10 Mar 2020 03:38:11 +0100
> Magnus Danielson  wrote:
> 
>> Now, to raise the complexity, the state-model of noise does not allow
>> for flicker noise variants. There just isn't a a good way to express
>> that. There is a few articles that give rough estimates, but no
>> half-integrators to be seen and therefore the noise models which is so
>> important in Kalman does not work very well.
> 
> There is a thing called "fractional control" which deals with fractional
> order (integrator/differentiator) control loops. But, what I have seen
> so far was only fractional order in the underlying system model, not in
> the noise. But I have only scratched at the surface of this topic, so
> there is a lot I have not seen yet.
> 
> If someone here knows more about fractional control, I would really
> enjoy a chat about the topic.
> 
>   Attila Kinali
> 
> -- 
> In science if you know what you are doing you should not be doing it.
> In engineering if you do not know what you are doing you should not be doing 
> it.
>-- Richard W. Hamming, The Art of Doing Science and Engineering
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Tue, 10 Mar 2020 03:38:11 +0100
Magnus Danielson  wrote:

> Now, to raise the complexity, the state-model of noise does not allow
> for flicker noise variants. There just isn't a a good way to express
> that. There is a few articles that give rough estimates, but no
> half-integrators to be seen and therefore the noise models which is so
> important in Kalman does not work very well.

There is a thing called "fractional control" which deals with fractional
order (integrator/differentiator) control loops. But, what I have seen
so far was only fractional order in the underlying system model, not in
the noise. But I have only scratched at the surface of this topic, so
there is a lot I have not seen yet.

If someone here knows more about fractional control, I would really
enjoy a chat about the topic.

Attila Kinali

-- 
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Mon, 9 Mar 2020 16:46:38 -0700
jimlux  wrote:

> A Maximum Likelihood LMS estimator is essentially a special case of a 
> Kalman filter.

A small nitpick here:

The maximum likelihood estimator and Kalman filter are only equivalent
under the assumption of white gaussian noise. If the noise is correlated
(as is the case for flicker phase, white frequency... ), the two behave
(slightly) differently. A GPSDO is kind of a corner case here. While the
LO phase noise is clearly not white anymore, the noise of the GPS PPS
(after sawtooth correction) is pretty close to being white, though not
exactly. As the GPS noise is the dominiating one, assuming white noise
is most likely to be good enough for us to do a successful design using
standard techniques (which all assume white noise).


Attila Kinali

-- 
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi,

On 2020-03-10 00:46, jimlux wrote:
> On 3/9/20 2:36 PM, Poul-Henning Kamp wrote:
>> 
>> In message <3899483.rfyw6ut...@linux-5fgm.suse>, Matthias Welwarsky
>> writes:
>>
>>> I've actually been thinking of using a Kalman filter to find the
>>> "true value"
>>> of the EFC. I just couldn't wrap my mind around the theory yet.
>>
>> Yeah, they are hard to get started with, there seems to be only two
>> kinds of texts about Kalman: Hard-core math and woo-doo library usage.
>>
>
> Kalman filters are actually pretty simple..
> They're basically a single exponential type smoothing filter y(i) =
> alpha * x(i) + (1-alpha)*y(i-1)
>
> where you choose alpha to be related to the current uncertainty of the
> estimate and the uncertainty of the measurement, so that each
> contributes such that the new estimate has the minimum uncertainty.
>
> Where it gets tricky is when you have multiple variables in and out,
> and you need to have the covariances of the inputs to be able to
> "choose wisely"
>
> And, since in most implementations, the multiple variables are the
> state variables (x(t), x'(t), x''(t), etc). the uncertainty in the
> measurements of the higher derivatives tends to be higher (because a
> differentiator is a high pass filter).

Now, to raise the complexity, the state-model of noise does not allow
for flicker noise variants. There just isn't a a good way to express
that. There is a few articles that give rough estimates, but no
half-integrators to be seen and therefore the noise models which is so
important in Kalman does not work very well.

The covariance matrixes may be given some semi-relevant form thought,
but nothing have been very straight that I have seen.

It should be said that Kalman is kind of optimum for "white" noise
(what-ever that is), but we are far from white noise. Variants of Kalman
filters use noise-colour compensation of some sort, and that kind of
solves some of the issues. It does not fit the problem perfectly. This
is why time-scale algorithms is not directly Kalman filters but only
Kalman-esque to some degree.

Cheers,
Magnus



___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi,

On 2020-03-09 22:31, Poul-Henning Kamp wrote:
> 
> In message <20200309222553.e5b65b79daa2ee195cf13...@kinali.ch>, Attila Kinali 
> writes:
>> On Mon, 09 Mar 2020 13:44:59 +
>> "Poul-Henning Kamp"  wrote:
>>
>>> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
>>> and adjustment, with a continuous very weak proportional phase adjustment
>>> to come with measurement noise and rounding errors ?
>> Please correct me if I'm wrong, but that sounds like a
>> simplified version of a Kalman filter, with the only
>> predicted variable being the frequency of the LO.
> I think this has many names.
>
> Dave Mills called it a FLL - Frequency Locked Loop.
>
> I'm not sure a Kalman filter would really do much extra for the
> basic GPS+(OCXO|RB) case, unless you get advanced and also feed it
> temperature and air pressure.
>
> Once you have more than two references, Kalman makes a lot of sense.
>
>
The Kalman filter has the benefit of auto-tuning on itself as you
run-in, but for a time-frequency system, it's just a self-tuning
PI-loop, so when it have stabilized, the difference is very small. It
took a bit of re-drawing of the processing, but when it showed up on the
sketch-book it was very clear what was going on.

Cheers,
Magnus


___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi,

You probably want a long-time-constant steering of the FLL from the
phase, to make sure any residue frequency offsets and low-frequency
parts keeps the phase-control within range.

Cheers,
Magnus

On 2020-03-09 15:04, Bob kb8tq wrote:
> Hi
>
> If you go that way, just run a pure FLL for the “main loop” and do the phase
> on top of that. Assuming you are disciplining an OCXO, it works pretty well ….
> Even more so if you keep time tagged phase ( to do frequency from phase) 
> and can look at some very long tau “frequency” as a section of the loop. 
>
> Bob
>
>> On Mar 9, 2020, at 9:44 AM, Poul-Henning Kamp  wrote:
>>
>> 
>> In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky writes:
>>
 Backing up a bit …. the objective is not to minimize overshoot or
 keep the loop from oscillating. The issue here is optimizing the noise
 output of the combination of GPS + OCXO when combined via
 the control loop. It’s a very different objective ….
>>> Absolutely. The GPS will introduce a ton of noise and the objective for the 
>>> control loop is mainly to keep the influence of this noise away from the 
>>> GPSDO 
>>> output for small tau. You want the GPS only have an influence for large 
>>> tau, 
>>> ideally only countering the aging of the LO.
>> Has anybody ever played seriously with separate frequency and phase
>> adjustments ?
>>
>> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
>> and adjustment, with a continuous very weak proportional phase adjustment
>> to come with measurement noise and rounding errors ?
>>
>> -- 
>> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
>> p...@freebsd.org | TCP/IP since RFC 956
>> FreeBSD committer   | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by incompetence.
>>
>> ___
>> 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.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[jimlux]

On 3/9/20 2:36 PM, Poul-Henning Kamp wrote:


In message <3899483.rfyw6ut...@linux-5fgm.suse>, Matthias Welwarsky writes:


I've actually been thinking of using a Kalman filter to find the "true value"
of the EFC. I just couldn't wrap my mind around the theory yet.


Yeah, they are hard to get started with, there seems to be only two
kinds of texts about Kalman: Hard-core math and woo-doo library usage.



Kalman filters are actually pretty simple..
They're basically a single exponential type smoothing filter y(i) = 
alpha * x(i) + (1-alpha)*y(i-1)


where you choose alpha to be related to the current uncertainty of the 
estimate and the uncertainty of the measurement, so that each 
contributes such that the new estimate has the minimum uncertainty.


Where it gets tricky is when you have multiple variables in and out, and 
you need to have the covariances of the inputs to be able to "choose wisely"


And, since in most implementations, the multiple variables are the state 
variables (x(t), x'(t), x''(t), etc). the uncertainty in the 
measurements of the higher derivatives tends to be higher (because a 
differentiator is a high pass filter).



A Maximum Likelihood LMS estimator is essentially a special case of a 
Kalman filter.


And, of course, because no modern discussion is complete without working 
in Machine Learning: the classic LMS adjustment methods(w(i+1) = w(i) + 
alpha * x(i)) for a single layer classifier boils down to the same thing.



___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Montag, 9. März 2020 22:45:28 CET Attila Kinali wrote:
> [1] "Kalman Filtering", by Dan Simon, 2001
> http://aug-roma.wdfiles.com/local--files/progetti:arpinpero/Kalman_filtering
> .pdf

Nice. Particularly, since the chosen example is vehicle cruise control, which 
is pretty much what a GPSDO does. In case of a FLL, it tries to match the 
speed of two vehicles, in case of a PLL, it's a vehicle tracking another 
vehicle at a set distance :) EFC is the equivalent to acceleration.

BR,
Matthias





___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Mon, 09 Mar 2020 22:33:32 +0100
Matthias Welwarsky  wrote:

> I've actually been thinking of using a Kalman filter to find the "true value" 
> of the EFC. I just couldn't wrap my mind around the theory yet.

If you are not afraid of matrices and linear algebra, than I found
that [1] is a good introduction into Kalman filters. Other than
that, you need a decent grasp on control theory. For this I usually
recommend [2], of which you don't have to read everything, but
I would at least recommend the introductory chapters, the part
on loop stability and how to tune control loops.

Attila Kinali


[1] "Kalman Filtering", by Dan Simon, 2001
http://aug-roma.wdfiles.com/local--files/progetti:arpinpero/Kalman_filtering.pdf


[2] "Feedback control of dynamic systems" by Franklin, Powell, Emami-Naeini
-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Mon, 09 Mar 2020 21:31:00 +
"Poul-Henning Kamp"  wrote:

> >Please correct me if I'm wrong, but that sounds like a
> >simplified version of a Kalman filter, with the only
> >predicted variable being the frequency of the LO.
> 
> I think this has many names.

Definitely. If you leave out the predictive aspect, then,
for the phase/frequency case of an GPSDO, the loop
formulation becomes a PI loop (unless I misunderstood
someting). If you take frequency drift into account,
it becomes a PII² loop.

> I'm not sure a Kalman filter would really do much extra for the
> basic GPS+(OCXO|RB) case, unless you get advanced and also feed it
> temperature and air pressure.

Kalman filters are just a formalism to map a system model into
a control loop that predicts the internal states of the model
and gives a more optimal control using this predictive power.
You can map any PID loop back to a Kalman formalism.

Attila Kinali 

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <3899483.rfyw6ut...@linux-5fgm.suse>, Matthias Welwarsky writes:

>I've actually been thinking of using a Kalman filter to find the "true value"
>of the EFC. I just couldn't wrap my mind around the theory yet.

Yeah, they are hard to get started with, there seems to be only two
kinds of texts about Kalman: Hard-core math and woo-doo library usage.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Montag, 9. März 2020 22:25:53 CET Attila Kinali wrote:
> On Mon, 09 Mar 2020 13:44:59 +
> 
> "Poul-Henning Kamp"  wrote:
> > I'm thinking 24h (to minimize GPS periodicities) frequency measurement
> > and adjustment, with a continuous very weak proportional phase adjustment
> > to come with measurement noise and rounding errors ?
> 
> Please correct me if I'm wrong, but that sounds like a
> simplified version of a Kalman filter, with the only
> predicted variable being the frequency of the LO.

I've actually been thinking of using a Kalman filter to find the "true value" 
of the EFC. I just couldn't wrap my mind around the theory yet.

> 
>   Attila Kinali





___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <20200309222553.e5b65b79daa2ee195cf13...@kinali.ch>, Attila Kinali 
writes:
>On Mon, 09 Mar 2020 13:44:59 +
>"Poul-Henning Kamp"  wrote:
>
>> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
>> and adjustment, with a continuous very weak proportional phase adjustment
>> to come with measurement noise and rounding errors ?
>
>Please correct me if I'm wrong, but that sounds like a
>simplified version of a Kalman filter, with the only
>predicted variable being the frequency of the LO.

I think this has many names.

Dave Mills called it a FLL - Frequency Locked Loop.

I'm not sure a Kalman filter would really do much extra for the
basic GPS+(OCXO|RB) case, unless you get advanced and also feed it
temperature and air pressure.

Once you have more than two references, Kalman makes a lot of sense.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Mon, 09 Mar 2020 13:44:59 +
"Poul-Henning Kamp"  wrote:

> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
> and adjustment, with a continuous very weak proportional phase adjustment
> to come with measurement noise and rounding errors ?

Please correct me if I'm wrong, but that sounds like a
simplified version of a Kalman filter, with the only
predicted variable being the frequency of the LO.

Attila Kinali
-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <4892914a-b4d6-47a6-9b10-eb18376fc...@n1k.org>, Bob kb8tq writes:

>Hi
>
>In this case the “phase” is phase correction of the output rather than PLL ….

And a much smaller phase correction, because it is not trying to also
steer the frequency.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

In this case the “phase” is phase correction of the output rather than PLL ….

Bob

> On Mar 9, 2020, at 10:58 AM, Matthias Welwarsky  
> wrote:
> 
> On Montag, 9. März 2020 15:04:40 CET Bob kb8tq wrote:
>> Hi
>> 
>> If you go that way, just run a pure FLL for the “main loop” and do the phase
>> on top of that. Assuming you are disciplining an OCXO, it works pretty well
>> …. Even more so if you keep time tagged phase ( to do frequency from phase)
>> and can look at some very long tau “frequency” as a section of the loop.
> 
> Not sure about the merit of this. As soon as your LO is close to the "true"  
> frequency, the phase error will become dominant. Which means the FLL part 
> will 
> contribute nothing and the whole thing will effectively become a PLL.
> 
> BR,
> Matthias
> 
>> 
>> Bob
>> 
>>> On Mar 9, 2020, at 9:44 AM, Poul-Henning Kamp  wrote:
>>> 
>>> 
>>> 
>>> In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky 
> writes:
> Backing up a bit …. the objective is not to minimize overshoot or
> keep the loop from oscillating. The issue here is optimizing the noise
> output of the combination of GPS + OCXO when combined via
> the control loop. It’s a very different objective ….
 
 Absolutely. The GPS will introduce a ton of noise and the objective for
 the
 control loop is mainly to keep the influence of this noise away from the
 GPSDO output for small tau. You want the GPS only have an influence for
 large tau, ideally only countering the aging of the LO.
>>> 
>>> Has anybody ever played seriously with separate frequency and phase
>>> adjustments ?
>>> 
>>> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
>>> and adjustment, with a continuous very weak proportional phase adjustment
>>> to come with measurement noise and rounding errors ?
>> 
>> ___
>> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Montag, 9. März 2020 15:04:40 CET Bob kb8tq wrote:
> Hi
> 
> If you go that way, just run a pure FLL for the “main loop” and do the phase
> on top of that. Assuming you are disciplining an OCXO, it works pretty well
> …. Even more so if you keep time tagged phase ( to do frequency from phase)
> and can look at some very long tau “frequency” as a section of the loop.

Not sure about the merit of this. As soon as your LO is close to the "true"  
frequency, the phase error will become dominant. Which means the FLL part will 
contribute nothing and the whole thing will effectively become a PLL.

BR,
Matthias

> 
> Bob
> 
> > On Mar 9, 2020, at 9:44 AM, Poul-Henning Kamp  wrote:
> > 
> > 
> > 
> > In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky 
writes:
> >>> Backing up a bit …. the objective is not to minimize overshoot or
> >>> keep the loop from oscillating. The issue here is optimizing the noise
> >>> output of the combination of GPS + OCXO when combined via
> >>> the control loop. It’s a very different objective ….
> >> 
> >> Absolutely. The GPS will introduce a ton of noise and the objective for
> >> the
> >> control loop is mainly to keep the influence of this noise away from the
> >> GPSDO output for small tau. You want the GPS only have an influence for
> >> large tau, ideally only countering the aging of the LO.
> > 
> > Has anybody ever played seriously with separate frequency and phase
> > adjustments ?
> > 
> > I'm thinking 24h (to minimize GPS periodicities) frequency measurement
> > and adjustment, with a continuous very weak proportional phase adjustment
> > to come with measurement noise and rounding errors ?
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Montag, 9. März 2020 14:44:59 CET Poul-Henning Kamp wrote:
> 
> 
> In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky writes:
> >> Backing up a bit …. the objective is not to minimize overshoot or
> >> keep the loop from oscillating. The issue here is optimizing the noise
> >> output of the combination of GPS + OCXO when combined via
> >> the control loop. It’s a very different objective ….
> >
> >Absolutely. The GPS will introduce a ton of noise and the objective for the
> >control loop is mainly to keep the influence of this noise away from the
> >GPSDO output for small tau. You want the GPS only have an influence for
> >large tau, ideally only countering the aging of the LO.
> 
> Has anybody ever played seriously with separate frequency and phase
> adjustments ?
> 
> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
> and adjustment, with a continuous very weak proportional phase adjustment
> to come with measurement noise and rounding errors ?

This is one of the areas where a GPSDO simulator can be a great tool.

BR,
Matthias





___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

If you go that way, just run a pure FLL for the “main loop” and do the phase
on top of that. Assuming you are disciplining an OCXO, it works pretty well ….
Even more so if you keep time tagged phase ( to do frequency from phase) 
and can look at some very long tau “frequency” as a section of the loop. 

Bob

> On Mar 9, 2020, at 9:44 AM, Poul-Henning Kamp  wrote:
> 
> 
> In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky writes:
> 
>>> Backing up a bit …. the objective is not to minimize overshoot or
>>> keep the loop from oscillating. The issue here is optimizing the noise
>>> output of the combination of GPS + OCXO when combined via
>>> the control loop. It’s a very different objective ….
>> 
>> Absolutely. The GPS will introduce a ton of noise and the objective for the 
>> control loop is mainly to keep the influence of this noise away from the 
>> GPSDO 
>> output for small tau. You want the GPS only have an influence for large tau, 
>> ideally only countering the aging of the LO.
> 
> Has anybody ever played seriously with separate frequency and phase
> adjustments ?
> 
> I'm thinking 24h (to minimize GPS periodicities) frequency measurement
> and adjustment, with a continuous very weak proportional phase adjustment
> to come with measurement noise and rounding errors ?
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Samstag, 7. März 2020 15:35:22 CET Tobias Pluess wrote:
> Hi,
> I am sure it is theoretically possible to find an optimal control loop
> design if you have accurate models of the OCXO and for the behaviour of the
> 1PPS pulse.
> TvB has written a GPSDO simulator which allows to code different PLL and
> control algorithms. I have implemented something similar in Matlab.
> Basically, if you know the VCO tuning characteristics and the phase
> detector constant, then you can use procedures as described in the PLL
> books that are out there (I have ond from R. Best).

Funny, that was also my approach. I have no idea about control theory or PLL 
design so I'm not able to apply any prior knowledge here, but converting 
"gpsim1.c" to Matlab (or Octave, in my case) was pretty much straight forward 
and having a math toolkit under the bonnet is much more versatile than a C 
compiler and runtime.

> Maybe the easiest way is indeed using the GPSDO simulator.
> If there is some interest, I could perhaps post my Matlab code. It plots
> nicely the calculated EFC voltage and simumates the OCXOs frequency
> variation as the EFC is varied.

The GPSDO simulator is fine for sanity-checking certain design parameters, 
like, if the width of your DAC is sufficient for the LO you're targeting. The 
question of "how many bits" you need can be visualized nicely with the 
simulator. However, you'll need model data for the GPS and the LO and you have 
to be aware that whatever optimal filter and control loop design and 
parameters you work out, will have to work outside the limited space your 
model data presents.

BR,
Matthias

> 
> Best
> Tobias
> HB9FSX
> 
> On Sat., 7 Mar. 2020, 12:36 Gilles Clement,  wrote:
> > Hi,
> > How do you optimally tune the control loop time constant ?
> > (Mine gets quite unstable when the update rate is slow - and the amplitude
> > of the change step low - enough not to degrade the OCXO performance )
> > Is there a method described somewhere (like the Ziegler–Nichols method for
> > PID) ?
> > Thx,
> > Gilles.
> > 
> > > Le 3 mars 2020 à 18:28, Attila Kinali  a écrit :
> > > 
> > > On Tue, 3 Mar 2020 12:14:37 -0500
> > > 
> > > Jim Harman  wrote:
> > >> I don't understand why you say the DAC should have a resolution of
> > >> 24-30
> > >> bits. I can see that the loop time constant affects the precision
> > 
> > needed in
> > 
> > >> the filter calculations, but what does the time constant have to do
> > >> with
> > >> the needed DAC resolution? We don't have to wait for the whole time
> > >> constant before changing the DAC, we can update the filter calculations
> > 
> > and
> > 
> > >> look at its output every second and adjust the DAC whenever the PI
> > 
> > filtered
> > 
> > >> phase error is one DAC step or more.
> > > 
> > > You do wait the whole time before updating the DAC value.. kind of ish.
> > > The control loop's time constant is exactly that: The time it takes
> > > the control loop for a change in the input to affect the output (very
> > > loosely speaking). Yes, the sample rate at which the loop runs is
> > > much higher, but that doesn't change the fact that the loop is slow
> > > to react. And you want it to be slow to react, as otherwise the high
> > > noise of GPS degrades the performance of your OCXO.
> > > 
> > >> If the OCXO has a tuning range of 1 ppm and we want frequency control
> > >> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
> > >> assuming the DAC covers the full tuning range of the oscillator?
> > > 
> > > Yes. There is a calculation mistake in there. I corrected it in
> > 
> > > the next mail:
> > http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/0979
> > 63.html> 
> > >   Attila Kinali
> > > 
> > > --
> > >   The bad part of Zurich is where the degenerates
> > > 
> > >throw DARK chocolate at you.
> > > 
> > > ___
> > > 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.
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <1593455.ijmom2w...@linux-5fgm.suse>, Matthias Welwarsky writes:

>> Backing up a bit …. the objective is not to minimize overshoot or
>> keep the loop from oscillating. The issue here is optimizing the noise
>> output of the combination of GPS + OCXO when combined via
>> the control loop. It’s a very different objective ….
>
>Absolutely. The GPS will introduce a ton of noise and the objective for the 
>control loop is mainly to keep the influence of this noise away from the GPSDO 
>output for small tau. You want the GPS only have an influence for large tau, 
>ideally only countering the aging of the LO.

Has anybody ever played seriously with separate frequency and phase
adjustments ?

I'm thinking 24h (to minimize GPS periodicities) frequency measurement
and adjustment, with a continuous very weak proportional phase adjustment
to come with measurement noise and rounding errors ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Sonntag, 8. März 2020 02:08:25 CET Bob kb8tq wrote:
> Hi
> 
> Backing up a bit …. the objective is not to minimize overshoot or
> keep the loop from oscillating. The issue here is optimizing the noise
> output of the combination of GPS + OCXO when combined via
> the control loop. It’s a very different objective ….

Absolutely. The GPS will introduce a ton of noise and the objective for the 
control loop is mainly to keep the influence of this noise away from the GPSDO 
output for small tau. You want the GPS only have an influence for large tau, 
ideally only countering the aging of the LO.

> 
> Bob
> 
> > On Mar 7, 2020, at 8:01 PM, Bill Hawkins  wrote:
> > 
> > Try https://en.wikipedia.org/wiki/PID_controller
> > 
> > If that doesn't help, what we used to do for industrial process
> > controllers was to set Reset time to the largest value and Derivative to
> > zero (to disable them) and then increasethe gain until the loop
> > oscillated when you made a step change to the setpoint, then you used 70%
> > of that value for gain. The period of oscillation told you how to do
> > Reset, but I don't remember that. Conservative settings were used because
> > control valves were not linear. Heaters are generally linear.
> > 
> > Bill Hawkins, whose memory isn't what it used to be.
> > 
> > On Sat, Mar 7, 2020, at 5:04 PM, Hal Murray wrote:
> >> kb...@n1k.org said:
> >>> As far as I know there is no “closed form” solution to tuning a GPSDO.
> >>> It is very much a measure / tweak / measure / tweak sort of thing.
> >> 
> >> I've seen a recipe for tuning a PID controller. That was ages ago. I
> >> wonder
> >> where.
> >> 
> >> The key idea was that you needed to be able to poke the system and see
> >> how it responded.
> >> 
> >> Google for >tune PID< gets several hits that might be worth
> >> investigating.
> > 
> > ___
> > 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.





___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Gilles Clement]

Hi Magnus,
Quite interesting.
Could you point us to one or rwo pages developing please ?
Thx.
Gilles.

> Le 8 mars 2020 à 10:54, Magnus Danielson  a écrit :
> 
> H
> 
>> On 2020-03-08 07:38, Poul-Henning Kamp wrote:
>> 
>> In message <5583e434-4c72-4a4f-a60b-75a4204ef...@n1k.org>, Bob kb8tq writes:
>> 
>>> Backing up a bit …. the objective is not to minimize overshoot or 
>>> keep the loop from oscillating. The issue here is optimizing the noise
>>> output of the combination of GPS + OCXO when combined via
>>> the control loop. It’s a very different objective ….
>> Yes, but a PI loop is still the best mathematical tool for it,
>> you just need the PI loop to have adjustable parameters.
>> 
>> Adjusting those parameters after the initial capture is the hard
>> part, because the signal you are looking for is in the "wander"
>> domain.
> 
> First, a PID PLL degenerates into a PI loop. The P and D steering ends
> up achieving the same thing as P in the PI, do there is no benefit of D.
> I have shown such derivations in the past. Not too hard to do.
> 
> Second, a PI loop has trivial dimensioning from damping factor and
> frequency, and the damping factor we know we need to keep high enough,
> so say 3 or higher, so we end up only having the loop frequency, which
> is the reciprocal of time-constant. These rules is easy to do, a page of
> paper is enough or a whiteboard.
> 
> So, these basic facts is just the rule of the game.
> 
>> The best I have come up with, is to average the measured phase error
>> to get rid of the GPS jitter/sawtooth, and adjust the PI loop
>> parameters based on the time between sign-changes of that averaged
>> signal.
> Third, the averaging filter needs a limitation on how low it frequency
> can go, before it starts to affect the pole-pair of the PI-loop, at
> which time stability cannot be guaranteed. Corrections needs to be
> performed to ensure stability and performance as it comes closer.
>> If you plot the histogram of the time between sign-changes, you want
>> the peak below the supposed "allan-intercept" and if you get time
>> intervals more than double the "allan-intercept" you have probably
>> tightend too much.
> 
> The Allan intercept is really where the cut-over from reference Allan
> plot to the steered oscillator plot. The concept of Allan intercept is
> actually not perfect science, but a concept. The actual physics would
> make the cut-over analysis on the phase-noise plots make more sense, but
> for the time-constants we talk, that's where the Allan deviation plot
> has taken over typically. Actually doing the cut-over in Allan deviation
> form carries with it biases values, making the Allan intercept value
> biased. It gets you to the right neighborhood, sure, but do expect a few
> trims for optimum stability.
> 
> Cheers,
> Magnus
> 
> 
> 
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[jimlux]

On 3/8/20 8:53 AM, Poul-Henning Kamp wrote:


In message <5f5e8822-006f-a059-51f8-d6a986300...@earthlink.net>, jimlux writes:


The conceptual idea being similar to setting a PLL Loop filter bandwidth
such that the reference noise (multiplied up) and the VCO noise are the
same at that point?


I tried that, and got absolutely no where, because the noise-spectra
are not flat or even comparable.



That's exactly what I was thinking.. phase noise is straightforward. 
ADEV is not.




Instead started to look at the time distribution of the zero-crossings
of the residual low-pass filtered phase error, and that has given me
much better results all in all.



interesting idea.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Jim Harman]

Here is the procedure I use to set up my GPSDO, which is based loosely on
Lars Walenius' excellent write-up on his system. To tune the filter you
need to have a Hold mode that opens the control loop and lets you set the
DAC value and a way to monitor the raw phase detector output minus its
nominal value, i.e. the input to the filter. Call this value err.

There will be a DAC value that causes err to remain constant, i.e. to set
the oscillator to exactly 10 MHz. Call this value DAC_Offset

For testing and setup, it is also very helpful to be able to set the time
constant on the fly

The filter updates once per sec. If your system updates at a different
rate, you will have to scale things accordingly.

The filter starts with a prefilter to smooth the GPS data. This does a
moving average of err and has a time constant of 1/2 to 1/4 of the PI
filter TC and a gain of 1. You can start with 2 for the prefilter divisor.
Call the output of the prefilter errFilt.

The PI filter has 3 parameters:

gain is the system's sensitivity to a change in err. It is the change in
DAC counts it takes to make err change by 1 count per sec.
TC is the time constant. It controls how fast the filter responds to a
change in err.
damping is the filter's damping factor. It controls the relative size of
the filter's I term and affects how much overshoot the filter has.

The PI filter boils down to
pTerm = errFilt * gain
iTerm += pTerm / (TC * damping)
output = (pTerm + iTerm) / TC

and the value sent to the DAC is output + DAC_Offset.

To tune the system, start by determining DAC_Offset. In Hold mode, adjust
the DAC value so that err stays constant. You will want to warm it up for
at least 1 hour before trying this

Next we determine the gain. Still in Hold mode, adjust the DAC value by an
amount a so that err starts to move up or down and measure its rate of
change r in counts/sec. Then gain = a/r. For example if an adjustment of
100 DAC counts makes r go from 0 to 1 count/sec, the gain is 100.

You can set the damping to 1.75 to start.

Once you have set the gain and the DAC offset, you can try closing the
loop. Set the initial TC short - 100 sec or so - and the system should
stabilize in a few minutes. My experience with an OCXO is that once the
system has thoroughly warmed up you will get best performance with a time
constant of 500-1000 sec. Optimizing the other parameters takes some
experimentation. You can observe the filter's response characteristics by
forcing step changes in the error or the DAC output or the nominal phase
detector output, but in the end as others have said, you will have to
compare your system to a known good reference.
___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <5f5e8822-006f-a059-51f8-d6a986300...@earthlink.net>, jimlux writes:

>The conceptual idea being similar to setting a PLL Loop filter bandwidth 
>such that the reference noise (multiplied up) and the VCO noise are the 
>same at that point?

I tried that, and got absolutely no where, because the noise-spectra
are not flat or even comparable.

Instead started to look at the time distribution of the zero-crossings
of the residual low-pass filtered phase error, and that has given me
much better results all in all.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <7f4f318c-d220-41ff-a26f-282581de3...@n1k.org>, Bob kb8tq writes:

>This all comes back to *having* the ADEV / HDEV / Phase Noise data
>on your steered device and GPS to work from. In a lot of cases, people
>do not have that information ….. They are looking for a procedure to 
>truly do this “blind”. 

Right.

So you do not need to be very exact about where you think the
"allan-intercept" is for my method to work, within an order of
magnitude is generally OK, and if you wanted to, you could
add a third loop around the PI autotuning to try to optimize it
over a couple of years.

However, I am pretty certain that we can do better (and faster!)
than that, by tuning until we get the right PDF shape for the
zero-crossing intervals, if only we know what it should be.

My math skills have not been sufficient to derive that.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi,

On 2020-03-08 16:15, jimlux wrote:
> On 3/8/20 1:52 AM, Magnus Danielson wrote:
>>
>> The Allan intercept is really where the cut-over from reference Allan
>> plot to the steered oscillator plot. The concept of Allan intercept is
>> actually not perfect science, but a concept. The actual physics would
>> make the cut-over analysis on the phase-noise plots make more sense, but
>> for the time-constants we talk, that's where the Allan deviation plot
>> has taken over typically. Actually doing the cut-over in Allan deviation
>> form carries with it biases values, making the Allan intercept value
>> biased. It gets you to the right neighborhood, sure, but do expect a few
>> trims for optimum stability.
>>
>
>
> The conceptual idea being similar to setting a PLL Loop filter
> bandwidth such that the reference noise (multiplied up) and the VCO
> noise are the same at that point?
>
Yes, that's where the term intercept comes from.
> Of course, it's "easy-ish" for a crystal oscillator (flat noise
> spectrum at crossover) and VCO (steadily declining spectrum at
> crossover) and those noise spectra remain the same (ish).
In theory simple yes.
>
> I think the "art" comes in picking the right gains and bandwidths,
> because of things like GPS has diurnal variations, temperature
> variations (also diurnal, but also faster with HVAC turning on and off)

Which is the reality with a number of systematic disturbances which is
not random noise. Such concerns takes over, and the Allan deviation
intercept is even further from modeling that correctly.

Cheers,
Magnus


___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

Hi Bob,

On 2020-03-08 14:45, Bob kb8tq wrote:
> Hi
>
> This all comes back to *having* the ADEV / HDEV / Phase Noise data
> on your steered device and GPS to work from. In a lot of cases, people
> do not have that information ….. They are looking for a procedure to 
> truly do this “blind”. 

Indeed. In similar sense, you can't optimize it within its own system as
you become somewhat blind, even if some properties may indirectly be
inferred. An external reference is needed and measurements needs to be
done against that, either for the inputs noises or the result,
preferably both.

We can infer quite a bit from a number of scenarios, but we end up
having difficulty to pin-point the optimum with only the system itself.

For some reason, you need to measure and learn over and over.

Cheers,
Magnus



___
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] New Subscriber, DIY GPSDO project (yes, another one)

[jimlux]

On 3/8/20 1:52 AM, Magnus Danielson wrote:


The Allan intercept is really where the cut-over from reference Allan
plot to the steered oscillator plot. The concept of Allan intercept is
actually not perfect science, but a concept. The actual physics would
make the cut-over analysis on the phase-noise plots make more sense, but
for the time-constants we talk, that's where the Allan deviation plot
has taken over typically. Actually doing the cut-over in Allan deviation
form carries with it biases values, making the Allan intercept value
biased. It gets you to the right neighborhood, sure, but do expect a few
trims for optimum stability.




The conceptual idea being similar to setting a PLL Loop filter bandwidth 
such that the reference noise (multiplied up) and the VCO noise are the 
same at that point?


Of course, it's "easy-ish" for a crystal oscillator (flat noise spectrum 
at crossover) and VCO (steadily declining spectrum at crossover) and 
those noise spectra remain the same (ish).


I think the "art" comes in picking the right gains and bandwidths, 
because of things like GPS has diurnal variations, temperature 
variations (also diurnal, but also faster with HVAC turning on and off)


___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

This all comes back to *having* the ADEV / HDEV / Phase Noise data
on your steered device and GPS to work from. In a lot of cases, people
do not have that information ….. They are looking for a procedure to 
truly do this “blind”. 

Bob

> On Mar 8, 2020, at 5:52 AM, Magnus Danielson  wrote:
> 
> H
> 
> On 2020-03-08 07:38, Poul-Henning Kamp wrote:
>> 
>> In message <5583e434-4c72-4a4f-a60b-75a4204ef...@n1k.org>, Bob kb8tq writes:
>> 
>>> Backing up a bit …. the objective is not to minimize overshoot or 
>>> keep the loop from oscillating. The issue here is optimizing the noise
>>> output of the combination of GPS + OCXO when combined via
>>> the control loop. It’s a very different objective ….
>> Yes, but a PI loop is still the best mathematical tool for it,
>> you just need the PI loop to have adjustable parameters.
>> 
>> Adjusting those parameters after the initial capture is the hard
>> part, because the signal you are looking for is in the "wander"
>> domain.
> 
> First, a PID PLL degenerates into a PI loop. The P and D steering ends
> up achieving the same thing as P in the PI, do there is no benefit of D.
> I have shown such derivations in the past. Not too hard to do.
> 
> Second, a PI loop has trivial dimensioning from damping factor and
> frequency, and the damping factor we know we need to keep high enough,
> so say 3 or higher, so we end up only having the loop frequency, which
> is the reciprocal of time-constant. These rules is easy to do, a page of
> paper is enough or a whiteboard.
> 
> So, these basic facts is just the rule of the game.
> 
>> The best I have come up with, is to average the measured phase error
>> to get rid of the GPS jitter/sawtooth, and adjust the PI loop
>> parameters based on the time between sign-changes of that averaged
>> signal.
> Third, the averaging filter needs a limitation on how low it frequency
> can go, before it starts to affect the pole-pair of the PI-loop, at
> which time stability cannot be guaranteed. Corrections needs to be
> performed to ensure stability and performance as it comes closer.
>> If you plot the histogram of the time between sign-changes, you want
>> the peak below the supposed "allan-intercept" and if you get time
>> intervals more than double the "allan-intercept" you have probably
>> tightend too much.
> 
> The Allan intercept is really where the cut-over from reference Allan
> plot to the steered oscillator plot. The concept of Allan intercept is
> actually not perfect science, but a concept. The actual physics would
> make the cut-over analysis on the phase-noise plots make more sense, but
> for the time-constants we talk, that's where the Allan deviation plot
> has taken over typically. Actually doing the cut-over in Allan deviation
> form carries with it biases values, making the Allan intercept value
> biased. It gets you to the right neighborhood, sure, but do expect a few
> trims for optimum stability.
> 
> Cheers,
> Magnus
> 
> 
> 
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Magnus Danielson]

H

On 2020-03-08 07:38, Poul-Henning Kamp wrote:
> 
> In message <5583e434-4c72-4a4f-a60b-75a4204ef...@n1k.org>, Bob kb8tq writes:
>
>> Backing up a bit …. the objective is not to minimize overshoot or 
>> keep the loop from oscillating. The issue here is optimizing the noise
>> output of the combination of GPS + OCXO when combined via
>> the control loop. It’s a very different objective ….
> Yes, but a PI loop is still the best mathematical tool for it,
> you just need the PI loop to have adjustable parameters.
>
> Adjusting those parameters after the initial capture is the hard
> part, because the signal you are looking for is in the "wander"
> domain.

First, a PID PLL degenerates into a PI loop. The P and D steering ends
up achieving the same thing as P in the PI, do there is no benefit of D.
I have shown such derivations in the past. Not too hard to do.

Second, a PI loop has trivial dimensioning from damping factor and
frequency, and the damping factor we know we need to keep high enough,
so say 3 or higher, so we end up only having the loop frequency, which
is the reciprocal of time-constant. These rules is easy to do, a page of
paper is enough or a whiteboard.

So, these basic facts is just the rule of the game.

> The best I have come up with, is to average the measured phase error
> to get rid of the GPS jitter/sawtooth, and adjust the PI loop
> parameters based on the time between sign-changes of that averaged
> signal.
Third, the averaging filter needs a limitation on how low it frequency
can go, before it starts to affect the pole-pair of the PI-loop, at
which time stability cannot be guaranteed. Corrections needs to be
performed to ensure stability and performance as it comes closer.
> If you plot the histogram of the time between sign-changes, you want
> the peak below the supposed "allan-intercept" and if you get time
> intervals more than double the "allan-intercept" you have probably
> tightend too much.

The Allan intercept is really where the cut-over from reference Allan
plot to the steered oscillator plot. The concept of Allan intercept is
actually not perfect science, but a concept. The actual physics would
make the cut-over analysis on the phase-noise plots make more sense, but
for the time-constants we talk, that's where the Allan deviation plot
has taken over typically. Actually doing the cut-over in Allan deviation
form carries with it biases values, making the Allan intercept value
biased. It gets you to the right neighborhood, sure, but do expect a few
trims for optimum stability.

Cheers,
Magnus




___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Poul-Henning Kamp]

In message <5583e434-4c72-4a4f-a60b-75a4204ef...@n1k.org>, Bob kb8tq writes:

> Backing up a bit …. the objective is not to minimize overshoot or 
> keep the loop from oscillating. The issue here is optimizing the noise
> output of the combination of GPS + OCXO when combined via
> the control loop. It’s a very different objective ….

Yes, but a PI loop is still the best mathematical tool for it,
you just need the PI loop to have adjustable parameters.

Adjusting those parameters after the initial capture is the hard
part, because the signal you are looking for is in the "wander"
domain.

The best I have come up with, is to average the measured phase error
to get rid of the GPS jitter/sawtooth, and adjust the PI loop
parameters based on the time between sign-changes of that averaged
signal.

If you plot the histogram of the time between sign-changes, you want
the peak below the supposed "allan-intercept" and if you get time
intervals more than double the "allan-intercept" you have probably
tightend too much.

With good modern dual-band GPS receivers, you can probably also
steer after the magnitude of the averaged signal, in a sense
putting a PI loop around the PI loop.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

Backing up a bit …. the objective is not to minimize overshoot or 
keep the loop from oscillating. The issue here is optimizing the noise
output of the combination of GPS + OCXO when combined via
the control loop. It’s a very different objective ….

Bob

> On Mar 7, 2020, at 8:01 PM, Bill Hawkins  wrote:
> 
> Try https://en.wikipedia.org/wiki/PID_controller
> 
> If that doesn't help, what we used to do for industrial process controllers 
> was to set Reset time to the largest value and Derivative to zero (to disable 
> them) and then increasethe gain until the loop oscillated when you made a 
> step change to the setpoint, then you used 70% of that value for gain. The 
> period of oscillation told you how to do Reset, but I don't remember that. 
> Conservative settings were used because control valves were not linear. 
> Heaters are generally linear.
> 
> Bill Hawkins, whose memory isn't what it used to be.
> 
> On Sat, Mar 7, 2020, at 5:04 PM, Hal Murray wrote:
>> 
>> kb...@n1k.org said:
>>> As far as I know there is no “closed form” solution to tuning a GPSDO. It is
>>> very much a measure / tweak / measure / tweak sort of thing. 
>> 
>> I've seen a recipe for tuning a PID controller. That was ages ago. I wonder 
>> where.
>> 
>> The key idea was that you needed to be able to poke the system and see how 
>> it 
>> responded.
>> 
>> Google for >tune PID< gets several hits that might be worth investigating.
>> 
>> 
>> -- 
>> These are my opinions. I hate spam.
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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.


___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bill Hawkins]

Try https://en.wikipedia.org/wiki/PID_controller

If that doesn't help, what we used to do for industrial process controllers was 
to set Reset time to the largest value and Derivative to zero (to disable them) 
and then increasethe gain until the loop oscillated when you made a step change 
to the setpoint, then you used 70% of that value for gain. The period of 
oscillation told you how to do Reset, but I don't remember that. Conservative 
settings were used because control valves were not linear. Heaters are 
generally linear.

Bill Hawkins, whose memory isn't what it used to be.

On Sat, Mar 7, 2020, at 5:04 PM, Hal Murray wrote:
> 
> kb...@n1k.org said:
> > As far as I know there is no “closed form” solution to tuning a GPSDO. It is
> > very much a measure / tweak / measure / tweak sort of thing. 
> 
> I've seen a recipe for tuning a PID controller. That was ages ago. I wonder 
> where.
> 
> The key idea was that you needed to be able to poke the system and see how it 
> responded.
> 
> Google for >tune PID< gets several hits that might be worth investigating.
> 
> 
> -- 
> These are my opinions. I hate spam.
> 
> 
> 
> 
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

That does not help you optimize the noise in a GPSDO. It’s targeted
at a completely different aspect of the control process. 

Bob

> On Mar 7, 2020, at 6:04 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> As far as I know there is no “closed form” solution to tuning a GPSDO. It is
>> very much a measure / tweak / measure / tweak sort of thing.  
> 
> I've seen a recipe for tuning a PID controller.  That was ages ago.  I wonder 
> where.
> 
> The key idea was that you needed to be able to poke the system and see how it 
> responded.
> 
> Google for >tune PID< gets several hits that might be worth investigating.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Hal Murray]

kb...@n1k.org said:
> As far as I know there is no “closed form” solution to tuning a GPSDO. It 
> is
> very much a measure / tweak / measure / tweak sort of thing.  

I've seen a recipe for tuning a PID controller.  That was ages ago.  I wonder 
where.

The key idea was that you needed to be able to poke the system and see how it 
responded.

Google for >tune PID< gets several hits that might be worth investigating.


-- 
These are my opinions.  I hate spam.




___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Tobias Pluess]

Hi,
I am sure it is theoretically possible to find an optimal control loop
design if you have accurate models of the OCXO and for the behaviour of the
1PPS pulse.
TvB has written a GPSDO simulator which allows to code different PLL and
control algorithms. I have implemented something similar in Matlab.
Basically, if you know the VCO tuning characteristics and the phase
detector constant, then you can use procedures as described in the PLL
books that are out there (I have ond from R. Best).

But I agree that it is perhaps a very difficult problem -  you cannot
simply try out different algorithms because each time it takes days to wait
until everything has settled and stabilised, then you need to record that
data etc.

Maybe the easiest way is indeed using the GPSDO simulator.
If there is some interest, I could perhaps post my Matlab code. It plots
nicely the calculated EFC voltage and simumates the OCXOs frequency
variation as the EFC is varied.

Best
Tobias
HB9FSX


On Sat., 7 Mar. 2020, 12:36 Gilles Clement,  wrote:

> Hi,
> How do you optimally tune the control loop time constant ?
> (Mine gets quite unstable when the update rate is slow - and the amplitude
> of the change step low - enough not to degrade the OCXO performance )
> Is there a method described somewhere (like the Ziegler–Nichols method for
> PID) ?
> Thx,
> Gilles.
>
> > Le 3 mars 2020 à 18:28, Attila Kinali  a écrit :
> >
> > On Tue, 3 Mar 2020 12:14:37 -0500
> > Jim Harman  wrote:
> >
> >> I don't understand why you say the DAC should have a resolution of 24-30
> >> bits. I can see that the loop time constant affects the precision
> needed in
> >> the filter calculations, but what does the time constant have to do with
> >> the needed DAC resolution? We don't have to wait for the whole time
> >> constant before changing the DAC, we can update the filter calculations
> and
> >> look at its output every second and adjust the DAC whenever the PI
> filtered
> >> phase error is one DAC step or more.
> >
> > You do wait the whole time before updating the DAC value.. kind of ish.
> > The control loop's time constant is exactly that: The time it takes
> > the control loop for a change in the input to affect the output (very
> > loosely speaking). Yes, the sample rate at which the loop runs is
> > much higher, but that doesn't change the fact that the loop is slow
> > to react. And you want it to be slow to react, as otherwise the high
> > noise of GPS degrades the performance of your OCXO.
> >
> >> If the OCXO has a tuning range of 1 ppm and we want frequency control
> >> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
> >> assuming the DAC covers the full tuning range of the oscillator?
> >
> > Yes. There is a calculation mistake in there. I corrected it in
> > the next mail:
> >
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097963.html
> >
> >   Attila Kinali
> >
> > --
> >   The bad part of Zurich is where the degenerates
> >throw DARK chocolate at you.
> >
> > ___
> > 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.
>
___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

As far as I know there is no “closed form” solution to tuning a GPSDO.
It is very much a measure / tweak / measure / tweak sort of thing. 

That said, there are a lot of basic design constraints that are pretty
well known. Your DAC needs to have a pretty small LSB. Updates
are normally done once a second ( = each time the PPS is measured). 

Bob

> On Mar 7, 2020, at 5:07 AM, Gilles Clement  wrote:
> 
> Hi,
> How do you optimally tune the control loop time constant ? 
> (Mine gets quite unstable when the update rate is slow - and the amplitude of 
> the change step low - enough not to degrade the OCXO performance )
> Is there a method described somewhere (like the Ziegler–Nichols method for 
> PID) ?
> Thx, 
> Gilles. 
> 
>> Le 3 mars 2020 à 18:28, Attila Kinali  a écrit :
>> 
>> On Tue, 3 Mar 2020 12:14:37 -0500
>> Jim Harman  wrote:
>> 
>>> I don't understand why you say the DAC should have a resolution of 24-30
>>> bits. I can see that the loop time constant affects the precision needed in
>>> the filter calculations, but what does the time constant have to do with
>>> the needed DAC resolution? We don't have to wait for the whole time
>>> constant before changing the DAC, we can update the filter calculations and
>>> look at its output every second and adjust the DAC whenever the PI filtered
>>> phase error is one DAC step or more.
>> 
>> You do wait the whole time before updating the DAC value.. kind of ish.
>> The control loop's time constant is exactly that: The time it takes
>> the control loop for a change in the input to affect the output (very
>> loosely speaking). Yes, the sample rate at which the loop runs is
>> much higher, but that doesn't change the fact that the loop is slow
>> to react. And you want it to be slow to react, as otherwise the high
>> noise of GPS degrades the performance of your OCXO.
>> 
>>> If the OCXO has a tuning range of 1 ppm and we want frequency control
>>> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
>>> assuming the DAC covers the full tuning range of the oscillator?
>> 
>> Yes. There is a calculation mistake in there. I corrected it in
>> the next mail: 
>> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097963.html
>> 
>>  Attila Kinali
>> 
>> -- 
>>  The bad part of Zurich is where the degenerates
>>   throw DARK chocolate at you.
>> 
>> ___
>> 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.


___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Gilles Clement]

Hi,
How do you optimally tune the control loop time constant ? 
(Mine gets quite unstable when the update rate is slow - and the amplitude of 
the change step low - enough not to degrade the OCXO performance )
Is there a method described somewhere (like the Ziegler–Nichols method for PID) 
?
Thx, 
Gilles. 

> Le 3 mars 2020 à 18:28, Attila Kinali  a écrit :
> 
> On Tue, 3 Mar 2020 12:14:37 -0500
> Jim Harman  wrote:
> 
>> I don't understand why you say the DAC should have a resolution of 24-30
>> bits. I can see that the loop time constant affects the precision needed in
>> the filter calculations, but what does the time constant have to do with
>> the needed DAC resolution? We don't have to wait for the whole time
>> constant before changing the DAC, we can update the filter calculations and
>> look at its output every second and adjust the DAC whenever the PI filtered
>> phase error is one DAC step or more.
> 
> You do wait the whole time before updating the DAC value.. kind of ish.
> The control loop's time constant is exactly that: The time it takes
> the control loop for a change in the input to affect the output (very
> loosely speaking). Yes, the sample rate at which the loop runs is
> much higher, but that doesn't change the fact that the loop is slow
> to react. And you want it to be slow to react, as otherwise the high
> noise of GPS degrades the performance of your OCXO.
> 
>> If the OCXO has a tuning range of 1 ppm and we want frequency control
>> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
>> assuming the DAC covers the full tuning range of the oscillator?
> 
> Yes. There is a calculation mistake in there. I corrected it in
> the next mail: 
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097963.html
> 
>   Attila Kinali
> 
> -- 
>   The bad part of Zurich is where the degenerates
>throw DARK chocolate at you.
> 
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Dienstag, 3. März 2020 18:41:43 CET Attila Kinali wrote:
> On Tue, 03 Mar 2020 14:42:49 +0100
> 
> Matthias Welwarsky  wrote:
> > In the meantime, I'm thinking of another modification to make: getting rid
> > of the HC390 ripple counter. I think I might be able to use the STM32 as
> > a frequency divider. I just have to figure out how to program the timers.
> > What might work is the following:
> > 
> > - Feed the 10MHz clock into the external trigger input for the timer,
> > configure the timer to count the trigger pulses instead of the internal
> > clock  source.
> 
> Better idea: feed the 10MHz input directly into the clock input
> RCC_OSC_IN and let the STM32 derive its internal clock from that.
> Doing that, the clock of your timer unit will be phase locked to
> the 10MHz signal. Then you can use the timer for both capturing
> the incomming PPS and for generating the 250kHz. The capturing
> will solve the issue with aliasing. The timer output should have
> a jitter in the low ps range. There is a bit more going on than
> you would want in the STM32 for a low noise signal, but most
> likely not so much as to degrade the output enough to matter.
> If you are worried about that, you can still add a 7474, with
> D connected to the STM32 timer output and the CLK to the 10MHz
> to clean the jitter. But as I said, that's probably not necessary
> in this case.

I have an STM32F042 without FPU and I'm doing a lot of double precision math. 
I'm not sure I can spare the 4/5th of the cycles.

> 
> If you want to create a stabilized output PPS from the STM32,
> you will need to do some software trickery to align the PPS,
> as you cannot hope to shift the phase of the Rb in a reasonable
> time to match up.

That's not very high on my laundry list.

> 
>   Attila Kinali





___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Tue, 03 Mar 2020 14:42:49 +0100
Matthias Welwarsky  wrote:

> In the meantime, I'm thinking of another modification to make: getting rid of 
> the HC390 ripple counter. I think I might be able to use the STM32 as a 
> frequency divider. I just have to figure out how to program the timers. What 
> might work is the following:
> 
> - Feed the 10MHz clock into the external trigger input for the timer, 
> configure the timer to count the trigger pulses instead of the internal 
> clock  source.

Better idea: feed the 10MHz input directly into the clock input
RCC_OSC_IN and let the STM32 derive its internal clock from that.
Doing that, the clock of your timer unit will be phase locked to
the 10MHz signal. Then you can use the timer for both capturing
the incomming PPS and for generating the 250kHz. The capturing
will solve the issue with aliasing. The timer output should have
a jitter in the low ps range. There is a bit more going on than
you would want in the STM32 for a low noise signal, but most
likely not so much as to degrade the output enough to matter.
If you are worried about that, you can still add a 7474, with
D connected to the STM32 timer output and the CLK to the 10MHz
to clean the jitter. But as I said, that's probably not necessary
in this case.

If you want to create a stabilized output PPS from the STM32,
you will need to do some software trickery to align the PPS,
as you cannot hope to shift the phase of the Rb in a reasonable
time to match up.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Bob kb8tq]

Hi

Ideally in a digital control loop you want at least 2 “extra” bits past the 
minimum required to hit your target accuracy. Things like noise, LSB
non-linearity, calculation roundoff, all drive that need. Indeed for a 
low noise loop, you would push the margin out even further. 

If your OCXO’s EFC is not perfectly linear (they never are) then it’s 
“slope ratio” gets into the act. If the highest slope is 2X the lowest 
(which is not uncommon), that will add another bit to the total. 


Bob

> On Mar 3, 2020, at 12:14 PM, Jim Harman  wrote:
> 
> Attila,
> 
> In your post from October you say,
> 
> What, I think, you haven't had a look at is the resolution of your DAC.
>> You get, including your resistive divider a 17bit resolution. But this
>> is not enough. You want to be able to control the OCXO such, that at
>> the loop time constant, you have less than 1LSB offset in frequency.
>> Usualy people aim for something in the order of 1000s as loop time
>> constant,
>> often even longer than that. Assuming your GPS receiver gives you
>> approximately
>> 1ns RMS jitter (probably worse than that, but it makes it easy to
>> calculate)
>> that would mean frequency control of the level of 1e-12 is required.
>> Assuming
>> your OCXO has a tuning range of 1ppm (I've seen 0.1 to 20ppm for OCXOs)
>> that would mean you have to controll the EFC voltage better than parts in
>> 1e-9
>> or 30 bits. Yes, this is kind of unreallistic, but that's what the design
>> should aim for. If you acheive something around 24bits, you will be
>> probably
>> close enough. (Note: that's 24bit resolution and stability over the
>> loop time constant. It is not 24bit absolute resolution)
> 
> 
> I don't understand why you say the DAC should have a resolution of 24-30
> bits. I can see that the loop time constant affects the precision needed in
> the filter calculations, but what does the time constant have to do with
> the needed DAC resolution? We don't have to wait for the whole time
> constant before changing the DAC, we can update the filter calculations and
> look at its output every second and adjust the DAC whenever the PI filtered
> phase error is one DAC step or more.
> 
> If the OCXO has a tuning range of 1 ppm and we want frequency control
> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
> assuming the DAC covers the full tuning range of the oscillator?
> 
> Thanks for any explanation you can provide.
> 
> 
>> 
> --Jim Harman
> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Tue, 3 Mar 2020 12:14:37 -0500
Jim Harman  wrote:

> I don't understand why you say the DAC should have a resolution of 24-30
> bits. I can see that the loop time constant affects the precision needed in
> the filter calculations, but what does the time constant have to do with
> the needed DAC resolution? We don't have to wait for the whole time
> constant before changing the DAC, we can update the filter calculations and
> look at its output every second and adjust the DAC whenever the PI filtered
> phase error is one DAC step or more.

You do wait the whole time before updating the DAC value.. kind of ish.
The control loop's time constant is exactly that: The time it takes
the control loop for a change in the input to affect the output (very
loosely speaking). Yes, the sample rate at which the loop runs is
much higher, but that doesn't change the fact that the loop is slow
to react. And you want it to be slow to react, as otherwise the high
noise of GPS degrades the performance of your OCXO.

> If the OCXO has a tuning range of 1 ppm and we want frequency control
> of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
> assuming the DAC covers the full tuning range of the oscillator?

Yes. There is a calculation mistake in there. I corrected it in
the next mail: 
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097963.html

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Jim Harman]

Attila,

In your post from October you say,

What, I think, you haven't had a look at is the resolution of your DAC.
> You get, including your resistive divider a 17bit resolution. But this
> is not enough. You want to be able to control the OCXO such, that at
> the loop time constant, you have less than 1LSB offset in frequency.
> Usualy people aim for something in the order of 1000s as loop time
> constant,
> often even longer than that. Assuming your GPS receiver gives you
> approximately
> 1ns RMS jitter (probably worse than that, but it makes it easy to
> calculate)
> that would mean frequency control of the level of 1e-12 is required.
> Assuming
> your OCXO has a tuning range of 1ppm (I've seen 0.1 to 20ppm for OCXOs)
> that would mean you have to controll the EFC voltage better than parts in
> 1e-9
> or 30 bits. Yes, this is kind of unreallistic, but that's what the design
> should aim for. If you acheive something around 24bits, you will be
> probably
> close enough. (Note: that's 24bit resolution and stability over the
> loop time constant. It is not 24bit absolute resolution)


I don't understand why you say the DAC should have a resolution of 24-30
bits. I can see that the loop time constant affects the precision needed in
the filter calculations, but what does the time constant have to do with
the needed DAC resolution? We don't have to wait for the whole time
constant before changing the DAC, we can update the filter calculations and
look at its output every second and adjust the DAC whenever the PI filtered
phase error is one DAC step or more.

If the OCXO has a tuning range of 1 ppm and we want frequency control
of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
assuming the DAC covers the full tuning range of the oscillator?

Thanks for any explanation you can provide.


>
--Jim Harman
___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Dienstag, 3. März 2020 14:14:37 CET Attila Kinali wrote:
> N'achmittag!
> 
> > No heatsink, just a couple of thermal vias into the ground plane and it
> > gets a bit warm, but not more than 35°C (case temperature). I just
> > checked with a thermocouple.
> 
> Ok.. I'm surprised. Is the PCB able to dissipate this much heat?

Well, it probably means that, yes. But I've not characterized the power 
consumption fully. I was in a bit of a hurry to get the prototype up and 
working so I didn't really make a power or thermal budget before, I just put 
everything together and hoped for the best. Since the numbers cannot lie, 
either the heat transfer through the thermal vias is much better than 
anticipated or the actual power consumption is much less than the estimate :)

I'll know that soon.

> 40°C is not just OKish, it's totally OK. I wouldn't worry until you
> hit something like 60°C. As long as the die is safely below 100°C
> it will be fine.
> 
> And yes, the 10MHz output will add a lot of additional current.
> At 3.3V that is about 25-30mA going into the connector.

That's going to roast the LDO for sure.

> > > I would also recommed using a DC/DC switched power supply to go
> > > down from 24V to 5V, to get around the big bulk of waste heat
> > > production.
> > 
> > For the GPS pre-regulator definitely. For the rest of the electronics -
> > maybe. But I wanted the power supply of U6 at more than 5V and I had to
> > balance the power dissipation somewhat to not burden everything onto U3,
> > hence the 12V intermediate voltage. Still, U3 could be replaced by a buck
> > converter down to, say, 6V, that would take the stress off of all
> > downstream LDOs. I just need to find something that has an appropriate
> > footprint. I don't have a lot of PCB area. I seem to remember that
> > synchronous buck converters can be had in SOT-23-6 package ;) I just need
> > to find something with a high enough switching frequency so that the
> > inductor can be very small.
> 
> There are parts are meant as a replacement for 78xx. Ie fit
> in a TO-220 footprint, like e.g. the OKI-78SR series from Murata.
> They are usually available in 3.3V, 5V and 12V... some manufacturers
> also have values in-between.

Thanks for the pointers, I'll have a look at them.

> > On the idea of using a TVS diode instead of the SCR crowbar - forget it. I
> > tried. By the time the polyfuse trips, the TVS has released the magic
> > smoke. The LPRO-101 draws about 1.7A during initial heat-up, the fuse has
> > to be rated accordingly. A TVS diode with a breakdown voltage of 27V
> > would have to dissipate, say, about 50 Watts for a couple of seconds at
> > least. I used a LDP24A, Besides from being of enormous size, I didn't
> > trust it not causing a fire when the protection trips.
> 
> Oh...kay? The input circuitry is usually meant as a protection against
> surges, not against having a power supply with the wrong voltage attached.
> So I am a litte bit surprised that you try to protect against that.
> Do you see it likely that your power supply goes up to a voltage that
> would break the LDOs downstream?

Hm, the origin of that circuit was a connector board I designed for the LPRO 
as a standalone frequency reference. I was a bit afraid to damage the Rb by 
connecting an incompatible power supply. I wasn't too worried about surge 
protection but actually overvoltage and reverse polarity. I just copied and 
pasted that part into the GPSDO.

> > Do you have some schematics online of your design? I've seen Tobias
> > schematics on the list, but I only looked at the last month of postings
> > so far.
> Not yet. I'm working on a write-up that explains all the components
> and what design decisions lead to them. For now, you can find the
> key components in the mails I wrote as an answer to Tobias:
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097962
> .html
> http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-November/0982
> 07.html

Thanks, I'll have a look.

In the meantime, I'm thinking of another modification to make: getting rid of 
the HC390 ripple counter. I think I might be able to use the STM32 as a 
frequency divider. I just have to figure out how to program the timers. What 
might work is the following:

- Feed the 10MHz clock into the external trigger input for the timer, 
configure the timer to count the trigger pulses instead of the internal clock 
source.
- Set the timer to auto-reload the desired divisor, e.g. 20 (-1),
- Set the capture/compare register to the same value, set the output mode to 
"toggle"

The result should be a 250kHz signal at the timers output pin. I have no idea 
though if the jitter is going to be better than with the HC390. If anything in 
the above scheme is linked to the internal AHB clock, the expected jitter will 
be around 20ns. That would definitely not improve the situation ;)

BR,
Matthias

> 
> 
>   Attila Kinali





___

Re: [time-nuts] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

N'achmittag!

On Sun, 01 Mar 2020 01:38:11 +0100
Matthias Welwarsky  wrote:


> On Samstag, 29. Februar 2020 20:08:13 CET Attila Kinali wrote:

> > The bulk (ie a bit less than half) of the power is dissipated in U3,
> > which is a 0.5A spec'ed LDO in D3PAK... if it's properly cooled.
> > Your PCB doesn't show any heatsink and will dissipate into the board.
> > Assuming that you can dump more than 100-200mW at a single spot
> > into a densly populated PCB without some thermal design is asking
> > for trouble. You will need a heatsink. If we are going by the above
> > 4W number, you need to get rid of at least 2W in U3. Assuming a
> > 20°C above ambient case temp is ok, this means a maximum thermal
> > resistance of 10K/W, better 5K/W. That's doable with a large D3PAK
> > heatsink, but even that is probably pushing it, unless you add a fan
> 
> No heatsink, just a couple of thermal vias into the ground plane and it gets 
> a 
> bit warm, but not more than 35°C (case temperature). I just checked with a 
> thermocouple. 

Ok.. I'm surprised. Is the PCB able to dissipate this much heat?


> > The next two LDO, U4 isn't any better off. It comes in even
> > tinier SOT-23-5 cases, which I wouldn't trust beyond 100mW
> > dissipation. That limits the current going through it to
> > about 10mA. Yet there are quite a few components on it that
> > definitely draw more alone. Heck, U8 alone probably draws 40-50mA.
> > Guestimating, I would say there is a total 60-100mA on U4,
> > which would result in something around 0.5-0.8W of dissipated power.
> 
> Yes, but you're overestimating the power consumption. The complete digital 
> part has no more than, say 30mA total consumption on the 3.3V rail. U4 gets a 
> bit warm, but 40°C case temperature is OK'ish. Still a lot, but apparently 
> the 
> thermal conductivity is enough. However - this is with no load on the 10MHz 
> output. The output driver is connected to the same power rail. This might 
> push 
> U4 over the edge ;)

40°C is not just OKish, it's totally OK. I wouldn't worry until you
hit something like 60°C. As long as the die is safely below 100°C
it will be fine.

And yes, the 10MHz output will add a lot of additional current.
At 3.3V that is about 25-30mA going into the connector. 


> > I would also recommed using a DC/DC switched power supply to go
> > down from 24V to 5V, to get around the big bulk of waste heat
> > production.
> 
> For the GPS pre-regulator definitely. For the rest of the electronics - 
> maybe. 
> But I wanted the power supply of U6 at more than 5V and I had to balance the 
> power dissipation somewhat to not burden everything onto U3, hence the 12V 
> intermediate voltage. Still, U3 could be replaced by a buck converter down 
> to, 
> say, 6V, that would take the stress off of all downstream LDOs. I just need 
> to 
> find something that has an appropriate footprint. I don't have a lot of PCB 
> area. I seem to remember that synchronous buck converters can be had in 
> SOT-23-6 package ;) I just need to find something with a high enough 
> switching 
> frequency so that the inductor can be very small.

There are parts are meant as a replacement for 78xx. Ie fit
in a TO-220 footprint, like e.g. the OKI-78SR series from Murata.
They are usually available in 3.3V, 5V and 12V... some manufacturers
also have values in-between.


 
> > Going forward.. or rather backward. You have Q1 presumably as
> > reverse polarity protection. Unfortunately it doesn't work that
> > way. The way you put the FET in, it will act as a source follower.
> > Meaning the voltage at the source will be the voltage at the
> > gate minus the threshold voltage. Now the gate is being pulled
> > up by a 8.4V Zener diode, which means the gate is supposedly
> > 8.4V-ish below the source, but that's more than the thresold
> > voltage, so the FET closes off and doesn't conduct. For this
> > kind of thing to work, you would have to turn the FET around,
> > the source pointing at the power source. But then, while
> > the FET sure does not conduct during reverse polarity,
> > the body/protection diode of the FET will conduct. Hence you
> > don't get any protection there. It would be a better idea
> > to just use a 1N4001 instead. Simpler, and can withstand
> > 100V reverse polarity :-) D4/D5 are probably meant as over
> > voltage protection. While this definitely works, it's kind of
> > crude. At least at these voltages. If this would be a 1kV system,
> > then using a triac would be fine, but for low voltage electronics,
> > the time it takes to fire a triac and get it switching will not
> > prevent the downstream electronics from getting fried. A better
> > approach is to use an appropriately rated TVS diode. Overall
> > simpler and better (aka faster) protection.
> 
> You probably missed that Q1 is a p-channel mosfet. The circuit around Q1 is 
> basically a textbook approach to reverse polarity protection. 

GAH! Indeed I did! I take back everything I said!

> On the idea of us

Re: [time-nuts] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

Hi Attila,

thanks for the review, but I think you're a bit too pessimistic about the 
power consumption. But let's get through your points:

On Samstag, 29. Februar 2020 20:08:13 CET Attila Kinali wrote:
> 
> First of all, the power supply seems to be under-dimensioned.
> You are going down from 24V, which means you are burning around 7
> times the power consumption of your electronics in the LDOs.
> Even if you assume everything is low power and the electronics only
> use around 200-300mW, that means you burn another 1.4-2.1W (Watt, no milli!)
> in the LDOs. Something in the order of 500-700mW consumption in the
> electronics would be probably closer to the truth. I.e. you should plan for
> ~4W that are dissipated by the LDOs. Or better still,
> calculate how much power each component uses and design the power
> supply accordingly.

I'll check the total power consumption when I assemble the next two PCBs, but 
I think you're probably not far off. The bulk of it is however the Ublox 
module, definitely the single most prominent consumer.

> The bulk (ie a bit less than half) of the power is dissipated in U3,
> which is a 0.5A spec'ed LDO in D3PAK... if it's properly cooled.
> Your PCB doesn't show any heatsink and will dissipate into the board.
> Assuming that you can dump more than 100-200mW at a single spot
> into a densly populated PCB without some thermal design is asking
> for trouble. You will need a heatsink. If we are going by the above
> 4W number, you need to get rid of at least 2W in U3. Assuming a
> 20°C above ambient case temp is ok, this means a maximum thermal
> resistance of 10K/W, better 5K/W. That's doable with a large D3PAK
> heatsink, but even that is probably pushing it, unless you add a fan

No heatsink, just a couple of thermal vias into the ground plane and it gets a 
bit warm, but not more than 35°C (case temperature). I just checked with a 
thermocouple. 

> The next problem is U12. I don't know which one of the ublox
> modules you choose, but be warned: they consume a lot of power!
> At the lower end of the spectrum we have the power safe mode
> of an NEO-6 spec'ed at typically (not max!) 11mA during tracking.
> It can, and will go up to 47mA(typ) during aquisition. Max
> current consumption is spec'ed at 67mA. The LEA/NEO-M8T are
> spec'ed at 32mA average, 67mA max. A LEA-5 is known to go up to
> 180mA during aquisition, while the datasheet only says only
> 150mA max. And all this is not yet including the antenna power
> supply, which is another 10-30mA. So, assuming you have a modern
> ublox module, you are in for around 100mA current consumption
> during aquisition (can last for several minutes) and around 50mA
> during tracking. That means poor little U12 has to dissipate 2W
> during aquisition and 1W during tracking. There is no way a tiny
> SC-73/SOT-223 case is going to handle that.

Yep, this one was more of an afterthought when I realized that I couldn't 
route the 12V rail through to the Ublox module and that the 12V regulator 
would never be able to cope with the additional load thermally. So I decided 
to put another 5V regulator in front of the Ublox module and pray. It keeps 
thermal equilibrium of around 46°C when the receiver is in HOLD mode, but 
certainly gets pretty toasty while it's acquiring satellites. If I do a 
revision, I'm definitely going to put a buck converter here, there's some 
pretty nice synchronous designs from TI with very good efficiency.

> The next two LDO, U4 isn't any better off. It comes in even
> tinier SOT-23-5 cases, which I wouldn't trust beyond 100mW
> dissipation. That limits the current going through it to
> about 10mA. Yet there are quite a few components on it that
> definitely draw more alone. Heck, U8 alone probably draws 40-50mA.
> Guestimating, I would say there is a total 60-100mA on U4,
> which would result in something around 0.5-0.8W of dissipated power.

Yes, but you're overestimating the power consumption. The complete digital 
part has no more than, say 30mA total consumption on the 3.3V rail. U4 gets a 
bit warm, but 40°C case temperature is OK'ish. Still a lot, but apparently the 
thermal conductivity is enough. However - this is with no load on the 10MHz 
output. The output driver is connected to the same power rail. This might push 
U4 over the edge ;)

Keep in mind also that the ambient temperature is not 20°C, the whole PCB sits 
in front of the LPRO-101 with a surface temperature of about 40°C. 

> Only U9 and U10 have low enough loads that I would say that they
> can do their job. Though you should calculate the maximum load
> and dissipated power, just to be sure

These two are fine, they don't need source a lot of current. 

> I would also recommed using a DC/DC switched power supply to go
> down from 24V to 5V, to get around the big bulk of waste heat
> production.

For the GPS pre-regulator definitely. For the rest of the electronics - maybe. 
But I wanted the power supply of U6 at more than 5V and I had to

Re: [time-nuts] New Subscriber, DIY GPSDO project (yes, another one)

[Attila Kinali]

On Sat, 29 Feb 2020 15:01:13 +0100
Matthias Welwarsky  wrote:

> Following up in the previous post, here's the latest schematics and some 
> screen shots of top and bottom layers. This is a two layer board, btw.

I had a quick look at your design. It looks okish, but there are
a few things that need to be improved.

First of all, the power supply seems to be under-dimensioned.
You are going down from 24V, which means you are burning around 7
times the power consumption of your electronics in the LDOs. 
Even if you assume everything is low power and the electronics only
use around 200-300mW, that means you burn another 1.4-2.1W (Watt, no milli!)
in the LDOs. Something in the order of 500-700mW consumption in the
electronics would be probably closer to the truth. I.e. you should
plan for ~4W that are dissipated by the LDOs. Or better still,
calculate how much power each component uses and design the power
supply accordingly.

The bulk (ie a bit less than half) of the power is dissipated in U3,
which is a 0.5A spec'ed LDO in D3PAK... if it's properly cooled.
Your PCB doesn't show any heatsink and will dissipate into the board.
Assuming that you can dump more than 100-200mW at a single spot
into a densly populated PCB without some thermal design is asking
for trouble. You will need a heatsink. If we are going by the above
4W number, you need to get rid of at least 2W in U3. Assuming a
20°C above ambient case temp is ok, this means a maximum thermal
resistance of 10K/W, better 5K/W. That's doable with a large D3PAK
heatsink, but even that is probably pushing it, unless you add a fan

The next problem is U12. I don't know which one of the ublox
modules you choose, but be warned: they consume a lot of power!
At the lower end of the spectrum we have the power safe mode
of an NEO-6 spec'ed at typically (not max!) 11mA during tracking.
It can, and will go up to 47mA(typ) during aquisition. Max
current consumption is spec'ed at 67mA. The LEA/NEO-M8T are
spec'ed at 32mA average, 67mA max. A LEA-5 is known to go up to
180mA during aquisition, while the datasheet only says only
150mA max. And all this is not yet including the antenna power
supply, which is another 10-30mA. So, assuming you have a modern
ublox module, you are in for around 100mA current consumption
during aquisition (can last for several minutes) and around 50mA
during tracking. That means poor little U12 has to dissipate 2W
during aquisition and 1W during tracking. There is no way a tiny
SC-73/SOT-223 case is going to handle that.

The next two LDO, U4 isn't any better off. It comes in even
tinier SOT-23-5 cases, which I wouldn't trust beyond 100mW
dissipation. That limits the current going through it to
about 10mA. Yet there are quite a few components on it that
definitely draw more alone. Heck, U8 alone probably draws 40-50mA.
Guestimating, I would say there is a total 60-100mA on U4,
which would result in something around 0.5-0.8W of dissipated power.

Only U9 and U10 have low enough loads that I would say that they
can do their job. Though you should calculate the maximum load
and dissipated power, just to be sure

I would also recommed using a DC/DC switched power supply to go
down from 24V to 5V, to get around the big bulk of waste heat
production. 

Going forward.. or rather backward. You have Q1 presumably as
reverse polarity protection. Unfortunately it doesn't work that
way. The way you put the FET in, it will act as a source follower.
Meaning the voltage at the source will be the voltage at the
gate minus the threshold voltage. Now the gate is being pulled
up by a 8.4V Zener diode, which means the gate is supposedly
8.4V-ish below the source, but that's more than the thresold
voltage, so the FET closes off and doesn't conduct. For this
kind of thing to work, you would have to turn the FET around,
the source pointing at the power source. But then, while
the FET sure does not conduct during reverse polarity, 
the body/protection diode of the FET will conduct. Hence you
don't get any protection there. It would be a better idea
to just use a 1N4001 instead. Simpler, and can withstand
100V reverse polarity :-) D4/D5 are probably meant as over
voltage protection. While this definitely works, it's kind of
crude. At least at these voltages. If this would be a 1kV system,
then using a triac would be fine, but for low voltage electronics,
the time it takes to fire a triac and get it switching will not
prevent the downstream electronics from getting fried. A better
approach is to use an appropriately rated TVS diode. Overall
simpler and better (aka faster) protection.


Going further back: You use two decade counters to devide the 10MHz
signal from the rubidium by 2000. and use this than as a stop signal
for the TD7200. Yes, this idea works but be aware that the 74390 is
a ripple counter. This means that each division stage is clocked by
the previous stage. This means the jitter of each stage add up. If
you want to stay with this topology, I would sugge

Re: [time-nuts] New Subscriber, DIY GPSDO project (yes, another one)

[ew via time-nuts]

Please contact me direct off list
In a message dated 2/27/2020 4:46:32 PM Eastern Standard Time, 
time-n...@welwarsky.de writes:

On Donnerstag, 27. Februar 2020 19:16:22 CET ew via time-nuts wrote:
> Matthias where are you located. I am in the US but I have some partners in
> crime that may be able to help you with AV testing    ewkeh...@aol.com
> 
> Bert Kehren

I'm in Germany.

BR,
Matthias

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

___
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] New Subscriber, DIY GPSDO project (yes, another one)

[Matthias Welwarsky]

On Donnerstag, 27. Februar 2020 19:16:22 CET ew via time-nuts wrote:
> Matthias where are you located. I am in the US but I have some partners in
> crime that may be able to help you with AV testingewkeh...@aol.com
> 
> Bert Kehren

I'm in Germany.

BR,
Matthias

> ___
> 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] New Subscriber, DIY GPSDO project (yes, another one)

[ew via time-nuts]

Matthias where are you located. I am in the US but I have some partners in 
crime that may be able to help you with AV testing    ewkeh...@aol.com

Bert Kehren
___
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.