Yet another GPSDO project.
I was reading on this list for quite a while, but still have some questions I'd like to ask. Please forgive me my perhaps silly questions since I am a newbie to the timenuts world :-)
So I have built my own GPSDO. I used a low phase noise OCXO from AXTAL, a LEA-M8T module and a small STM32F303 microcontroller.
Since this was my very first attempt in this topic, my approach was quite basic: I used the OCXO as clock source for a free-running counter and the rising edge of the 1PPS signal was used to sample the counter. I then subtracted the last sampled value from the most recent one and thus had a measure of the OCXO's frequency. Since the counter is free-running, any frequency error should, at some point, accumulate such that there is 1 count difference (at least I think so). If there are more than 10e6 counts, my OCXO is too fast, and if there are less than 10e6 counts I know the OCXO is too slow. So depending on these two conditions, the value of a DAC is increased or decreased. In theory, a GPSDO with this scheme should basically "lock" at some time, however I expected that the performance wouldn't be amazingly good (but I wanted to see where I can get).
Next step, I tested the GPSDO. For this purpose I got an Oscilloquartz STAR4, and I let both GPSDOs run and warm up for about a week before I did some measurements. In my own design, I also implemented a 1PPS output (just by dividing the 10MHz clock with timer), and I used the 1PPS of my GPSDO and the STAR4 together with a HP 5335A time interval counter.
It was a bit disappointing to see that there is, even after a week of warmup, still some drift visible. My own GPSDO (for sure it's not the STAR4 :-)) appears to drift about 10ns in 10min, and I have the impression that this is way too much. So I didn't even try to do some Allan Deviation measurements, I bet it would be a nightmare. (I also made a timelapse video of the two OCXO signals displayed on a 'scope. Nothing beautiful :-/ )
Instead I would like to make a 2nd version. This time I would like to implement a PLL. The reason is also that I want the 1PPS to be aligned to UTC, as commercial GPSDOs seem to do this.
And this is now the point where I need some advice! :-)
I think I will still divide the 10 MHz down to a 1PPS signal, and then phase lock that to the 1PPS from the GPS module. One could do this e.g. with a phase/frequency detector with two D-flipflops, e.g. like this one:
https://electronics.stackexchange.com/questions/301402/phase-frequency-detector-in-pll
The signals UP and DN could then be used to steer the OCXO. A counter could be incremented whenever an impulse comes from the UP signal, and the very same counter could be decremented if there is an impulse from the DN signal. However I think this is way too basic, I need a proper loop filter. But what do I do with the phase detector signals and how to interface them with a proper loop filter, say an FIR or even IIR filter? the STAR4 GPSDO has an adjustable loop filter time constant, default 200s. I want something similar, but it is currently not yet clear how to interface a digital filter with a phase detector.
Later I would also like to add the sawtooth correction, but so far I have not yet found out how to do that - I couldn't find out in the uBlox manual where I can find info about the 1PPS timing.
Thanks for any interesting inputs!
Many thanks
Tobias
HB9FSX
You might want to study the design by Lars Walenius posted on this list in
2014 and updated here
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/
Lars has unfortunately passed away, but his design lives on. I have built a
couple of GPSDOs based on his design and would be happy to answer any
questions you have.
--
--Jim Harman
Hi
Sounds like you are having fun :)
Indeed GPSDO’s are an interesting thing to play with. The further you dig, the more nasty …. errr ….
fun …. things you find.
Some real quick pointers:
The output of the GPS module (any GPS module) is womping around a lot compared to an OCXO. Your
5335 will get to around a nanosecond at 1 second. It should easily be able to show your raw GPS PPS moving
around. A good OCXO should be 100X more quiet (maybe not more accurate, but more quiet).
One way to look at “quiet” is an ADEV plot. I’d post a few, but Apple Mail is not playing nice with the
list software right now. Tom’s leapsecond.com web site is a fine place to find a lot of them on a lot of
different devices.
The point is that as you go to longer and longer time spans, your GPS module gets more and more quiet
(measured in parts per billion). Your OCXO likely hits a floor and does not improve at longer time spans.
Out there somewhere the two curves cross over. It might be 100s it could be 10,000s. It depends a lot
on exactly what GPS you have, your antenna location (drop outs are bad …), your OCXO, and how much
temperature swings in your lab. Indeed your counter or timer or whatever also has a noise floor that it
dependent on time span. That gets in the mix as well.
So, the trick is to only “update” the DAC at a very slow rate. This may be through any of a number of
processes. One common one is to keep feeding the updates at a 1 second rate, but to reduce their
magnitude massively via a control process. There are many alternatives.
Since you are after a really long time span, stamping the PPS with a continuous running timer is a
“really good way” to do it. Shameless plug;
The TAPPR TICC time stamps GPS PPS signals really well and TAPPR needs some orders :) :) :)
(why all these ad’s in my posts? I need another couple of them myself and they are all out ….)
A counter / timer in a micro is another way to do the same thing. Since you want to get into the vicinity
of ( or less than) 1 ns, the TICC actually is a really good way to do it.
Another wrinkle to all this - the output from your GPS module is a “raw” output. It hops around because
of the way it comes off the TCXO in the module. They send a correction message to help this out.
You very much want to capture that message and use it to “correct” the reading on the pps. “Hanging
bridge” is the Google search for all the gory details.
=========
If I was going to go down this road today:
-
Pick whatever you are going to discipline and wire that up. OCXO’s and Rb’s are pretty common
targets for this kind of thing. -
Get an F9P or (when they hit retail) F9T uBlox module. They are more quiet than the alternatives.
-
Feed it into a TICC (see shameless plug above)
-
Run that all into a dirt cheap PC of some sort running an OS you are comfortable with (and
can lock out update reboots on …). -
Write up the code in an nice roomy tool set and run it on the PC. You will want to do this with
code and not a big rack full of analog filters. -
Feed the output out an isolated serial port to whatever you happen to be controlling. Fast approach
would be a DAC board on an Arduino driving an OCXO. If your device already has a DDS in it, the DAC
(and it’s many issues … noise … stability … resolution …..) could drop out of all this.
Yes, your “gizmo” spreads out a bit. Sorry about that. :) It also has nice things like log files, a display,
debug messages, LH doing this and that chore here. It could get cool features like mail alarm and status
messages, …… You also likely get the whole thing up and running in weeks vs months or years.
It still will not be optimized in weeks, but at least it is running properly.
To optimize these gizmos, it takes time and something to compare them to. You very much need to
optimize what you have done. There is no canned “always works” recipe for this. You are unlikely to
have really nice “noise plots” on everything in your lab run against a maser. The way you figure out the
noise cross over stuff is from the results of tweaking the code. ( = lots of code tweaks). There are lots
interesting bumps and lumps that need to get sorted out. (you might call that part debugging ….).
There is no way around the time part of it. You are dealing with very long time constants and you have
to look at the data for weeks and weeks. The effects of this or that tweak may look good early
on and awful over a couple of days. That’s the nature of the beast. Even in a commercial development
process the optimization part is where pretty much all the time is spent. “All” is in terms of calendar time
and man hours on the project.
The most common “thing to compare it to” is a Cs standard. Most people doing this (in a basement
or in a company) go that way. A Maser would be another alternative. The Cs is free of drift (pretty much).
The Maser is more quiet. Cost of the Maser is …. yikes. Cs has a wear out mechanism. If you
already have a Cs or a Maser … why are you building a GPSDO ? … hmmm ….. welcome to
Time Nuts …. it’s a disease ….:)
One “novel” way to monitor long term is to run something like a Trimble NetRS locked to the
output of your GPSDO. You then post process the files out of the NetRS via something like
NRCan’s free site. That gives you the same sort of 30 second time span information you likely
would collect off your Cs or Maser.
Cost wise … much less money. If you already have an L1 /L2 antenna for the F9 part, the only
real cost is whatever eBay wants this week for a NetRS. Collect the data on that same cheap PC
the rest of it runs on ….Shop hard and that can be $200. Go crazy on the first one you see and it
could be lots more money. (the cheap ones sell fast, the expensive ones hang around for years).
Lots of fun !!!!
Bob
On Mar 19, 2019, at 8:29 AM, Tobias Pluess tobias.pluess@xwmail.ch wrote:
I was reading on this list for quite a while, but still have some questions I'd like to ask. Please forgive me my perhaps silly questions since I am a newbie to the timenuts world :-)
So I have built my own GPSDO. I used a low phase noise OCXO from AXTAL, a LEA-M8T module and a small STM32F303 microcontroller.
Since this was my very first attempt in this topic, my approach was quite basic: I used the OCXO as clock source for a free-running counter and the rising edge of the 1PPS signal was used to sample the counter. I then subtracted the last sampled value from the most recent one and thus had a measure of the OCXO's frequency. Since the counter is free-running, any frequency error should, at some point, accumulate such that there is 1 count difference (at least I think so). If there are more than 10e6 counts, my OCXO is too fast, and if there are less than 10e6 counts I know the OCXO is too slow. So depending on these two conditions, the value of a DAC is increased or decreased. In theory, a GPSDO with this scheme should basically "lock" at some time, however I expected that the performance wouldn't be amazingly good (but I wanted to see where I can get).
Next step, I tested the GPSDO. For this purpose I got an Oscilloquartz STAR4, and I let both GPSDOs run and warm up for about a week before I did some measurements. In my own design, I also implemented a 1PPS output (just by dividing the 10MHz clock with timer), and I used the 1PPS of my GPSDO and the STAR4 together with a HP 5335A time interval counter.
It was a bit disappointing to see that there is, even after a week of warmup, still some drift visible. My own GPSDO (for sure it's not the STAR4 :-)) appears to drift about 10ns in 10min, and I have the impression that this is way too much. So I didn't even try to do some Allan Deviation measurements, I bet it would be a nightmare. (I also made a timelapse video of the two OCXO signals displayed on a 'scope. Nothing beautiful :-/ )
Instead I would like to make a 2nd version. This time I would like to implement a PLL. The reason is also that I want the 1PPS to be aligned to UTC, as commercial GPSDOs seem to do this.
And this is now the point where I need some advice! :-)
I think I will still divide the 10 MHz down to a 1PPS signal, and then phase lock that to the 1PPS from the GPS module. One could do this e.g. with a phase/frequency detector with two D-flipflops, e.g. like this one:
https://electronics.stackexchange.com/questions/301402/phase-frequency-detector-in-pll
The signals UP and DN could then be used to steer the OCXO. A counter could be incremented whenever an impulse comes from the UP signal, and the very same counter could be decremented if there is an impulse from the DN signal. However I think this is way too basic, I need a proper loop filter. But what do I do with the phase detector signals and how to interface them with a proper loop filter, say an FIR or even IIR filter? the STAR4 GPSDO has an adjustable loop filter time constant, default 200s. I want something similar, but it is currently not yet clear how to interface a digital filter with a phase detector.
Later I would also like to add the sawtooth correction, but so far I have not yet found out how to do that - I couldn't find out in the uBlox manual where I can find info about the 1PPS timing.
Thanks for any interesting inputs!
Many thanks
Tobias
HB9FSX
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.
Tobias Pluess writes:
I was reading on this list for quite a while, but still have some
questions I'd like to ask. Please forgive me my perhaps silly
questions since I am a newbie to the timenuts world :-)
So I have built my own GPSDO. I used a low phase noise OCXO from
AXTAL, a LEA-M8T module and a small STM32F303 microcontroller. Since
this was my very first attempt in this topic, my approach was quite
basic: I used the OCXO as clock source for a free-running counter and
the rising edge of the 1PPS signal was used to sample the counter. I
then subtracted the last sampled value from the most recent one and
thus had a measure of the OCXO's frequency. Since the counter is
free-running, any frequency error should, at some point, accumulate
such that there is 1 count difference (at least I think so).
Yes, but there are several wrinkles to take care of with that method.
The first is that the PPS output of the GPS module has jitter that your
OCXO should not try to chase. The other is that once the frequency
difference becomes small enough you're having to wait a long time before
you notice the frequency is still a bit off and then you don't know
exactly by how much.
If there are more than 10e6 counts, my OCXO is too fast, and if there
are less than 10e6 counts I know the OCXO is too slow. So depending on
these two conditions, the value of a DAC is increased or decreased.
If both the measurement and the OCXO are stable enough this will indeed
work, but your problem is that you need to wait for 100ns of error to
accumulate to make your next decision. So when you come very close to
target frequency you will probably be in the rising portion of the ADEV
for the oscillator again since your steering gets too sparse in time.
In theory, a GPSDO with this scheme should basically "lock" at some
time, however I expected that the performance wo uldn't be amazingly
good (but I wanted to see where I can get). Next step, I tested the
GPSDO. For this purpose I got an Oscilloquartz STAR4, and I let both
GPSDOs run and warm up for about a week before I did some
measurements. In my own design, I also implemented a 1PPS output (just
by dividing the 10MHz clock with timer), and I used the 1PPS of my
GPSDO and the STAR4 together with a HP 5335A time interval counter.
It was a bit disappointing to see that there is, even after a week of
warmup, still some drift visible. My own GPSDO (for sure it's not the
STAR4 :-)) appears to drift about 10ns in 10min, and I have the
impression that this is way too much.
Provided the drift rate is almost constant, you'd be down to about
2e-11@1s with that figure. That's not too shabby given the simplicity
of your scheme.
So I didn't even try to do some Allan Deviation measurements, I bet it
would be a nightmare. (I also made a timelapse video of the two OCXO
signals displayed on a 'scope. Nothing beautiful :-/ ) Instead I would
like to make a 2nd version. This time I would like to implement a
PLL. The reason is also that I want the 1PPS to be aligned to UTC, as
commercial GPSDOs seem to do this. And this is now the point where I
need some advice! :-) I think I will still divide the 10 MHz down to a
1PPS signal, and then phase lock that to the 1PPS from the GPS
module. One could do this e.g. with a phase/frequency detector with
two D-flipflops, e.g. like this one:
https://electronics.stackexchange.com/questions/301402/phase-frequency-detector-in-pll
The signals UP and DN could then be used to steer the OCXO. A counter
could be incremented whenever an impulse comes from the UP signal, and
the very same counter could be decremented if there is an impulse from
the DN signal. However I think this is way too basic, I need a proper
loop filter. But what do I do with the phase detector signals and how
to interface them with a proper loop filter, say an FIR or even IIR
filter? the STAR4 GPSDO has an adjustable loop filter time constant,
default 200s. I want something similar, but it is currently not yet
clear how to interface a digital filter with a phase detector.
Later I would also like to add the sawtooth correction, but so far I
have not yet found out how to do that - I couldn't find out in the
uBlox manual where I can find info about the 1PPS timing.
Considering you have a timing module, there are more possibilities
inside that module you can use before going for external circuits. For
starters, you can timestamp the PPS from the OCXO with the module itself
and get a better estimate of how far off you are. Second, the module
can ouptut an additional higher frequency clock that you can use for
determining the phase difference to your OCXO more precisely. Last but
not least, the timing modules have a frequency aiding mode where you can
feed in a stable frequency to one of the EXTINT pins (I think up to
500kHz, see UBX-MGA-INI-FREQ message) and tell the module what frequency
and stability it has and the module will come up with a better estimate
of its own internal frequency and converge much faster. If you had FTS
firmware on the module (unlikely), there'd even be a mode where the PPS
from your OCXO would directly processed to a signal that drives a DAC to
steer its frequency on target.
Regards,
Achim.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra