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.
/tvb
----- 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 <hmur...@megapathdsl.net> wrote:
t...@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.
--
Chris Albertson
Redondo Beach, California
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
