Hi

Depending on your definition of “accuracy”, and the actual device, the answer is likely
in the 1 ppb to 10 ppt range based on a 10 second measurement.

What’s going on?

First up you have the basic accuracy of GPS. Over many days of averaging (with a fairly
fancy averaging device) that can be quite good ( << 1 ppt). Most GPSDO’s run averaging
in the (maybe) 100 second range. That gets you into a whole different arena. ( = long term
accuracy is not the issue).

Next, you have noise. GPS at 1 second likely has several ppb of noise (as measured by ADEV).
At 10 seconds you should be below one ppb, but maybe not by a lot.

Your local reference also has noise as does the loop. Is the loop + reference 1 ppb or 1 ppt at
one second? (again measuring with ADEV). It depends a lot on just what you have. A good guess
is 10 ppt. That may also apply at 10 or even at 30 seconds.

Now comes the question of your “accuracy” definition. ADEV is a “one sigma, delta between readings”
measure. If you are after absolute frequency, this is not what ADEV is measuring. If you are after a
six sigma “frequency accuracy” number, you might well need to multiply the ADEV by 10 or 100X.

Often GPSDO’s that are intended as frequency references are spec’d out as “better than X 99% of
the time ( typical ).” You have a sort of three sigma, with the qualifier that it is typical. ( So not all the
time … hmmm …..).

So what are you trying to do? What sort of “accuracy” do you need? What are you looking for?
Is ADEV an adequate measure?

Bob

Not sure what you mean by "accuracy over a 10 sec interval".  If you mean
(in)correctness of frequency averaged over a given 10 sec interval, it's
more
like a few parts in 10^9.  But if you mean stability of frequency without
regard
for its correctness, you might see your 2 parts in 10^12 in at least some
intervals,
although that seems a bit tight to me.

The numbers I mention above are for a GPSDO using an OCXO with a
disciplining
time constant of just a few seconds, which is kind of a worst case
scenario.  However,
if your VCO is stable enough to be reigned in with a time constant of
hundreds of
seconds, you can do much better for stability and at least moderately
better for
absolute frequency accuracy.

If your primary interest is fixed in that 10 sec interval, a GPSDO with a
good OCXO is
likely to be the best way to go.  OTOH, if your interest evolves into
appreciably longer time
intervals, you'd likely do better with a GPS disciplined Rb oscillator,
where disciplining
time constants of several hours (or even longer) are feasible.  However,
many of the
usual Rb standards tend to have a hump in their phase and frequency
variations around
time intervals of a few seconds.

I hope this helps.

Dana

On Wed, Sep 9, 2020 at 6:40 PM donald collie donaldbcollie@gmail.com
wrote:

Hi Donald --

Over a 10 second interval, you're really looking at the short term
stability of the oscillator in the GPSDO, which could vary be several
orders of magnitude.  The GPS component will set the nominal frequency,
but the noise around nominal will be that of the OCXO.

A quite good GPSDO, like a Z3801A or Trimble Thunderbolt, can show short
term stability in the 12s, but not all will be that good.  An
inexpensive unit like the Bodnar might be more like 1 PPB.

John

On 9/9/20 7:04 PM, donald collie wrote:

Hi

Maybe a good idea to “back up” a bit here:

The most commonly plotted data for the performance of a GPSDO is ADEV.
Very simply put, to do ADEV you take a series of readings at a specific time
spacing ( called tau ). The delta frequency from one reading to the next is then
computed. You take the standard deviation of that “delta” information.

What you are looking at is the “good guess” at what the frequency will be in the
next time slot, based on what it is in this time slot. This may or may not be what
your system / measurement instruments are looking as a. spec.

The big reason ADEV exists is that it is convergent. As you take more data, the
results don’t move all over the place, they converge to a single value. Measure today,
then measure tomorrow, you get pretty much the same number.

You might want to know what the maximum frequency error compared to “absolutely
correct” is in your 10 second time period. This is a measure that is non-convergent. The
longer you collect the data, the bigger the number gets. Measure for an hour and you
get a different number compared to measuring for a day. Measure today / measure
tomorrow and you may get dramatically different results.

This is not to say that nobody ever can know what the frequency is. Only that “max” is
not a good limit for this sort of random fluctuation. Again, this is what drove the guys
at NIST to come up with ADEV back in the 1960’s. It’s what keeps us using it as a
means of comparison today.

Bob

Hi

A couple things to check:

1. Is your power supply doing odd things? It’s the first thing I’d suspect in this case.

2. Does the OCXO “behave” if you turn off the GPS ( = disconnect the antenna ) and watch
   it with a counter?

3. While the antenna is disconnected from the TBolt, hook it to something else and see how it’s doing?

4. What does. LH show for sats and all the other stuff as this is going on ?

Bob

Guess my image didn't make it, I will add it as an attachment this time.

Swapped power supplies no difference.

Antenna is on a splitter shared with a non E thunderbolt and it is
working fine along with a NTP100 and Tymserve 2100 with no complaints
from them.

I will try disconnecting the antenna and see what happens.

Thanks for the suggestions.

Kevin

On 9/10/2020 2:41 PM, Bob kb8tq wrote:

Thankyou to all who responded. It looks as if 2 parts in 10^12 is about
what can be expected - certainly much better than the 1 part in 10^9
available from  a typical double ovened quartz crystal oscillator barefoot.
Cheers!...............................................................................................................................Donald
Brett Collie

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Sep 11, 2020 at 1:15 AM Bob kb8tq kb8tq@n1k.org wrote:

On Freitag, 11. September 2020 01:08:09 CEST Kevin Schuchmann wrote:

The temperature curve seems to show some correlation to what is happening with
the DAC. Seems that the DAC and OSC jumps are mostly during periods of some
thermal perturbation.

Regards,
Matthias

Hi

Well ….

A reasonably good DOCXO will come in around 2x10^-10 over 0 to 70C. Over a
typical 4 C “lab wander” you should see < 1x10^-11. After being on power for a month
or three, aging should be below 1x10^-11 per day.

ADEV wise, it should do better than the GPSDO …..parts in 10^-13 are not unusual at
10 seconds on a typical design.

Bob

Matthias,
   You are correct, having spent hours looking at all the stable areas
and cooling and heating the gpsdo I find that when it reports that it is
116.25 F then it is stable.
So now I guess I need to figure out why it is so picky. I will measure
the current draw from a cold start and see if I see the oven warming up
and then stabilizing and then heat and cool it and see how it reacts,
and also look at the electronics and see if an area is overly sensitive
to temperature.

Thanks
Kevin

On 9/11/2020 2:26 AM, Matthias Welwarsky wrote:

I've been looking for a thunderbolt for a while, mostly because they're
such a benchmark within this group. I missed the period when they were more
commonly available and have mostly found ones that were a lot more
expensive, or had a large delivery cost due to being in Australia.

Some cheaper examples turned up on UK ebay. These aren't the classic
time-nuts ones but presumably look fairly similar to Lady Heather.

https://www.ebay.co.uk/itm/154078750287

I haven't been able to find a comparison of the various thunderbolt models.
Is there a description somewhere ? I've found a few hints about this one -
I think it's a single 48V supply and possibly a lower-quality OCXO.

On Sat, Sep 12, 2020 at 5:14 PM Kevin Schuchmann kschuchm@gmail.com wrote:

Hi

The unit your link points to is the “classic” TBolt that showed up in volume a bit
over a decade ago. That one is packaged with a (noisy) switching power supply.

There is no easy way to tell what era it is from. Indeed if it is from the 1990’s the
OCXO will not be quite as good as what’s in one from > 2002. Since the unit normally
operates locked, that’s not a real big deal.

Since Trimble used “Thunderbolt” for a whole line of parts and was not very good
at labeling devices, there is no easy way to refer to this or that specific device. That
makes coming up with a list of units a bit hard. For example - what’s the model number
of the part in that eBay listing ? ( No I don’t know either …. :) ).

Bob

Kevin,

how long has it been in storage? I expect the GPSDO doing quite clever things
to compensate for temperature effects. There may be some parameters stored on
the device and the characteristics of the OCXO may have changed after being
turned off for an extended period.

Regards,
Matthias

On Samstag, 12. September 2020 18:13:35 CEST Kevin Schuchmann wrote:

Kevin,

Can you post your Lady Heather config file and command line options that
created that image ?

George

On 9/10/2020 19:08, Kevin Schuchmann wrote:

Thanks!

The one I've seen pictured most often comes in a (I think) slightly lower
gold-coloured (alocromed) case.
e.g. http://www.sydneystormcity.com/TrimbleThunderboltGPS.jpg
Is that any different ?

I did order the one from my link so will report on any markings. The vendor
mentioned part 48050-61 but as you say, that seems to be common to all of
them.

On Sat, Sep 12, 2020 at 10:14 PM Bob kb8tq kb8tq@n1k.org wrote:

Hi

As far as anybody knows (which is a big qualifier indeed ….), the TBolt family only
does it’s “temperature compensation” stuff when it’s in holdover. While it’s locked, there
appears to be no compensation being done. If it’s doing anything while locked, it’s
learning what the TC is, so it can use that information while in holdover.

Bob

Matthias,
   It was put away for about 3 months, then powered up and ignored for
about a month as I figured it would have to settle in again.
I then started monitoring it with LH  and saw the abrupt jumps that
would not go away.

   I pulled the cover off today and the OCXO behaves as expected, cool
it and the current draw goes up, warm it and current drops.
It is stable as far as I can tell with the equipment I have.

  What I did find is the oscillator for the GPS ingest is incredibly
sensitive to temp changes, just blowing a little air through a straw at
it can cause  the unit to no longer find any usable satellites. I then
started paying more attention to the Doppler values and realized this is
where the abrupt shifts are coming from, they should be a smooth
increase or decrease depending on if the sat is approaching or receding.

  I totally missed that they are glitching, if I can hit the sweet spot
temp wise the GPS Doppler becomes smooth with no quick jumps and the
chart reflects this with a stable oscillator plot.

 So it looks like my problem is the GPS ingest section, looking at it's
oscillator it measures 12.5 MHz but I have not been able to find any
specs so far  based on the numbers on its case.

Thanks
  Kevin

On 9/12/2020 12:52 PM, Matthias Welwarsky wrote:

Hi

The unit you most commonly see is a version done for E911 cell tower upgrades.
It was an intermediate step to add that functionality before it could be done internal
to the cell base station. Once the “real” solution came along, the E911 boxes became
scrap. They went off to China to be salvaged.

The one in the listing is simply the board you normally see mated up with a power supply.
Trimble shipped them out mainly as evaluation devices. The bulk of what was produced
went into the E911 application.

There is a bunch of information on all this back in the archives 10 to 15 years ago. Searching
those archives is a bit of a challenge with all the changes in the list over the years.

Functionally, there is no difference between the one you are looking at and the more common
one. Both came in a variety of firmware versions. Both have a range of OCXO’s in them
(99% all from the same source, but changing designs over the years …). Without digging
into the exact board, there is no easy way to see what’s what. The good news is that they
all pretty much work fine.

Bob

On Samstag, 12. September 2020 23:53:39 CEST Bob kb8tq wrote:

That is interesting, why wouldn't they use the information if it's available?
Watching the temperature gives you a prediction of what is going to happen,
while watching the phase only shows what has already happened. And knowing
what's about to happen is always very favorable in control theory.

Hi

The point is that there is no need to compensate the part while it is locked.
It meets all the specs required of it by virtue of the lock to GPS. The big issue
on these devices ( = cell tower GPSDO’s) is holdover. That’s where all the
magic comes in.

Indeed, trying to compensate and learn at the same time generates even
more issues to deal with. The temperature effect is not a simple linear / first
order sort of thing ….

Bob

But doesn't the compensation help generate a feed-forward term, a way to
make the integrator better managed ?

On Sun, Sep 13, 2020 at 2:31 PM Bob kb8tq kb8tq@n1k.org wrote:

Hi

Not done that way in this case. Keep in mind that the “stock” configuration only runs a loop time
constant in the 10’s of seconds.

On the TBolt, the main source of temperature error is the DAC. Tossing a bit more “stuff” at that
part of the design would have been higher on the list than playing with compensation. It met the
spec so why spend the money …..

Bob

Bob kb8tq writes:

Data point:

20 years ago, I needed to buy a batch of a dozen OCXO's for hand-built
NTP servers for the new danish ATC network.

This is where the Soekris 4501 trick comes from, and I wanted a
frequency I could feed directly to the Soekris if at all possible.

I ended up "buying into" an existing production run of IsoTemp
OCXO-0131's at 32.768 MHz spec'ed for "some telco application".

I attach a 16 year long plot of the frequency error for one of
the servers on my side of the firewall-of-doom.

(There were a network misconfiguration, so the data from middle of
2011 to end of 2015 is not valid - long story, mostly about fibers
and backhoes)

It took this one five years to "settle in", but for the last decade
it has consistently drifted 2.2e-9/year = 7e-16/second.

The software PLL in these NTP servers did model drift and we tested
that, unplugging the GPS antenna on one server.

After 18 weeks in hold-over it had still not drifted out of spec.

In the 19th week, they added two 3.5" disks to a server mounted in
the same rack, literally opening the rack-door, checking the dymo
to make sure they had the right server, pulling out the spacers,
stuck in the disks, clsoed the rack-door and left the room.

The plot for that server clearly shows a change in OCXO-behaviour
and 121 hours later, the NTP finally wandered out of spec.

Other tests rules out thermal causes, so our conclusion is that
either the vibration from the intervention or from the rotation
of the two new disks did it.

My personal conclusion is that high-order PLL's are fun, but they
require patience on a timescale of years and you need not bother
unless you have a very benign environment.

Poul-Henning

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

On Sonntag, 13. September 2020 15:05:36 CEST Bob kb8tq wrote:

It depends. For short time constants, yes, likely the control loop is able to
follow the temperature-induced drift of the OCXO. But you might want the TC to
be as long as possible. Naturally, the control loop becomes very slow to
react. By following the temperature, you have an additional input that allows
the controller to act more quickly to a changing environment. Effectively this
will lead to higher stability of the output.

Maybe, but a linear approximation is probably better than nothing as it still
reduces the amount of change that the control loop has to counteract.

If you look at the attached screenshot - there's roughly 5500 seconds of data
from my GPSDO. At about 2500 seconds the temperature compensation was engaged.
It's just a linear correction factor for the DAC output. The factor was
computed using a linear regression fit to find the correlation between the
temperature and the OCXO drift. In the DAC chart the blue trace is the actual,
corrected DAC output, the orange trace is the uncorrected DAC computed from
the TIC input. The green trace is the OCXO drift. Without the temperature
compensation, the TIC takes a dive down to almost -15ns. While the temperature
continues its decline at an approximately constant rate, after the
compensation was engaged the TIC excursions are smaller and therefore the
stability of the output higher.

Now, of course the picture gets somewhat muddy if you keep computing the
compensation factor while the compensation is active, but what you still get
is a residual factor, which you can maybe use to refine the compensation
subsequently. The correlation factor (r_xy) will tell if there's still
something to be done.

Matthias Welwarsky writes:

The word you are looking for here is not "Temperature Coefficient"
but "Thermal Impedance" (more on this below).

Only if you first spend months and years measuring all the parameters
and time constants of the multiphysics model you use, well enough
to make useful predictions with it.

No, it is usually worse.

A major part of the trouble is the complex hysteresis-effects when
the temperture changes direction: The components which warm fast
also cools fast.

For example:  When the temp goes up you will likely find that your
DAC warms faster than the XTAL, but when the temp goes down it also
cools faster than the XTAL.

That means the temperature difference between the DAC and XTAL depends
on the temperature rising or dropping, so you have to model the tempco
and temperature of them individually.

This is nowhere near enough data to show anything.  Collect a full
week with/without and we can talk.

In the end, the proof is in your allan-variance, if it improves, you got
something, if it does not, you wasted your time.

The easiest and cheapest way for you to get better results, is to increase
the thermal impedance between the surroundings and your GPSDO.

That will make the temperature change slower, which also means it
changes less and therefore your hysteresis effects also get smaller.

Note that "thermal impedance" is not the same as "thermal insulation":

Thermal insulation materials have high thermal resistance and low
thermal mass, and wrapping your GPSDO in that would just make it
run hot.

Think of it is a thermal RC filter with a huge resistor and a small
capacitor.

We want the a low to moderate resistor, so the GPSDO can still dump
its heat, with a huge capacitor to filter out the changes in
temperature.

Apart from the entire "get electronics wet" thing, water would have
been near perfect.

Table-top granite (about 2cm thick) is really great, but not very accessible.

Metals almost conduct heat too well, but a box of 1-5cm thick iron
plates works great, but pay attention to the weight.

For most of us, concrete is the way to go:

Get three cinderblocks of the kind that looks like a 'H' with two
horizontal bars.

Put the first cinderblock down on its side.

Put the next cinderblock on top of it in normal orientation.

Put your OCXO into the cavity.

Hack notches in the edge of the cinderblock for the cables.

Put the third cinderblock on top, also on its side.

You have now increased the thermal impedance by almost two orders
of magnitude, and your PLL will be boooooored.

If need be, you can make the central cavity more air-tight by
"sealing" between the cinderblocks with a layer of cloth or
tissue-paper.

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

On Mon, Sep 14, 2020 at 10:36 AM Poul-Henning Kamp phk@phk.freebsd.dk wrote:

There are alternatives to water...
https://www.3m.co.uk/3M/en_GB/novec-uk/applications/immersion-cooling/

