First success with very simple, very low cost GPSDO, under $8
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 Apr 10, 2014, at 15:52, "Tom Miller" tmiller11147@verizon.net wrote:
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
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?
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
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.
On Thu, Apr 10, 2014 at 10:55 AM, Charles Steinmetz
csteinmetz@yandex.comwrote:
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.
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.
Alternatively, you could figure out the EFC voltage needed to zero the
cold oscillator
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
From: Chris Albertson albertson.chris@gmail.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Thursday, April 10, 2014 6:05 PM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO
On Thu, Apr 10, 2014 at 10:55 AM, Charles Steinmetz
csteinmetz@yandex.comwrote:
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.
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.
Alternatively, you could figure out the EFC voltage needed to zero the
cold oscillator
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
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.
On Thu, Apr 10, 2014 at 4:52 PM, Bob Stewart bob@evoria.net wrote:
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.
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
From: Chris Albertson albertson.chris@gmail.com
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Thursday, April 10, 2014 11:33 PM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO
On Thu, Apr 10, 2014 at 4:52 PM, Bob Stewart bob@evoria.net wrote:
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.
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
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
From: Bob Stewart bob@evoria.net
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Friday, April 11, 2014 12:20 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO
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
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
On 10/04/14 20:28, Tom Van Baak wrote:
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.
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:
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.
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
On Sat, Apr 12, 2014 at 9:48 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
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.
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
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.