[time-nuts] I've designed a GPSDO, but how "good" is it?

[Nick Sayer]

> On Aug 17, 2015, at 1:16 AM, Attila Kinali <attila at kinali.ch> wrote:
> 
> On Sun, 16 Aug 2015 16:54:08 -0700
> Nick Sayer via time-nuts <time-nuts at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.