[time-nuts] First success with very simple, very low cost GPSDO, under $8

Magnus Danielson magnus at rubidium.dyndns.org
Sat Apr 12 12:48:17 EDT 2014


Hi,

On 10/04/14 06:43, Tom Van Baak wrote:
>> You are right in the I don't even need data cycles.  All I want is the
>> error which is 5,000,000 minus the count.  this is hopefully zero.
>
> Correct. Keep the counter running. No need to zero it, ever. Use differential measurements. Essentially you are using binary modulus arithmetic.

BTW a trick for zero-dead-time counters is to let the counters running 
and just sample them. This fits very well with the work description for 
the counter in a GPSDO.

>> This would be easier if we have a 32 bit counter that could be reset
>> to zero each second.   In the past I think people have built counters
>> like this but now I can buy a $3.80 Arduino that does the counting,
>> ADC and DAC and computer USB interface.  So I put up with a harder to
>> use 16-bit nonresetable counter
>
> Chris,
>
> In applications like this, never reset a counter to zero; this opens chances for off-by-one errors and cycle slips. Just compute differences. The start-up value of the timer is irrelevant.
>
> Moreover, 32-bits is unnecessary. Perhaps you didn't understand Bob's posting. Even 16-bits is more than enough. Let me explain.
>
> You only need enough bits to cover the worst case OCXO frequency drift or the worst case GPS jitter error, per second. For example, if your OCXO stays accurate to 1 ppm it can't possibly drift more than 1 us per second. Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of correct time. Therefore, the maximum number of 100 ns ticks you will be off in any second is +/-10. So even a 8-bit counter is enough. Does this make sense now?

In fact a 5 bit counter is enough, and then a '373 to sample it. The 
enable to the 373 needs to be synchronous to the 5/10 MHz clock, so a 
pair of DFFs ('74) is needed to synchronize the PPS and another pair to 
create the single cycle enable.

> If you were building a general purpose arbitrary frequency counter, then a resetable 32-bit counter would be nice. But you're not. A GPSDO is a special case where you know the frequency will always be very close to 5 or 10 MHz every second. So you only need a few bits to measure the error each second.
>
> To use your decimal example, if the measurements are mostly 5000000 but sometimes 4999999 or 5000001 you only need to look at the last digit for your error. In hex this would be 4C4B40, 4C4B3F, 4C4B41, only the bottom two bits are needed (0, F, or 1).
>
> The bottom line is you don't need timer interrupts, you don't need time. You don't need 32-bits. You probably don't need 16-bits. You don't need semaphores. All you're interested in is how far off the oscillator is each second. One interrupt (for the GPS 1PPS) is all you need. If your CPU has a capture register you don't need interrupts at all. Then you don't need volatile either. Since your error is limited to +100 and -100 you can use 8-bit integers. You don't need to test for 30 hours; instead the code will be simple enough that it is air tight by design, not by luck. You will avoid interrupt collisions by not having more than one interrupt; you don't have to enable or disable interrupts either. You'll be surprised how simple it all gets.

If you use a simple SR flip-flop to hold the state if there is a new 
value or not. When a value is sampled, it is set. The software then 
polls that bit and if it is set, it reads the sampled counter, sets the 
R bit and then clears it. As long as you poll regularly you will not 
miss or double-read a value.

It's fairly easy to decouple the hard timing requirements to looser 
timing requirements if you just care about a few details.

Cheers,
Magnus




More information about the time-nuts mailing list