Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bert Kehren via time-nuts]

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 and 
coffee maker  after 3 days. Lab lost out. Yes holdover when disconnecting 
antennas for lab  work and modifications. Did in no way help. Ambient 
temperature a 
much bigger  problem.
In my humble opinion holdover is for commercial applications, it would be  
nice if we would spend more time discussing how to improve commercial 
products  not intended for time-nuts application. Lot of room for improvement.
Bert Kehren
 
 
In a message dated 10/26/2017 5:23:39 P.M. Eastern Daylight Time,  
aph...@comcast.net writes:

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 one  cycle if the amplitude of the 
Cesium that was acting as the reference  changed or the zero crossing 
(10 MHZ) was a few nanoseconds out of spec  relative to the other two 
Cesiums. Nowadays they create ensembles of  Cesiums and use them to 

steer their timing systems while the Cesiums  are steered by GPS.
Sophisticated Kalman filters are used to steer the  signals based on 
the properties of the signal sources.

The  Microsemi 4145 Ultraclean Oscillator is designed for 
catastrophic signal  loss and freezes the DAC that controls the BVA 
oscillator. This works well  because even the DAC is ovenized. It 
will also go into holdover if the  input reference drifts too quickly.

It is pretty easy to make a simple  temperature controlled box to 
house your temperature sensitive references.  Just provide lots of 
insulation and control it at a temperature higher  than your highest 
expected ambient.

I never measured the  temperature of oscillators and used the 
information to compensate holdover  but it makes sense with a 
specific oscillator and enough run time to  collect the data
to categorize the oscillator for temperature and ageing.  This is 
easier to accomplish when the DAC is is directly controlling the  
oscillator. Since I prefer analog control loops, it could also be 
done  when the analog loop controls the oscillator if the DAC tracks 
the analog  loop control voltage. A comparator compares the DAC 
output to the analog  loop voltage. The DAC is adjusted to track and 
thereby characterized so  that it can be set to the correct value 
when switched to holdover. As Bob  pointed out this may or may not be 
the last value of the DAC depending on  the mode of failure of the 
reference signal.

As Bob points out,  there are very sophisticated ways of doing 
temperature compensation today.  As an example of his point, I was 
told that the Microsemi CSAC (chip-scale  atomic clock) uses 
temperature compensation at many places in the design  to achieve its 
performance specs. I imagine that is the current ultimate  in 
temperature compensation for commercial products!

Bob  M


On 10/26/2017 8:33 AM, Bob kb8tq wrote:
> 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 “learn” temperature or aging. That gets fed into  the 
DAC when in holdover.
> The value of this depends a lot on the  quality of the training process. 
Separating this and that
> input to get  a good value for a specific parameter is rarely done with 
good accuracy. The  exception
> to that rule are oscillators that have a large TC or a very  high drift 
rate. In most cases those are not
> the ones you pick for a  GPSDO.
> 
> Bob
> 
>> On Oct 25, 2017, at 7:46 PM,  Bob Martin   wrote:
>>
>>   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 the control voltage  (output frequency).
>> I've used both methods and prefer the  latter.
>>
>> Bob M
>>
>> On 10/25/2017  5: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 happen.   
It pretty  much did what I expected... chaos...   the time-nut equivalent of 
a  naughty schoolboy putting a microphone up to the speaker of the public 
address  system.  I't's a tough job, but somebody gotta do it   ;-)
   No, not really. The rubidium would be the  real 

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob Martin]

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 one cycle if the amplitude of the 
Cesium that was acting as the reference changed or the zero crossing 
(10 MHZ) was a few nanoseconds out of spec relative to the other two 
Cesiums. Nowadays they create ensembles of Cesiums and use them to 
steer their timing systems while the Cesiums are steered by GPS.
Sophisticated Kalman filters are used to steer the signals based on 
the properties of the signal sources.


The Microsemi 4145 Ultraclean Oscillator is designed for 
catastrophic signal loss and freezes the DAC that controls the BVA 
oscillator. This works well because even the DAC is ovenized. It 
will also go into holdover if the input reference drifts too quickly.


It is pretty easy to make a simple temperature controlled box to 
house your temperature sensitive references. Just provide lots of 
insulation and control it at a temperature higher than your highest 
expected ambient.


I never measured the temperature of oscillators and used the 
information to compensate holdover but it makes sense with a 
specific oscillator and enough run time to collect the data
to categorize the oscillator for temperature and ageing. This is 
easier to accomplish when the DAC is is directly controlling the 
oscillator. Since I prefer analog control loops, it could also be 
done when the analog loop controls the oscillator if the DAC tracks 
the analog loop control voltage. A comparator compares the DAC 
output to the analog loop voltage. The DAC is adjusted to track and 
thereby characterized so that it can be set to the correct value 
when switched to holdover. As Bob pointed out this may or may not be 
the last value of the DAC depending on the mode of failure of the 
reference signal.


As Bob points out, there are very sophisticated ways of doing 
temperature compensation today. As an example of his point, I was 
told that the Microsemi CSAC (chip-scale atomic clock) uses 
temperature compensation at many places in the design to achieve its 
performance specs. I imagine that is the current ultimate in 
temperature compensation for commercial products!


Bob M


On 10/26/2017 8:33 AM, Bob kb8tq wrote:

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 “learn” temperature or aging. That gets fed into the DAC 
when in holdover.
The value of this depends a lot on the quality of the training process. 
Separating this and that
input to get a good value for a specific parameter is rarely done with good 
accuracy. The exception
to that rule are oscillators that have a large TC or a very high drift rate. In 
most cases those are not
the ones you pick for a GPSDO.

Bob


On Oct 25, 2017, at 7:46 PM, Bob Martin  wrote:

  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 the control voltage (output frequency).
I've used both methods and prefer the latter.

Bob M

On 10/25/2017 5: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 happen.   It pretty 
much did what I expected... chaos...   the time-nut equivalent of a naughty 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)

  No, not really. The rubidium would be the real hold-over clock.

Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the 
"holdover" state.  It's sort of like a GPSDO holdover state.  Their discipline 
firmware does let you set the time constant and damping values.  I tried a little playing 
around with them, but never found any settings that worked consistently well with the 
LEA-5T.
___
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.

___
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.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to 

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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 for a couple of 
weeks, 
why bother? The delta is small and it may not be quite the same yesterday as it 
is today. 
Guessing it based on the sort of data you have is worse than guessing tempco. 

This all *assumes* you are chasing the aging and tempco of the OCXO. If your
electronics contribute a lot of error (as some do), they may need the help. 

Bob


> On Oct 26, 2017, at 1:28 PM, Mark Sims  wrote:
> 
> Many years ago I  tried to add some code to Lady Heather to calculate the 
> tempco and aging of the oscillator in a normally running Tbolt.   Although 
> the equations would theoretically work (using SVD decomposition) it seldom 
> worked properly.   Failure seemed to be caused by noise in the small numbers 
> involved.   I wound up adding code that could do it by disabling disciplining 
> to get aging and varying the temperature to get tempco.
> 
> --
> 
>> Separating this and that input to get a good value for a specific parameter 
>> is rarely done with good accuracy
> ___
> 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.

___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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 “learn” temperature or aging. That gets fed into the DAC 
when in holdover.
The value of this depends a lot on the quality of the training process. 
Separating this and that
input to get a good value for a specific parameter is rarely done with good 
accuracy. The exception
to that rule are oscillators that have a large TC or a very high drift rate. In 
most cases those are not
the ones you pick for a GPSDO. 

Bob

> On Oct 25, 2017, at 7:46 PM, Bob Martin  wrote:
> 
>  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 the control voltage (output frequency).
> I've used both methods and prefer the latter.
> 
> Bob M
> 
> On 10/25/2017 5: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 happen.   It 
>> pretty much did what I expected... chaos...   the time-nut equivalent of a 
>> naughty schoolboy putting a microphone up to the speaker of the public 
>> address system.  I't's a tough job, but somebody gotta do it  ;-)
>>>  No, not really. The rubidium would be the real hold-over clock.
>> Symmetricom calls the disciplining state where it can't lock to the 1PPS 
>> signal the "holdover" state.  It's sort of like a GPSDO holdover state.  
>> Their discipline firmware does let you set the time constant and damping 
>> values.  I tried a little playing around with them, but never found any 
>> settings that worked consistently well with the LEA-5T.
>> ___
>> 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.
> ___
> 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.

