Magnus Danielson wrote:

Magnus

So the correct description of the cause of hanging bridges is something
like?

As the frequency of the clock which controls the timing of the receiver
PPS pulse output drifts and approaches pleisiosynchronism with the
"true" frequency of the PPS signal, the rate of change of the PPS timing
error due to quantisation decreases reaching zero should the clock
achieve synchronism with the "true" PPS frequency.
Thus hanging bridges occur when the clock frequency approaches
pleisiosynchronism with the "true" PPS signal frequency and then drifts
away from pleisiosynchronism with the PPS signal..

When the frequency of the clock controlling the timing of the receiver
PPS pulse output is synchronous with the PPS frequency, then neither
sawtooth corrections or hanging bridges occur, however there may be a
fixed offset of upto 1/2 a clock cycle between the "correct" and the
actual leading edge of the receiver PPS output pulse.

Please correct and simplify these statements as required.

The only problem that I can see is we still need to define how close to
synchronism the timing clock frequency and the "true" PPS signal
frequency system must be to be considered pleisiosynchronous.

Bruce

In message 20061226.125102.1723212534.cfmd@bredband.net, Magnus Danielson wri
tes:

Overtone is a musical term and it is not the same as harmonic.

An harmonic frequency is N times the fundamental, where as an
overtone merely holds a rational relationship to the fundamental
(3/2, 4/3 etc.)

The reason you can tell the difference between a violin and a
clarinet is that they have different overtone spectra.

A somewhat arbitrary subset of an intruments overtones are called
"formants" because they are the principal "formers" of the instruments
sound.

Close, but no cigar.

If they merely have the same period/frequency, they are "syntonous",
but if the phase is also coincident, they are synchronous.

But just because two signals are asynchronous, doesn't mean they cannot
have the same frequency or phase for a shorter or longer period of time,
it just means that there is no mechanism that makes it so.

No, each transmitter and receiver are anisochronous, but the
communication between them, and by language extension the actual
cable, is asynchronous.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Dr Bruce Griffiths wrote:

Bruce,

The Trimble app note you pointed to says the 1 PPS output is not
quantized, so I believe that means there should not be sawtooth error.

Look at the bottom of this page http://www.ko4bb.com/Timing/FAQ-1.html

The last picture is the Thunderbolt PPS output against a free running HP
10811 divided by 256 with two 74F161.

The plot was obtained after removing steps, outliers (few, mostly due to
my acquisition software that puts some garbage in the output) and drift,
using Ulrich's Plotter program.

Since I was using the HP 5334, data is taken every 2 seconds.

How can I determine from this if sawtooth error is present?

Do I need to collect data differently?

Thanks

Didier

Note: my home brew GPIB data logging software records ambient
temperature at the same rate as the TI, which I believe would be a very
useful information. Unfortunately, I have not found yet how to display
both curves in a meaningful way using Plotter, so I have to strip the
temperature from the dataset before feeding it to Plotter. Also,
collecting data from two instruments causes my program to sometimes
insert garbage in the output file, which causes outliers and which I
need to fix before I put this software on my web page.

Poul-Henning Kamp wrote:

This is interesting because overtone, when used to describe oscillation
modes in crystals, has a slightly different meaning.

When a crystal is made to oscillate on one of it's overtone
frequencies, the oscillation frequency is not exactly an harmonic of the
fundamental (or 1st harmonic) oscillation frequency.

This term is obviously overloaded and maybe we should not be using it.

Didier KO4BB

Didier Juges wrote:

Didier

The last paragraph should have started with As you say, in the absence
of noise, ......

In effect the 10MHz oscillator will track the smoothed PPS frequency.
However pulse by pulse the computed PPS signal timing will vary with
respect to the position of the smoothed PPS signal, consequently when
quantised there will be some variation of the timing of the PPS edge
with respect to the edge of the smoothed PPS pulse position. Thus some
evidence of quantisation will be seen in the PPS pulse output. The rate
at which such steps occur depends on the noise in the computed PPS
transition time. If the noise is significantly less than 100ns such
steps will be infrequent.
Even if the rms noise were around 100ns the resultant PPS timing error
plot will not exhibit the short term correlations evident in the Oncore
timing receiver sawtooth correction plot. The corresponding correction
plot should be more random.

The other complication is that the Thunderbolt noise spec was
derived/measured when SA was turned on. It may be significantly smaller
now that SA has been turned off.

Your plots show little or no evidence of any 50ns quantisation steps or
even 20ns steps.
This means that the internal receiver timing noise is significantly
smaller than the quantisation step.
The 20ns rms probably refers to the the receiver's internal
(prequantisation) timing noise in the presence of SA.

Bruce

Dr Bruce Griffiths wrote:

Thank you Bruce, that's very encouraging.

Regarding the jam-sync mode, I am not sure how much the GPS_PPS and
HW_PPS need to be separated by before the jam-sync mode in engaged. I
believe it takes more than one pulse because typically this mode is only
used when recovering from holdover or after startup, so it should not be
engaged as long as the receiver has a valid fix, even when satellites
come in and out. So I would not expect to see phase jumps unless the GPS
signal went completely away. I need to write another logging program to
log the serial data from the Thunderbolt and see how often, if at all,
it goes into holdover with my currently marginal antenna situation. I
have not seen it happen since I moved the antenna in its current
location though.

When reading the data sheet for the Thunderbolt, and reading all the
pitfalls associated with non-integrated GPSDO designs using stand alone
GPS receivers, such as sawtooth correction and quantization noise, it
seems like the integrated approach used in the Thunderbolt is the best
way to go. Not only it is cheaper and simpler, and therefore should be
more reliable, but it avoids an entire class of problems and should
perform better, everything else being equal (receiver sensitivity and
internal noise, OCXO quality). In this case, simplicity goes with better
performance, which is not always the case.

Yet, I am surprised that so many of the OEM timing receiver solutions
use the conventional approach. For instance, the Lucent receiver John
just bought seems to have a discrete, independent GPS receiver (the
darker board on top), and many companies still build stand alone GPS
receivers specifically for timing application without embedding the
GPSDO logic and an OCXO. That does not seem to make much sense to me.

In the mean time, I keep forgetting the Thunderbolt specs were written
when SA was turned on, and therefore better performance should be
expected today from the same hardware.

Tom said he was planning a comparison test session of various GPSDO
designs in January or February I believe. If he does not have one, I'll
be glad to send him my Thunderbolt for comparison. Tom, if you are
interested, please speak up.

Thanks again.

Didier

From: Dr Bruce Griffiths bruce.griffiths@xtra.co.nz
Subject: Re: [time-nuts] TIC resolution impact on GPSDO's performance
Date: Wed, 27 Dec 2006 01:15:48 +1300
Message-ID: 45911274.5030605@xtra.co.nz

Bruce,

This is much better even if it is not more readable, but that is in the
beholders eye.

However, there is one thing which may not be all that clear. For each PPS pulse
to be generated, the firmware needs to decide which clock-transition will best
approximate the internal time solution. This means that it continously makes a
frequency justification. PDH guys would call this bit justification and SDH
guys would call this pointer justification. Justifications of this kind is
known for one thing, being bad of relasing detailed phase information. The lack
of transition causes the worstcase quantization error to manifest itself.
The high frequency error causes many justifications and when they are smoothed
out they give a higher degree of phase information. Having to rely on such a
justification mechanism isn't very nice. The negative sawtooth error output
really removes much of the problem and especially relating to the hanging
bridge problem becomes less of an issue by using the information. However, the
negative sawtooth error signal is limited in resolution so on modern receivers
the full potential of the receiver frontend.

The hanging bridge of the sawtooth correction is much smaller than that of the
PPS only. A hanging bridge of the PPS regulation can still output phase errors
and thus reduce the effective quantization error. The effect is there thought,
and for a shorter time.

A certain NZ product has my main attention right now. They have some problem
with a ringmod or some ringing... they use old tools and old magic and takes a
hell of a time to acheive. Back to the TV.

But yes, it could probably be better explained.

As always, what degree of synchronousity is meaningfull for us?

Also, do we really have to care? Is this really how this problem should be
solved? Just because this is how receivers traditionally have indicated time,
is this really the best solution to compare a clock, via a for our purposes a
really poor clock? I think not.

Cheers,
Magnus

On Tue, Dec 26, 2006 at 04:14:45PM -0600, Didier Juges wrote:

It is my understanding that the Motorola Oncore timing receiver

modules (UT,VP and onwards to the M12+ family) can be ordered in a
version that accepts an EXTERNAL 10 mhz rather than using an internal
crystal for timing.  At least I think it is a 10 mhz input, but I am
quite sure they can be ordered in a version that does not generate
timing or frequency from an internal xtal oscillator.

And if my presumption is correct that the Trimble Thunderbolt

hardware is either identical to or very similar to the HP/Symmetricom
58540A hardware (and both OEMed from a company in Japan) I think you
will find that they do use a Motorola GPS timing receiver in external
clocked mode using a clock derived from the 10 mhz OXCO.  I beleive my
58540As do anyway.

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

however, looking at the photos published today, it does not seem clear
they don't use a GPS receiver with an external clock.  Not easy to tell
since the guts of the Motorola module are under a shield can.

There is certainly no reason to integrate a GPS receiver with

the OXCO PLL and status electronics if one can buy an OEM one that takes
an external clock for less money (and hastle over firmware development
and licensing for the GPS side).  GPSDOs are a small market compared to
the overall market for OEM GPS solutions and there are economies of
scale involved.

And as a final note - a Datum 9390 box I have that dates to

beginning of time (GPS time that is) used a Rb derived clock for the
antique OEM Trimble GPS receiver board it uses so that approach has been
around from the early days...

--
Dave Emery N1PRE,  die@dieconsulting.com  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."

Didier,

looking at your plots, i see that your 'Tau'on the main page is set to
0.5 instead of 2 as it should be with your measurement arrangement.  I
understand that due to the unity '/s' you were fooled into thinking that
you need to compute a '1/2' sample rate from your measurement
arrangemant. This is due to my mistake to mix the both terms 'sample
rate' and 'tau' into one text field. I will have to check how to name
the field best without any ambiguity. As long as this bug is there you
should simply exchange the 0.5 by 2.

After this correction your Allan plot will start with 3.06 E-9 @ 2 s.
This is VERY close to the effect of the 2 ns resolution of your counter,
so probably

is correct. Note however, that with 1 s dead time between measurements
we need a dead time correction that Plotter is currently not being able
to compute. The results will not be worlds apart but there will be
subtle differences.

In order to display two plots into one with the two having largely
different scales give the second plot a different vertical scale by

1. Open chart editor

2. In the left upper part choose the series that you want to give a new
   vertical axis

3. In the right window open the 'General' parameter page

4. At 'vertical axis' choose 'right' and close the chart editor to see
   the result

5. Note that you may introduce as many new vertical axes as you want in
   the 'chart' 'axis' part of the chart editor (see the '+' sign?). Using
   the method 1/2/3 you may assign series to new created axes. Note also
   that the new axes may be shifted horizontical against their original
   position to give every axis its own gorizontal position in the plot.

I wish I had the time to write a user manual!

73 de Ulrich, DF6JB