Measure GPSDO stability with minimum resources?
For my GPSDO, I need to calculate the OCXO aging for holdover projection purposes as well as get some figure of merit for the recent past of the OCXO stability. The latter is so that I can determine that the PLL has (or soon will have) a good lock. I'm developing on a dfPIC33FJ128MC802, and I've used about 70% of the code space, I could probably set aside 4K bytes of data space for this calculation.
I have a rather primitive way of doing part of this, but I was hoping someone would steer me to something a bit better.
Bob
On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart bob@evoria.net wrote:
For my GPSDO, I need to calculate the OCXO aging for holdover projection
purposes as well as get some figure of merit for the recent past of the
OCXO stability.
Do you have a serial port or some way of generating a logging stream?
If so, one low-overhead way to track the aging is to compute an average DAC
value and periodically "print" the result to the serial port. I have found
that a 3-hour average works well for observing aging. Each second you
simply add the current DAC value to a Long and after 3 hours divide by
10800, print the result, reset the total, and repeat. It is helpful to also
include the current time. This could be extracted from the GPS NMEA data
or simply be seconds since startup. If you separate the values with a Tab
and end each set of values with a newline, you can capture the data with an
attached PC, copy/paste to Excel, and analyze it there. The trend line
feature in Excel's chart will compute and display a least square fit to the
aging.
If you don't want to keep the monitor connected full time and you have some
extra RAM or preferably EEPROM, you can store historic average values in a
circular buffer and print one of the values every second. 288 bytes will
store 18 days worth of 16 bit 3-hour averages.
My system, based on the one posted here by Lars Walenius some time
ago,collects 144 sets of 5-minute averages (12 hours worth) and another 144
sets of 3-hour averages. It spits out one line of logging data each second.
The first part of each line has the current data, and the second part has
either one of the 5-minute sets or one of the 3-hour sets. So 5 minutes
worth of logging data has 300 lines, showing current data plus 5-minute
averages for the past 12 hours and 3-hour averages for the past 18 days.
All this, including the GPSDO code, fits comfortably in a 32u4-based
Arduino Micro, which has 32K of program memory, 2.5K of RAM, and 1K of
EEPROM.
--
--Jim Harman
I just noticed that my reply didn't go to the list so...
Thanks for the reply. What I'm really looking for is a way to do everything in the PIC. I've been experimenting with saving the DAC value in a circular queue every 20 seconds for 60 minutes, and plotting the difference value between the head and tail of the queue every second. After posting this question, I took another look at the overall behavior and decided to cut the queue size down from 60 minutes to 5. At the moment, I'm doing a trial run of integrating the difference values starting at the point where I decide that it's locked. Maybe I'll gain enough insight from this to get a better idea on calculating the aging rate. The 5 minute queue seems to give me a good indication of how well the PLL is locked. Maybe saving the integrated values into a longer queue that's sampled once every 5 minutes will give me something for aging rate.
Bob -----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Jim Harman <j99harman@gmail.com>
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, October 5, 2016 4:37 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart bob@evoria.net wrote:
For my GPSDO, I need to calculate the OCXO aging for holdover projection purposes as well as get some figure of merit for the recent past of the OCXO stability.
Do you have a serial port or some way of generating a logging stream?
If so, one low-overhead way to track the aging is to compute an average DAC value and periodically "print" the result to the serial port. I have found that a 3-hour average works well for observing aging. Each second you simply add the current DAC value to a Long and after 3 hours divide by 10800, print the result, reset the total, and repeat. It is helpful to also include the current time. This could be extracted from the GPS NMEA data or simply be seconds since startup. If you separate the values with a Tab and end each set of values with a newline, you can capture the data with an attached PC, copy/paste to Excel, and analyze it there. The trend line feature in Excel's chart will compute and display a least square fit to the aging.
If you don't want to keep the monitor connected full time and you have some extra RAM or preferably EEPROM, you can store historic average values in a circular buffer and print one of the values every second. 288 bytes will store 18 days worth of 16 bit 3-hour averages.
My system, based on the one posted here by Lars Walenius some time ago,collects 144 sets of 5-minute averages (12 hours worth) and another 144 sets of 3-hour averages. It spits out one line of logging data each second. The first part of each line has the current data, and the second part has either one of the 5-minute sets or one of the 3-hour sets. So 5 minutes worth of logging data has 300 lines, showing current data plus 5-minute averages for the past 12 hours and 3-hour averages for the past 18 days.
All this, including the GPSDO code, fits comfortably in a 32u4-based Arduino Micro, which has 32K of program memory, 2.5K of RAM, and 1K of EEPROM.
--
--Jim Harman
On Wed, Oct 5, 2016 at 6:46 PM, Bob Stewart bob@evoria.net wrote:
What I'm really looking for is a way to do everything in the PIC. I've
been experimenting with saving the DAC value in a circular queue every 20
seconds for 60 minutes, and plotting the difference value between the head
and tail of the queue every second. After posting this question, I took
another look at the overall behavior and decided to cut the queue size down
from 60 minutes to 5.
Hi Bob,
Unless the oscillator is still warming up, 5 minutes or even 60 is way too
short a time to look at aging. For aging, you will want to look at the
change in DAC values over several days at least.
Looking at the current value and one in the past will give you a feel for
what is going on, but then you are discarding all the intermediate data.
You really want to do a least squares fit using as many data points as you
can handle, Check Wikipedia under Linear Least Squares for an example.
What sort of phase detector are you using? If you want to see whether the
system is locked, you may be better off looking at the phase detector
signal.and declaring a lock if the low pass filtered phase error stays
within a pre-determined range.
--
--Jim Harman
Hi Jim,
I'm using an interpolated RC/ADC TIC to measure the time interval between the 1PPS from the receiver to the next OCXO pulse. I also count the OCXO pulses between 1PPS ticks to make sure I'm on 10 MHz.
I've been developing and improving this GPSDO for over 2 years now, so I have a good understanding of the qualities of the OCXO, etc. But, what I know in general, and what each OCXO does in specific is a slightly different story. So, phase lock first: I have been checking to see if the phase error to target has remained less than +/- 13ns for 500 seconds before declaring "locked" with good success. So, lock detection is not critical, but being able to have more confidence, rather than using a set value like this would be nice. And that's the reason I mentioned the 5 minute circular queue experiment. It does seem to give me a nice low number when I can look at a plot and say "that's locked", so I may play with it some more.
As you say, aging is an entirely different question. The OCXOs I use eventually retrace out and age at about 1 (20-bit) DAC step per hour; some better, some worse, and not always in the same direction. Being able to project this before several months go by would be nice for holdover projections. Doesn't the KS-24361 GPSDO set start making holdover projections within a half our of being powered on? That's the sort of thing I was looking for.
After posting, I realized that integrating the DAC movement while in lock wasn't a very good idea, as eventually it's going to reach a rather large magnitude. And that number wouldn't be very useful, as it's not related to any time period, other than when time began. I also realized that since it is under PLL control, there aren't going to be any large swings, so I don't need any real sort of figure of merit that describes +/- swings, etc. So, I guess I was making this harder than it needed to be.
So, now I'm thinking about going to a 24-hour circular queue that samples every 5 minutes. That would be 288 slots, or 1152 bytes, which I can spare. With 24 hours of data, I should be able to get some idea as to how quickly it's settling down. The question is how to use that to project retrace and aging over the next 24 hours in case of a holdover event?
Bob -----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Jim Harman <j99harman@gmail.com>
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, October 5, 2016 9:14 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
On Wed, Oct 5, 2016 at 6:46 PM, Bob Stewart bob@evoria.net wrote:
What I'm really looking for is a way to do everything in the PIC. I've been experimenting with saving the DAC value in a circular queue every 20 seconds for 60 minutes, and plotting the difference value between the head and tail of the queue every second. After posting this question, I took another look at the overall behavior and decided to cut the queue size down from 60 minutes to 5.
Hi Bob,
Unless the oscillator is still warming up, 5 minutes or even 60 is way too short a time to look at aging. For aging, you will want to look at the change in DAC values over several days at least.
Looking at the current value and one in the past will give you a feel for what is going on, but then you are discarding all the intermediate data. You really want to do a least squares fit using as many data points as you can handle, Check Wikipedia under Linear Least Squares for an example.
What sort of phase detector are you using? If you want to see whether the system is locked, you may be better off looking at the phase detector signal.and declaring a lock if the low pass filtered phase error stays within a pre-determined range.
--
--Jim Harman
The HP Smartclock app note will help you a lot:
http://leapsecond.com/hpan/an1279.pdf
There are lots of Z3801A EFC curves on the web for you to see what typical
range of unit-to-unit variation is.
Of course to actually test holdover, you do that by opening the PLL loop
(unhook GPS antenna) and letting the EFC extrapolation in your software run
for a day (or whatever), watching the phase difference. Then you have to
test that the system recovers back into phase lock smoothly after getting
hooked back up.
Tim N3QE
On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart bob@evoria.net wrote:
For my GPSDO, I need to calculate the OCXO aging for holdover projection
purposes as well as get some figure of merit for the recent past of the
OCXO stability. The latter is so that I can determine that the PLL has (or
soon will have) a good lock. I'm developing on a dfPIC33FJ128MC802, and
I've used about 70% of the code space, I could probably set aside 4K bytes
of data space for this calculation.
I have a rather primitive way of doing part of this, but I was hoping
someone would steer me to something a bit better.
Bob
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 Tim,
Thanks for the document. I have been doing some 12 hour holdover tests. But as I mentioned, the HP quick projections had fooled me into thinking there was some trick to this other than actually capturing the DAC over multiple days to get a real projection.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Tim Shoppa <tshoppa@gmail.com>
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Thursday, October 6, 2016 12:37 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
The HP Smartclock app note will help you a lot:
http://leapsecond.com/hpan/an1279.pdf
There are lots of Z3801A EFC curves on the web for you to see what typical range of unit-to-unit variation is.
Of course to actually test holdover, you do that by opening the PLL loop (unhook GPS antenna) and letting the EFC extrapolation in your software run for a day (or whatever), watching the phase difference. Then you have to test that the system recovers back into phase lock smoothly after getting hooked back up.
Tim N3QE
On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart bob@evoria.net wrote:
For my GPSDO, I need to calculate the OCXO aging for holdover projection purposes as well as get some figure of merit for the recent past of the OCXO stability. The latter is so that I can determine that the PLL has (or soon will have) a good lock. I'm developing on a dfPIC33FJ128MC802, and I've used about 70% of the code space, I could probably set aside 4K bytes of data space for this calculation.
I have a rather primitive way of doing part of this, but I was hoping someone would steer me to something a bit better.
Bob
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.
Thanks to everyone who responded to my post. I put in a 5 minute DAC value averager and saved that once every 15 minutes to a 12 hour circular queue last night. It just started giving me responses, and I've gotten -139 seconds, -4800, -7200, and -2400. The -139 is probably because I started the thing up too early in the lock process. I'm going to have to give some thought to this as I get more results. I expected to get values around -3600, and actually, the last three fit that criteria with a dividend of only 43,200 (12 hours). I notice that I had an OCXO burp in the middle of the night. So, I'll have to give some thought about saving a number of the most recent values and throwing away any that don't seem to fit in with the rest. Once I'm satisfied with the code, I'll increase the queue size to at least 48 hours. I'm not sure if more than that is really useful, but a multiple of 24 may bias it toward environmental conditions at startup, so perhaps 64 hours would be better.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Stewart <bob@evoria.net>
To: Discussion of Precise Time and Frequency Measurement time-nuts@febo.com
Sent: Wednesday, October 5, 2016 12:37 PM
Subject: [time-nuts] Measure GPSDO stability with minimum resources?
For my GPSDO, I need to calculate the OCXO aging for holdover projection purposes as well as get some figure of merit for the recent past of the OCXO stability. The latter is so that I can determine that the PLL has (or soon will have) a good lock. I'm developing on a dfPIC33FJ128MC802, and I've used about 70% of the code space, I could probably set aside 4K bytes of data space for this calculation.
I have a rather primitive way of doing part of this, but I was hoping someone would steer me to something a bit better.
Bob
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.