[time-nuts] GPS DO Alternatives

Bob Camp lists at rtty.us
Mon Dec 10 00:19:12 UTC 2012


Hi

Unless the OCXO and PPS both stay within +/-50 ns (100 ns p-p) over the entire lock in period, the PLL will not lock up. If you slip outside that range the error signal changes sign.  It drives away from lock rather than towards lock. The XOR and mixer phase detectors have this same problem.

If you are averaging 100 samples and locking in 10 averages (unlikely), that comes out to < (50x10^-9/1000 = 5.0 x10^-11). That's not going to happen with an OCXO. It's unlikely to happen with an Rb. Lock up would occur in 1,000 seconds in this case.

Can you divide the 10 MHz to widen things out - yes. If your OCXO is at 0.1 ppm, you would first look at dividing by 10,000. That would give you a range of +/- 500 us. At this point the same averaging and lock would occur in 10,000,000 seconds. Other than possibly not wanting to wait that long, the lock still is unlikely to occur. The time drift scales at the same time the lock time goes up. You still need a 5x10^-11 Rb to get it to lock up. The scale does not help for oscillator accuracy. It does help for GPS jitter, but that never factored into the analysis above. It was assumed to be zero.  

Starting out simple / easy  and then boosting things up later sounds like a good idea. Some architectures simply do not lend themselves to a boost. 

-------

One might also ask, if this is the problem, how is it solved?

1) Measure the PPS to GPS with a counter of some sort
2) Slip the PPS on the OCXO to get it near the "right" place
3) Monitor the offset with the counter to get a coarse lock
4) Possibly go through a few steps
5) Fire up the PLL 

In the case above you would need to get to ~ 1x10^-11 before you went into state 5. That's likely more than a few steps in part 4. 

Bob

On Dec 9, 2012, at 6:26 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> 
> albertson.chris at gmail.com said:
>>> I don't think that is going to do what you want.  The problem is what
>>> happens if set and reset are on at the same time?
> 
>> This would be the best case.  The result will be random and we'd read an
>> average value of 0.5 from the flip flop. 
> 
> The problem is that FFs don't work that way.
> 
> There are two types of FFs.
> 
> SR-FFs have set and reset inputs.  Set turns it on.  Reset turns it off.  
> These are level sensitive, not edge sensitive.  If both set and reset are 
> active at the same time (overlap) you have to look in the data sheet to see 
> what happens.  After the overlap, the last one active wins.
> 
> Edge triggered D-FFs have data (D) and clock inputs.  If D is high when clock goes high, the output will be high.  If D is low when clock goes high, the output will be low.
> 
> There are rules for FFs: Setup, hold, min high/low on the clock, ...  Read the data sheet for the whole list.
> 
> 
>> I think you want everything to be edge triggered.  The flip flop should look
>> only at the leading edge of each pulse. 
> 
> That would be handy, but I don't know of any FFs that work that way.  All of the clocked FFs only have one clock.
> 
> You might make it work by using the PPS as the clock with the D input hard wired to 1.  That will set the FF unless the reset is active.
> 
> 
> albertson.chris at gmail.com said:
>> You don't get a PPS from the OXCO.  It runs at 10MHz (Or whatever you like)
>> so it resets the flip flop every 100 nanoseconds. 
> 
>> The way this works is the PPS from the GPS sets the FF to "1" once per
>> second and then some time later the OXCO resets it back to zero.   If we
>> sample the FF at some fixed time after the PPS and that fixed time is less
>> then the OXCO period then the FF will be either 1 or 0.   THe computer tries
>> to drive the OXCO so that the sampled value is 0.5 on average.   So it looks
>> at the last 1000 samples and tries to hit "500". 
> 
> How are you going to implement that fixed time delay and sampling?  I don't see a simple way to do it.
> 
> What is the correct delay?  How about 0?
> 
> In general, when people start adding things like "fixed delays", I start thinking "kludge - there must be a better way".
> 
> ------------
> 
> There is another problem with using the OCXO output (100 ns) directly.  How do you eliminate aliasing/beats?  Suppose the OCXO is running at exactly 9 MHz.  If you average over 1000 samples, you'll get your 0.500 .  If you look carefully, you can find a pattern.
> 
> There is probably some simple math in here, but I'm not enough of a PLL wizard to be able to describe it.  Capture range and things like that.
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> 
> _______________________________________________
> 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.




More information about the time-nuts mailing list