Cheers

Arne

In 1973 I moved for TI to Dallas and had a 20 foot hole drilled to place my Sulzer One alternate.. Today I monitor my lab closely to better understand what to do. The monitor is placed on the top of the HP5065A  which stands on its sides.Attached monitor data that shows when I had a 3 hour power outage including no AC but also pressure now with a storm 120 miles west.Bert Kehren  In a message dated 9/14/2020 5:36:48 AM Eastern Standard Time, phk@phk.freebsd.dk writes: 

Matthias Welwarsky writes:

The word you are looking for here is not "Temperature Coefficient"
but "Thermal Impedance" (more on this below).

Only if you first spend months and years measuring all the parameters
and time constants of the multiphysics model you use, well enough
to make useful predictions with it.

No, it is usually worse.

A major part of the trouble is the complex hysteresis-effects when
the temperture changes direction: The components which warm fast
also cools fast.

For example:  When the temp goes up you will likely find that your
DAC warms faster than the XTAL, but when the temp goes down it also
cools faster than the XTAL.

That means the temperature difference between the DAC and XTAL depends
on the temperature rising or dropping, so you have to model the tempco
and temperature of them individually.

This is nowhere near enough data to show anything.  Collect a full
week with/without and we can talk.

In the end, the proof is in your allan-variance, if it improves, you got
something, if it does not, you wasted your time.

The easiest and cheapest way for you to get better results, is to increase
the thermal impedance between the surroundings and your GPSDO.

That will make the temperature change slower, which also means it
changes less and therefore your hysteresis effects also get smaller.

Note that "thermal impedance" is not the same as "thermal insulation":

Thermal insulation materials have high thermal resistance and low
thermal mass, and wrapping your GPSDO in that would just make it
run hot.

Think of it is a thermal RC filter with a huge resistor and a small
capacitor.

We want the a low to moderate resistor, so the GPSDO can still dump
its heat, with a huge capacitor to filter out the changes in
temperature.

Apart from the entire "get electronics wet" thing, water would have
been near perfect.

Table-top granite (about 2cm thick) is really great, but not very accessible.

Metals almost conduct heat too well, but a box of 1-5cm thick iron
plates works great, but pay attention to the weight.

For most of us, concrete is the way to go:

    Get three cinderblocks of the kind that looks like a 'H' with two
    horizontal bars.

    Put the first cinderblock down on its side.

    Put the next cinderblock on top of it in normal orientation.

    Put your OCXO into the cavity.

    Hack notches in the edge of the cinderblock for the cables.

    Put the third cinderblock on top, also on its side.

You have now increased the thermal impedance by almost two orders
of magnitude, and your PLL will be boooooored.

If need be, you can make the central cavity more air-tight by
"sealing" between the cinderblocks with a layer of cloth or
tissue-paper.

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

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Hi

At that point the part meets all relevant specifications. The customer is happy
( = it meets spec). Any further work on the part simply increases the cost of the
device. Why would you do this if it already is fully spec compliant ?

If you spend a few years digging into this and trying various approaches, be sure
to apply the same firmware to multiple devices. If it all is a “learning” process. How
do you suggest training? The “worst case” will always be an excursion outside the
normal variation the part sees…..

If the data is collected in a formal fashion (via temperature test) and then programmed
into the device, how stable is it long term? How is it impacted by air flow and unit
orientation? ( hint: a lot ….).

Not cheap or easy …..

Bob

ew via time-nuts writes:

When we built our new house I wanted to build some kind of "clock
vault", but however I looked at it, it was either far too expensive
or impossible to get planning permission for due to the ground water
protection zoning.

I later talked to a geologist who knows the Danish underground well,
and he estimated I would have needed to drill to at least 25m depth
to escape seasonal temperature-changes and cited a research paper
from the 1950'ies where the did precisely that experiment.

He also mentioned something I had not thought about my self: The
ø=15cm end-capped dry steel-pipe I was dreaming of would have been
subject to a LOT of upward boyancy force.

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

shouldbe q931 writes:

For very, very specific use-cases, yes.

I have hard time seeing anybody dunk their OCXO or Rb...

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

I received one of these thunderbolts. It seems to work (currently
handicapped by an inadequate antenna) and is labelled P/N 48050-61  D/C
0331 on the outside.
The firmware is 3.00 and the OCXO labelled 37265 10.000000 MHz B11859-17495
0310.

On Sat, Sep 12, 2020 at 10:43 PM Adrian Godwin artgodwin@gmail.com wrote: