Re: [time-nuts] ensemble oscillators for better stability

[Hal Murray]

i...@blackmountainforge.com said:
> I know that this is not germane but I keep thinking of this video:
> http://www.youtube.com/watch?v=kqFc4wriBvE
> 32 mechanical metronomes on a moveable floor. They all sync up in a bit more
> than two minutes. 

Neat.  Thanks.

The Tuxedo Park book reported that Loomis had 3 Shortt clocks setup in a 
basement lab carved out of bedrock.

They would get locked unless they were swinging 60 degrees to each other.

-- 
These are my opinions.  I hate spam.




___
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] ensemble oscillators for better stability

[Tom Knox]

I think the key is to always obtain the best oscillator/s possible. 
Combining oscillator for lower Phase Noise does work but with 
diminishing returns. If I am not mistaken 2 perfectly matched phase 
locked oscillators can theoretically lower Phase Noise 3dB, four can 
lower Phase Noise another 3dB etc. Dual oscillators in Cross Correlated 
measurements will also produce a 3dB theoretical reduction in a Phase 
Noise measurement system.

Thomas Knox



> Date: Sat, 29 Dec 2012 23:33:52 +0100
> From: mag...@rubidium.dyndns.org
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] ensemble oscillators for better stability
> 
> Tom,
> 
> On 29/12/12 18:11, Tom Van Baak wrote:
> > Corby,
> >
> > So that's an interesting experiment. I think the key is keeping them
> > in tight phase so that what you gain in combined performance is still
> > better than what you lose with the additional mixing electronics.
> 
> If you just mixup, then you do not need to lock them up. You only need 
> that if you add them up in a power-combiner.
> 
> > A couple of comments that come to mind.
> >
> > 1) This was a topic some years back -- for internal use, hp tightly
> >combined multiple 10811 oscillators so that the net phase noise or
> >short-term performance was significantly better than any one of the
> >constituent oscillators.
> 
> Care to share a reference on that? It would be interesting to see how 
> they did it and how well they where doing it.
> 
> > 2) It would be nice to be able to extend this to more than 2
> >oscillators, in such a way that you gain by sqrt(N) without
> >corresponding losses due to increased noise.
> 
> Using the mix-up strategy would be possible. Also, for three sources you 
> would get back to your starting frequency easily on the second mixer. A 
> mix-up strategy would allow to mix 5 and 10 MHz sources, but 
> unfortunately that would give the 10 MHz sources twice the weight of 5 
> MHz sources. The free-running measure and locked additive strategies 
> does not have that drawback.
> 
> > 3) You already realize that being able to keep coherence between the
> >standards as long as possible is highly desirable.
> 
> It depends on what strategy you try to achieve.
> 
> > 4) Consider that none of the UTC(k) timing labs use your technique.
> >The reason is that it's far easier to compare N frequency
> >standards in near-realtime (like every second or every 100 s,
> >etc.) combining the measurement *numbers* than it is to combine
> >the actual *electrons* coming out of the frequency standards in
> >realtime.
> 
> Also, they do not need the high-frequency phase noise benefit. If they 
> need low phase-noise, an active H-maser is used.
> 
> Another benefit of not locking the standards is that you can observe 
> them undisturbed by a control-loop, which make things easier for what 
> they try to achieve.
> 
> > So this is one reason why I keep encouraging those of you building
> > amateur, inexpensive, high-resolution, multi-port phase comparators.
> 
> It is indeed an interesting thing do to. To benefit it needs to have 
> many channels, say 8 or so. Preferably expandable further as you have 
> more sources to look at and form an ensemble of.
> 
> > If you had a couple of these comparators you'd simultaneously
> > measure each of your 5065A and perhaps several other standards all
> > using a common reference. It wouldn't really matter which standard
> > was the reference, since the data is all pair-wise relative.
> 
> As you compare many sources, doing M-cornered hat stuff becomes 
> possible, and you can get some confidence in the absolute phase-noise of 
> all involved sources.
> 
> > It's trivial to create an ensemble in software, based on multiple
> > phase measurements that arrive by spi or gpib or rs232. With that
> > calculated mean phase you can then ex post facto apply a correction
> > to each of the oscillators in the ensemble. It's like sawtooth
> > correction; you take the pulse as you see it, but you apply a
> > freshly calculated correction factor.
> 
> A note on ensembles is that NTP actually features ensemble calculations, 
> as it is able to estimate the noise, do weighting of various sources 
> etc. Inspired by the work done at NIST. I'm not completely sure that NTP 
> will work well with unlocked frequency sources, but I mention it so 
> people can look in their NTP books and read up a bit.
> 
> The main point is that the past noise of a source is used to calculate 
> the weight it can have in order to form the optimum stability. This is 
> how the national labs create their time-scales, and then how EAL is 
> built for maximum frequency stability, then being corrected into the TAI 
> for phase stability and then synthesized into UTC to form a stable GMT 
> replacement.
> 
> Once you have started to walk on the ensemble path, you are not that far 
> off from looking at doing a full-blown time-scale.
> 
> Cheers,
> Magnus
> 
> 

Re: [time-nuts] ensemble oscillators for better stability

[DaveH]

I know that this is not germane but I keep thinking of this video:

http://www.youtube.com/watch?v=kqFc4wriBvE

32 mechanical metronomes on a moveable floor. They all sync up in a bit more
than two minutes.

Dave

> -Original Message-
> From: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Saturday, December 29, 2012 20:17
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] ensemble oscillators for better stability
> 
> >> 1) This was a topic some years back -- for internal use, hp tightly
> >>combined multiple 10811 oscillators so that the net 
> phase noise or
> >>short-term performance was significantly better than 
> any one of the
> >>constituent oscillators.
> > 
> > Care to share a reference on that? It would be interesting 
> to see how 
> > they did it and how well they where doing it.
> 
> Magnus,
> 
> Yes, it came up in a long thread called "GPS noise reduction" 
> back in April 2008. I'll mention it again  -- when I visited 
> the HP facility in Santa Clara years ago I saw or was told 
> about a special low noise 10 MHz reference that was used to 
> measure the phase noise of shipping 10811 oscillators. The 
> reference itself was a set of several hand-picked 10811's 
> that were combined in some clever way so that they all 
> steered themselves creating a coherent single output with 
> significantly lower noise than any one individual 10811. I 
> don't have further details but assume the RF and PLL experts 
> here on the list can figure out what is meant by this and 
> propose a paper design. It was probably more than 2 
> oscillators, but I don't remember now if it was 3 or 6 or 
> more. Rick Karlquist may also know about this system; either 
> when/how it was built or what level of performance it delivered.
> 
> /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.


___
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] ensemble oscillators for better stability

[Tom Van Baak]

>> 1) This was a topic some years back -- for internal use, hp tightly
>>combined multiple 10811 oscillators so that the net phase noise or
>>short-term performance was significantly better than any one of the
>>constituent oscillators.
> 
> Care to share a reference on that? It would be interesting to see how 
> they did it and how well they where doing it.

Magnus,

Yes, it came up in a long thread called "GPS noise reduction" back in April 
2008. I'll mention it again  -- when I visited the HP facility in Santa Clara 
years ago I saw or was told about a special low noise 10 MHz reference that was 
used to measure the phase noise of shipping 10811 oscillators. The reference 
itself was a set of several hand-picked 10811's that were combined in some 
clever way so that they all steered themselves creating a coherent single 
output with significantly lower noise than any one individual 10811. I don't 
have further details but assume the RF and PLL experts here on the list can 
figure out what is meant by this and propose a paper design. It was probably 
more than 2 oscillators, but I don't remember now if it was 3 or 6 or more. 
Rick Karlquist may also know about this system; either when/how it was built or 
what level of performance it delivered.

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

