[time-nuts] Yet another GPSDO project.

Wed Mar 20 20:22:34 UTC 2019

Hi Bob

yes, this is exactly what I do currently.
My microcontroller offers some 32 bit counters. I use the OCXO as clock for one of these and let the counter run all the time, it is never stopped. With every rising edge of the 1PPS signal, the counter value is copied into some register (input capture) while the counter continues to run.
The cool thing is: if you interpret the value read from the counter as a signed 32 bit integer, you don't have to care about overflows. It works if one always subtracts the previous reading from the current one!
However, the resolution is only 100ns.
The microcontroller offers a PLL; I tried to use that, and the datasheet says it has a jitter of 300ps - sounds good to me. However, when I used the PLL, the frequency stability was quite bad. Thanks to a post in the EEVBlog forum I found out that the PLL has some sort of frequency modulation or sawtooth waveform, which basically renders it useless for this kind of application, unfortunately :-(
But indeed, having a PLL would be great because this particular microcontroller can run with up to 60MHz. So if I used, say 50MHz, the resolution could easily be increased to 20ns, which I think is way better than what I currently have.

Of course the resolution could be increased greatly if I combined this approach with a TDC7200, as you have used one in your TICC. However I am unsure whether this would work as intended. The TDC7200 needs a reference clock. Of course the OCXO would be ideal for it - but as long as the GPSDO is not locked, the OCXO frequency will be wrong by some (unknown) amount, and thus the time measurement of the TDC7200 will be wrong as well, won't it?
I am currently trying to figure out how I may connect the TDC7200 to my hardware.

However it sill does not solve the problem that the phase of my OCXO is still quite arbitrary and not aligned to UTC and so is my 1PPS output.

How actually do professional GPSDOs work? in my STAR4 GPSDO, there is only one large FPGA which does the magic - I am pretty sure they use a more sophisticated algorithm than I do.

Best
Tobias

________________________________________
From: time-nuts [time-nuts-bounces at lists.febo.com] on behalf of Bob kb8tq [kb8tq at n1k.org]
Sent: Wednesday, March 20, 2019 14:27
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Yet another GPSDO project.

Hi

Indeed you want a digital “phase detector” of some sort. Your counter on the micro
is a phase detector. If you clock it off of the OCXO and read it based on the PPS,
what you get is phase. If you never arbitrarily reset the running counter, it reads phase
forever and ever (no slips). If you get a micro that lets you phase lock the internal clock,
you can come up with a counter that runs in the hundreds of MHz. That gets you at least
into the 10’s of ns. An FPGA is another way to get a counter like this.

Since things like counters are stable long term, they make good phase detectors in a
case like this. You might “help” a little to get the last few digits (as the TICC does). Still
the bulk of what you read is done by a simple counter. Drift is still taken out and you
hang on to your phase reference long term.

As a very simple example:

Most micro’s will let you set up a counter so it rolls over at a set point. The example
below assumes it counts to some yyyyyy….. = one second value and the next count
is zero.

Second by second my counter at the PPS edge reads out:

xxxx1204
xxxx1212
xxxx1223
xxxx1232
xxxx1231
xxxx1245
xxxx1259
…..
xxxx1325

and on it goes.

Since I never reset the count, it’s off by some weird amount. I really don’t care what that is.
I can look at the readings and if the first and last are 10 seconds apart that’s phase over 10
seconds. In the example above my phase changed by 1325-1204 = 121 counts.

All the loop needs to do is to “steer” things so the count stays at xxx1204. Subtract what I
saw when I first started up from whatever I got just now and keep that at zero.

Yes this all *assumes* the counter has been set up to roll over nicely at the one second
transition. If not, there is a bit more math to do to account for that issue. There are also
gotcha’s with counter / timer’s on micro’s maybe not doing quite what you think they should
due to clock domain issues.

Some designs out there run a very small counter ( = ignore all the xxxx in the example above)
and *assume* that things will never roll over. There are lots of alternatives …

Bob

> On Mar 20, 2019, at 3:53 AM, Tobias Pluess <tobias.pluess at xwmail.ch> wrote:
>
> Hi,
>
> no, I don't want the OCXO to closely follow the 1PPS - this would make no sense. Instead I thought the "right way" of doing it is perhaps:
>
> a) measure the phase difference between the GPS PPS and the PPS derived from the OCXO.
> b) put that phase difference into a loop filter.
> c) the loop filter's output goes to a DAC.
>
> Of course I don't want to have an analog phase detector, nor an analog loop filter due to the reasons you already mentioned (small phase detector output voltage, insance capacitor values etc.). Instead both the loop filter and the phase detector should be digital, and this is my current step where I struggled - how to do that.
> But thanks to the loop filter I would expect the phase jitter of the GPS PPS to be averaged out. Of course the loop filter's averaging time should be chosen such that it lies approximately at the point there the ADEV of the OCXO becomes worse than the ADEV of the GPS (however, I have no ADEV info available about my oscillator, *sigh*).
>
> But for example, if my OCXO's ADEV begins to increase at, say 1000s, the perhaps easiest loop filter would be a FIR filter which averages the last 1000 measurements of the phase difference between GPS PPS and OCXO PPS, right? (afterwards one could improve this to IIR or whatever to save filter taps...).
>
> The OCXO I have is perhaps not the most stable one, but also not a low cost device. It has an aging of perhaps 1ppb per day and 100ppb per year, but it is not a double oven device, unfortunately... perhaps I should look for an Oscilloquartz 8663 or so?
>
>
> Tobias
> HB9FSX
>
>
> ________________________________________
> From: time-nuts [time-nuts-bounces at lists.febo.com] on behalf of Bob kb8tq [kb8tq at n1k.org]
> Sent: Tuesday, March 19, 2019 23:35
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Yet another GPSDO project.
>
> Hi
>
> Ok, *if* you phase lock the OCXO to closely follow the GPS PPPS, the OCXO will be every bit as noisy
> as the GPS. Actually it will be worse since you now have 1Hz noise running around that needs to be
> taken care of ( = the output of the phase detector is a series of pulses at a 1 Hz rate).
>
> Net result is that you still need a a long time constant loop to do any good. There also will
> be some interesting “analog” issues in trying to deal with the ouput of a normal phase detector at this
> slow a rate (leakage, giant capacitors, weird noise issues …).  Bottom line - it’s going to be an
> exciting design in a number of ways.
>
> You might say - up the output rate of the GPS. That’s fine, but the correction information you need only
> comes out once a second. The rest of the time you are running with (noisy) uncorrected pulses.  You
> took one step forward and two back ….
>
> ========
>
> The normal way the lockup issue is handled is via software and by “cheating” a bit while the device
> locks up. Just how you do this depends a *lot* on how your system is set up. With a pure PLL you
> don’t have quite as many choices as with a phase sampling ( TICC counter-like) setup. With phase samples,
> you can look at frequency and lock to that early on. Then switch to a true phase lock later on. Most
> high performance GPSDO’s go through multiple steps before they are in their final lock condition.
>
> ========
>
> Stepping back a bit - Whats good?
>
> A $100 telecom Rb off of eBay will hold 0.1 ppb for a very long time with very little help. Yes you might
> buy two or three to get one good one. You also can do a bit of digging and improve the odds. Second
> to second wise they should hold 0.01 ppb.
>
> An fairly good ( = double oven) OCXO might hold 1 ppb for a month after it warms up for a
> while. If you buy it on eBay. Second to second wise it should be around 0.002 ppb
>
> A low cost OCXO might struggle at the 50 ppb level over a month. Second to second wise ….
> who knows … maybe 0.1 ppb (yikes …).
>
> A GSPDO (while locked) will have zero net frequency error (it’s phase locked).  It’s short
> term frequency can / will / yikes wander. The net will be zero. Second to second wise it should
> be about the same as it’s “core” device (Rb or OCXO).
>
> Based on all this, I’d suggest that a GPSDO needs to be in the < 0.1 ppb range in terms of
> “how good" to beat out the unlocked Rb.
>
> 0.1 ppb is a nanosecond over 10 seconds. It is a phase error of 360 / 1,000,000,000 degrees
> at 1 Hz over that time period. That’s a pretty small phase change and not a very big time change.
> At 100 seconds you are up to 10 ns (so a bit easier to spot). You are also at 10X the degrees,
> still pretty tough.
>
> To turn the phase into other units:  if your phase detector has a 1V / radian slope (not uncommon on
> an analog phase detector), you are after 2*PI / 1,000,000,000 volts on the output. That’s just a bit over
> 6 nV. Ideally you would want your detector drift to be < 20% of this (or about 1 nV) to get the job done
> …. yikes ….
>
> Lots of fun !!
>
> Bob
>
>> On Mar 19, 2019, at 4:43 PM, Tobias Pluess <tobias.pluess at xwmail.ch> wrote:
>>
>> Thanks for the replies so far.
>> Unfortunately I used digest mode for this mailing list, so perhaps my answers are not well-formed - please excuse; I have changed my settings to non-digest (even though this is perhaps a bit less convenient).
>>
>> @Jim Harman
>> Indeed I know Lars' GPSDO. Can you tell what performance you achieved with one of those?
>>
>> @ Bob
>> wow. That's quite a pile of information you put in your post!
>> Indeed I have some fun with the GPSDO topic, but not yet particularly with my unit, its performance is, in my oppinion, currently way too poor. So I need a better one ;-) Cs or Maser would be awesome, but I don't even have a Rb. I once thought of buying one from the 'bay, but they are often of doubtful pedigree and nobody knows how much life is perhaps left in the Rb valve, if I am unlucky it will only last for a few months, so I think I will not risk that.
>>
>> Of course I know the PPS from the GPS module is jittery. This is why we want to synchronize our OCXOs, isn't it ;-)
>> However the STAR4 GPSDO I have here has also an 1PPS output, which is derived from the OCXO. I used this PPS on my HP 5335A. I am looking for a HP 53131A or 53132A since months for a decent price - this would allow for higher resolution.
>> I have made an ADEV plot for my GPSDO, but I didn't save it because it was disappointing.
>>
>> By the way, this is the unit I built:
>>
>> https://hb9fsx.ch/wordpress/index.php/2018/11/14/my-own-gpsdo-part-i/
>>
>> I have also a homemade antenna for it, since I read somewhere that the quadrifilar helix antennas are better than patch antennas, I made one by myself. A choke ring antenna would perhaps be even more awesome, but this is for a later project!
>>
>>
>> @ Achim.
>> Yes indeed, I encounter the problem that my measurement resolution is only 100ns. So it takes ages until the frequency locks and it takes longer and longer, the closer the frequency is... and I exactly assumed what you have pointed out: perhaps my steering becomes so sparse in time, that the OCXO's aging rate is faster.
>> 2e-11 at 1s is not bad, but hoped for something with e-12 or even better - I think this should be possible, not?
>>
>>
>> So I think I would really like to go the PLL route, I hope to achieve faster lock time and a bonus would be that the PPS pulses derived from my OCXO would be aligned to those of the GPS module.
>> But how to interface the PFD to a microcontroller and implement the loop filter is still a mystery for me :-)
>>
>> Thanks for all your hints
>> 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.
>
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.

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