[time-nuts] First success with very simple, very low cost GPSDO, under $8
Tom Van Baak
tvb at LeapSecond.com
Thu Apr 10 03:41:12 EDT 2014
The key is not to worry about overflows. Let them happen. Don't count them. Don't prevent them. Fixed point binary arithmetic is wonderful. Here we're only concerned with the modulus or remainder.
If a 16-bit timer is counting at 5 MHz and its value is 0xnnnn, then one second later its value will be 0xnnnn+0x4B40. This because 5000000/65536 = 76.2939453125 = 76 + 19264/65536 and 19264 = 0x4B40.
In other words, if you know the oscillator frequency is really close to 5 MHz and you know the 1PPS period is really close to 1 second, then the difference between timer now and timer a second ago will always be right around 0x4B40.
This greatly simplifies the code, as it boils down to: error = TCNT1now - TCNT1then - 0x4B40.
The decimal equivalent of this is to consider if your car had only a 2 digit odometer. If you expect to drive 123 miles every week, do you have to count odometer "overflows"? How do you tell if you drove 125 miles or 120 miles instead of 123? Easy. Just subtract successive readings and see how far you are from 23. That's the error value.
Another analogy is a wrist watch. If you need to time something that takes about 195 seconds, you can essentially ignore the hour and minute hand, and look only at the seconds hand. Your events should occur about 15 seconds on the dial apart. If it's a bit more or less than 15 seconds, that's the error value.
----- Original Message -----
From: Chris Albertson
To: Discussion of precise time and frequency measurement
Cc: Tom Van Baak ; Hal Murray
Sent: Thursday, April 10, 2014 12:11 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 11:18 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
tvb at LeapSecond.com said:
> 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?
Am I confused or did you forget to add the 2 errors to cover the case when
they both happen during the same second? 2 us or a count of 20 is still
tiny, even for an 8 bit counter.
I think what you are saying is that the error can be expressed in about five bits. That is right.
But I still need to count all the cycles in the second and can't just let a 8 or 16 bit counter run free. The reason is I don't know where the overflow happens. Overflow is not in sync with PPS.
OK this might work. I hope it does as it would allow a bit of code to be removed. Let's see...
The system powers up, I enable the 8-bit counter and then assign an interrupt handler to the PPS and enable the PPS interrupt and I get the very first PPS interrupt and notice the counter vale is 67.
At the next interrupt the counter is 82
With only these two numbers 67 and 82 and knowing the counter is 8 bits how to I know the "error" which is the number of cycles different from 5000000.
Or more simply: "after reading the 82 how to I adjust the DAC?"
If you can spell it out I'll try it. But I bet you need one more number: the count of the times the 8-bit counter overflowed.
OK we might be able to assume a number of overflows because there are tight bounds on the PPS and OCXO performance.
One problem is I know for sure the overflow rate is not a fixed number per second. The 16-bit timer overflow happens 50000000/65536 times per second and an 8-bit timer overflows 5000000/256 times per second. Neather in an integer.
It might work, then I can get rid of counting overflows.
Redondo Beach, California
More information about the time-nuts