___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob Martin]

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 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 the control voltage (output frequency).

I've used both methods and prefer the latter.

Bob M

On 10/25/2017 5: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 
happen.   It pretty much did what I expected... chaos...   the 
time-nut equivalent of a naughty schoolboy putting a microphone up 
to the speaker of the public address system.  I't's a tough job, 
but somebody gotta do it  ;-)




  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to 
the 1PPS signal the "holdover" state.  It's sort of like a GPSDO 
holdover state.  Their discipline firmware does let you set the 
time constant and damping values.  I tried a little playing around 
with them, but never found any settings that worked consistently 
well with the LEA-5T.

___
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.


___
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.


___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob Martin]

  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 the control voltage (output frequency).

I've used both methods and prefer the latter.

Bob M

On 10/25/2017 5: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 happen.   It pretty 
much did what I expected... chaos...   the time-nut equivalent of a naughty 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)



  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the 
"holdover" state.  It's sort of like a GPSDO holdover state.  Their discipline 
firmware does let you set the time constant and damping values.  I tried a little playing 
around with them, but never found any settings that worked consistently well with the 
LEA-5T.
___
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.


___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Dana Whitlow]

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 happen.   It
> pretty much did what I expected... chaos...   the time-nut equivalent of a
> naughty schoolboy putting a microphone up to the speaker of the public
> address system.  I't's a tough job, but somebody gotta do it  ;-)
>
>
> >  No, not really. The rubidium would be the real hold-over clock.
>
> Symmetricom calls the disciplining state where it can't lock to the 1PPS
> signal the "holdover" state.  It's sort of like a GPSDO holdover state.
> Their discipline firmware does let you set the time constant and damping
> values.  I tried a little playing around with them, but never found any
> settings that worked consistently well with the LEA-5T.
> ___
> 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.
>
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

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 
schoolboy putting a microphone up to the speaker of the public address system.  
I't's a tough job, but somebody gotta do it  ;-)


In the music world, some really like caotic oscillators.
You just built a very expensive one. :)0


  No, not really. The rubidium would be the real hold-over clock.


Symmetricom calls the disciplining state where it can't lock to the 1PPS signal the 
"holdover" state.  It's sort of like a GPSDO holdover state.  Their discipline 
firmware does let you set the time constant and damping values.  I tried a little playing 
around with them, but never found any settings that worked consistently well with the 
LEA-5T.


Well, holdover is the behavior, but a typical design can have several 
states which is deemed as hold-over. Everything else than tracking is 
holdover.


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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

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 “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 include noise on the reference
signal or odd perturbations in the reference.

Bob


On Oct 24, 2017, at 6:42 PM, 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 was in charge.I need to try it again now that I have my X72 
interface boards back from China and can properly connect to the X72.