Re: [time-nuts] ensemble of standards

[Bob Camp]

Hi

Having written code for a 4K PDP-8, I suspect that more of the heavy lifting 
was hand optimized assembler rather than Fortran. More or less, compile it / it 
doesn't fit / poke into it / fix it / recompile it / poke it some more / give 
up & hand optimize the problem areas.

Bob

On Dec 29, 2012, at 10:32 PM, Magnus Danielson  
wrote:

> On 30/12/12 02:46, cdel...@juno.com wrote:
>> Also about ensembles,
>> 
>> http://www.mksa.deit.univpm.it/biblioteca/sala_tecnica/scaffale_strumenti
>> /Campioni/EPSG070861.pdf
>> 
>> This article describes combining 4 HP 5071A standards.
>> 
>> Description on page 2 and block diagram in figure 2.
>> 
>> Unfortunately no details on the controller are given!
>> 
>> It's what I'd like to do to two or more HP 5065A
>> 
>> Anyone know what they did in the controller?
> 
> I'd assume that this is similar to what is described in Chapter 9 of NBS 
> Monograph 140, by Dr. David Allan and friends:
> 
> http://tf.boulder.nist.gov/general/pdf/194.pdf
> 
> When reading the FORTRAN code, one has to realize that the ER calculations is 
> hard-wired to the way that the NBS setup at the time where done, so that the 
> 8 clocks was compared by a number of pair-wise measures and that the 
> time-differences is combined as needed where some of the clocks becomes 
> transfer standards in the comparison back to the primary reference standard. 
> Clock 3 is the main clock in the hookup.
> 
> A modern view on things is found here:
> http://tf.boulder.nist.gov/general/pdf/816.pdf
> 
> The original time-scale algorithm ran on a PDP-8 machine with 4k word memory, 
> coded in Fortran by Dr. Allan. Today they run using a pair of redundant 386 
> machines and using a blend of Jim Greys buffer and mixers and that of 
> commercial time-interval measurement rig.
> 
> 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.


___
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] ensemble of standards

[Magnus Danielson]

On 30/12/12 02:46, cdel...@juno.com wrote:

Also about ensembles,

http://www.mksa.deit.univpm.it/biblioteca/sala_tecnica/scaffale_strumenti
/Campioni/EPSG070861.pdf

This article describes combining 4 HP 5071A standards.

Description on page 2 and block diagram in figure 2.

Unfortunately no details on the controller are given!

It's what I'd like to do to two or more HP 5065A

Anyone know what they did in the controller?


I'd assume that this is similar to what is described in Chapter 9 of NBS 
Monograph 140, by Dr. David Allan and friends:


http://tf.boulder.nist.gov/general/pdf/194.pdf

When reading the FORTRAN code, one has to realize that the ER 
calculations is hard-wired to the way that the NBS setup at the time 
where done, so that the 8 clocks was compared by a number of pair-wise 
measures and that the time-differences is combined as needed where some 
of the clocks becomes transfer standards in the comparison back to the 
primary reference standard. Clock 3 is the main clock in the hookup.


A modern view on things is found here:
http://tf.boulder.nist.gov/general/pdf/816.pdf

The original time-scale algorithm ran on a PDP-8 machine with 4k word 
memory, coded in Fortran by Dr. Allan. Today they run using a pair of 
redundant 386 machines and using a blend of Jim Greys buffer and mixers 
and that of commercial time-interval measurement rig.


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] Strange GPS behaviour

[Bob Camp]

Hi

The more interesting event is when you re-flash a +/- 1 us navigation receiver 
and it instantly becomes a < +/- 100 ns timing receiver *without* position hold 
engaged.

Bob


On Dec 29, 2012, at 10:20 PM, Said Jackson  wrote:

> Bob,
> 
> Our Position-Hold enabled units (Fury, Mini-JLT, various CSAC units, and 
> GPS-405 support accurate position reporting in ECEF, NMEA, and various other 
> standards.
> 
> Users can select how many fixes are averaged for the position report.
> 
> They can also be instantly switched back and forth between position hold, and 
> mobile mode using simple English SCPI commands. Some of them have built in 3 
> axis accelerometers that allow instant detection of when the vehicle starts 
> moving so it can be switched into mobile mode at that time.
> 
> We recently did a test by putting an antenna in a side window in the office 
> that had maybe 10% view of the sky, then let the unit run in mobile mode 
> while doing the auto survey. After two days, we switched it into position 
> hold mode. Most of the time it sees only one sat direct, all others are only 
> seen through multipath. The results are astonishing, SD went down from about 
> 30ns+ to about 8ns. Spikes to +/-150ns went away completely.
> 
> I can post some GPSCon graphs of this  significant improvement during the 
> test next week if there is interest.
> 
> Bye
> Said
> 
> Sent From iPhone
> 
> On Dec 29, 2012, at 18:56, Bob Camp  wrote:
> 
>> Hi
>> 
>> The interesting thing is that you sometimes can get a position hold receiver 
>> to report it's estimated location…. Not so much on current product, but on 
>> some of the old stuff.
>> 
>> Bob
>> 
>> On Dec 29, 2012, at 9:51 PM, Jim Lux  wrote:
>> 
>>> On 12/29/12 6:34 PM, Bob Camp wrote:
 Hi
 
 The gotcha is that often the "navigation" and "timing" receivers are 
 identical in terms of hardware. There is no upgraded hardware in the 
 timing device.
 
 When you put a receiver into position hold, you are telling it "I don't 
 care about the location solution". It reduces the weight of that part of 
 the filter. Yes, that's only one way to look at it and there are other 
 ways to look at it.
>>> 
>>> 
>>> or, another conceptual model is: I'm fixed, I know where the transmitting 
>>> satellite is, and can calculate range and doppler a priori, so anything 
>>> else must be local clock variation and propagation.  And you can average 
>>> out the propagation among multiple satellites (or use one satellite as your 
>>> timing reference)..
>>> 
>>> Particularly if you are post processing and have precise ephemeris data for 
>>> the satellites
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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.


___
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] Strange GPS behaviour

[Said Jackson]

Bob,

Our Position-Hold enabled units (Fury, Mini-JLT, various CSAC units, and 
GPS-405 support accurate position reporting in ECEF, NMEA, and various other 
standards.

Users can select how many fixes are averaged for the position report.

They can also be instantly switched back and forth between position hold, and 
mobile mode using simple English SCPI commands. Some of them have built in 3 
axis accelerometers that allow instant detection of when the vehicle starts 
moving so it can be switched into mobile mode at that time.

We recently did a test by putting an antenna in a side window in the office 
that had maybe 10% view of the sky, then let the unit run in mobile mode while 
doing the auto survey. After two days, we switched it into position hold mode. 
Most of the time it sees only one sat direct, all others are only seen through 
multipath. The results are astonishing, SD went down from about 30ns+ to about 
8ns. Spikes to +/-150ns went away completely.

I can post some GPSCon graphs of this  significant improvement during the test 
next week if there is interest.

Bye
Said

Sent From iPhone

On Dec 29, 2012, at 18:56, Bob Camp  wrote:

> Hi
> 
> The interesting thing is that you sometimes can get a position hold receiver 
> to report it's estimated location…. Not so much on current product, but on 
> some of the old stuff.
> 
> Bob
> 
> On Dec 29, 2012, at 9:51 PM, Jim Lux  wrote:
> 
>> On 12/29/12 6:34 PM, Bob Camp wrote:
>>> Hi
>>> 
>>> The gotcha is that often the "navigation" and "timing" receivers are 
>>> identical in terms of hardware. There is no upgraded hardware in the timing 
>>> device.
>>> 
>>> When you put a receiver into position hold, you are telling it "I don't 
>>> care about the location solution". It reduces the weight of that part of 
>>> the filter. Yes, that's only one way to look at it and there are other ways 
>>> to look at it.
>> 
>> 
>> or, another conceptual model is: I'm fixed, I know where the transmitting 
>> satellite is, and can calculate range and doppler a priori, so anything else 
>> must be local clock variation and propagation.  And you can average out the 
>> propagation among multiple satellites (or use one satellite as your timing 
>> reference)..
>> 
>> Particularly if you are post processing and have precise ephemeris data for 
>> the satellites
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Strange GPS behaviour

[Hal Murray]

li...@rtty.us said:
> When you put a receiver into position hold, you are telling it "I don't care
> about the location solution". It reduces the weight of that part of the
> filter. Yes, that's only one way to look at it and there are other ways to
> look at it. 

I thought it was better than that.  You are telling it "You are here.  Use 
that to figure out the time."


-- 
These are my opinions.  I hate spam.




___
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] Anyone ever put rubidium in an HP 70000 series mainframe?

[ewkehren]

I do feed a Rb in to all my istruments including my 7 spectrum analser. I 
had two choices 301 or create 100 Mhz. There blank modulrs available but make 
sure you get one with power module, power comming from the mainframe is if I 
recall 48 KHz.
Bert Kehren




Sent from Samsung tabletDavid Kirkby  wrote:The HP 
7 series modular measurement system allows one to configure
a range of modules to do various things such as spectrum analysis.

There's an oscillator in the unit somewhere (I don't know where), but
for higher accuracy one can buy an HP  70310A precision frequency
reference, like this, although this unit is well overpriced. I paid
$180 for mine.

http://www.ebay.co.uk/itm/HP-AGILENT-70310A-PRECISION-FREQUENCY-REF-MODULE-/110807441589?pt=LH_DefaultDomain_0&hash=item19cca360b5

In fact, you need that precision reference if you want to use an
external reference.

I was wondering if anyone had put a rubidium in one. I have a unit
which is dead, and whilst it might be possible to fix it, the idea of
just keeping the case and putting in something else is a bit
attractice. I know it has  10 and 100 MHz outputs, so one would need
to generate 100 MHz.

Dave

___
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] Strange GPS behaviour

[Bob Camp]

Hi

The interesting thing is that you sometimes can get a position hold receiver to 
report it's estimated location…. Not so much on current product, but on some of 
the old stuff.

Bob

On Dec 29, 2012, at 9:51 PM, Jim Lux  wrote:

> On 12/29/12 6:34 PM, Bob Camp wrote:
>> Hi
>> 
>> The gotcha is that often the "navigation" and "timing" receivers are 
>> identical in terms of hardware. There is no upgraded hardware in the timing 
>> device.
>> 
>> When you put a receiver into position hold, you are telling it "I don't care 
>> about the location solution". It reduces the weight of that part of the 
>> filter. Yes, that's only one way to look at it and there are other ways to 
>> look at it.
> 
> 
> or, another conceptual model is: I'm fixed, I know where the transmitting 
> satellite is, and can calculate range and doppler a priori, so anything else 
> must be local clock variation and propagation.  And you can average out the 
> propagation among multiple satellites (or use one satellite as your timing 
> reference)..
> 
> Particularly if you are post processing and have precise ephemeris data for 
> the satellites
> 
> 
> 
> 
> 
> 
> ___
> 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] Strange GPS behaviour

[Jim Lux]

On 12/29/12 6:34 PM, Bob Camp wrote:

Hi

The gotcha is that often the "navigation" and "timing" receivers are identical 
in terms of hardware. There is no upgraded hardware in the timing device.

When you put a receiver into position hold, you are telling it "I don't care about 
the location solution". It reduces the weight of that part of the filter. Yes, 
that's only one way to look at it and there are other ways to look at it.



or, another conceptual model is: I'm fixed, I know where the 
transmitting satellite is, and can calculate range and doppler a priori, 
so anything else must be local clock variation and propagation.  And you 
can average out the propagation among multiple satellites (or use one 
satellite as your timing reference)..


Particularly if you are post processing and have precise ephemeris data 
for the satellites







___
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] Strange GPS behaviour

[Bob Camp]

Hi

The gotcha is that often the "navigation" and "timing" receivers are identical 
in terms of hardware. There is no upgraded hardware in the timing device.

When you put a receiver into position hold, you are telling it "I don't care 
about the location solution". It reduces the weight of that part of the filter. 
Yes, that's only one way to look at it and there are other ways to look at it.

Bob

On Dec 29, 2012, at 5:42 PM, b...@lysator.liu.se wrote:

> Hi Bob,
> 
> I am curious about the sacrifice time and get better position. I have not
> seen any discussions about that in manuals, books or papers. Do you have
> reference?
> 
> What would be the difference between timing and navigation versions of
> cheap commercial receivers?
> 
> 1) Timing receivers are often stationary, navigation receivers are
> typically not stationary for extended periods of time. So a timing
> receiver can benefit from a time only solution. Ie you have a known
> (x,y,z)/(lat,lon,h) position and solve only for time, reducing the unknown
> from (x,y,z,t) to only (t). The known position can be had from a) full 4D
> single fix solution or better from b) a site survey taking the mean
> position from many hours of measurements or also good from c) an
> independently surveyed position of the antenna position. This mode will of
> cause improve time when there are fewer than 4 satellites tracked.
> 
> 2) Timing versions might get an upgraded oscillator. Maybe a TCXO instead
> of a standard XO.
> 
> 3) Navigation receivers integrations will not require high accuracy PPS
> output from the receiver. If you can save some cents on PPS generation
> hardware by having 500ns resolution of the PPS instead of 1-10ns
> resolution - the navigation receiver will not even have hardware resources
> to generate a decent 1PPS.
> 
> To my knowledge, the accuracy of (x,y,z,t) is given by the "geometrics" of
> the satellites tracked. The receiver reports this in the DOP (dilution of
> precision). There is PDOP (3d position), HDOP (horizontal position), HDOP
> (vertical position) and TDOP (Time). There is not much the receiver can do
> in normal operation with four or more tracked satellites to select between
> position and time accuracy. The relationship is given by the geometry of
> the measurements!
> 
> For a navigation receiver, there must be a time solution that is (scaled
> by c) more or less at the same accuracy as the position. Having 3 meter
> accuracy means the receiver time is good to 10ns. However the navigation
> receiver does not need to communicate this timing accuracy to the outside.
> It does not have to calibrate filter/processing delays. Slowly varying
> delays in analog filters due to temperature changes can also be ignored.
> Delays due to LNA and cables can also be ignored if you have a spec at
> 1PPS of 1us.
> 
> --
> 
>Björn
> 
> 
>> Hi
>> 
>> Indeed the solution is done once per second or so. In the solution they
>> weight the significance of position versus time. If you accept a larger
>> time error in the solution, you can come up with a smaller location error.
>> Is that a bit of mathematical sleight of hand? - of course it is. Can you
>> keep doing it forever? - no you can't. Eventually you need to get the time
>> back up to date.
>> 
>> Put another way - if all that was going on was the same solution process
>> in every receiver - there would be no differences in results. Software is
>> software. The hardware in a low cost timing receiver is the same as the
>> hardware in a low cost "location only" receiver. The difference is the
>> firmware. You can indeed shoot timing firmware into some location
>> receivers and turn them in to timing receivers.
>> 
>> Bob
>> 
>> On Dec 29, 2012, at 12:14 AM, Michael Perrett  wrote:
>> 
>>> Bob,
>>> That is simply not accurate - if the solution rate is 1/second, then all
>>> parameters are solved in that time frame. There are 4 indpendent
>>> variables
>>> and minimal processing power is required to solve all four equations.
>>> Although I am not very familiar with commercial receivers, that is what
>>> happens in the Rockwell, Trimble and IEC military units. If the output
>>> is
>>> more than once per second it is *usually* an output of the Kalman
>>> Filter,
>>> not a "true" measurement.
>>> 
>>> Michael / K7HIL
>>> 
>>> On Fri, Dec 28, 2012 at 6:20 PM, Bob Camp  wrote:
>>> 
 Hi
 
 …. except… A navigation GPS doesn't care much about the time solution.
 Updating the location is a much higher priority than updating the time.
 The
 typical "solution" is to let the time estimate coast for a while and
 update
 it much less often than the location.
 
 Bob
 
 On Dec 28, 2012, at 7:18 PM, Magnus Danielson
 
 wrote:
 
