I've designed a GPSDO, but how "good" is it?
On Sun, 16 Aug 2015 16:54:08 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
If I counted correctly, you have a maximum offset of 350ns. For GPSDOs
that are close to each other, that's a quite considerable shift of phase.
Are you sure your software implements a phase locked loop and not a
frequency locked loop?
The firmware is at: https://github.com/nsayer/GPS-disciplined-OXCO
I’d be hard pressed to see how it’s anything other than an FLL.
There’s no phase comparator. I’m counting how many system clock cycles
happen between PPS rising edges. That’s it.
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
For additional goodnes: steer the PPS such, that half of the time
you get a counter value a and the other half of the time a counter value a+1.
By doing this, you will use the sawtooth of the GPS module as dithering
for your counter, and thus increase the resolution when you average.
Assuming no hanging bridges, this will get you below 1ppb at taus >200-500s,
if you keep the TCXO stable enough, otherwise deviations due to temperature
shifts and supply voltage changes will dominate.
If this is good enough, I would leave it at that. If not, then first
thing would be a respin of the board with a seperate supply for the
DAC and TXCO using a modern, low noise, high PSRR LDO (have a look at
what TI came up with in the last 10 years, these are usually a good choice)
If that is still not enough, put a plastic cap over the TCXO.
If still not enough, glue a transistor on top of the TCXO with a
temp sensor (e.g. an 1k NTC) and use that to stabilize the TCXO
temperature to a few °C (you should have no trouble to get
to <0.1°C though). Have a look at the ham radio literature how
this poor mans OCXO is done. There it is (was?) pretty much standard.
If this still doesn't get you to well below 1ppb @tau=500s, then something
is screwed up in the implentation.
If you want get to 1ppb at shorter taus, then you will need to implement
a better TIC. Richard McCorkle's PICTIC-II is a good starting point.
IIRC He once told me that he got down to 30ps with an external 14bit ADC
(less noise and higher stability than the on chip ADCs found in uCs).
According to Bruce Griffiths, the right choice for the ADC is to use
an SAR. Analog and Ti are AFAIK the best choices here.
If we assume that you get to 100ps, then you will be able to reach
1ppb at taus in the range of 10s to 100s (ie the limiting factor will
be the GPS module). And of course, you will then need to do proper sawtooth
correction (i hope your module provides that, if not, choose a different one)
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
On Aug 16, 2015, at 9:40 PM, Nick Sayer nsayer@kfu.com wrote:
On Aug 16, 2015, at 6:04 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
Here’s some of the “that depends” questions:
What is your stability goal?
You talk about the NIST numbers on GPSDO’s. What level of stability are you after?
I believe I’m at or better than the stability I originally sought. Part 1 of my question is whether that’s actually true or whether my naivety is presenting me with a delusion. Part 2 is whether the price point at which I’ve arrived will support the level of stability I’ve achieved, or am I delusional in thinking people would or should pay what I’m asking for what I’m offering.
The stability can only be verified by careful testing, The design goal (what’s the spec) will in many ways determine
what sort of testing you will need to set up. A 1x10^-9 design would be tested differently than a 1x10^-13 design.
What is your end application?
Is this intended as a lab standard, the reference for a radio, something else entirely?
A low cost lab standard is what I have in mind. A box you can sit on your workbench with 3 BNC jacks that can feed 10 MHz into your frequency counter or what not.
Do you anticipate any phase noise sensitive instruments being attached? Most frequency counters are fairly simple.
What is the destination?
Is this heading towards a commercial venture or is it a basement project?
I’ve entered it in the “Best Product” Hackaday 2015 prize contest. That said, I have no intention of attempting to compete with the established commercial firms in this space. I want to stay at around a Q:100 unit cost of around $75, which is where it is right now (the retail price is higher at the moment because I’m not manufacturing them in Q:100 lots yet).
Ok, so have you taken a good look at your costs and return? Do you have an method set up for
support of the product and for handling returns / repairs? Overhead costs that do not get factored
in early can be very painful later on.
What is the budget?
Do you have $200K to spend on this? Did the piggybank run dry at $100?
For a commercial venture this is a very important factor. You don’t have to share
the info, You do have to work out a number.
What is the timeline?
Does the project complete at the end of the summer, no matter what? Is it
something that is worth another year or two of effort?
I’ve got something now, but I don’t mind revving it to improve it, as long as the budget doesn’t change a lot. A lot of suggestions so far have centered around improvements that could be made regardless of budget. Like I’ve said, I don’t want to try to compete with Trimble.
I would suggest that you figure on quite a bit of your spare time going into this.
What is your background?
Mostly software, but in the last few years I’ve become reconnected to my nascent hardware side. I’ve been selling stuff in my Tindie store for a while now - a fairly eclectic mix of different projects that interest me. What led me to this project was another one - my Crazy Clock. I discovered a rather embarrassing design error that was causing errors on the order of dozens of ppm (I expected under ten). The first step in coming to grips with that issue was determining its scope, and that meant an extremely accurate low frequency counter, and that led me to needing a frequency standard. But I don’t have any way to test something I buy off eBay, so I wanted a GPSDO. But I couldn’t find any that weren’t way out of budget, so I set out to design one. And because I figured I wasn’t the only maker that needed something like this, but didn’t have the need or budget for something 2 orders of magnitude better, I thought I’d try this.
Now where I am is trying to determine if I am correct in my assertions, and if my cost-benefit analysis of this as a product makes sense or not.
That’s what the market will tell you ….
Does all of the stuff we’ve been tossing around make perfect sense? (= you do
something like this for a living). Are we talking about a bunch of stuff that makes
very little sense? (= you are just getting started at this sort of thing).
No, it’s all perfectly sensible.
Ok, so here’s the next layer:
If you are selling a frequency standard, most of your customers will probably be
interested in it’s frequency stability. Unfortunately this opens a major can of worms
spec wise. There are a number of measures that characterize various types of
noise. None of them directly address “if I measure 1.23 x10^-10 is it correct”. You
see numbers like “< 1x10^-10 99% of the time” in spec sheets.
If you dig into the archives, you can find numbers posts from people who are
disappointed that their "1x10^-13 GPSDO” can not deliver a 1x10^-10 frequency
measurement 99% of the time.
Each of these twists and turns heads you off into a different set of further issues and
likely some more questions. For a commercial venture, buying custom oscillators in
bulk is a very normal thing to do. For a battery powered balloon carried reference, you
do things different than for a rack mount standard. Each of these projects people come up
with have its own unique drivers.
Each of us in our replies, tries to guess what your constraints are or are not. In doing
so we likely substitute our constraints for yours. The further our constraints diverge from
your constraints, the further off base our advice and answers will be.
I appreciate that. I came here with a narrow question in mind, but perhaps it wasn’t the correct one.
There is only so much you can pack in a single message …
Bob
Bob
On Aug 16, 2015, at 3:39 PM, Nick Sayer via time-nuts time-nuts@febo.com wrote:
On Aug 16, 2015, at 12:31 PM, Tom Van Baak tvb@LeapSecond.com wrote:
Anyway, to answer your question -- to measure its true performance you only need two things. 1) a phase meter (or time interval counter) that's good to 1 ns or better, and 2) a local reference standard that's maybe 10x better than the TCXO and the Adafruit GPS. Usually that means a cesium standard, or supremely qualified GPSDO, or equivalent.
I have a frequency counter, but it’s not a phase meter. I have a scope, but I assume that trying to use a ruler with scope traces isn’t the textbook way of doing that. :D
I have considered in the past buying a used rubidium standard off eBay, but have hesitated because I don’t know how much life there is left in the tube, and I just have to take it on faith that it’s stable and accurate. I have somewhat more faith in the GPS PPS, but clearly that has limits.
A number of us here on the time-nuts list have such equipment at home. And unlike professional labs, we will do it for free/fun if you loan the GPSDO for a week.
I will happily give one to someone if they would be willing to help a relative newbie with this stuff.
Just one though. They’re kind of expensive to build. :D
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Aug 17, 2015, at 4:06 AM, Bob Camp kb8tq@n1k.org wrote:
On Aug 16, 2015, at 9:40 PM, Nick Sayer nsayer@kfu.com wrote:
On Aug 16, 2015, at 6:04 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
Here’s some of the “that depends” questions:
What is your stability goal?
You talk about the NIST numbers on GPSDO’s. What level of stability are you after?
I believe I’m at or better than the stability I originally sought. Part 1 of my question is whether that’s actually true or whether my naivety is presenting me with a delusion. Part 2 is whether the price point at which I’ve arrived will support the level of stability I’ve achieved, or am I delusional in thinking people would or should pay what I’m asking for what I’m offering.
The stability can only be verified by careful testing, The design goal (what’s the spec) will in many ways determine
what sort of testing you will need to set up. A 1x10^-9 design would be tested differently than a 1x10^-13 design.
10^-9 was the target all along. Question number two that I came with was whether or not it was reasonable to ask $175 for 10^-9.
What is your end application?
Is this intended as a lab standard, the reference for a radio, something else entirely?
A low cost lab standard is what I have in mind. A box you can sit on your workbench with 3 BNC jacks that can feed 10 MHz into your frequency counter or what not.
Do you anticipate any phase noise sensitive instruments being attached? Most frequency counters are fairly simple.
I stared with an immediate need, and that was for low frequency testing with sample times in the 10^1 range, so phase coherency has not been anything I’ve been concerned with. The Connor Winfield phase plots at the low end look “good enough” to me, and with a 370 ppt DAC granularity, I can’t ask for a lot of phase coherency at the high end (you can see that in the time lapse videos).
What is the destination?
Is this heading towards a commercial venture or is it a basement project?
I’ve entered it in the “Best Product” Hackaday 2015 prize contest. That said, I have no intention of attempting to compete with the established commercial firms in this space. I want to stay at around a Q:100 unit cost of around $75, which is where it is right now (the retail price is higher at the moment because I’m not manufacturing them in Q:100 lots yet).
Ok, so have you taken a good look at your costs and return? Do you have an method set up for
support of the product and for handling returns / repairs? Overhead costs that do not get factored
in early can be very painful later on.
Yup. The rule of thumb I have always used is that retail price is double the cost. That’s why I talk about a Q:100 cost of $75 and am charging $175. $175 is not $150 because I am not yet at Q:100 build costs, but that is the eventual goal.
What is the budget?
Do you have $200K to spend on this? Did the piggybank run dry at $100?
For a commercial venture this is a very important factor. You don’t have to share
the info, You do have to work out a number.
What is the timeline?
Does the project complete at the end of the summer, no matter what? Is it
something that is worth another year or two of effort?
I’ve got something now, but I don’t mind revving it to improve it, as long as the budget doesn’t change a lot. A lot of suggestions so far have centered around improvements that could be made regardless of budget. Like I’ve said, I don’t want to try to compete with Trimble.
I would suggest that you figure on quite a bit of your spare time going into this.
That never happens. :)
What is your background?
Mostly software, but in the last few years I’ve become reconnected to my nascent hardware side. I’ve been selling stuff in my Tindie store for a while now - a fairly eclectic mix of different projects that interest me. What led me to this project was another one - my Crazy Clock. I discovered a rather embarrassing design error that was causing errors on the order of dozens of ppm (I expected under ten). The first step in coming to grips with that issue was determining its scope, and that meant an extremely accurate low frequency counter, and that led me to needing a frequency standard. But I don’t have any way to test something I buy off eBay, so I wanted a GPSDO. But I couldn’t find any that weren’t way out of budget, so I set out to design one. And because I figured I wasn’t the only maker that needed something like this, but didn’t have the need or budget for something 2 orders of magnitude better, I thought I’d try this.
Now where I am is trying to determine if I am correct in my assertions, and if my cost-benefit analysis of this as a product makes sense or not.
That’s what the market will tell you ….
Does all of the stuff we’ve been tossing around make perfect sense? (= you do
something like this for a living). Are we talking about a bunch of stuff that makes
very little sense? (= you are just getting started at this sort of thing).
No, it’s all perfectly sensible.
Ok, so here’s the next layer:
If you are selling a frequency standard, most of your customers will probably be
interested in it’s frequency stability. Unfortunately this opens a major can of worms
spec wise. There are a number of measures that characterize various types of
noise. None of them directly address “if I measure 1.23 x10^-10 is it correct”. You
see numbers like “< 1x10^-10 99% of the time” in spec sheets.
If you dig into the archives, you can find numbers posts from people who are
disappointed that their "1x10^-13 GPSDO” can not deliver a 1x10^-10 frequency
measurement 99% of the time.
Ok, well, with the advice I’ve gotten so far here I’ve decided I am going to see if I can afford a TimePod and I’m going to try and get one of those FE-5680A rubidium standards off eBay. If that works out, then my perception (correct me if I’m wrong), is that that will be enough to characterize 10^-9 levels of expected performance.
I’ve also mailed a unit to a kind volunteer here who said he’d take a look at it. If his opinion differs wildly from what I think is the current state of affairs, then I can stop and take a serious look at whether a new design would be able to better reach the same goals with the same pricing.
Each of these twists and turns heads you off into a different set of further issues and
likely some more questions. For a commercial venture, buying custom oscillators in
bulk is a very normal thing to do. For a battery powered balloon carried reference, you
do things different than for a rack mount standard. Each of these projects people come up
with have its own unique drivers.
Each of us in our replies, tries to guess what your constraints are or are not. In doing
so we likely substitute our constraints for yours. The further our constraints diverge from
your constraints, the further off base our advice and answers will be.
I appreciate that. I came here with a narrow question in mind, but perhaps it wasn’t the correct one.
There is only so much you can pack in a single message …
Bob
Bob
On Aug 16, 2015, at 3:39 PM, Nick Sayer via time-nuts time-nuts@febo.com wrote:
On Aug 16, 2015, at 12:31 PM, Tom Van Baak tvb@LeapSecond.com wrote:
Anyway, to answer your question -- to measure its true performance you only need two things. 1) a phase meter (or time interval counter) that's good to 1 ns or better, and 2) a local reference standard that's maybe 10x better than the TCXO and the Adafruit GPS. Usually that means a cesium standard, or supremely qualified GPSDO, or equivalent.
I have a frequency counter, but it’s not a phase meter. I have a scope, but I assume that trying to use a ruler with scope traces isn’t the textbook way of doing that. :D
I have considered in the past buying a used rubidium standard off eBay, but have hesitated because I don’t know how much life there is left in the tube, and I just have to take it on faith that it’s stable and accurate. I have somewhat more faith in the GPS PPS, but clearly that has limits.
A number of us here on the time-nuts list have such equipment at home. And unlike professional labs, we will do it for free/fun if you loan the GPSDO for a week.
I will happily give one to someone if they would be willing to help a relative newbie with this stuff.
Just one though. They’re kind of expensive to build. :D
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Aug 17, 2015, at 1:16 AM, Attila Kinali attila@kinali.ch wrote:
On Sun, 16 Aug 2015 16:54:08 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
If I counted correctly, you have a maximum offset of 350ns. For GPSDOs
that are close to each other, that's a quite considerable shift of phase.
Are you sure your software implements a phase locked loop and not a
frequency locked loop?
The firmware is at: https://github.com/nsayer/GPS-disciplined-OXCO
I’d be hard pressed to see how it’s anything other than an FLL.
There’s no phase comparator. I’m counting how many system clock cycles
happen between PPS rising edges. That’s it.
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
I do that. It’s a 32 bit counter (the 16 bit counter has an overflow interrupt that increments the high 16 bytes in software). The counter free-runs. 32 bits at 10 MHz takes around 400 seconds to wrap.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
I don’t quite get it.
What I do is every time there’s a capture interrupt, I subtract the counter value of the last capture from this one. That gives me how many clock cycles there were between PPS rising edges. But there’s no way for me to know the phase relationship between the two rising edges (the PPS and 10 MHz). I can only assume that the capture takes place within one cycle. Fortunately, I don’t have to be concerned with software latency, as the capture interrupt occurs immediately after, well before anything else gets in the way.
I actually do the above counting 100 PPS intervals. That is, I only collect the delta every 100 capture interrupts. That’s the 1 ppb error resolution over 100 seconds. For the user feedback, I keep a rolling window of ten of those. When the sum of those ten error deltas is < 10, I call that 1 ppb over 1000 seconds.
When the error delta over 100 seconds is non-zero and less than 5, I increment or decrement the DAC value, thus adjusting the trim by an expected ~370 ppt. When the error is more than 5, I double the error and add/subtract that to the DAC value. It’s not a PID, but it generally reaches steady-state quickly enough. I don’t make any LOCK LED indications at all until the 1000 second sample window is full, and by then the 100 second deltas are under 5 (usually at or under 1).
For additional goodnes: steer the PPS such, that half of the time
you get a counter value a and the other half of the time a counter value a+1.
By doing this, you will use the sawtooth of the GPS module as dithering
for your counter, and thus increase the resolution when you average.
Assuming no hanging bridges, this will get you below 1ppb at taus >200-500s,
if you keep the TCXO stable enough, otherwise deviations due to temperature
shifts and supply voltage changes will dominate.
If this is good enough, I would leave it at that. If not, then first
thing would be a respin of the board with a seperate supply for the
DAC and TXCO using a modern, low noise, high PSRR LDO (have a look at
what TI came up with in the last 10 years, these are usually a good choice)
If that is still not enough, put a plastic cap over the TCXO.
If still not enough, glue a transistor on top of the TCXO with a
temp sensor (e.g. an 1k NTC) and use that to stabilize the TCXO
temperature to a few °C (you should have no trouble to get
to <0.1°C though). Have a look at the ham radio literature how
this poor mans OCXO is done. There it is (was?) pretty much standard.
If this still doesn't get you to well below 1ppb @tau=500s, then something
is screwed up in the implentation.
If you want get to 1ppb at shorter taus, then you will need to implement
a better TIC. Richard McCorkle's PICTIC-II is a good starting point.
IIRC He once told me that he got down to 30ps with an external 14bit ADC
(less noise and higher stability than the on chip ADCs found in uCs).
According to Bruce Griffiths, the right choice for the ADC is to use
an SAR. Analog and Ti are AFAIK the best choices here.
If we assume that you get to 100ps, then you will be able to reach
1ppb at taus in the range of 10s to 100s (ie the limiting factor will
be the GPS module). And of course, you will then need to do proper sawtooth
correction (i hope your module provides that, if not, choose a different one)
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Mon, 17 Aug 2015 07:14:34 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
I do that. It’s a 32 bit counter (the 16 bit counter has an overflow
interrupt that increments the high 16 bytes in software). The counter
free-runs. 32 bits at 10 MHz takes around 400 seconds to wrap.
So that works right. Good.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
I don’t quite get it.
What I do is every time there’s a capture interrupt, I subtract the counter
value of the last capture from this one. That gives me how many clock cycles
there were between PPS rising edges. But there’s no way for me to know the
phase relationship between the two rising edges (the PPS and 10 MHz). I can
only assume that the capture takes place within one cycle. Fortunately, I
don’t have to be concerned with software latency, as the capture interrupt
occurs immediately after, well before anything else gets in the way.
By taking the difference of "current pulse time" minus "previous pulse time"
and using this as the input into your control loop, you are making an FLL.
Instead you should use "time the pps is expected to arrive" minus "when
the pulse actually arrived".
You have a nominal frequency of 10MHz and a 16bit counter. That means
a second is 152 overflows plus 38528 counts long. Assuming you start with
0, the expected arrival of the next pulse is at count 38528. When it comes
earlier, your TCXO frequency was too low, when it comes later your TCXO
frequency was too high. The third pulse is exected to arrive at
count = (385282) % 2^16 = 11520. Again, feed the difference between that
value and when the pulse actually arrived into your control loop. The forth
pulse is expected at, (385283) % 2^16 = 50048,... etc pp
By not taking the difference to the previous pulse, but to the expected
time of the pulse, any fractional error in the calculation/frequency
will accumulate until it reaches the point where it actually becomes
visible as an offset between expected pulse time and pulse time.
And hence, forms a PLL.
If the timer of the ATtiny allows that, you can set it to overflow
at 62500. This divides 10e6 evenly, which gives you a constant count
number when you expect the pulse, which you then can set into mid range,
ie. at 31250. (makes the software easier)
When the error delta over 100 seconds is non-zero and less than 5, I
increment or decrement the DAC value, thus adjusting the trim by an expected
~370 ppt. When the error is more than 5, I double the error and add/subtract
that to the DAC value. It’s not a PID, but it generally reaches steady-state
quickly enough. I don’t make any LOCK LED indications at all until the 1000
second sample window is full, and by then the 100 second deltas are under 5
(usually at or under 1).
You really should read the wikipedia article on the PID loop and implement
a simple PI loop (no need for the D part). That's not more effort than what
you already did, but gives you better stability.
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
Hi Attila,
I'm planning to collect raw phase data from his TCXO (in holdover). Not only will we get the ADEV of his LO but that data, plus the Adafruit GPS data, can then be fed into the GPSDO simulator program.
Nick can modify the simulator with his current algorithm and see how his GPSDO would perform with different styles of control loop. The GPS simulator can easily model his phase comparator (a CPU capture register with some known granularity) and his DAC (also with known granularity).
When done right, the very C code used in his AVR control loop can be the C code used in the simulator. Actual LO data, actual GPS data, actual code. The result is seeing how your GPSDO works on your PC in a few seconds instead of waiting a few days (and needing a precision frequency counter and atomic reference) to test the real thing. More info here:
http://www.leapsecond.com/pages/gpsdo-sim/
https://www.febo.com/pipermail/time-nuts/2014-March/083734.html
In the end of course you want to test the real h/w, but being able to see how control loops work, and solving problems of lost lock, and maximizing the performance of the code -- can be done far more efficiently under simulation.
/tvb
----- Original Message -----
From: "Attila Kinali" attila@kinali.ch
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Monday, August 17, 2015 12:07 PM
Subject: Re: [time-nuts] I've designed a GPSDO, but how "good" is it?
On Mon, 17 Aug 2015 07:14:34 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
I do that. It’s a 32 bit counter (the 16 bit counter has an overflow
interrupt that increments the high 16 bytes in software). The counter
free-runs. 32 bits at 10 MHz takes around 400 seconds to wrap.
So that works right. Good.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
I don’t quite get it.
What I do is every time there’s a capture interrupt, I subtract the counter
value of the last capture from this one. That gives me how many clock cycles
there were between PPS rising edges. But there’s no way for me to know the
phase relationship between the two rising edges (the PPS and 10 MHz). I can
only assume that the capture takes place within one cycle. Fortunately, I
don’t have to be concerned with software latency, as the capture interrupt
occurs immediately after, well before anything else gets in the way.
By taking the difference of "current pulse time" minus "previous pulse time"
and using this as the input into your control loop, you are making an FLL.
Instead you should use "time the pps is expected to arrive" minus "when
the pulse actually arrived".
You have a nominal frequency of 10MHz and a 16bit counter. That means
a second is 152 overflows plus 38528 counts long. Assuming you start with
0, the expected arrival of the next pulse is at count 38528. When it comes
earlier, your TCXO frequency was too low, when it comes later your TCXO
frequency was too high. The third pulse is exected to arrive at
count = (385282) % 2^16 = 11520. Again, feed the difference between that
value and when the pulse actually arrived into your control loop. The forth
pulse is expected at, (385283) % 2^16 = 50048,... etc pp
By not taking the difference to the previous pulse, but to the expected
time of the pulse, any fractional error in the calculation/frequency
will accumulate until it reaches the point where it actually becomes
visible as an offset between expected pulse time and pulse time.
And hence, forms a PLL.
If the timer of the ATtiny allows that, you can set it to overflow
at 62500. This divides 10e6 evenly, which gives you a constant count
number when you expect the pulse, which you then can set into mid range,
ie. at 31250. (makes the software easier)
When the error delta over 100 seconds is non-zero and less than 5, I
increment or decrement the DAC value, thus adjusting the trim by an expected
~370 ppt. When the error is more than 5, I double the error and add/subtract
that to the DAC value. It’s not a PID, but it generally reaches steady-state
quickly enough. I don’t make any LOCK LED indications at all until the 1000
second sample window is full, and by then the 100 second deltas are under 5
(usually at or under 1).
You really should read the wikipedia article on the PID loop and implement
a simple PI loop (no need for the D part). That's not more effort than what
you already did, but gives you better stability.
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
On Aug 17, 2015, at 12:31 PM, Tom Van Baak tvb@LeapSecond.com wrote:
Hi Attila,
I'm planning to collect raw phase data from his TCXO (in holdover). Not only will we get the ADEV of his LO but that data, plus the Adafruit GPS data, can then be fed into the GPSDO simulator program.
Nick can modify the simulator with his current algorithm and see how his GPSDO would perform with different styles of control loop. The GPS simulator can easily model his phase comparator (a CPU capture register with some known granularity) and his DAC (also with known granularity).
When done right, the very C code used in his AVR control loop can be the C code used in the simulator. Actual LO data, actual GPS data, actual code. The result is seeing how your GPSDO works on your PC in a few seconds instead of waiting a few days (and needing a precision frequency counter and atomic reference) to test the real thing. More info here:
http://www.leapsecond.com/pages/gpsdo-sim/
https://www.febo.com/pipermail/time-nuts/2014-March/083734.html
In the end of course you want to test the real h/w, but being able to see how control loops work, and solving problems of lost lock, and maximizing the performance of the code -- can be done far more efficiently under simulation.
Thanks to both of you. I will definitely look into the simulator. Given the budget, I don’t have a free hand to improve the hardware, but firmware (modulo memory requirements) is free, so I’m certainly willing to explore.
/tvb
----- Original Message -----
From: "Attila Kinali" attila@kinali.ch
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Monday, August 17, 2015 12:07 PM
Subject: Re: [time-nuts] I've designed a GPSDO, but how "good" is it?
On Mon, 17 Aug 2015 07:14:34 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
I do that. It’s a 32 bit counter (the 16 bit counter has an overflow
interrupt that increments the high 16 bytes in software). The counter
free-runs. 32 bits at 10 MHz takes around 400 seconds to wrap.
So that works right. Good.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
I don’t quite get it.
What I do is every time there’s a capture interrupt, I subtract the counter
value of the last capture from this one. That gives me how many clock cycles
there were between PPS rising edges. But there’s no way for me to know the
phase relationship between the two rising edges (the PPS and 10 MHz). I can
only assume that the capture takes place within one cycle. Fortunately, I
don’t have to be concerned with software latency, as the capture interrupt
occurs immediately after, well before anything else gets in the way.
By taking the difference of "current pulse time" minus "previous pulse time"
and using this as the input into your control loop, you are making an FLL.
Instead you should use "time the pps is expected to arrive" minus "when
the pulse actually arrived".
You have a nominal frequency of 10MHz and a 16bit counter. That means
a second is 152 overflows plus 38528 counts long. Assuming you start with
0, the expected arrival of the next pulse is at count 38528. When it comes
earlier, your TCXO frequency was too low, when it comes later your TCXO
frequency was too high. The third pulse is exected to arrive at
count = (385282) % 2^16 = 11520. Again, feed the difference between that
value and when the pulse actually arrived into your control loop. The forth
pulse is expected at, (385283) % 2^16 = 50048,... etc pp
By not taking the difference to the previous pulse, but to the expected
time of the pulse, any fractional error in the calculation/frequency
will accumulate until it reaches the point where it actually becomes
visible as an offset between expected pulse time and pulse time.
And hence, forms a PLL.
If the timer of the ATtiny allows that, you can set it to overflow
at 62500. This divides 10e6 evenly, which gives you a constant count
number when you expect the pulse, which you then can set into mid range,
ie. at 31250. (makes the software easier)
When the error delta over 100 seconds is non-zero and less than 5, I
increment or decrement the DAC value, thus adjusting the trim by an expected
~370 ppt. When the error is more than 5, I double the error and add/subtract
that to the DAC value. It’s not a PID, but it generally reaches steady-state
quickly enough. I don’t make any LOCK LED indications at all until the 1000
second sample window is full, and by then the 100 second deltas are under 5
(usually at or under 1).
You really should read the wikipedia article on the PID loop and implement
a simple PI loop (no need for the D part). That's not more effort than what
you already did, but gives you better stability.
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Aug 17, 2015, at 12:07 PM, Attila Kinali attila@kinali.ch wrote:
On Mon, 17 Aug 2015 07:14:34 -0700
Nick Sayer via time-nuts time-nuts@febo.com wrote:
Without having had a look at your code (sorry, i currently don't have
the time for this), if you trully implemented just an FLL, then this
is where you should start from. The way to get a PLL is to let the counter
of the capture unit run freely. Don't reset it, just let it wrap around.
I do that. It’s a 32 bit counter (the 16 bit counter has an overflow
interrupt that increments the high 16 bytes in software). The counter
free-runs. 32 bits at 10 MHz takes around 400 seconds to wrap.
So that works right. Good.
The PPS pulse will now be wandering in each period, so you have to track
where you would expect the PPS next (unless you set the counter such,
that its wrap around divides a second evenly). Doing this, you will
integrate over the frequency difference and thus get a phase comparator.
I don’t quite get it.
What I do is every time there’s a capture interrupt, I subtract the counter
value of the last capture from this one. That gives me how many clock cycles
there were between PPS rising edges. But there’s no way for me to know the
phase relationship between the two rising edges (the PPS and 10 MHz). I can
only assume that the capture takes place within one cycle. Fortunately, I
don’t have to be concerned with software latency, as the capture interrupt
occurs immediately after, well before anything else gets in the way.
By taking the difference of "current pulse time" minus "previous pulse time"
and using this as the input into your control loop, you are making an FLL.
Instead you should use "time the pps is expected to arrive" minus "when
the pulse actually arrived".
You have a nominal frequency of 10MHz and a 16bit counter. That means
a second is 152 overflows plus 38528 counts long. Assuming you start with
0, the expected arrival of the next pulse is at count 38528. When it comes
earlier, your TCXO frequency was too low, when it comes later your TCXO
frequency was too high. The third pulse is exected to arrive at
count = (385282) % 2^16 = 11520. Again, feed the difference between that
value and when the pulse actually arrived into your control loop. The forth
pulse is expected at, (385283) % 2^16 = 50048,... etc pp
By not taking the difference to the previous pulse, but to the expected
time of the pulse, any fractional error in the calculation/frequency
will accumulate until it reaches the point where it actually becomes
visible as an offset between expected pulse time and pulse time.
And hence, forms a PLL.
That’s not different than simply tracking cumulative rather than immediate error, isn’t it?
I’m doing that with a rolling ten-sample (1000 second) window to report lock quality to the user (0.1ppb granularity).
I’m also doing that for a 100 second sample time to derive the error for the feedback loop (1.0 ppb granularity, but with 375 ppt “nudges” when the absolute value is small).
I’m sorry if I seem obtuse, but I don’t see how the arithmetic results in a different answer.
If the timer of the ATtiny allows that, you can set it to overflow
at 62500. This divides 10e6 evenly, which gives you a constant count
number when you expect the pulse, which you then can set into mid range,
ie. at 31250. (makes the software easier)
When the error delta over 100 seconds is non-zero and less than 5, I
increment or decrement the DAC value, thus adjusting the trim by an expected
~370 ppt. When the error is more than 5, I double the error and add/subtract
that to the DAC value. It’s not a PID, but it generally reaches steady-state
quickly enough. I don’t make any LOCK LED indications at all until the 1000
second sample window is full, and by then the 100 second deltas are under 5
(usually at or under 1).
You really should read the wikipedia article on the PID loop and implement
a simple PI loop (no need for the D part). That's not more effort than what
you already did, but gives you better stability.
I’ve done PID before (for a reflow oven controller), but thought that the current code was easier to understand. I’m going to try the GPSDO simulator and see how it matches up. It’s entirely possible that an improvement could be made in the time-to-lock, but the steady state performance appears to my eyes to be as close to optimal as I could envision. But I’m new at this, so it’s entirely possible that I’m not looking at it correctly.
Attila Kinali
--
I must not become metastable.
Metastability is the mind-killer.
Metastability is the little-death that brings total obliteration.
I will face my metastability.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the metastability has gone there will be nothing. Only I will remain.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Aug 17, 2015, at 12:49 PM, Nick Sayer via time-nuts time-nuts@febo.com wrote:
On Aug 17, 2015, at 12:07 PM, Attila Kinali attila@kinali.ch wrote:
You really should read the wikipedia article on the PID loop and implement
a simple PI loop (no need for the D part). That's not more effort than what
you already did, but gives you better stability.
I’ve done PID before (for a reflow oven controller), but thought that the current code was easier to understand. I’m going to try the GPSDO simulator and see how it matches up. It’s entirely possible that an improvement could be made in the time-to-lock, but the steady state performance appears to my eyes to be as close to optimal as I could envision. But I’m new at this, so it’s entirely possible that I’m not looking at it correctly.
I thought some more, and in principle, I could use the 100 second sample error as the proportional and 1000 second cumulative error as the integral. What I wanted to insure with my hand-coded decision making was that the system was not completely insensitive to momentary excursions in the steady state, but that it didn’t overreact. I suppose that could just mean that Kp = 1 and Ki =~ 2 or 3.
Hi
On Aug 17, 2015, at 9:59 AM, Nick Sayer nsayer@kfu.com wrote:
On Aug 17, 2015, at 4:06 AM, Bob Camp kb8tq@n1k.org wrote:
On Aug 16, 2015, at 9:40 PM, Nick Sayer nsayer@kfu.com wrote:
On Aug 16, 2015, at 6:04 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
Here’s some of the “that depends” questions:
What is your stability goal?
You talk about the NIST numbers on GPSDO’s. What level of stability are you after?
I believe I’m at or better than the stability I originally sought. Part 1 of my question is whether that’s actually true or whether my naivety is presenting me with a delusion. Part 2 is whether the price point at which I’ve arrived will support the level of stability I’ve achieved, or am I delusional in thinking people would or should pay what I’m asking for what I’m offering.
The stability can only be verified by careful testing, The design goal (what’s the spec) will in many ways determine
what sort of testing you will need to set up. A 1x10^-9 design would be tested differently than a 1x10^-13 design.
10^-9 was the target all along. Question number two that I came with was whether or not it was reasonable to ask $175 for 10^-9.
If you are trying to hit a frequency accuracy (as in 99.9% on frequency) spec of 1x10^-9 with a TCXO, that’s not going to happen.
There are a lot of GPSDO’s on eBay what will do something in the parts in 10^-11 that cost $110 to $150. I believe that Jackson
will still sell you a brand new commercial unit for about $185.
What is your end application?
Is this intended as a lab standard, the reference for a radio, something else entirely?
A low cost lab standard is what I have in mind. A box you can sit on your workbench with 3 BNC jacks that can feed 10 MHz into your frequency counter or what not.
Do you anticipate any phase noise sensitive instruments being attached? Most frequency counters are fairly simple.
I stared with an immediate need, and that was for low frequency testing with sample times in the 10^1 range, so phase coherency has not been anything I’ve been concerned with. The Connor Winfield phase plots at the low end look “good enough” to me, and with a 370 ppt DAC granularity, I can’t ask for a lot of phase coherency at the high end (you can see that in the time lapse videos).
Phase noise and phase coherency are two different things.
You can get better or worse phase noise picking between the auction site GPSDO’s. If somebody wants to multiply to microwaves, things like -150 dbc /Hz at 100 Hz
offset sort of numbers become a differentiator.
What is the destination?
Is this heading towards a commercial venture or is it a basement project?
I’ve entered it in the “Best Product” Hackaday 2015 prize contest. That said, I have no intention of attempting to compete with the established commercial firms in this space. I want to stay at around a Q:100 unit cost of around $75, which is where it is right now (the retail price is higher at the moment because I’m not manufacturing them in Q:100 lots yet).
Ok, so have you taken a good look at your costs and return? Do you have an method set up for
support of the product and for handling returns / repairs? Overhead costs that do not get factored
in early can be very painful later on.
Yup. The rule of thumb I have always used is that retail price is double the cost. That’s why I talk about a Q:100 cost of $75 and am charging $175. $175 is not $150 because I am not yet at Q:100 build costs, but that is the eventual goal.
Some use 3:1 or 4:1 for products with significant testing and support costs ….
What is the budget?
Do you have $200K to spend on this? Did the piggybank run dry at $100?
For a commercial venture this is a very important factor. You don’t have to share
the info, You do have to work out a number.
What is the timeline?
Does the project complete at the end of the summer, no matter what? Is it
something that is worth another year or two of effort?
I’ve got something now, but I don’t mind revving it to improve it, as long as the budget doesn’t change a lot. A lot of suggestions so far have centered around improvements that could be made regardless of budget. Like I’ve said, I don’t want to try to compete with Trimble.
I would suggest that you figure on quite a bit of your spare time going into this.
That never happens. :)
What is your background?
Mostly software, but in the last few years I’ve become reconnected to my nascent hardware side. I’ve been selling stuff in my Tindie store for a while now - a fairly eclectic mix of different projects that interest me. What led me to this project was another one - my Crazy Clock. I discovered a rather embarrassing design error that was causing errors on the order of dozens of ppm (I expected under ten). The first step in coming to grips with that issue was determining its scope, and that meant an extremely accurate low frequency counter, and that led me to needing a frequency standard. But I don’t have any way to test something I buy off eBay, so I wanted a GPSDO. But I couldn’t find any that weren’t way out of budget, so I set out to design one. And because I figured I wasn’t the only maker that needed something like this, but didn’t have the need or budget for something 2 orders of magnitude better, I thought I’d try this.
Now where I am is trying to determine if I am correct in my assertions, and if my cost-benefit analysis of this as a product makes sense or not.
That’s what the market will tell you ….
Does all of the stuff we’ve been tossing around make perfect sense? (= you do
something like this for a living). Are we talking about a bunch of stuff that makes
very little sense? (= you are just getting started at this sort of thing).
No, it’s all perfectly sensible.
Ok, so here’s the next layer:
If you are selling a frequency standard, most of your customers will probably be
interested in it’s frequency stability. Unfortunately this opens a major can of worms
spec wise. There are a number of measures that characterize various types of
noise. None of them directly address “if I measure 1.23 x10^-10 is it correct”. You
see numbers like “< 1x10^-10 99% of the time” in spec sheets.
If you dig into the archives, you can find numbers posts from people who are
disappointed that their "1x10^-13 GPSDO” can not deliver a 1x10^-10 frequency
measurement 99% of the time.
Ok, well, with the advice I’ve gotten so far here I’ve decided I am going to see if I can afford a TimePod and I’m going to try and get one of those FE-5680A rubidium standards off eBay. If that works out, then my perception (correct me if I’m wrong), is that that will be enough to characterize 10^-9 levels of expected performance.
I’m sure that Symmetricom will be happy to sell you a TimePod. The last batch we bought were about $12K. Pricing moves around a lot on this stuff so it is always
worth getting a quote.
The FE will do ok, I’d still get a couple of GPSDO’s. The Z3801 is well documented. There are a lot of others out there.
I’ve also mailed a unit to a kind volunteer here who said he’d take a look at it. If his opinion differs wildly from what I think is the current state of affairs, then I can stop and take a serious look at whether a new design would be able to better reach the same goals with the same pricing.
Once you get the TimePod you will have a much better picture of what’s going on.
Bob
Each of these twists and turns heads you off into a different set of further issues and
likely some more questions. For a commercial venture, buying custom oscillators in
bulk is a very normal thing to do. For a battery powered balloon carried reference, you
do things different than for a rack mount standard. Each of these projects people come up
with have its own unique drivers.
Each of us in our replies, tries to guess what your constraints are or are not. In doing
so we likely substitute our constraints for yours. The further our constraints diverge from
your constraints, the further off base our advice and answers will be.
I appreciate that. I came here with a narrow question in mind, but perhaps it wasn’t the correct one.
There is only so much you can pack in a single message …
Bob
Bob
On Aug 16, 2015, at 3:39 PM, Nick Sayer via time-nuts time-nuts@febo.com wrote:
On Aug 16, 2015, at 12:31 PM, Tom Van Baak tvb@LeapSecond.com wrote:
Anyway, to answer your question -- to measure its true performance you only need two things. 1) a phase meter (or time interval counter) that's good to 1 ns or better, and 2) a local reference standard that's maybe 10x better than the TCXO and the Adafruit GPS. Usually that means a cesium standard, or supremely qualified GPSDO, or equivalent.
I have a frequency counter, but it’s not a phase meter. I have a scope, but I assume that trying to use a ruler with scope traces isn’t the textbook way of doing that. :D
I have considered in the past buying a used rubidium standard off eBay, but have hesitated because I don’t know how much life there is left in the tube, and I just have to take it on faith that it’s stable and accurate. I have somewhat more faith in the GPS PPS, but clearly that has limits.
A number of us here on the time-nuts list have such equipment at home. And unlike professional labs, we will do it for free/fun if you loan the GPSDO for a week.
I will happily give one to someone if they would be willing to help a relative newbie with this stuff.
Just one though. They’re kind of expensive to build. :D
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.