> Based on Tom's post suggesting looking at one day prompted me to look at
> what averaging is needed for one day readings, hence the subject post.
Yeah, the reason I suggested one-day averaging is
that there are a host of effects you notice when you
use short GPS averaging times: sawtooth, jitte
> Averaging improves the measurement proportionally to the square root of
the number of averages. With 100 second averages 2.3E-13 could be seen in
24 hours, and with 10,000 second averaging 2.3E-14 could be seen in one day.
Ah but the square root rule is only true when the
samples are independen
> Very interesting, Bill. Thanks for that info. I'm a bit surprised as I
> would have thought that deriving the 1 PPS from the 10MHz would yield
> the best performance. Of course, this means that using the 1 PPS to
> measure the stability of the 10MHz oscillator isn't correct, so I've
> done
The trouble with averaging GPS 1PPS is that it needs to be done for
multiple of 12h periods to counter the systematic effect of reception
conditions.
I found that simply recording the 1PPS timings and comparing raw
samples with 86400 seconds intervals and _then_ averaging to be
the best strategy.
Group,
What if I use two clocks and a Time Interval counter?
I'd apply the sawtooth 10 MHz output to a decade divider and
feed 1 MHz to a Datum 9300 time code generator. The generator
provides a day-time clock and a 1 PPS output
I'd apply the standard-under-test 10 MHz output to an identical
div
Brooke Clarke wrote:
Hi John:
But the data does not include the variation we get because of the
sawtooth error in the Motorola GPS receivers. I'm using an old 8
channel UT+ timing receiver with the asymmetrical sawtooth error.
Maybe if I get one of the newer M12+Timing receivers and correct t
Hi John:
But the data does not include the variation we get because of the
sawtooth error in the Motorola GPS receivers. I'm using an old 8
channel UT+ timing receiver with the asymmetrical sawtooth error. Maybe
if I get one of the newer M12+Timing receivers and correct the sawtooth
either i
Hi Brooke --
As you well know, I'm still learning my way around this stuff. I've
done plots of a standard vs. raw GPS using anything from 100 second to
3600 second (1 hour) averages. Recently, Tom suggested reducing data to
1 day when looking at the Cesium offset.
Recently someone gave a link
Hi:
Is this line of reasoning correct?
When I average the raw GPS 1 PPS using 100 to 1,000 pulses and look at the
standard deviation (assuming everything else is OK) it's in the mid 30 ns area.
So when the time interval between a single raw GPS 1 PPS and a perfect clock is
measured the expected e
I used Unix between 1983 and 1993, but now it is a withered skill
that is not supported by any Unix operating system. I can download
the .gz files, but I can't open them with WinZip. Is this a version
problem, requiring a newer version of WinZip than 1998? Seems to me
that WinZip could open a tar
Bill Jones, K8CU wrote:
John,
On the Z3801A the 1 PPS from the Motorola GPS receiver is sent to pin 82 of
the CPU (U32). From there, the Z3801A 1 PPS output is sourced from the CPU
on pin 78 and eventually drives the output line driver at U6.
The 1 PPS is definitely not simply divided from the 10 M
John,
On the Z3801A the 1 PPS from the Motorola GPS receiver is sent to pin 82 of
the CPU (U32). From there, the Z3801A 1 PPS output is sourced from the CPU
on pin 78 and eventually drives the output line driver at U6.
The 1 PPS is definitely not simply divided from the 10 MHz oscillator
output.
I asked myself that question the other day and decided to see whether
the 1pps was simply divided from the 10MHz frequency, or whether it was
actively stepped. So, I started an experiment with the time interval
counter to compare the 1 PPS output* with a 1 PPS signal from an
external divider o
13 matches
Mail list logo