> On 28/12/12 23:35, Bob Camp wrote:
>> Hi
>> 
>> The GPS does an estimate against the local crystal frequency. It
 generates the PPS off of it's estimate. The less often it updates the
 estimate 

Re: [time-nuts] GPSDO compare FTS-4060

[Adrian]

Chris,

patience is the key to successfully trimming your Cs unit.
You will really want to compare it to your GPS for a week or so.
You might be surprised about your findings.
Actually, you're in need of a third high performance source...
how else can you tell which of the two is more stable?
Yep, use TimeLab and a TI counter!

Regards,
Adrian


Chris Howard schrieb:

On 12/29/2012 7:17 PM, Magnus Danielson wrote:


I would recommend to use a TIC and TimeLab to assist you on that task.

It is recommended to look at the phase plot (P), frequency plot (F) and 
modified Allan deviation plot (M) every once in a while.

A benefit is naturally that you can share the measurements in a suitable form 
for others to toy with and provide comments to you.

Cheers,
Magnus


Yes, this is how poor innocent people like me are drawn
into the world of being a time nut!

I have a Racal 1992 counter but have avoided the computer interface
issues so far.



But that would be really cool.

Chris












___
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] ensemble of standards

[cdelect]

Also about ensembles,

http://www.mksa.deit.univpm.it/biblioteca/sala_tecnica/scaffale_strumenti
/Campioni/EPSG070861.pdf

This article describes combining 4 HP 5071A standards. 

Description on page 2 and block diagram in figure 2.

Unfortunately no details on the controller are given!

It's what I'd like to do to two or more HP 5065A

Anyone know what they did in the controller?

Corby

___
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] GPSDO compare FTS-4060

[Chris Howard]

On 12/29/2012 7:17 PM, Magnus Danielson wrote:

> I would recommend to use a TIC and TimeLab to assist you on that task.
> 
> It is recommended to look at the phase plot (P), frequency plot (F) and 
> modified Allan deviation plot (M) every once in a while.
> 
> A benefit is naturally that you can share the measurements in a suitable form 
> for others to toy with and provide comments to you.
> 
> Cheers,
> Magnus


Yes, this is how poor innocent people like me are drawn
into the world of being a time nut!

I have a Racal 1992 counter but have avoided the computer interface
issues so far.



But that would be really cool.

Chris












___
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] GPSDO compare FTS-4060

[Magnus Danielson]

On 30/12/12 02:08, Chris Howard wrote:


Today I arrived home from a trip to Cleveland
to pick up my FTS-4060 Cesium standard.

About 45 minutes after power-up the lock
light came on.

This is unit S/N 1253.  I think the only
option it has is the 1 MHz/100 kHz output.

I connected both my GPSDO and this thing to
my O-scope and can see that the GPSDO is
slightly faster.   With the scope triggering
on the 4060, it takes right at 8 minutes
for the GPSDO to advance by one full cycle.

Reading on list archives, it seems to me that
the 4060 needs to be tweaked to match the GPSDO.

I have printed out the manual for the 4060 and
I will read about that and see what I can figure out.

I also think I will measure the one-cycle-advance
time period over the course of the next few days
and see if it changes much.


I would recommend to use a TIC and TimeLab to assist you on that task.

It is recommended to look at the phase plot (P), frequency plot (F) and 
modified Allan deviation plot (M) every once in a while.


A benefit is naturally that you can share the measurements in a suitable 
form for others to toy with and provide comments to you.


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.

[time-nuts] Anyone ever put rubidium in an HP 70000 series mainframe?

[David Kirkby]

The HP 7 series modular measurement system allows one to configure
a range of modules to do various things such as spectrum analysis.

There's an oscillator in the unit somewhere (I don't know where), but
for higher accuracy one can buy an HP  70310A precision frequency
reference, like this, although this unit is well overpriced. I paid
$180 for mine.

http://www.ebay.co.uk/itm/HP-AGILENT-70310A-PRECISION-FREQUENCY-REF-MODULE-/110807441589?pt=LH_DefaultDomain_0&hash=item19cca360b5

In fact, you need that precision reference if you want to use an
external reference.

I was wondering if anyone had put a rubidium in one. I have a unit
which is dead, and whilst it might be possible to fix it, the idea of
just keeping the case and putting in something else is a bit
attractice. I know it has  10 and 100 MHz outputs, so one would need
to generate 100 MHz.

Dave

___
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] GPSDO compare FTS-4060

[Chris Howard]

Today I arrived home from a trip to Cleveland
to pick up my FTS-4060 Cesium standard.

About 45 minutes after power-up the lock
light came on.

This is unit S/N 1253.  I think the only
option it has is the 1 MHz/100 kHz output.

I connected both my GPSDO and this thing to
my O-scope and can see that the GPSDO is
slightly faster.   With the scope triggering
on the 4060, it takes right at 8 minutes
for the GPSDO to advance by one full cycle.

Reading on list archives, it seems to me that
the 4060 needs to be tweaked to match the GPSDO.

I have printed out the manual for the 4060 and
I will read about that and see what I can figure out.

I also think I will measure the one-cycle-advance
time period over the course of the next few days
and see if it changes much.

Chris
w0ep
Columbus, MS

___
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] Fw: Rubidium Lamp PIX

[Magnus Danielson]

On 30/12/12 00:33, Joe Leikhim wrote:

I wonder if a small laser like those salvaged from a CDR writer would be
effective at evaporating the rb?


I doubt it. 250 mW laser compared to my (small) 300 W heat-gun? It took 
some time to heat the rubidium up to achieve the effect. Too little 
power, and most is lost in the cooling to the surrounding and heating is 
very small.


If you focus you might get the effect at a small spot, but it will take 
time an patience to achieve the full cleaning effect. A heat-gun is much 
cruder, but does the job well enough and quick enough.


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] Strange GPS behaviour

[Magnus Danielson]

Hi Björn,

On 29/12/12 23:42, b...@lysator.liu.se wrote:

Hi Bob,

I am curious about the sacrifice time and get better position. I have not
seen any discussions about that in manuals, books or papers. Do you have
reference?

What would be the difference between timing and navigation versions of
cheap commercial receivers?

1) Timing receivers are often stationary, navigation receivers are
typically not stationary for extended periods of time. So a timing
receiver can benefit from a time only solution. Ie you have a known
(x,y,z)/(lat,lon,h) position and solve only for time, reducing the unknown
from (x,y,z,t) to only (t). The known position can be had from a) full 4D
single fix solution or better from b) a site survey taking the mean
position from many hours of measurements or also good from c) an
independently surveyed position of the antenna position. This mode will of
cause improve time when there are fewer than 4 satellites tracked.


I've long assumed that T-receivers have the additional T-only positional 
mode. I recall the Motorola Oncores having a whole bunch of different 
positional modes, where timing mode is one amongst many others.



