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.

I am not sure about Arduino, but probably it too has so-called "timer
overflow interrupt". If so, then its possible to use that other
interrupt and some "long" (lets say 32-bit) RAM variable to accumulate
real value of counter.

In one of my project I was using timer overflow and Besier method to
make good 1 minutes intervals.

volatile signed long t_besier = 12000000L;

interrupt void TPM2OV_ISR(void)
{
TPM2SC = TPM2SC;
if (TPM2SC_TOF)
TPM2SC_TOF=0;
t_besier -= 65536L;
if(t_besier < 0) {
t_besier += 12000000L;
t_time++;
}
}

On 2014-04-09 23:10, Chris Albertson wrote:

--
WBW,

V.P.

Why even try to discipline an OCXO before it's warm?  Just leave the
control loop off for a predetermined time at startup.  You can light
up a bright red "unlocked" LED, and even inhibit the 10 MHz output
until lock is achieved if you want.

Alternatively, you could figure out the EFC voltage needed to zero
the cold oscillator and load the corresponding DAC code at
startup.  However, if the control loop is slow enough for good GPSDO
performance at tau out to 100 seconds or more, it would probably be
too slow to track the oscillator as it warms up -- so you would
likely need switched fast and slow loop filters.  (Switched "acquire"
and "maintain" time constants are often very useful for a number of
reasons, and a GPSDO can benefit from several different "maintain"
time constants for best performance in noisy conditions and
recovering from holdover.)

Best regards,

Charles

I agree with Charles. Further, you don't even have to wait a predetermined amount of time (this would be oscillator or environment dependent). Instead simply monitor the rate of frequency change. When the drift rate drops to the level where your PID is known to be able to track, then start the PID.

Realize that just 2 seconds after power-up you have your first frequency measurement. By 3 seconds you have your first drift measurement. Just wait until it falls to however few ppm/second or ppb/second you need for your loop to smoothly track. This avoids special case PID startup or wind-up code. Although you can argue it merely replaces it with special case drift rate code.

I'm suspicious of fast/slow tracking loops. If you want to vary the tracking, perhaps it is best to continuously, transparently, smoothly vary loop parameters according to drift rate rather than use a hardcoded fast/slow algorithm binary switch. I'm sure there's deep theory on this, which I have not read yet.

/tvb

----- Original Message -----
From: "Charles Steinmetz" csteinmetz@yandex.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Thursday, April 10, 2014 10:55 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO

I should have said warm start, not cold. I was referring to the code, not the oscillator. So tell me, the OCXO is warm, there's no previous EFC information to draw upon, and the oscillator is off-frequency by more than can be measured with, let's say eight timer bits. What do those early measurements tell me, and which direction from midway should the EFC be adjusted?

/tvb wrote:

No reason to be suspicious, they work well if they are designed
well.  Quite often, the best loop tuning for acquiring lock is very
different from the desired loop characteristics during locked
operation.  This is particularly true in very slow loops such as we
see in GPSDO applications.  In this case, two time constants, each
with its well-defined application, can work spectacularly better than
just one.  With just one tc, mutually exclusive design constraints
pull in two directions and often result in a compromise that
sacrifices operating characteristics to achieve bearable performance
during lock acquisition.  Separate acquisition and maintenance time
constants allow you to have both, and there is no practical
difficulty in making sure that each one does its job and does not
interfere with the other.  The fast tc operates only during
acquisition, and the slow tc operates 99.99% of the time.  Only when
there has been a big disturbance (in which case the GPSDO should be
in an alarm status) would the fast tc be recalled.

Having several intermediate time constants raises potential worries
that the control circuitry will not always choose the best tc for
current conditions.  There are many instances in which it works well
(it has been widely speculated that the HP 38xx GPSDOs use this
technique), although care is necessary in design.  However, if, as
you posit, it would be beneficial for the loop parameters to vary
with the drift rate, it would seem clear that several steps of
piecewise approximation would surely be better than just one
operating alignment as long as proper care is taken and no harmful
artifacts are created in doing so.

Best regards,

Charles

That's why I suggested a timer.  Certainly, the delay chosen for a
cold start would be excessive for a warm start, but I'm assuming that
the GPSDOs we're discussing are not used in life-and-death
circumstances where every second of unavailability is
critical.  Whenever you power up -- warm or cold -- you wait
(probably ~ 5 minutes) for availability.

Using the PPS to discipline the oscillator during warmup may seem
like a good idea.  However:  (i) it will not be disciplined to useful
time-nuts standards both because it is drifting and because the
frequency is being set by the noisy, jittery GPS PPS signal.  But
much worse, (ii) if the loop is fast enough to track the oscillator
as it warms up, it is almost certainly too fast to give best
performance at low to medium tau when the oscillator is warm, because
the noisy, jittery PPS will be contributing to stability at tau where
the nice, quiet OCXO should be in charge.

Precision takes time.  Time nuts can't afford to be impatient.

Best regards,

Charles

Use 16-bits if you have it, especially during cold/warm start. But if you only have 8-bits then I can think of two solutions. One is to extend the h/w 8-bit timer with one or two bytes of s/w overflow count. The other is to reduce the sample rate by 2^N (you can do this on a PIC with a prescaler; not sure about AVR) so the numbers are smaller by a factor of 2^N and still fit in 16- or 8-bits. It's one of the rare cases where a trade-off between range and resolution is in your favor.

If your CPU doesn't have a prescaler, or maybe even if it does, just use 16-bits. Or implement the overflow code -- but realize that it's really tricky to make it work at the boundary conditions.

/tvb

----- Original Message -----
From: "KD0GLS" kd0gls@mninter.net
To: "Tom Van Baak" tvb@leapsecond.com; "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Thursday, April 10, 2014 11:48 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO

I should have said warm start, not cold. I was referring to the code, not the oscillator. So tell me, the OCXO is warm, there's no previous EFC information to draw upon, and the oscillator is off-frequency by more than can be measured with, let's say eight timer bits. What do those early measurements tell me, and which direction from midway should the EFC be adjusted?

Hi Vlad,

Correct, your code example is the traditional way to keep track of elapsed time without long-term rounding error, although it's usually not attributed to Bézier.

Not sure if you've been following the whole thread, though -- the problem with timer interrupt code is that it can, and will on rare occasion, conflict with 1PPS rising edge pin interrupts. On a microcontroller, for best precision, the solution is to get rid of the timer interrupts, or get rid of the 1PPS interrupts, or both. Secondly, you cannot share multi-byte variables between interrupt level and main level without synchronization or arbitration.

Your code snippet is a good example of what is subtle and dangerous, and dare I say, wrong. You are updating long t_besier in an interrupt handler. Any main level code using t_besier faces byte carry corruption in the multi-byte value of t_besier. True, this works fine on a 32- or 64-bit cpu, but not on an 8- or 16-bit cpu.

/tvb

----- Original Message -----
From: "d0ct0r" time@patoka.org
To: time-nuts@febo.com
Sent: Thursday, April 10, 2014 10:12 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8

My bad ! I messed up Bezier and Bresenham line algorithm, which I was
using for generating one average timed period from any other timed
period (like the PIC timer0 overflow period, for example).

I am not familiar with Arduino. STM32, for sure, has interrupt priority.
But than it will not be 8$ project. ;-)  The best results I achieve
using DMA. Timer updating the buffer variable(s) in background and its
not using interrupts for it. So, I could read the current value of
counter any time. At least I got good results for this approach when I
connect MCU clock to GPSDO and tried to measure the signal from external
OCXO. I got perfect 10 Mhz at that time.

Hmm...

--
WBW,

V.P.

Don't you also need to wait for the GPS at first power up?

----- Original Message -----
From: "Charles Steinmetz" csteinmetz@yandex.com
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Thursday, April 10, 2014 3:31 PM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO

Certainly.  However I was addressing only the measurement capabilities of the timer with regard to its width, not the overall operation of the system.

On Thu, Apr 10, 2014 at 10:55 AM, Charles Steinmetz
csteinmetz@yandex.comwrote:

Even if you wait long enough you still need to set the DAC to "something"
as a first try.    What if your first guess is off by a large amount.  The
answer is not to guess better because you still need some way to determine
if the guess is correct.

How to do that?  Can you write code to do this without counting overflows?
You can be off by 256 cycles and never know it.  Let's assume someone is
building a GPSDO because they need a frequency reference and don't have
one.  A good assumption, I think.  How could such a person "figure out the
EFC voltage needed"  with out either coining cycles?

I'm thinking about turning the overflow counter off after lock.  But
without one I think we have a chicken and egg problem where you would need
an accurate frequency reference to build a GPSDO.

--

Chris Albertson
Redondo Beach, California

FWIW, I set the DAC to midpoint and use a binary search to get to frequency.  On my system, I start off with a change of 0x80 and work my way down to 0x04 in powers of 2 (0x80, 0x40, 0x20, etc).  Once I get to 256 seconds between DAC changes, I light the PLL fuse.  I could probably get away with less than 256 seconds.  Before I built the TIC, I worked down to 0x01 which resulted in pretty long times between changes.

Bob

On Thu, Apr 10, 2014 at 4:52 PM, Bob Stewart bob@evoria.net wrote:

The point i not how to search but how to know if the current frequency is
larger or smaller then the desired 10MHz WITHOUT counting all 10,000,000
cycles.

The proposal was that could let the timer overflow many times, ignore those
overflows and I need to look only at the last 5 or 6 bits of the timer
after the PPS interrupt.  I agree now that I can, under tightly limited
conditions,  but I claim in your case, while doing a binary search I must
count all 10,000,000 cycles.

So at each cycle in your binary search what data do you need to decide if
the frequency is high or low?

