Living in south Florida I have been through 8 hurricanes and uncountable
thunderstorms, while being a time-nut. At no time a hold over, because of
excellent power backup. Once a controlled power shut down in Miami because I
had to make a choice between window Air conditioner, refrigerators
Terrific points. There are so many levels of sophistication.
My own experience is with catastrophic signal loss on the reference.
Determining degradation on your primary reference can present
challenges. I once designed a device that compared three Cesiums
and switched the reference within
Hi
You get into all sorts of issues trying to estimate tempco. You have time lags
and gradients that make it a very messy process. Toss in measurement based on
small range temperature swings (like from a HVAC system) …. it’s a mess.
If the OCXO is a typical modern part and it’s been on power
Hi
Most GPSDO’s do some sort of “slew” to an average DAC value when they go into
holdover.
Freezing at the last value is not (in general) a good idea. Often things
degrade before there
is a dropout. Your final DAC value may not be a good one to maximize holdover
duration.
Some setups try to
Sorry, my mistake, change that to the former! I have used DACs that
were monotonic with decent results but prefer analog loops when the
time constants are short enough.
Bob M
On 10/25/2017 5:46 PM, Bob Martin wrote:
The holdover state is a DAC set to the last value of the analog
control
The holdover state is a DAC set to the last value of the analog
control voltage that adjusts the oscillator frequency. Some designs
use an analog control loop and switch the DAC into the control loop.
Others use the DAC to set the control voltage at all times. This can
result in a steps in
What "naughty schoolboy"? How else is one supposed to learn feedback
theory?
Dana
On Wed, Oct 25, 2017 at 6:30 PM, Mark Sims wrote:
> > No, you set up an oscillator so that is why you have that problem.
>
> I hooked the two rubidiums together just to see what would
Hi naugthy schoolboy Mark,
On 10/26/2017 01:30 AM, Mark Sims wrote:
No, you set up an oscillator so that is why you have that problem.
I hooked the two rubidiums together just to see what would happen. It pretty
much did what I expected... chaos... the time-nut equivalent of a naughty
Hi Bob,
Well, the PRC-10 actually have additional provisions to help it do well
on GPS as signal, and is used by severals to do exactly that.
Cheers,
Magnus
On 10/25/2017 09:26 PM, Bob kb8tq wrote:
Hi
Everybody I have ever talked to about the internal disciplining on Rb’s comes
up with
Hei Ole Petter,
You don't want to look at the PPS in that case.
You want to look at how the receivers clock solution pans out.
Since the receivers clock is set but then ticks to the speed of the
rubidium, you now got a high resolution frequency and phase comparison.
Depending on the
Hi Mark,
On 10/25/2017 12:42 AM, Mark Sims wrote:
I did a quick silly experiment where I took a PRS-10 disciplined by an X72
which was disciplined by the PRS-10. The result seemed to have created a
rupture in the space-time continuum. Nobody was happy... they didn't seem to
agree on who
Hi
Everybody I have ever talked to about the internal disciplining on Rb’s comes
up with “it’s not for a GPSDO” somewhere in the first minute of the
conversation.
The objective seems to be to tune the unit to a perfect source to speed up the
calibration process. The idea never appears to
Hi
Since you are doing a loop design that involves “months long” data runs, having
good logging and monitoring is a key part of the process. Without the testing
side
of the process you are pretty much guaranteed to go astray in one way or the
other.
That’s not to say you have to have a giant
I did log the #TIME message for several weeks on an OEMV-3 a while back.
The results were a bit suspicious, so I checked with Novatel support -
turns out the PPS on the OEMV (and I presume that also holds for OEM4) is
derived from L1 only - and the jitter is nothing to brag about. So for
Hi
The “best” approach would be to use a receiver that reports what’s going on to
some pretty
good resolution (say picoseconds). You also measure the pps offset (say to
picoseconds).
Then you feed *both* numbers into a software loop.
Since you are after a loop with a “many days” sort of
Hello Skip,
I have a theory, but it will be interesting to see what others say.
Assuming that the
1 PPS error to which you refer is the so-called "sawtooth" error, I've come
to suspect
that the rate at which the individual PPS pulses walk across the sawtooth
is related to,
and likely proportional
Skip,
I would rather use the rich Novatel reports and read out the time error
and use that as your phase detector, then the normal PI-loop stuff with
an optional low-pass to add and then use that to steer the rubidium.
It's one of those, when I get time, projects.
Cheers,
Magnus
On
17 matches
Mail list logo