2) Timing versions might get an upgraded oscillator. Maybe a TCXO instead
of a standard XO.


Don't think so. The noise and systematic stability is as important for 
positional as for timing versions, the timing version can benefit of the 
fixed position.



3) Navigation receivers integrations will not require high accuracy PPS
output from the receiver. If you can save some cents on PPS generation
hardware by having 500ns resolution of the PPS instead of 1-10ns
resolution - the navigation receiver will not even have hardware resources
to generate a decent 1PPS.


No. We should have seen this in the clock jitter. They have the same 
clock as the core-clock of the ASIC. The PPS is actually a variant of a 
1 ms measurement timer that the GPS uses to grab samples of channel 
phase and integrated I&Q values for all channels. The 1 ms timer holds 
the actual system time of the GPS, which is then adjusted to the real 
GPS time using different algorithms, but using the solution from the 
positioning. The PPS is trivial to produce as a predicted event with 
that solution in hand. Since the hardware support has a limited 
resolution, it's trivial to calculate the error of the predicted PPS 
from the actual time, so a sawtooth error could be sent out.


Saving resolution in the PPS generator clock doesn't help much, as you 
need a certain clock rate and you need to divide it down regardless. The 
amount of logic cost to do a coarser vs a core clock is essentially 
nothing compared to what 12, 16, 20 or 24 channel correlator setup cost, 
so going to core clock resolution is no real saviour.



To my knowledge, the accuracy of (x,y,z,t) is given by the "geometrics" of
the satellites tracked. The receiver reports this in the DOP (dilution of
precision). There is PDOP (3d position), HDOP (horizontal position), HDOP
(vertical position) and TDOP (Time). There is not much the receiver can do
in normal operation with four or more tracked satellites to select between
position and time accuracy. The relationship is given by the geometry of
the measurements!


The RAIM algorithm can naturally prune of satellites giving too large 
time/pseudo-range errors, above some limit. The number of available 
channels allows for all in view birds to be selected, rather than having 
a selected sub-set which gives the best geometry. RAIM with enough 
channels will prune on actual pseudo-range errors rather than expected 
xDOP from geometry basis and contribute to lower numbers.



For a navigation receiver, there must be a time solution that is (scaled
by c) more or less at the same accuracy as the position. Having 3 meter
accuracy means the receiver time is good to 10ns. However the navigation
receiver does not need to communicate this timing accuracy to the outside.
It does not have to calibrate filter/processing delays. Slowly varying
delays in analog filters due to temperature changes can also be ignored.
Delays due to LNA and cables can also be ignored if you have a spec at
1PPS of 1us.


The biases of C/A code tracking is large enough that most of those 
issues can be overlooked. You can however shift DOP from the x, y and z 
into TDOP performance of the t solution by letting each and every 
pseudo-range be used in a pure T-RAIM pruning and then position solution.


The pseudo-range of a satellite can be written as:

p_sat = sqrt( (X - X_sat)^2 + (Y - Y_sat)^2 + (Z - Z_sat)^2) + c*(T - T_sat)

where p_sat is being measured for each sat and X, Y, Z and T is the 
solution when applied for a number of sats (4 needed for 3D+T position). 
When X, Y and Z is known from before, this equation becomes trivial to 
solve, but also you can see that any precision/error that previous was 
distributed over X, Y, Z and T is now only sent out on T. If X, Y and Z 
is of sufficient precision, the T solution w

Re: [time-nuts] Fw: Rubidium Lamp PIX

[Joe Leikhim]

I wonder if a small laser like those salvaged from a CDR writer would be 
effective at evaporating the rb?



On 12/29/2012 2:53 PM, time-nuts-requ...@febo.com wrote:

Message: 2
Date: Sat, 29 Dec 2012 09:15:02 -0500
From: Chuck Harris
To: Discussion of precise time and frequency measurement

Subject: Re: [time-nuts] Fw: Rubidium Lamp PIX
Message-ID:<50defae6.6040...@erols.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Should be easy enough for you to figure out.  The idea is to
evaporate any rubidium that is blocking the light from leaving
the bulb and making a straight path to the filter cell, and
ultimately the detector end of the package. Look at the bulb
on the side where the light must exit, and if it is shiny
and black, heat it there until it clears.


--
Joe Leikhim


Leikhim and Associates

Communications Consultants

Oviedo, Florida

jleik...@leikhim.com

407-982-0446

WWW.LEIKHIM.COM


___
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] Fw: Rubidium Lamp PIX

[Don Latham]

Hey, thanks, Chuck. I think I have a couple of candidates. Soon as I get
some time. . .
Don

Chuck Harris
> Should be easy enough for you to figure out.  The idea is to
> evaporate any rubidium that is blocking the light from leaving
> the bulb and making a straight path to the filter cell, and
> ultimately the detector end of the package. Look at the bulb
> on the side where the light must exit, and if it is shiny
> and black, heat it there until it clears.
>
> -Chuck Harris
>
> Don Latham wrote:
>> this would be even better with some arrows showing where to put the
>> heat
>> to heal the lamp!
>> Don
>>
>> cdel...@juno.com
>>>
>>>
>>>
>>> Here is a PIX of various Rubidium lamps.
>>>
>>> >From the left top,
>>>
>>> Tracor  EG&G  LPRO   5065A   R20   FRS   PRS10
>>>
>>> bottom two are FRK
>>>
>>> I'll see if Tom Van Baak will add them to his site
>>> also___
>>> 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.
>


-- 
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell


Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com



___
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] Strange GPS behaviour

[bg]

Hi Bob,

I am curious about the sacrifice time and get better position. I have not
seen any discussions about that in manuals, books or papers. Do you have
reference?

What would be the difference between timing and navigation versions of
cheap commercial receivers?

1) Timing receivers are often stationary, navigation receivers are
typically not stationary for extended periods of time. So a timing
receiver can benefit from a time only solution. Ie you have a known
(x,y,z)/(lat,lon,h) position and solve only for time, reducing the unknown
from (x,y,z,t) to only (t). The known position can be had from a) full 4D
single fix solution or better from b) a site survey taking the mean
position from many hours of measurements or also good from c) an
independently surveyed position of the antenna position. This mode will of
cause improve time when there are fewer than 4 satellites tracked.

2) Timing versions might get an upgraded oscillator. Maybe a TCXO instead
of a standard XO.

3) Navigation receivers integrations will not require high accuracy PPS
output from the receiver. If you can save some cents on PPS generation
hardware by having 500ns resolution of the PPS instead of 1-10ns
resolution - the navigation receiver will not even have hardware resources
to generate a decent 1PPS.

To my knowledge, the accuracy of (x,y,z,t) is given by the "geometrics" of
the satellites tracked. The receiver reports this in the DOP (dilution of
precision). There is PDOP (3d position), HDOP (horizontal position), HDOP
(vertical position) and TDOP (Time). There is not much the receiver can do
in normal operation with four or more tracked satellites to select between
position and time accuracy. The relationship is given by the geometry of
the measurements!

For a navigation receiver, there must be a time solution that is (scaled
by c) more or less at the same accuracy as the position. Having 3 meter
accuracy means the receiver time is good to 10ns. However the navigation
receiver does not need to communicate this timing accuracy to the outside.
It does not have to calibrate filter/processing delays. Slowly varying
delays in analog filters due to temperature changes can also be ignored.
Delays due to LNA and cables can also be ignored if you have a spec at
1PPS of 1us.

--

Björn


