Another point with the software is that your handler for the PPS just reads
the counter. This gives an offset between the PPS edge and the value read,
as your software takes time to respond to the interrupt and read the
counter. In your code, it doesn't matter as you only have one interrupt.
However, if you have another interrupt enabled, this could run after the
PPS pulse but before the handler runs, giving you a very rare jitter.
A better way would be to use the input capture feature to read the timer
into a capture register. Then the interrupt handler has until the next edge
to read the capture register.
Just an idea, you might be able to assign the interrupt priority for the
PPS edge to a priority above all others to avoid this problem, but this is
getting complex. Simpler to handle it by hardware. To debug jitter, you
could make your mainline set an output line, and watch the delay between
the PPS and the line on a CRO set on infinite persistance, just to check if
it works.

Tom Harris celephicus@gmail.com

On 9 April 2014 13:05, Chris Albertson albertson.chris@gmail.com wrote:

On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephicus@gmail.com wrote:

Actually there are two interrupts.  One is for PPS and the other is
for overflow of the 16-bit counter.  This over flow happens about 76
times per seconds.

Do you know how to do this.  I don't see any way to capture the timer
value other then reading it with software.  The timer capture register
is 16 bits and is set atomically after each timer increment but I
don't see a way to make an external interrupt pin capture a timer.

The two interrupts do bump into each other about roughly every 100
seconds but I can detect that.  I think I'll just ignore that second.

Chris Albertson
Redondo Beach, California

Have you considered reading the timer only at PPS?  You don't need to keep track of the actual count.  You just need to keep track of the difference between counts at each PPS.  Resolution isn't a problem since the difference in the lower 16 bits is a fixed number for your purpose.  IOW, 10,000,000 is 0x989680.  You're only interested in the 0x9680.  If there's a difference in two successive timer counts of 0x9680, then you know you counted 10,000,000, unless your oscillator is capable of running at one of the other values that gives 0x9680 as the lower two bytes.

Bob

Bob,

Yes, that is kind of how it works.  The timer is only read once per
second.  After reading it we subtract whatever was the count in the
previous sample to get the number of cycles in this last second.
There is no accurate way to reset the timer at the start of the
second.  So we let it run "forever".  The 16-bit timer actually over
flows many times per second.  The maximum value it ever gets to is
about 65,536.  (actually 2^16 - 1)    The counter will never reach
10,000,000.  (but actually we count after a divide by 2 so 5,000,000
is the target number)

As it turns out even in a perfect world the counter value every second
is some random value between zero and 65535.  Because when the
overflows happen depend in the exact microsecond I applied power to
the system., that is my arbitrary "zero" and I count up from there
overflowing back to zero about 76.6 times per second  Every second we
capture whatever the timer value is and compute "delts cycles"

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.

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

On Wed, Apr 9, 2014 at 6:33 PM, Bob Stewart bob@evoria.net wrote:

--

Chris Albertson
Redondo Beach, California

Correct. Keep the counter running. No need to zero it, ever. Use differential measurements. Essentially you are using binary modulus arithmetic.

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?

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.

/tvb

To many "ifs" and "you could...".  The Arduino is what it is.  There
is no capture register, no interrupt priorities and the counter is
16-bits and the overflow actually takes one cycle.    The code is
posted.  You can read it.  Every second it does what is suggested and
computers the difference in cycles from 5000000.  Mostly it gets zero.
It ran for close to 100,000 continuous seconds without a glitch and
then the OCXO failed.

There is really no problem that requires a "fix". (other than an
ovenized crystal that only works well when it's cold)  The goal was
to have  minimally complex design to use as a baseline.

The real experiment begins AFTER this.  That is to add one
"improvement" at a time and see what is gained in performance.

So I think I have every flavor of sophistication backed out.  I am
only counting cycles and the PI contents are only roughly tuned.  I'm
at the point where if one more thing is removed it stops working.
That is the baseline.

One thing I added was the "I" term.  I had just a "P" controller but
had to move to PI because P would not lock even after one hour and if
I moved the gain up it would over shoot and never lock.  Adding "I"
was only 3 lines of C code and makes it lock in a few minutes.

On Wed, Apr 9, 2014 at 9:43 PM, Tom Van Baak tvb@leapsecond.com wrote:

--

Chris Albertson
Redondo Beach, California

Tom Harris celephicus@gmail.com

On 10 April 2014 16:35, Chris Albertson albertson.chris@gmail.com wrote:

There certainly is an input capture, and it makes the code EASIER to
understand, as you know that the timer will be captured on the next cycle
after the PPS edge, not when the current instruction has finished and the
time 1 overflow interrupt has exited (forgot about that one). This forum
post should get you started. Sure the Arduino is a prettly limited
processor but it is more than enough for this job.

On Wed, Apr 9, 2014 at 11:43 PM, Tom Van Baak tvb@leapsecond.com wrote:

Chinese remainder theorem. Use that and stop worrying about how big your
word is. Since we have these really great integer divisors we can use
between 1e7 and 1e0, it becomes trivial. Your counter word only needs to be
large enough to handle the maximum possible accumulated error in an
interval. In fact, you probably can get by comfortably with an 8-bit
counter.

--
Brian Lloyd, WB6RQN/J79BPL
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.com
+1.916.877.5067

In my case, the cold-start frequency of my OCXO with EFC at midpoint was off sufficiently far that I needed a minimum number of remainder bits to know which way to initially steer it. Don't recall the exact number I needed, but it was more than eight at 10 MHz. Like this design, I had 16 bits to work with, which gave me a usable range.