First success with very simple, very low cost GPSDO, under $8
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:
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:
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
From: Chris Albertson albertson.chris@gmail.com
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Sent: Wednesday, April 9, 2014 6:35 PM
Subject: Re: [time-nuts] First success with very simple, very low
cost GPSDO, under $8
On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephicus@gmail.com
wrote:
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.
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.
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.
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
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.
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.
--
WBW,
V.P.
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.
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
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.
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 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?
On Apr 10, 2014, at 13:28, "Tom Van Baak" tvb@LeapSecond.com 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.
/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
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.
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
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.
/tvb wrote:
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.
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
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
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?
On Apr 10, 2014, at 13:28, "Tom Van Baak" tvb@LeapSecond.com 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.
/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
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.
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
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.
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
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++;
}
}
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.
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).
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.
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.
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.
Hmm...
----- 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
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++;
}
}
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.
--
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
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