> Hi
>
> Indeed the solution is done once per second or so. In the solution they
> weight the significance of position versus time. If you accept a larger
> time error in the solution, you can come up with a smaller location error.
>  Is that a bit of mathematical sleight of hand? - of course it is. Can you
> keep doing it forever? - no you can't. Eventually you need to get the time
> back up to date.
>
> Put another way - if all that was going on was the same solution process
> in every receiver - there would be no differences in results. Software is
> software. The hardware in a low cost timing receiver is the same as the
> hardware in a low cost "location only" receiver. The difference is the
> firmware. You can indeed shoot timing firmware into some location
> receivers and turn them in to timing receivers.
>
> Bob
>
> On Dec 29, 2012, at 12:14 AM, Michael Perrett  wrote:
>
>> Bob,
>> That is simply not accurate - if the solution rate is 1/second, then all
>> parameters are solved in that time frame. There are 4 indpendent
>> variables
>> and minimal processing power is required to solve all four equations.
>> Although I am not very familiar with commercial receivers, that is what
>> happens in the Rockwell, Trimble and IEC military units. If the output
>> is
>> more than once per second it is *usually* an output of the Kalman
>> Filter,
>> not a "true" measurement.
>>
>> Michael / K7HIL
>>
>> On Fri, Dec 28, 2012 at 6:20 PM, Bob Camp  wrote:
>>
>>> Hi
>>>
>>> …. except… A navigation GPS doesn't care much about the time solution.
>>> Updating the location is a much higher priority than updating the time.
>>> The
>>> typical "solution" is to let the time estimate coast for a while and
>>> update
>>> it much less often than the location.
>>>
>>> Bob
>>>
>>> On Dec 28, 2012, at 7:18 PM, Magnus Danielson
>>> 
>>> wrote:
>>>
 On 28/12/12 23:35, Bob Camp wrote:
> Hi
>
> The GPS does an estimate against the local crystal frequency. It
>>> generates the PPS off of it's estimate. The less often it updates the
>>> estimate the more odd things you see as the crystal drifts.

 A typical GPS off the shelf solves the position solution every second,
>>> having a 1 Hz report rate. This includes clock corrections. Some GPSes
>>> is
>>> capable of higher report-rates.

> Of course, the crystal can have trouble all it's own. If the crystal
>>> has a rapid rate of frequency change over a narrow temperature range,
>>> the
>>> GPS simply can't keep up with the crystal.

 Most GPS receivers only have TCXOs, and even if tossing in an OCXO,
>>> excessive heat can throw the frequency and hence the GPS solution way
>>> of
>>> the ma

Re: [time-nuts] ensemble oscillators for better stability

[Magnus Danielson]

Tom,

On 29/12/12 18:11, Tom Van Baak wrote:

Corby,

So that's an interesting experiment. I think the key is keeping them
in tight phase so that what you gain in combined performance is still
better than what you lose with the additional mixing electronics.


If you just mixup, then you do not need to lock them up. You only need 
that if you add them up in a power-combiner.



A couple of comments that come to mind.

1) This was a topic some years back -- for internal use, hp tightly
   combined multiple 10811 oscillators so that the net phase noise or
   short-term performance was significantly better than any one of the
   constituent oscillators.


Care to share a reference on that? It would be interesting to see how 
they did it and how well they where doing it.



2) It would be nice to be able to extend this to more than 2
   oscillators, in such a way that you gain by sqrt(N) without
   corresponding losses due to increased noise.


Using the mix-up strategy would be possible. Also, for three sources you 
would get back to your starting frequency easily on the second mixer. A 
mix-up strategy would allow to mix 5 and 10 MHz sources, but 
unfortunately that would give the 10 MHz sources twice the weight of 5 
MHz sources. The free-running measure and locked additive strategies 
does not have that drawback.



3) You already realize that being able to keep coherence between the
   standards as long as possible is highly desirable.


It depends on what strategy you try to achieve.


4) Consider that none of the UTC(k) timing labs use your technique.
   The reason is that it's far easier to compare N frequency
   standards in near-realtime (like every second or every 100 s,
   etc.) combining the measurement *numbers* than it is to combine
   the actual *electrons* coming out of the frequency standards in
   realtime.


Also, they do not need the high-frequency phase noise benefit. If they 
need low phase-noise, an active H-maser is used.


Another benefit of not locking the standards is that you can observe 
them undisturbed by a control-loop, which make things easier for what 
they try to achieve.



So this is one reason why I keep encouraging those of you building
amateur, inexpensive, high-resolution, multi-port phase comparators.


It is indeed an interesting thing do to. To benefit it needs to have 
many channels, say 8 or so. Preferably expandable further as you have 
more sources to look at and form an ensemble of.



If you had a couple of these comparators you'd simultaneously
measure each of your 5065A and perhaps several other standards all
using a common reference. It wouldn't really matter which standard
was the reference, since the data is all pair-wise relative.


As you compare many sources, doing M-cornered hat stuff becomes 
possible, and you can get some confidence in the absolute phase-noise of 
all involved sources.



It's trivial to create an ensemble in software, based on multiple
phase measurements that arrive by spi or gpib or rs232. With that
calculated mean phase you can then ex post facto apply a correction
to each of the oscillators in the ensemble. It's like sawtooth
correction; you take the pulse as you see it, but you apply a
freshly calculated correction factor.


A note on ensembles is that NTP actually features ensemble calculations, 
as it is able to estimate the noise, do weighting of various sources 
etc. Inspired by the work done at NIST. I'm not completely sure that NTP 
will work well with unlocked frequency sources, but I mention it so 
people can look in their NTP books and read up a bit.


The main point is that the past noise of a source is used to calculate 
the weight it can have in order to form the optimum stability. This is 
how the national labs create their time-scales, and then how EAL is 
built for maximum frequency stability, then being corrected into the TAI 
for phase stability and then synthesized into UTC to form a stable GMT 
replacement.


Once you have started to walk on the ensemble path, you are not that far 
off from looking at doing a full-blown time-scale.


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] Strange GPS behaviour

[bg]

Hi,

> On 12/28/12 9:14 PM, Michael Perrett wrote:
>> Bob,
>> That is simply not accurate - if the solution rate is 1/second, then all
>> parameters are solved in that time frame. There are 4 indpendent
>> variables
>> and minimal processing power is required to solve all four equations.
>> Although I am not very familiar with commercial receivers, that is what
>> happens in the Rockwell, Trimble and IEC military units. If the output
>> is
>> more than once per second it is *usually* an output of the Kalman
>> Filter,
>> not a "true" measurement.
>>
>
> how is the output of a Kalman filter not a "true measurement".. it's
> essentially the composite of many measurements, weighted by the
> uncertainty of those measurements, and, if properly setup, the
> uncertainty of the filter output is less than any of the component
> measurements.

Often these receivers can output either a filtered solution or an
"unfiltered" solution.

The kalman filter will do measurement updates once a second with
pseudorange and delta range measurements. In between - to get 10Hz or
whatever - they will use the kalman filter to predict the
position/velocity.

> Or by "true measurement" do you mean a "point solution" at an instant in
> time, which I don't think you would get from any receiver that uses any
> form of tracking loop, because what is the output of that tracking loop
> but some estimate of the observable, filtered through the loop filter.
> After all, you need to measure/estimate both code phase and rate.

Sure, the pr/dr measurements are filtered both by the tracking loop and by
the integration time. But that filtering is on another scale than using a
filter to predict outputs at a higher rate than what the point solution is
available at.

--

  Björn


___
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] Strange GPS behaviour

[David]

On Sat, 29 Dec 2012 12:18:56 -0800, Said Jackson 
wrote:

