BC
Bob Camp
Sat, Oct 31, 2015 11:58 PM
On Oct 31, 2015, at 6:29 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Hi Chris and Bob,
On 10/31/2015 02:13 PM, Bob Camp wrote:
On Oct 31, 2015, at 6:50 AM, Chris Wilson chris@chriswilson.tv wrote:
31/10/2015 10:46
I have a Racal counter locked to 1 MHz on its rear panel external
input socket from my Trimble Thunderbolt GPS. I derive the 1 Mhz
from a David Partridge divider board. If I also feed the counter
with the 10 Mhz direct output from the same GPS it reads one or two
Hz out. As I assume the counter is working purely mathematically
why would that be please?
Is it always out in the same direction ( = broken counter) or does it
bounce back and forth to each side of “correct” ( = noise) ?
Does not have to be a broken counter, not at all.
There’s a fine line between “broken” and “not calibrated” …. To me “broken” = needs to be fixed. That
can easily include calibration adjustments. It can also include an input that has drifted far enough that
the adjustments no longer bring it back into proper operation. The distinction here is between a counter
that is operating properly (bouncing each side of zero error) and one that exhibits a bias. The ones that
exhibit a bias need to be “fixed”.
Bob
For instance, the SR620 displays this kind of behavior if you have not calibrated it correctly.
Counters measure elapsed time and elapsed events.
If you divide time with events you get average period measure.
If you divide events with time you get average frequency measure.
While the time-base tries to give you a second worth of measures, in actual life it only delays the trigger of the "stop" in relation to the "start" trigger that time, and then the "stop" even is recorded and the elapsed time occurs.
If "start" and "stop" triggers does not trigger at the same phase (due to voltage offsets or time offsets), then there will be a time-bias. Some counters calibrate this bias out, where as others try hard to avoid it. If you don't calibrate it properly, this bias can cause a shift up or down in perceived frequency measure. This is not necessarily a sign of a broken counter, it's a sign of an uncalibrated counter.
For instance, the SR620 auto-calibration does not cancel this effect, you have to adjust the calibration manually to zero it out.
Another flaw could be missed or added cycles, as it adjust the event count in the above formula. Those usually show themselves as larger error.
Some people is very fond of using the frequency measure of counters, I've grown more and more sceptic to it for a number of reasons when doing ADEV and friends, then I use TI that avoids a number of issues.
But that is a much more involved story.
Cheers,
Magnus
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
> On Oct 31, 2015, at 6:29 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote:
>
> Hi Chris and Bob,
>
> On 10/31/2015 02:13 PM, Bob Camp wrote:
>> Hi
>>
>>
>>
>>> On Oct 31, 2015, at 6:50 AM, Chris Wilson <chris@chriswilson.tv> wrote:
>>>
>>>
>>>
>>> 31/10/2015 10:46
>>>
>>> I have a Racal counter locked to 1 MHz on its rear panel external
>>> input socket from my Trimble Thunderbolt GPS. I derive the 1 Mhz
>>> from a David Partridge divider board. If I also feed the counter
>>> with the 10 Mhz direct output from the same GPS it reads one or two
>>> Hz out. As I assume the counter is working purely mathematically
>>> why would that be please?
>>
>>
>> Is it always out in the same direction ( = broken counter) or does it
>> bounce back and forth to each side of “correct” ( = noise) ?
>
> Does not have to be a broken counter, not at all.
There’s a fine line between “broken” and “not calibrated” …. To me “broken” = needs to be fixed. That
can easily include calibration adjustments. It can also include an input that has drifted far enough that
the adjustments no longer bring it back into proper operation. The distinction here is between a counter
that is operating properly (bouncing each side of zero error) and one that exhibits a bias. The ones that
exhibit a bias need to be “fixed”.
Bob
>
> For instance, the SR620 displays this kind of behavior if you have not calibrated it correctly.
>
> Counters measure elapsed time and elapsed events.
> If you divide time with events you get average period measure.
> If you divide events with time you get average frequency measure.
>
> While the time-base tries to give you a second worth of measures, in actual life it only delays the trigger of the "stop" in relation to the "start" trigger that time, and then the "stop" even is recorded and the elapsed time occurs.
>
> If "start" and "stop" triggers does not trigger at the same phase (due to voltage offsets or time offsets), then there will be a time-bias. Some counters calibrate this bias out, where as others try hard to avoid it. If you don't calibrate it properly, this bias can cause a shift up or down in perceived frequency measure. This is not necessarily a sign of a broken counter, it's a sign of an uncalibrated counter.
>
> For instance, the SR620 auto-calibration does not cancel this effect, you have to adjust the calibration manually to zero it out.
>
> Another flaw could be missed or added cycles, as it adjust the event count in the above formula. Those usually show themselves as larger error.
>
> Some people is very fond of using the frequency measure of counters, I've grown more and more sceptic to it for a number of reasons when doing ADEV and friends, then I use TI that avoids a number of issues.
> But that is a much more involved story.
>
> Cheers,
> Magnus
> _______________________________________________
> 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.
TV
Tom Van Baak
Sun, Nov 1, 2015 12:58 AM
As an aside, I work low frequency RF transmissions on 136 Mhz, and
very narrow bandwidth. Can a soundcard be locked to GPS instead of
its own internal crystal for precise frequency output?
Chris,
It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
/tvb
> As an aside, I work low frequency RF transmissions on 136 Mhz, and
> very narrow bandwidth. Can a soundcard be locked to GPS instead of
> its own internal crystal for precise frequency output?
Chris,
It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
/tvb
BS
Bob Stewart
Sun, Nov 1, 2015 1:25 AM
Tom,
It's been awhile since I did soundcard SSTV, but the program MMSSTV uses the time ticks from WWV to do a calculation similar to what you describe. You tune in WWV on your receiver, which is coupled to your computer's soundcard. The MMSSTV calibration routine puts a raster scan on the screen. You adjust the calibration factor so that the time ticks are lined up vertically from top to bottom. The code is proprietary, but I suspect that he is merely dumping bytes from the soundcard on the screen, and the calibration value is some sort of multiplier for the soundcard's clock rate. Someone who has done soundcard FFT programming might have a better idea.
Bob
From: Tom Van Baak <tvb@LeapSecond.com>
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Saturday, October 31, 2015 7:58 PM
Subject: Re: [time-nuts] Beginners GPS locked frequency counter question
As an aside, I work low frequency RF transmissions on 136 Mhz, and
very narrow bandwidth. Can a soundcard be locked to GPS instead of
its own internal crystal for precise frequency output?
Chris,
It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
/tvb
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.
Tom,
It's been awhile since I did soundcard SSTV, but the program MMSSTV uses the time ticks from WWV to do a calculation similar to what you describe. You tune in WWV on your receiver, which is coupled to your computer's soundcard. The MMSSTV calibration routine puts a raster scan on the screen. You adjust the calibration factor so that the time ticks are lined up vertically from top to bottom. The code is proprietary, but I suspect that he is merely dumping bytes from the soundcard on the screen, and the calibration value is some sort of multiplier for the soundcard's clock rate. Someone who has done soundcard FFT programming might have a better idea.
Bob
From: Tom Van Baak <tvb@LeapSecond.com>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Saturday, October 31, 2015 7:58 PM
Subject: Re: [time-nuts] Beginners GPS locked frequency counter question
> As an aside, I work low frequency RF transmissions on 136 Mhz, and
> very narrow bandwidth. Can a soundcard be locked to GPS instead of
> its own internal crystal for precise frequency output?
Chris,
It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
/tvb
_______________________________________________
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.
BC
Bob Camp
Sun, Nov 1, 2015 2:32 AM
Hi
So … how good is the “calibrate and go” (not the tone on second channel) approach likely to be?
If it’s a bare crystal or normal XO (not a TCXO) that is supplying the clock, the crystal will follow some
fairly well known curves. Which one of the curves it follows will depend entirely on the individual sample
you have. What I see on my sound card will not be what you see on a different sample of exactly the same
sound card installed in a similar machine.
It’s a pretty good bet that your device will change by 0.1 to 1 ppm per degree C. Yes it can be a bit better. It
can also be a whole lot worse. Your room environment is likely to move 1 to 3 C per hour if you have the heat
or air-conditioning turned on. If you are in an unheated garage … who knows. If you take the most likely 0.5 ppm/C tempco
and the most likely 2C change you get a “wobble” of about 1 ppm. The period of this wobble probably will be
in the 30 to 90 minute range.
On top of the temperature induced effects there are also voltage issues and long term aging. Unless you are in
a very unusual setting, both should be well below the temperature related effects until you get out to time periods
of many months to several years.
At 130 KHz, 1 ppm is 0.13 Hz. You will need to run a pretty good / long FFT on the sound card to get that sort of
resolution. With some coding, you can do various things to speed the process up a bit. Depending on what
you are doing, 1 ppm may indeed be “good enough”.
A typical TBolt GPSDO when locked and running normally will supply an output that is good to better than 0.1 ppb
99% of the time. It will hit 0.01 ppb 90% of the time. With some care, it could be even better. Both assume you
are using a counter gate in the 1 to 10 seconds range to check it.
That moves you up 10,000 to 100,000 times more accurate than the 1ppm drift on the sound card time base.
Getting useful accuracy at that level out of a straight sound card reading is quite a challenge. You also get into a lot
of fancy math surrounding things like 6 hour long measurement times.
My guess would be that the GPSDO is not really needed in this case ...
Bob
As an aside, I work low frequency RF transmissions on 136 Mhz, and
very narrow bandwidth. Can a soundcard be locked to GPS instead of
its own internal crystal for precise frequency output?
Chris,
It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
/tvb
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
So … how good is the “calibrate and go” (not the tone on second channel) approach likely to be?
If it’s a bare crystal or normal XO (not a TCXO) that is supplying the clock, the crystal will follow some
fairly well known curves. Which one of the curves it follows will depend entirely on the individual sample
you have. What I see on my sound card will not be what you see on a different sample of exactly the same
sound card installed in a similar machine.
It’s a pretty good bet that your device will change by 0.1 to 1 ppm per degree C. Yes it can be a bit better. It
can also be a whole lot worse. Your room environment is likely to move 1 to 3 C per hour if you have the heat
or air-conditioning turned on. If you are in an unheated garage … who knows. If you take the most likely 0.5 ppm/C tempco
and the most likely 2C change you get a “wobble” of about 1 ppm. The period of this wobble probably will be
in the 30 to 90 minute range.
On top of the temperature induced effects there are also voltage issues and long term aging. Unless you are in
a very unusual setting, both should be well below the temperature related effects until you get out to time periods
of many months to several years.
At 130 KHz, 1 ppm is 0.13 Hz. You will need to run a pretty good / long FFT on the sound card to get that sort of
resolution. With some coding, you can do various things to speed the process up a bit. Depending on what
you are doing, 1 ppm may indeed be “good enough”.
A typical TBolt GPSDO when locked and running normally will supply an output that is good to better than 0.1 ppb
99% of the time. It will hit 0.01 ppb 90% of the time. With some care, it could be even better. Both assume you
are using a counter gate in the 1 to 10 seconds range to check it.
That moves you up 10,000 to 100,000 times more accurate than the 1ppm drift on the sound card time base.
Getting *useful* accuracy at that level out of a straight sound card reading is quite a challenge. You also get into a lot
of fancy math surrounding things like 6 hour long measurement times.
My *guess* would be that the GPSDO is not really needed in this case ...
Bob
> On Oct 31, 2015, at 8:58 PM, Tom Van Baak <tvb@LeapSecond.com> wrote:
>
>> As an aside, I work low frequency RF transmissions on 136 Mhz, and
>> very narrow bandwidth. Can a soundcard be locked to GPS instead of
>> its own internal crystal for precise frequency output?
>
> Chris,
>
> It might first be interesting to see how far off the frequency is before you worry about disciplining it with GPS.
>
> One trick that I use is to make the soundcard generate 1 Hz pulses and compare that against GPS with a TI counter. The tool is 1hz.c 1hz.exe in my tools directory (http://leapsecond.com/tools). This avoids having to open up the computer and probe or buffer the soundcard oscillator.
>
> If you collect a long enough data set you will also get a feel for how stable the oscillator is; something you will need to know to tune your GPSDO algorithms.
>
> But wait, there's more. If you find that your soundcard oscillator is, say, 12.34 ppm fast -- you don't actually have to tune or discipline or replace the physical oscillator. Instead just change the software that's writing to the soundcard and have it generate waveforms that it thinks are 12.34 ppm too slow. In other words, instead of defining PCM_RATE 48000 as a constant, you set pcm_rate = 48000 * (1 + 12.34e-6) as a variable. One line of code.
>
> It gets even better. If all you need is one channel of output, then generate your waveform on the L channel and generate 1PPS on the R channel. Use a TBolt and TIC to continuously measure R vs. 1PPS and send those readings back to the PC for averaging. As the time interval grows (indicating a frequency offset) beyond acceptable levels, then make corresponding changes your pcm_rate variable. This essentially becomes a software GPSDO. No h/w changes are required to the board; you don't even have to open the case. The output waveform will always be spot on-frequency, regardless of soundcard oscillator frequency offset and drift.
>
> /tvb
>
> _______________________________________________
> 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.
JL
Jim Lux
Sun, Nov 1, 2015 2:03 PM
On 10/31/15 7:32 PM, Bob Camp wrote:
Hi
So … how good is the “calibrate and go” (not the tone on second channel) approach likely to be?
If it’s a bare crystal or normal XO (not a TCXO) that is supplying the clock, the crystal will follow some
fairly well known curves. Which one of the curves it follows will depend entirely on the individual sample
you have. What I see on my sound card will not be what you see on a different sample of exactly the same
sound card installed in a similar machine.
having just done a bunch of measurements over 4 days on some crystals of
this type (16 MHz, nothing special), I can shed some light on it.
over half a day sitting on my desk, they fluctuated about 0.1 ppm (peak
excursion)
AVAR is about 1E-9 at tau=10sec, rising to 2e-7 at 10,000 seconds (after
taking out the temperature dependence)
There is a strong temperature dependence.. with temperature changes of 6
degrees (C) the frequency change is on the order of 6ppm (90 Hz out of
16 MHz)
It’s a pretty good bet that your device will change by 0.1 to 1 ppm per degree C. Yes it can be a bit better. It
can also be a whole lot worse. Your room environment is likely to move 1 to 3 C per hour if you have the heat
or air-conditioning turned on. If you are in an unheated garage … who knows. If you take the most likely 0.5 ppm/C tempco
and the most likely 2C change you get a “wobble” of about 1 ppm. The period of this wobble probably will be
in the 30 to 90 minute range.
yes, that's about right..
Although my office doesn't have that kind of fluctuation..
And I ran the 4 day test with the oscillators in a cardboard box over
the weekend, so that damps short term variations.
On 10/31/15 7:32 PM, Bob Camp wrote:
> Hi
>
> So … how good is the “calibrate and go” (not the tone on second channel) approach likely to be?
>
> If it’s a bare crystal or normal XO (not a TCXO) that is supplying the clock, the crystal will follow some
> fairly well known curves. Which one of the curves it follows will depend entirely on the individual sample
> you have. What I see on my sound card will not be what you see on a different sample of exactly the same
> sound card installed in a similar machine.
having just done a bunch of measurements over 4 days on some crystals of
this type (16 MHz, nothing special), I can shed some light on it.
over half a day sitting on my desk, they fluctuated about 0.1 ppm (peak
excursion)
AVAR is about 1E-9 at tau=10sec, rising to 2e-7 at 10,000 seconds (after
taking out the temperature dependence)
There is a strong temperature dependence.. with temperature changes of 6
degrees (C) the frequency change is on the order of 6ppm (90 Hz out of
16 MHz)
>
> It’s a pretty good bet that your device will change by 0.1 to 1 ppm per degree C. Yes it can be a bit better. It
> can also be a whole lot worse. Your room environment is likely to move 1 to 3 C per hour if you have the heat
> or air-conditioning turned on. If you are in an unheated garage … who knows. If you take the most likely 0.5 ppm/C tempco
> and the most likely 2C change you get a “wobble” of about 1 ppm. The period of this wobble probably will be
> in the 30 to 90 minute range.
yes, that's about right..
Although my office doesn't have that kind of fluctuation..
And I ran the 4 day test with the oscillators in a cardboard box over
the weekend, so that damps short term variations.
NS
Nick Sayer
Sun, Nov 1, 2015 4:51 PM
On Oct 31, 2015, at 3:29 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Some people is very fond of using the frequency measure of counters, I've grown more and more sceptic to it for a number of reasons when doing ADEV and friends, then I use TI that avoids a number of issues.
But that is a much more involved story.
In doing my evaluations of my GPSDO, I’ve tried two configurations:
-
Feeding a reference into one input and the test signal into the other and asking my 53220A to give me the time difference between the two, and then having TimeLab fetch that.
-
Feeding a reference into the external reference input and the test signal into input 1 and asking for the frequency, and having TimeLab fetch that.
So far, #2 has given me (very) slightly lower AVARs. My guess as to why is that if you’re reading phase differences, then that is very sensitive to the accuracy with which you time the sampling. I’m interrogating the TIA with a virtual machine over WiFi, so I don’t have any reason to expect that that timing is going to be exceptionally accurate.
If anyone has any additional insight or corrections to my understanding, I’m all ears.
> On Oct 31, 2015, at 3:29 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote:
>
> Some people is very fond of using the frequency measure of counters, I've grown more and more sceptic to it for a number of reasons when doing ADEV and friends, then I use TI that avoids a number of issues.
> But that is a much more involved story.
>
In doing my evaluations of my GPSDO, I’ve tried two configurations:
1. Feeding a reference into one input and the test signal into the other and asking my 53220A to give me the time difference between the two, and then having TimeLab fetch that.
2. Feeding a reference into the external reference input and the test signal into input 1 and asking for the frequency, and having TimeLab fetch that.
So far, #2 has given me (very) slightly lower AVARs. My guess as to why is that if you’re reading phase differences, then that is very sensitive to the accuracy with which you time the sampling. I’m interrogating the TIA with a virtual machine over WiFi, so I don’t have any reason to expect that that timing is going to be exceptionally accurate.
If anyone has any additional insight or corrections to my understanding, I’m all ears.
