Warrenm
tvb posted
Were you able to test how quickly, or how well, the filter learned the
tempco of the OCXO?
Only at a couple of very general data points.
Using a very Bad unit, the Kalman filter had an effect, although not very
good in under 1/2 day.
After a week or so on a good
Hi Michael,
Nice, clean plots. Thanks for sharing.
Ah, but does correlation imply causation? Note that crystal resonators, even
inside an oven, are also sensitive ambient temperature sensors. As temperature
changes the OCXO drifts off-frequency -- the TBolt then sees the average PPSns
diverge
Hi all,
if I will use a dual mixer TI meter, suppose to have :
LO 5.000.005 Hz
Ref and Ftest 5 MHz
IF= 5Hz
how do I have to setup Timelab for acquisition?
Sampling interval =
Input frequency =
Scale factor =
Thanks all,
Luciano
timeok
Hi
The later TBolt OCXO's have temperature performance similar to an HP10811.
Bob
-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Mark Sims
Sent: Tuesday, December 11, 2012 9:36 PM
To: time-nuts@febo.com
Subject: [time-nuts]
Racal 1992 GPIB, to Chuck Forsberg:
thank you, I will go to see your work.
A little update, after about 20 hours this
is the logging situation:
http://www.flickr.com/photos/14336723@N08/8267828444/
Not bad, seem the GPS chipset jitter claim
of 10nS is real, what do you think.
Could this unit be
Hi
20 hours should be 20*60*60 = 72000 samples. The graphs appear to show about
17,000 samples.
If the results do cover a 20 hour period and do not have drift removed,
that's a good FE5680. 1.4x10^-14 is an amazing number for one of those.
Bob
-Original Message-
From:
Bob Camp li...@rtty.us ha scritto:
Hi
20 hours should be 20*60*60 = 72000 samples. The graphs appear to show about
17,000 samples.
Hello Bob,
unfortunately I'm not logging all the pps
samples, I'm picking one sample every about
4 pulses, because I'm triggering the counter
and waiting 4s
Hi
Ok, so the data is already decimated and it does show a 20 hour period.
The way I'm reading things - the pps's start out at zero offset on the left
side (yellow line at about sample 350). They still are at roughly zero
offset on the right side (at about sample 17045). Total peak to peak in
Bob Camp li...@rtty.us ha scritto:
Hi
Ok, so the data is already decimated and it does show a 20 hour period.
Yes
The way I'm reading things - the pps's start out at zero offset on the left
side (yellow line at about sample 350). They still are at roughly zero
offset on the right side (at
Hi
If you are driving the counter's frequency standard input with the FE5680
and simply measuring the period of the GPS output, then the data would make
sense.
I am assuming that the counter starts counting on the pps out of the FE5680
and stops counting on the pps out of the GPS. That way
Bob Camp li...@rtty.us ha scritto:
Hi
If you are driving the counter's frequency standard input with the FE5680
and simply measuring the period of the GPS output, then the data would make
sense.
Bob, the data make sense :)
I'm using the FE5680 as ext standard for
the counter, the pps is
Hi
Yes, I would run the FE5680 into the counter's frequency standard input.
For the real data, you can set up the counter to start on the GPS pps and
stop on the 10 MHz output from the FE5680. You will only have 100 ns of
range. You can unscramble the data after the fact. If you don't want to
Hey time-legumes, I figured a few of you all might be interested in some of the
work that the team and I have been doing. We recently acquired a couple of
RaspberryPis, and out of curiosity, we wanted to see how well our RADclock
software performs on this small platform. Anyways, our dive into
Matt,
On 12/12/2012 10:23 PM, Matt Davis wrote:
Hey time-legumes, I figured a few of you all might be interested in some of the
work that the team and I have been doing. We recently acquired a couple of
RaspberryPis, and out of curiosity, we wanted to see how well our RADclock
software
Thanks Bob, the next logging session will
be setup as per your suggestion.
Now I'm logging with the counter
in time interval, Rb 1 is the start,
GPS is the stop and Rb2 is the ext
reference. The pulses are 670mS apart now.
Fabio.
Bob Camp li...@rtty.us ha scritto:
Hi
Yes, I would run the
Hi
That approach works well. If you have them about a half second apart I'd stick
with that setup.
Bob
On Dec 12, 2012, at 7:25 PM, Fabio Eboli fabi...@quipo.it wrote:
Thanks Bob, the next logging session will
be setup as per your suggestion.
Now I'm logging with the counter
in time
Matt you have my attention.
I am curious if the RADclock could act as a time server. Already you can
tell I don't know alot. But did skim through some of the RADcloc docs. But
the fact that it could live on a Rasberry Pi makes it really interesting. A
timesource on the wall give it power and
Hi, Luciano --
The sampling interval would be whatever rate the counter is returning
readings, as usual. I usually let the acquisition driver estimate the rate,
unless I know it's exactly one reading per second.
In frequency mode, the scale factor should be 1E-6. You need the program
to treat
Hi Magnus,
From: Magnus Danielson mag...@rubidium.dyndns.org
Matt,
On 12/12/2012 10:23 PM, Matt Davis wrote:
Hey time-legumes, I figured a few of you all might be interested in some of
the
work that the team and I have been doing. We recently acquired a couple of
RaspberryPis, and
19 matches
Mail list logo
