Trimble thunderbolt accuracy expectations
A couple of weeks back I caught my thunderbolt way out of lock, and doing
some sort of weird sawtooth oscillation in the DAC and PPS reading causing
the PPS alignment to swing +-50ns or so away from correct alignment (based
on some +-10ns GPS receivers I have here). After lots of attempts at
various things, I finally issued it a 'factory reset' command and it seems
to be a lot more healthy, but I'm not convinced this is as healthy as it
should be. In particular, I seem to be getting an ADEV around 4.2e-10 at
1 tau, and 1.5e-12 at 1e5 tau which seems too high, based on various
discussions I've found on the net.
Seems like a good excuse to finally take the time to understand this unit,
and also start down the path of trying to get as accurate of a clock here
as possible within resonable financial constraints. I'm primarily
interested in getting a highly-accurate UTC-aligned 1PPS source.
Alignment to UTC is the primary goal, as this is in support of various
projects which rely on UTC aligned pulses. An accurate 10Mhz frequency
source is only a nice side effect. I should note that the thunderbolt has
(until now) been more than adequate for past projects, but I'm always
wanting something better... sounds like lots of people on this list
understand that disease.
So...back to the issue at hand: I'm now trying to finally figure out how
understand all of the parameters and also trying to get my head around the
interrelation between all of the parameters. I also understand that
there's some tuning possibilities which I'm looking at as well. I haven't
yet opened it up to see what OCXO is in it. I'd appreciate some guidance
as to what others look for when ascertaining the health of a thunderbolt,
and what I should be expecting as far as ranges on things that matter like
ADEV.
One parameter in particular that I'm trying to figure out how to determine
is what the expected offset from UTC/GPS is, i.e. +- a certain number of
ns. I'd like to be able to look at the unit and determine how healthy it
is, and what level of uncertainty I should expect. I know the ADEV is
based on the deviation of the PPS signal, but it doesn't sound like it's
related to the deviation from the UTC second. I also see the PPS
parameter up at the top in Lady Heather, but this doesn't seem like it's
what I'm looking for. Can someone clarify this for me?
--
Forrest Christian, AC7DE CEO*, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forrestc@imach.com | http://www.packetflux.com
http://www.linkedin.com/in/fwchristian http://facebook.com/packetflux
http://twitter.com/@packetflux
Hi
I agree that your TBolt likely had some sort of issue. That probably needs to be
tracked down independent of any other “quest”. First recommendation would be
to run the filter tune stuff in LH.
Accuracy, stability, and repeatability are all different things. They do bump into
each other from time to time. ADEV measures stability. Good ADEV is something
people do focus on. In a GPSDO, it may not go hand in hand with good accuracy.
Lots of corrections may give you good accuracy and lousy ADEV.
The biggest issue (even if you are NIST) with UTC accuracy are static offsets. The
delay through a piece of coax can be calculated. Delay through an antenna or a
receiver, maybe not so much. Since all antennas and receivers exhibit a delay,
comparing one to another may not be the best solution. There are relatively cheap
GPS simulators that claim nanosecond level accuracy. Rigging them to work with
this or that GPS may or may not be very easy.
The next layer to this is the ionosphere. We go round and round about this. It’s not
an easy thing to dig into. GPS has a model of the ionosphere that it updates. The
model is not very complex. It is not updated minute to minute. If you have a lot of
sunspot activity, this can be an issue. If you are at the low point in a cycle, it may not
be as big a deal. L1/L2 receivers are one way to help with this in an active situation.
Over a lot of years, people have popped up with the observation that the best thing to
do with a clock is to just let it run. Don’t try to adjust it. Don’t poke at it. Don’t move it
around. Don’t change it’s environment. Just leave it alone. Observe it’s rate and compensate
for that rate with math.
Expanding any system to multiple devices tends to help reduce errors. Ten clocks
(each made a different way) are likely to each have their own odd behavior. The result
of looking at them as a group will be a better thing than just looking at any one of them.
There are a number of papers on this going back over a lot of years.
So enough yack, what’s the suggestion?
Set up a group of free running clocks and the gear to monitor them to something like 1 ns.
That’s not a massive endeavor these days. There are a lot of ways to do it on the cheap.
Set up something with good short term stability (OCXO maybe?) and synthesize your pps
from it. Aim for the same ~1 ns step level. Again, not a crazy hard number with the kind
of stuff that’s out there today.
Feed your data into a PC and look at what’s going on. Steer the PPS as best you can to
match GPS. Get the GPS to UTC offsets from the various internet sources. You have an offset
from GPS to NIST or USNO. You also have an offset from USNO or NIST to BIH. Correct for them
in your processing. Will. you hit 1 ns as a result or will you “only” get to 10 ns? Time will tell….
With 1 ns steps, the ADEV of your pps will not be super duper (when it steps). Your accuracy
will more likely be limited by things other than that 1 ns resolution. If you get to the point that
1 ns is the issue, there are ways to bump things up by an order of magnitude without spending
an infinite amount of money.
Also remember, once you move a foot, your 1 ns time needs to be corrected …..
Bob
On Dec 3, 2017, at 8:41 AM, Forrest Christian (List Account) lists@packetflux.com wrote:
A couple of weeks back I caught my thunderbolt way out of lock, and doing
some sort of weird sawtooth oscillation in the DAC and PPS reading causing
the PPS alignment to swing +-50ns or so away from correct alignment (based
on some +-10ns GPS receivers I have here). After lots of attempts at
various things, I finally issued it a 'factory reset' command and it seems
to be a lot more healthy, but I'm not convinced this is as healthy as it
should be. In particular, I seem to be getting an ADEV around 4.2e-10 at
1 tau, and 1.5e-12 at 1e5 tau which seems too high, based on various
discussions I've found on the net.
Seems like a good excuse to finally take the time to understand this unit,
and also start down the path of trying to get as accurate of a clock here
as possible within resonable financial constraints. I'm primarily
interested in getting a highly-accurate UTC-aligned 1PPS source.
Alignment to UTC is the primary goal, as this is in support of various
projects which rely on UTC aligned pulses. An accurate 10Mhz frequency
source is only a nice side effect. I should note that the thunderbolt has
(until now) been more than adequate for past projects, but I'm always
wanting something better... sounds like lots of people on this list
understand that disease.
So...back to the issue at hand: I'm now trying to finally figure out how
understand all of the parameters and also trying to get my head around the
interrelation between all of the parameters. I also understand that
there's some tuning possibilities which I'm looking at as well. I haven't
yet opened it up to see what OCXO is in it. I'd appreciate some guidance
as to what others look for when ascertaining the health of a thunderbolt,
and what I should be expecting as far as ranges on things that matter like
ADEV.
One parameter in particular that I'm trying to figure out how to determine
is what the expected offset from UTC/GPS is, i.e. +- a certain number of
ns. I'd like to be able to look at the unit and determine how healthy it
is, and what level of uncertainty I should expect. I know the ADEV is
based on the deviation of the PPS signal, but it doesn't sound like it's
related to the deviation from the UTC second. I also see the PPS
parameter up at the top in Lady Heather, but this doesn't seem like it's
what I'm looking for. Can someone clarify this for me?
--
Forrest Christian, AC7DE CEO*, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forrestc@imach.com | http://www.packetflux.com
http://www.linkedin.com/in/fwchristian http://facebook.com/packetflux
http://twitter.com/@packetflux
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.
If UTC accuracy is your goal then the practical limits are well-established.
National labs operating clock ensembles (multiple Cs , H-masers) with
calibrated time links ( GPS, two way satellite time- transfer) and steering
them to UTC with predictive algorithms typically achieve 5 to 10 ns
accuracy to UTC.
Calibration of GPS receiver + antenna delays can be done with one of BIPM's
travelling receivers to an accuracy of about 1.5 ns. The uncertainty
increases to 2.5 ns when this is transferred to another receiver - this is
what you would get if your system was calibrated by one of the national
labs whose receiver is calibrated directly by the BIPM.
Realising this accuracy requires post-processing of time-transfer data with
precise antenna co-ordinates, satellite ephemeris etc.
Absolute calibration of delays using a GNSS simulator as Bob suggests is a
bit trickier than it first appears because of the need to include the
antenna. This is usually done in a microwave anechoic chamber but this may
be overkill for timing.
Cheers
Michael
On Mon, 4 Dec 2017 at 3:44 am, Bob kb8tq kb8tq@n1k.org wrote:
Hi
I agree that your TBolt likely had some sort of issue. That probably needs
to be
tracked down independent of any other “quest”. First recommendation would
be
to run the filter tune stuff in LH.
Accuracy, stability, and repeatability are all different things. They do
bump into
each other from time to time. ADEV measures stability. Good ADEV is
something
people do focus on. In a GPSDO, it may not go hand in hand with good
accuracy.
Lots of corrections may give you good accuracy and lousy ADEV.
The biggest issue (even if you are NIST) with UTC accuracy are static
offsets. The
delay through a piece of coax can be calculated. Delay through an antenna
or a
receiver, maybe not so much. Since all antennas and receivers exhibit a
delay,
comparing one to another may not be the best solution. There are
relatively cheap
GPS simulators that claim nanosecond level accuracy. Rigging them to work
with
this or that GPS may or may not be very easy.
The next layer to this is the ionosphere. We go round and round about
this. It’s not
an easy thing to dig into. GPS has a model of the ionosphere that it
updates. The
model is not very complex. It is not updated minute to minute. If you have
a lot of
sunspot activity, this can be an issue. If you are at the low point in a
cycle, it may not
be as big a deal. L1/L2 receivers are one way to help with this in an
active situation.
Over a lot of years, people have popped up with the observation that the
best thing to
do with a clock is to just let it run. Don’t try to adjust it. Don’t poke
at it. Don’t move it
around. Don’t change it’s environment. Just leave it alone. Observe it’s
rate and compensate
for that rate with math.
Expanding any system to multiple devices tends to help reduce errors. Ten
clocks
(each made a different way) are likely to each have their own odd
behavior. The result
of looking at them as a group will be a better thing than just looking at
any one of them.
There are a number of papers on this going back over a lot of years.
So enough yack, what’s the suggestion?
Set up a group of free running clocks and the gear to monitor them to
something like 1 ns.
That’s not a massive endeavor these days. There are a lot of ways to do it
on the cheap.
Set up something with good short term stability (OCXO maybe?) and
synthesize your pps
from it. Aim for the same ~1 ns step level. Again, not a crazy hard number
with the kind
of stuff that’s out there today.
Feed your data into a PC and look at what’s going on. Steer the PPS as
best you can to
match GPS. Get the GPS to UTC offsets from the various internet sources.
You have an offset
from GPS to NIST or USNO. You also have an offset from USNO or NIST to
BIH. Correct for them
in your processing. Will. you hit 1 ns as a result or will you “only” get
to 10 ns? Time will tell….
With 1 ns steps, the ADEV of your pps will not be super duper (when it
steps). Your accuracy
will more likely be limited by things other than that 1 ns resolution. If
you get to the point that
1 ns is the issue, there are ways to bump things up by an order of
magnitude without spending
an infinite amount of money.
Also remember, once you move a foot, your 1 ns time needs to be corrected
…..
Bob
On Dec 3, 2017, at 8:41 AM, Forrest Christian (List Account) <
lists@packetflux.com> wrote:
A couple of weeks back I caught my thunderbolt way out of lock, and doing
some sort of weird sawtooth oscillation in the DAC and PPS reading
causing
the PPS alignment to swing +-50ns or so away from correct alignment
(based
on some +-10ns GPS receivers I have here). After lots of attempts at
various things, I finally issued it a 'factory reset' command and it
seems
to be a lot more healthy, but I'm not convinced this is as healthy as it
should be. In particular, I seem to be getting an ADEV around 4.2e-10
at
1 tau, and 1.5e-12 at 1e5 tau which seems too high, based on various
discussions I've found on the net.
Seems like a good excuse to finally take the time to understand this
unit,
and also start down the path of trying to get as accurate of a clock here
as possible within resonable financial constraints. I'm primarily
interested in getting a highly-accurate UTC-aligned 1PPS source.
Alignment to UTC is the primary goal, as this is in support of various
projects which rely on UTC aligned pulses. An accurate 10Mhz frequency
source is only a nice side effect. I should note that the thunderbolt
has
(until now) been more than adequate for past projects, but I'm always
wanting something better... sounds like lots of people on this list
understand that disease.
So...back to the issue at hand: I'm now trying to finally figure out how
understand all of the parameters and also trying to get my head around
the
interrelation between all of the parameters. I also understand that
there's some tuning possibilities which I'm looking at as well. I
haven't
yet opened it up to see what OCXO is in it. I'd appreciate some
guidance
as to what others look for when ascertaining the health of a thunderbolt,
and what I should be expecting as far as ranges on things that matter
like
ADEV.
One parameter in particular that I'm trying to figure out how to
determine
is what the expected offset from UTC/GPS is, i.e. +- a certain number of
ns. I'd like to be able to look at the unit and determine how healthy
it
is, and what level of uncertainty I should expect. I know the ADEV is
based on the deviation of the PPS signal, but it doesn't sound like it's
related to the deviation from the UTC second. I also see the PPS
parameter up at the top in Lady Heather, but this doesn't seem like it's
what I'm looking for. Can someone clarify this for me?
--
Forrest Christian, AC7DE CEO*, PacketFlux Tec
https://maps.google.com/?q=hristian,+AC7DE*+*CEO**,+PacketFlux+Tec&entry=gmail&source=ghnologies,
Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forrestc@imach.com | http://www.packetflux.com
http://www.linkedin.com/in/fwchristian <
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.
On Sun, Dec 3, 2017 at 8:41 AM, Forrest Christian (List Account) <
lists@packetflux.com> wrote:
One parameter in particular that I'm trying to figure out how to determine
is what the expected offset from UTC/GPS is, i.e. +- a certain number of
ns. I'd like to be able to look at the unit and determine how healthy it
is, and what level of uncertainty I should expect. I know the ADEV is
based on the deviation of the PPS signal, but it doesn't sound like it's
related to the deviation from the UTC second. I also see the PPS
parameter up at the top in Lady Heather, but this doesn't seem like it's
what I'm looking for. Can someone clarify this for me?
Lady Heather can't tell you the quality of what the GPSDO outputs. Without
a better reference to compare against, the best you can do is infer from
some "normal operation" parameters, that it your unit is likely operating
within spec.
First, some background about my unit:
I'm currently running with a time constant of 1000 seconds, and a dampening
of 1.2, with the DAC at around 2.1062 Volts. I have the satellite mask set
for 10 degrees and 4 AMU; more restrictive values were found to be unusable
because of the lack of a full sky view.
I strongly recommend using much faster settings initially, like 100 seconds
and 0.7 dampening, and letting it run like that until the DAC trend stays
mostly horizontal over at minimum a week-long 360 minute/div view. It can
take a while (days, months, or 2 years in my case).
My Thunderbolt E has shown some behaviours that can be exhibited when there
is poor satellite coverage:
-
There is no window for what is considered a valid offset, so the unit
will chase wildly erroneous values. -
Hold-over algorithm seems to fail with multiple short back-to-back
outages, or constellation changes. This behaviour is probably related to
#1. A minimum-valid timer would also have helped here.
It typically takes my unit 3 days to recover from a poor-reception event
with wildly erroneous offsets, which would typically last nearly 3 hours.
Though, I've not had such an event since the unit stabilized recently
(perhaps luck).
What I, a total amateur, look for in Lady Heather:
-
Low DAC span, and predominantly horizontal trend over an 60 minute/div
view, with some drift trend possibly showing over 360 minute/div or 1440
minute/div views. Expect some relationship to temperature change, with the
DAC having to compensate for all the electronics located outside the
crystal oven, which includes the DAC itself. -
PPS rms around 3 ns (roughly 1 meter) and under 10 ns. I think mine is
reporting just under 6 ns, last I looked. Don't know if this is good or
bad, but it seems reasonable to me. The relative amount of cloud cover
seems to affect this value slightly (lower during periods of clear sky). -
Temperature can largely be ignored, until you see a trend that doesn't
make sense.
Make sure to properly terminate the outputs, and keep the loads driven
constant, as there is a definite dependence on output loading!
~~
Andrew E. Mileski