[time-nuts] Yet another GPSDO project.

Tue Mar 19 15:16:20 UTC 2019

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:

1) 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. 

2) Get an F9P or (when they hit retail) F9T uBlox module. They are more quiet than the alternatives.

3) Feed it into a TICC (see shameless plug above)

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

5) 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. 

6) 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 at 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 at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.