>Fabio,
>
>Happens in all the GPS receivers we have tested here. The difference between 
>receivers is how fast they can recognize this error and how fast they can 
>re-aquire once they shut off the 1PPS output due to tcxo instability.
>
>There was a recent thread here about effects of adding a fan to a Z380x and 
>the behavior you have seen is one of the reasons why that is a bad idea.
>
>Some receivers like Rockwell, Trimble etc allow for external 10MHz input from 
>an ocxo or atomic clock, and some GPSDOs make use of that feature. Having a 
>very stable and accurate 10MHz reference for the GPS is also supposed to 
>reduce time to second fix.

I am going to have to add that feature to my shopping list of what to
look for when I upgrade from my Garmin GPS18-5.

One feature I found interesting in the GPS18-5 is that the adjustable
dead reckoning time can be set to disable the timing pulse output when
there is no current navigation solution.

___
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] Strange GPS behaviour

[Jim Lux]

On 12/28/12 9:14 PM, Michael Perrett wrote:

Bob,
That is simply not accurate - if the solution rate is 1/second, then all
parameters are solved in that time frame. There are 4 indpendent variables
and minimal processing power is required to solve all four equations.
Although I am not very familiar with commercial receivers, that is what
happens in the Rockwell, Trimble and IEC military units. If the output is
more than once per second it is *usually* an output of the Kalman Filter,
not a "true" measurement.



how is the output of a Kalman filter not a "true measurement".. it's 
essentially the composite of many measurements, weighted by the 
uncertainty of those measurements, and, if properly setup, the 
uncertainty of the filter output is less than any of the component 
measurements.


Or by "true measurement" do you mean a "point solution" at an instant in 
time, which I don't think you would get from any receiver that uses any 
form of tracking loop, because what is the output of that tracking loop 
but some estimate of the observable, filtered through the loop filter. 
After all, you need to measure/estimate both code phase and rate.


You could record raw signals off the air, and post process by 
correlating over a long time span to get a "unfiltered" measurement 
(although, I suppose the "integrate and dump" inherent in the 
correlation provides a sin x/x sort of frequency response)







___
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] Strange GPS behaviour

[Said Jackson]

Fabio,

Happens in all the GPS receivers we have tested here. The difference between 
receivers is how fast they can recognize this error and how fast they can 
re-aquire once they shut off the 1PPS output due to tcxo instability.

There was a recent thread here about effects of adding a fan to a Z380x and the 
behavior you have seen is one of the reasons why that is a bad idea.

Some receivers like Rockwell, Trimble etc allow for external 10MHz input from 
an ocxo or atomic clock, and some GPSDOs make use of that feature. Having a 
very stable and accurate 10MHz reference for the GPS is also supposed to reduce 
time to second fix.

Bye,
Said

Sent From iPhone

On Dec 28, 2012, at 14:27, Fabio Eboli  wrote:

> Like I mentioned in a precedent message
> (answering Magnus) I'm seeing some temp
> effects on my GPS module, see this message:
> http://www.febo.com/pipermail/time-nuts/2012-December/073310.html
> 
> In this graph there are the FE5680 voltages
> and temperatures, and the temperature sensed
> on the PCB near the GPS:
> http://www.flickr.com/photos/14336723@N08/8318815981/
> 
> At time 2s I heated the GPS receiver directly
> with hot air gun and the drift started to change
> rapidly.
> At 25000 I heated the FE5680#2 I was using
> as reference, but no visible effects, (apart
> the slight variation in it's voltage :)
> At 3 33000 35000 seconds I heated the
> GPS with a resistor placed near the PCB,
> this generated more gradual temperature
> variation on the GPS.
> 
> Here can be seen the results of the heating
> on the drift, (logging GPS PPS against Rb):
> http://www.flickr.com/photos/14336723@N08/8318816213/
> the hotair generated so much variation, that
> the script was unable to unscrable the data.
> The resistor heater generated slower temperature
> variation on the GPS, it's visible a glitch
> everytime there was a temperature variation,
> and the drift magnitude seem to follow the
> variation of the temperature in time (dT/dt).
> 
> I will try to reduce temperature sensivity
> incrementing the thermal capacitance and
> isolating the GPS from the ambient.
> 
> Is this normal or it's a defect ("feature") of
> my unit? I'm also curious about what internal
> structure can generate this wander in PPS.
> Like I said before it's like if the PPS pulse
> (for intervals of few 100's of nS) depends on
> something that is very temperature dependent.
> 
> Thanks,
> Fabio.
> 
> ___
> 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] Rubidium PIX

[cdelect]

Tom is hosting some rubidium PIX on his http://www.leapsecond.com/
website

http://www.leapsecond.com/corby/rb-lamp.htm

http://leapsecond.com/corby/5065a-optical/

http://www.leapsecond.com/pages/rb-cells/

Enjoy!

Corby

___
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] Strange GPS behaviour

[Bob Camp]

Hi

Indeed the solution is done once per second or so. In the solution they weight 
the significance of position versus time. If you accept a larger time error in 
the solution, you can come up with a smaller location error.  Is that a bit of 
mathematical sleight of hand? - of course it is. Can you keep doing it forever? 
- no you can't. Eventually you need to get the time back up to date.

Put another way - if all that was going on was the same solution process in 
every receiver - there would be no differences in results. Software is 
software. The hardware in a low cost timing receiver is the same as the 
hardware in a low cost "location only" receiver. The difference is the 
firmware. You can indeed shoot timing firmware into some location receivers and 
turn them in to timing receivers. 

Bob

On Dec 29, 2012, at 12:14 AM, Michael Perrett  wrote:

> Bob,
> That is simply not accurate - if the solution rate is 1/second, then all
> parameters are solved in that time frame. There are 4 indpendent variables
> and minimal processing power is required to solve all four equations.
> Although I am not very familiar with commercial receivers, that is what
> happens in the Rockwell, Trimble and IEC military units. If the output is
> more than once per second it is *usually* an output of the Kalman Filter,
> not a "true" measurement.
> 
> Michael / K7HIL
> 
> On Fri, Dec 28, 2012 at 6:20 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> …. except… A navigation GPS doesn't care much about the time solution.
>> Updating the location is a much higher priority than updating the time. The
>> typical "solution" is to let the time estimate coast for a while and update
>> it much less often than the location.
>> 
>> Bob
>> 
>> On Dec 28, 2012, at 7:18 PM, Magnus Danielson 
>> wrote:
>> 
>>> On 28/12/12 23:35, Bob Camp wrote:
 Hi
 
 The GPS does an estimate against the local crystal frequency. It
>> generates the PPS off of it's estimate. The less often it updates the
>> estimate the more odd things you see as the crystal drifts.
>>> 
>>> A typical GPS off the shelf solves the position solution every second,
>> having a 1 Hz report rate. This includes clock corrections. Some GPSes is
>> capable of higher report-rates.
>>> 
 Of course, the crystal can have trouble all it's own. If the crystal
>> has a rapid rate of frequency change over a narrow temperature range, the
>> GPS simply can't keep up with the crystal.
>>> 
>>> Most GPS receivers only have TCXOs, and even if tossing in an OCXO,
>> excessive heat can throw the frequency and hence the GPS solution way of
>> the mark. For many GPS reference stations, rubidiums is used to steer the
>> internal clock, and the quality of that lock can affect how well it tracks
>> it and have secondary frequency issues.
>>> 
>>> So, it comes as no surprise that the GPS module is temperature
>> sensitive. The metrology labs measure and compare the temperature stability
>> of various GPS-receivers,
>>> 
>>> There are also filters that can provide temperature effects, but the
>> TCXO is where it usually hurts most.
>>> 
>>> 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.
>> 
>> 
>> ___
>> 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] ensemble oscillators for better stability

[Tom Van Baak]

> Hi,
> 
> I've been playing around with 2 HP 5065A standards to see if averaging
> them will give better stability.

Corby,

