[time-nuts] Yet another GPSDO project.

Wed Mar 20 22:05:08 UTC 2019

Hi

One nice thing about just getting the TICC from TAPR:

https://www.tapr.org/kits_ticc.html <https://www.tapr.org/kits_ticc.html>

Is that all of the glue and hook it up stuff has already been done and debugged.
There’s also code on the attached MCU to take care of all sorts of odd stuff.

John has a nice writeup at:

https://www.tapr.org/pdf/DCC2016-The_TAPR_TICC_Counter_Measuriing_Trillionths_of_a_Second_with_an_Arduino_John_Ackerman_N8UR.pdf <https://www.tapr.org/pdf/DCC2016-The_TAPR_TICC_Counter_Measuriing_Trillionths_of_a_Second_with_an_Arduino_John_Ackerman_N8UR.pdf>

Since you are after a continuously running count (and not the difference between readings) the builtin time tagging software does just fine in this case. 
If you want to go full DIY, I think you probably are better of grabbing one of the cheap FPGA boards off eBay and doing things up in it. A Max 10 from Altera / Intel is < $50. It will PLL a 10 MHz clock up to 400 MHz. Programming and design software is free. Data entry into the design side can be via a schematic. No need to learn Verilog.

Bob

> On Mar 20, 2019, at 4:58 PM, Tobias Pluess <tobias.pluess at xwmail.ch> wrote:
> 
> Hi again Bob,
> 
> I read some documentation about your TICC and tried to figure out how I could implement something similar in my GPSDO, but having only one channel. I ended up with this:
> 
> https://hb9fsx.ch/wordpress/wp-content/uploads/2019/03/20190320_214120.jpg
> 
> It works as follows. The GPS 1PPS is asynchronous to the 10MHz clock. So it occurs anywhere. It is synced to the 10MHz and delayed by 300ns, the same as in the TICC. The rising edge of the 1PPS is used as the start signal for the TDC7200, and the rising edge of the delayed 1PPS is used as the stop signal.
> 
> While all this happens, the counter inside the microcontroller counts, and is latched when the microcontroller detects the rising edge.
> 
> On the next 1PPS signal from the GPS the same things happen again, and and the counter is latched another time.
> In my example, the counter counts from 00 to 08, and the TDC7200 gives the additional fractional 70ns.
> What do you think?
> 
> It needs not 2 TDCs but only one, but it also requires quite a bit of external glue logic. And I am not sure about the delay of 300ns: if the propagation delay of the logic producing this delay is not accurately known, the delay is not 300ns but 300ns + some offset, isn't it?
> 
> 
> Tobias
> HB9FSX
> 
> ________________________________________
> 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.
> 
> _______________________________________________
> 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.