BTW, the firmware based disciplining on the X72 seems to be rather crappy.  It 
has lots of trouble locking to less than perfect 1PPS inputs.   For instance it 
goes into holdover mode over half the time when driven by a Ublox LEA-5T (which 
seems to have like +/- 60 ns jitter on the 1PPS.   It does lock fine with a 
Tbolt...  but needing a GPSDO to discipline a rubidium sort of defeats the 
purpose of disciplining a rubidium.

Lady Heather now has an X72/SA22 disciplining routine built in that works 
fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
seconds and the 1PPS output is in the +/- 50 ns range.
___
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.


___
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.


___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

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 clock-mode, you might or might not experience 
clock-reset events. Typically 1 ms shifts of clock time. One needs to 
handle that in case you are not able to drive the clock quick enough 
towards on average be where the GPS/UTC average solution drives it to.


Anyway, so there is a different clock message, just don't recall it from 
the top of my head. I just recall that the Novatels is fairly generous 
with this data


Cheers,
Magnus

On 10/25/2017 06:14 AM, Ole Petter Ronningen wrote:
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 disciplining with PPS, something like a UBlox would be better as far 
as I can tell.


The other option is to log the #RANGE-message from the Novatel, convert 
to RINEX and solve with PPP, and use the output of that to adjust the 
rubidium. The added benefit is that you'll have an excellent log of what 
your reference is doing if you get odd results in some measurements.


Ole

On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson 
> wrote:


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 10/25/2017 12:17 AM, Skip Withrow wrote:

Hello time-nuts,

I've been thinking about a GPS receiver experiment and just
wondering
if there are any opinions or prior experience that might save me
a lot
of time.

What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS
even has
settings for OCXO/rubidium/cesium dynamics.

Then, (and here is the unknown part) what if the GPS receiver
1pps is
used to discipline the rubidium?  This basically forms a feedback
loop, so could either hurt or help - depending.  Supposedly the
better
oscillator would give a better GPS solution.  And the better
solution
(1pps) should provide a better oscillator frequency.

We know that GPS receivers using asynchronous clocks have 1pps
errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the
oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?

Comments appreciated.

Regards,
Skip Withrow
___
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.

___
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.



___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

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 was in charge.I need to try it again now that I have my X72 
interface boards back from China and can properly connect to the X72.


No, you set up an oscillator so that is why you have that problem.

Each rubidium has an integrator and each PI loop adds another, and now 
that you wire the feedback over them you have an unbalanced 4 pole 
system. Already a third degree system is somewhat of a challenge to keep 
stable, so fourth degree... sure, it can be done, but not that way.


I have been looking at mutual synchronization and there is some 
classical articles on it and recently some work have been done too.


A good mutual synchronization means that you find your aggregate clock 
to be at the middle frequency and phase of the two separate clocks. This 
also means that you want to drive your clocks towards each other, so one 
is to raise frequency and the other lower frequenncy. For un-equal clock 
EFCs, you need to scale the driving force accordingly. For more fancy 
setups of weighted clocks, you need to apply correct weights so that the 
better clock moves less than the clock being worse.


Another factor of the control is that delay needs to be compensated for, 
and this have already been analyzed in the classical mutual clock setup, 
but also exists in modern setups, and I happen to touch on that subject 
in an article, since the delay margin, which is just a different version 
of phase margin, needs to be adapted in accordance with the control loop 
bandwidth. With the right key-words you can find out more. I did that 
work on automatic power-grid stabilization and it was kind of 
interesting to forge an analysis out of three independent 
research-fields, so I found myself instructing a PhD student how she 
would drive here simulations into self-oscillation... and they sure did 
and we learned stuff. Ah well.


Anyway, mutual synchronization require some thought, but ends up not 
being all that different in the end.



BTW, the firmware based disciplining on the X72 seems to be rather crappy.  It 
has lots of trouble locking to less than perfect 1PPS inputs.   For instance it 
goes into holdover mode over half the time when driven by a Ublox LEA-5T (which 
seems to have like +/- 60 ns jitter on the 1PPS.   It does lock fine with a 
Tbolt...  but needing a GPSDO to discipline a rubidium sort of defeats the 
purpose of disciplining a rubidium.


No, not really. The rubidium would be the real hold-over clock.


Lady Heather now has an X72/SA22 disciplining routine built in that works 
fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
seconds and the 1PPS output is in the +/- 50 ns range.


Cool.

Cheers,
Magnusu
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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 include noise on the reference
signal or odd perturbations in the reference. 

Bob

> On Oct 24, 2017, at 6:42 PM, 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 was in charge.I need to try it again now that I have my 
> X72 interface boards back from China and can properly connect to the X72.
> 
> BTW, the firmware based disciplining on the X72 seems to be rather crappy.  
> It has lots of trouble locking to less than perfect 1PPS inputs.   For 
> instance it goes into holdover mode over half the time when driven by a Ublox 
> LEA-5T (which seems to have like +/- 60 ns jitter on the 1PPS.   It does lock 
> fine with a Tbolt...  but needing a GPSDO to discipline a rubidium sort of 
> defeats the purpose of disciplining a rubidium.
> 
> Lady Heather now has an X72/SA22 disciplining routine built in that works 
> fairly well using the LEA-5T.  Adevs are in the mid E-13 range at 10,000 
> seconds and the 1PPS output is in the +/- 50 ns range.  
> ___
> 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.

___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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 lab full of millions of dollars of 
gear. You
will need something to compare to and good logs of what goes in, what comes out,
and as much of the intermediates as you can stand to look at.

Bob

> On Oct 25, 2017, at 12:14 AM, Ole Petter Ronningen  
> wrote:
> 
> 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
> disciplining with PPS, something like a UBlox would be better as far as I
> can tell.
> 
> The other option is to log the #RANGE-message from the Novatel, convert to
> RINEX and solve with PPP, and use the output of that to adjust the
> rubidium. The added benefit is that you'll have an excellent log of what
> your reference is doing if you get odd results in some measurements.
> 
> Ole
> 
> On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
> mag...@rubidium.dyndns.org> wrote:
> 
>> 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 10/25/2017 12:17 AM, Skip Withrow wrote:
>> 
>>> Hello time-nuts,
>>> 
>>> I've been thinking about a GPS receiver experiment and just wondering
>>> if there are any opinions or prior experience that might save me a lot
>>> of time.
>>> 
>>> What I have been thinking about doing is taking a GPS receiver
>>> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10
>>> MHz) and driving it with a rubidium oscillator (that has 1pps
>>> disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
>>> settings for OCXO/rubidium/cesium dynamics.
>>> 
>>> Then, (and here is the unknown part) what if the GPS receiver 1pps is
>>> used to discipline the rubidium?  This basically forms a feedback
>>> loop, so could either hurt or help - depending.  Supposedly the better
>>> oscillator would give a better GPS solution.  And the better solution
>>> (1pps) should provide a better oscillator frequency.
>>> 
>>> We know that GPS receivers using asynchronous clocks have 1pps errors
>>> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
>>> on 10MHz and disciplined will the 1pps error be reduced such as the
>>> Thunderbolt?
>>> 
>>> Comments appreciated.
>>> 
>>> Regards,
>>> Skip Withrow
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>>> ailman/listinfo/time-nuts
>>> and follow the instructions there.
>>> 
>>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> 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.

___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Ole Petter Ronningen]

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
disciplining with PPS, something like a UBlox would be better as far as I
can tell.

The other option is to log the #RANGE-message from the Novatel, convert to
RINEX and solve with PPP, and use the output of that to adjust the
rubidium. The added benefit is that you'll have an excellent log of what
your reference is doing if you get odd results in some measurements.

Ole

On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:

> 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 10/25/2017 12:17 AM, Skip Withrow wrote:
>
>> Hello time-nuts,
>>
>> I've been thinking about a GPS receiver experiment and just wondering
>> if there are any opinions or prior experience that might save me a lot
>> of time.
>>
>> What I have been thinking about doing is taking a GPS receiver
>> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10
>> MHz) and driving it with a rubidium oscillator (that has 1pps
>> disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
>> settings for OCXO/rubidium/cesium dynamics.
>>
>> Then, (and here is the unknown part) what if the GPS receiver 1pps is
>> used to discipline the rubidium?  This basically forms a feedback
>> loop, so could either hurt or help - depending.  Supposedly the better
>> oscillator would give a better GPS solution.  And the better solution
>> (1pps) should provide a better oscillator frequency.
>>
>> We know that GPS receivers using asynchronous clocks have 1pps errors
>> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
>> on 10MHz and disciplined will the 1pps error be reduced such as the
>> Thunderbolt?
>>
>> Comments appreciated.
>>
>> Regards,
>> Skip Withrow
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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 response, you have *lots* 
of time to do the 
math. Updates every minute are probably overkill. Since the math can take a 
long time, the CPU
requirements aren’t very crazy. Equally, you can use a PC and get the job done. 
OS overhead 
likely isn’t going to be a big deal. 

You can separate out the math and run it at a pretty high level. Tweaking this 
or that would all 
be done in a high level language. No need for going crazy with assembler The 
loop is likely to 
be a “step and wait” sort of thing. There will be a bit of tweaking. Doing that 
in something easy
to use *is* an advantage. Having it buried in some mystery firmware written by 
who knows who
is not a good thing in this case. 

Bob


> On Oct 24, 2017, at 7:09 PM, Dana Whitlow  wrote:
> 
> 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 to, the error of the internal (or in this case, the
> external) clock
> oscillator.  If I'm right about its being proportional, then it seems to me
> that having
> the GPS's clock oscillator right on would freeze the PPS error at some
> fixed value,
> not necessarily zero.  If true, you'd experience a constant bias error to
> the timing of
> the PPS pulses.
> 
> Now you would seem to be in the perfect position to refute or verify my
> thinking,
> provided you have the means to vary an external clock's frequency in a
> controlled
> way, by watching how the PPS error behavior changes as a function of the
> clock
> frequency.
> 
> If you manage to try the experiment, I'd greatly appreciate hearing the
> outcome.
> 
> DanaK8YUM
> 
> 
> On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow 
> wrote:
> 
>> Hello time-nuts,
>> 
>> I've been thinking about a GPS receiver experiment and just wondering
>> if there are any opinions or prior experience that might save me a lot
>> of time.
>> 
>> What I have been thinking about doing is taking a GPS receiver
>> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10
>> MHz) and driving it with a rubidium oscillator (that has 1pps
>> disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
>> settings for OCXO/rubidium/cesium dynamics.
>> 
>> Then, (and here is the unknown part) what if the GPS receiver 1pps is
>> used to discipline the rubidium?  This basically forms a feedback
>> loop, so could either hurt or help - depending.  Supposedly the better
>> oscillator would give a better GPS solution.  And the better solution
>> (1pps) should provide a better oscillator frequency.
>> 
>> We know that GPS receivers using asynchronous clocks have 1pps errors
>> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
>> on 10MHz and disciplined will the 1pps error be reduced such as the
>> Thunderbolt?
>> 
>> Comments appreciated.
>> 
>> Regards,
>> Skip Withrow
>> ___
>> 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.
>> 
> ___
> 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.

___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Dana Whitlow]

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 to, the error of the internal (or in this case, the
external) clock
oscillator.  If I'm right about its being proportional, then it seems to me
that having
the GPS's clock oscillator right on would freeze the PPS error at some
fixed value,
not necessarily zero.  If true, you'd experience a constant bias error to
the timing of
the PPS pulses.

Now you would seem to be in the perfect position to refute or verify my
thinking,
provided you have the means to vary an external clock's frequency in a
controlled
way, by watching how the PPS error behavior changes as a function of the
clock
frequency.

If you manage to try the experiment, I'd greatly appreciate hearing the
outcome.

DanaK8YUM


On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow 
wrote:

> Hello time-nuts,
>
> I've been thinking about a GPS receiver experiment and just wondering
> if there are any opinions or prior experience that might save me a lot
> of time.
>
> What I have been thinking about doing is taking a GPS receiver
> (Novatel OEM4-G2) that has provisions for an external clock (5 or 10
> MHz) and driving it with a rubidium oscillator (that has 1pps
> disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
> settings for OCXO/rubidium/cesium dynamics.
>
> Then, (and here is the unknown part) what if the GPS receiver 1pps is
> used to discipline the rubidium?  This basically forms a feedback
> loop, so could either hurt or help - depending.  Supposedly the better
> oscillator would give a better GPS solution.  And the better solution
> (1pps) should provide a better oscillator frequency.
>
> We know that GPS receivers using asynchronous clocks have 1pps errors
> and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
> on 10MHz and disciplined will the 1pps error be reduced such as the
> Thunderbolt?
>
> Comments appreciated.
>
> Regards,
> Skip Withrow
> ___
> 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.
>
___
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.

Re: [time-nuts] I've been thinking about a GPS receiver experiment

[Magnus Danielson]

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 10/25/2017 12:17 AM, Skip Withrow wrote:

Hello time-nuts,

I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.

What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10).  The GPS even has
settings for OCXO/rubidium/cesium dynamics.

Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium?  This basically forms a feedback
loop, so could either hurt or help - depending.  Supposedly the better
oscillator would give a better GPS solution.  And the better solution
(1pps) should provide a better oscillator frequency.

We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?

Comments appreciated.

Regards,
Skip Withrow
___
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.


___
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.