So that's an interesting experiment. I think the key is keeping them in tight 
phase so that what you gain in combined performance is still better than what 
you lose with the additional mixing electronics.

A couple of comments that come to mind.

1) This was a topic some years back -- for internal use, hp tightly combined 
multiple 10811 oscillators so that the net phase noise or short-term 
performance was significantly better than any one of the constituent 
oscillators.

2) It would be nice to be able to extend this to more than 2 oscillators, in 
such a way that you gain by sqrt(N) without corresponding losses due to 
increased noise.

3) You already realize that being able to keep coherence between the standards 
as long as possible is highly desirable.

4) Consider that none of the UTC(k) timing labs use your technique. The reason 
is that it's far easier to compare N frequency standards in near-realtime (like 
every second or every 100 s, etc.) combining the measurement *numbers* than it 
is to combine the actual *electrons* coming out of the frequency standards in 
realtime.

So this is one reason why I keep encouraging those of you building amateur, 
inexpensive, high-resolution, multi-port phase comparators.

If you had a couple of these comparators you'd simultaneously measure each of 
your 5065A and perhaps several other standards all using a common reference. It 
wouldn't really matter which standard was the reference, since the data is all 
pair-wise relative.

It's trivial to create an ensemble in software, based on multiple phase 
measurements that arrive by spi or gpib or rs232. With that calculated mean 
phase you can then ex post facto apply a correction to each of the oscillators 
in the ensemble. It's like sawtooth correction; you take the pulse as you see 
it, but you apply a freshly calculated correction factor.

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

[time-nuts] Rubidium Lamp PIX

[cdelect]

Don,

The only lamps besides FRS lamps I have had to "rejuvinate" were HP lamps
that the oven had run away on forcing all the Rubidium out into the bulb
and coating the walls. 

The design of most standards insures that the base of the bulb will cool
faster than the bulb when turned off thus collecting the Rubidium back
into the base. The FRS was not quite as good in this respect!

If upon inspection you can see Rubidium anywhere but down in the very
base of the bulb you can use a heat gun to force it back into the base.
I sit the bulb so the base is sitting on something to heat sink it and
then ply the heat gun around the top of the bulb until all the visible
Rubidium  is off of the bulb proper. On an HP unit you can just leave the
bulb mounted on its board to use as the heat sink.

Here is a link to an excellent description of FRS lamp repair.

Corby


http://www.n4iqt.com/efratom8084008/eeratom_model_frs_lamp_assembly_repai
r.pdf

___
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] OSA 4530 Low noise GPSDO

[Magnus Danielson]

On 29/12/12 13:46, Azelio Boriani wrote:

Aha, it was you... I was about to buy that GPSDO when it suddenly
disappeared. Well done, Oscilloquartz products are not common on the usual
auction site as it is hard to find their complete documentation.


Yes, I have a few Oscilloquartz stuff and my curiosity had the better of 
me :)


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] Fw: Rubidium Lamp PIX

[paul swed]

Chuck hit the nail on the head. Thats what I have done and it restores the
bulbs nicely.
I have seen both the darkened area and actually a silver-ish glob that when
heat moved around and finally evaporated.
Paul
WB8TSL

On Sat, Dec 29, 2012 at 9:15 AM, Chuck Harris  wrote:

> Should be easy enough for you to figure out.  The idea is to
> evaporate any rubidium that is blocking the light from leaving
> the bulb and making a straight path to the filter cell, and
> ultimately the detector end of the package. Look at the bulb
> on the side where the light must exit, and if it is shiny
> and black, heat it there until it clears.
>
> -Chuck Harris
>
>
> Don Latham wrote:
>
>> this would be even better with some arrows showing where to put the heat
>> to heal the lamp!
>> Don
>>
>> cdel...@juno.com
>>
>>>
>>>
>>>
>>> Here is a PIX of various Rubidium lamps.
>>>
>>> >From the left top,
>>>
>>> Tracor  EG&G  LPRO   5065A   R20   FRS   PRS10
>>>
>>> bottom two are FRK
>>>
>>> I'll see if Tom Van Baak will add them to his site
>>> also__**_
>>> 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] Fw: Rubidium Lamp PIX

[Chuck Harris]

Should be easy enough for you to figure out.  The idea is to
evaporate any rubidium that is blocking the light from leaving
the bulb and making a straight path to the filter cell, and
ultimately the detector end of the package. Look at the bulb
on the side where the light must exit, and if it is shiny
and black, heat it there until it clears.

-Chuck Harris

Don Latham wrote:

this would be even better with some arrows showing where to put the heat
to heal the lamp!
Don

cdel...@juno.com




Here is a PIX of various Rubidium lamps.

>From the left top,

Tracor  EG&G  LPRO   5065A   R20   FRS   PRS10

bottom two are FRK

I'll see if Tom Van Baak will add them to his site
also___
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] OSA 4530 Low noise GPSDO

[Azelio Boriani]

Aha, it was you... I was about to buy that GPSDO when it suddenly
disappeared. Well done, Oscilloquartz products are not common on the usual
auction site as it is hard to find their complete documentation.

On Sat, Dec 29, 2012 at 1:57 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:

> Fellow time-nuts,
>
> Today I picked up the package containing the OSA 4530 "Low noise" GPSDO.
>
> It features a OSA 8663-B6SG double-oven SC-cut, and a Navicom GPcore Sync
> 15 GPS receiver, based on the Zarlink GP4020 chip.
>
> I don't have any quality info on the GPS receiver card, but it has it's
> own RAKON 10 MHz reference. If someone could hand me some reference on the
> GPS receiver board, I would be greatful.
>
> The OSA 4530 is a three board design, with bottom board being power and
> control board, middle board being OCXO, output buffer, PPS and time
> measure, and third board is the Navicom GPS receiver board.
>
> It would be nice to have a manual for it, I haven't found one just yet.
> Neither the control software.
>
> I will fire it up and see how it behaves.
>
> 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.
>
___
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] Testing the TAC, and a question about ADEV

[Fabio Eboli]

Il 2012-12-28 21:43 Magnus Danielson ha scritto:


The bucket statistic method is very simple.
You divide a scale into a suitable set of ranges, equally wide. The
you count how many "hits" you get within each of those ranges or
"buckets".


By the way, since I've seen some contributors
that are from Italy (Azelio...? :) what is the
correct name of the tecnique in Italian, maybe
it's something I've studied or seen somewhere.

Thanks.
Fabio.

___
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] Testing the TAC, and a question about ADEV

[Fabio Eboli]

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4030739&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4030739 



is one of the best in that it gives guidance on selecting suitable 
test oscillator periods.
It also details how the integral linearity can be derived from the 
test.

There are a couple of minor errors in the paper.

Bruce


Thank you for the references, unfortunately I dont
have an account to access to IEEE papers.


P.S. The micro's adc is charachterized
for total unadjusted error of +-2LSB Max
at 25°C, 12bit total.
It's s-h is 8pF with 1kohm in series,
probably I can sync the sampling to
open just before the pulse, and close
after the fact.

What error is that:


As per the datasheet blah blah :) :
"the total unadjusted error (TUE) is defined as the
maximum deviation between the actual and the ideal
transfer curves. It is a parameter that specifies
the total errors that may occur, causing maximum
deviation between the ideal digital output and the
actual digital output. It is the maximum deviation
recorded between the ideal expected value and the
actual value obtained from the ADC for any input voltage."

see:

pag 9, I was considering it the worse case error.


gain error?


+-1.5LSB


offset error?


+-1.5LSB


integral nonlinearity?


+-1.5LSB


What about monotonicity or differential linearity?


DNL +-1LSB

See :

pag 76



A worst case assumption would be that the ADC is perhaps only
monotonic for the 11 most significant bits.


Fabio.

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