--

Chris Albertson
Redondo Beach, California

The only thing I need to know, in fact the only thing available to me, is the fact that a phase crossing has occurred.  Since 10MHz is 0x989680, then all I need to know is whether my timer delta is above, equal to, or below 0x9680, without regard to anything else.  None of the other 0x9680 points are within the range of my oscillator.  In fact, they are way out of range.  There are two conditions that can happen with this type of counter which someone else spoke about.  In the one case, you are sitting right on the phase point, and the timer will bounce back and forth, from 0x967F to 0x9681; i.e. you will have a limited amount of phase information.  In the other, you are not near the phase point, and you will get just the frequency result.

The problem with sitting right on the phase point is that it tricks you into thinking you are getting more out of the system than you actually are.  But, you are only getting a few nanoseconds, i.e. a few degrees, worth of phase information.  Once the system drifts out of that little phase band, then all you know is which way it drifted, not how quickly or how far.  I spent far too many tens of hours thinking I could solve the problem.  I couldn't.  There's just not enough information available to you.  You have to resort to guessing, based on what you know about your oscillator.  But you can't be right enough in your guess to make a reliable phase control.  So, at least for me, it sits on phase for quite awhile, then it drifts off, your PLL stops, and you wait till you drift back to the phase point.  Rinse, repeat, fail.  But, it's always possible that you can see something in the data that I didn't.

Bob

I did a poor job of explaining this.  So, consider the "phase point" as where you are on the PPS coming in compared to your oscillator.  That PPS is not corrected for sawtooth.  So, when you have a regular sawtooth PPS, then at the "phase point" you will see the count bouncing back and forth.  But, then a ramp or a hanging bridge comes along and you no longer know where the phase is WRT where where you are.  You also don't know how long it's going to be there, or even whether you were at the actual phase center point and it's now on a hanging bridge, or that you were on a hanging bridge on one side and it's now gone to center, a bridge on the other side, or back to a sawtooth that averages to zero.  That's probably still pretty poorly said, but it's way past my bedtime.

Bob

Hi,

On 10/04/14 06:43, Tom Van Baak wrote:

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.

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 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

On 10/04/14 20:28, Tom Van Baak wrote:

This is where many spend their time building a heuristics.

My favorite solution is to derive the phase detector and let the result
feed into the integrator through a scaling factor. This input to the
integrator is in parallel to the I factor input. Code-wise we get
something like this:

Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + IVdp + FVdf
Vf = Vi + P*Vdp

For far-out frequency errors, the PI PLL is weak, due to Bessel
coefficient, so the FLL dominates and the F factor steers the loop gain
of the FLL. It steers the Vi state of the integrator until it becomes
close, with an exponential decay into zero frequency error. When it
does, the Bessel coefficient becomes stronger and stronger and then PI
PLL starts to take over. When the gain of the PLL surpasses that of the
decaying FLL the PLL just takes over... by design. When the PLL has
locked the frequency, the FLL part just doesn't have gain, but adds a
little noise.

The benefit of this approach is that the frequency correction is kept in
the Vi state, and depending on the Vi state either the FLL or PLL
dominates, there is no hand-over, there is no external intelligence to
chose mode, it is always steered by the need from frequency-error
needing to be corrected and the current Vi, or if you so like, the
current Vi error.

Simple, relatively easy to analyse and completely linear regulation
mechanisms.

Cheers,
Magnus

On Sat, Apr 12, 2014 at 9:48 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:

It turns out all of this is built into the AVR chip.  There is a counter
and logic to copy the current counter value to a register on a PPS pulse
raising edge.    The counter keeps running and every second its value is
trapped.

I can connect the OCXO and the PPS directly to the AVR pin.  The AVR has
hardware (a fast comparator) to "square" a low amplitude sine wave and trap
the counter on a zero crossing.  So it looks like I can get rid of  ALL of
the external chips.  The built in DAC is working well also but it needs
some external resisters and caps.

No need for '74 FFs or '373' or counter chips.    I do get precision timing
with no time critical software, no 74xxx chips.

--
Chris Albertson
Redondo Beach, California

Your oscillator is on its way. I set it right on 10.00000000 MHz against a
GPSDRb house standard. You will get a better waveform out if it sees about a
100 - 200 ohm termination, though the edge is nice and sharp with some
peaking overshoot.

You might get a bit more stability if you can add to the thermal insulation
around the oscillator. Also, consider using the internal reference output on
the pin marked n/c. It runs near 4.0 volts and is stable to ambient temp
changes. Maybe put the whole thing in a Styrofoam container that has about
one inch wall thickness.

Regards,
Tom

----- Original Message -----
From: "Chris Albertson" albertson.chris@gmail.com
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com; "Magnus Danielson" magnus@rubidium.dyndns.org
Sent: Sunday, April 13, 2014 12:30 AM
Subject: Re: [time-nuts] First success with very simple, very low cost
GPSDO, under $8