Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?
Yo Tom!
On Wed, 8 Nov 2017 09:31:01 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
How exactly do you measure offset of your GPS time output to
absolute UTC time?
Conceptually it's no different from measuring your favorite resister
or thermometer: you compare your DUT against a standard REF and the
difference is your error, a process called calibration.
Yup, I worked in metrology for a while. John Fluke Mfg Co., Inc.
Calibrating your UTC is harder.
Yup.
Here are couple examples:
That's enough reading to keep you busy for a few days.
Yup, I will, thanks. Now when was the last time you did that absolute
calibration of a GPS receiver to UTC? Can we see the results?
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
On Wed, November 8, 2017 12:55 pm, Gary E. Miller wrote:
I knew about the errata, I left out that detail to see when someone
actually read my citation.
OK, I don't want to quibble about versions, and whether the "latest
version" is 200H or 200H including errata, but I think we both agree that
the currently operating performance would be described by the rollup
document, i.e. the offset information for GPS time to UTC time should be
within 20ns 1 sigma, as opposed to the older 90 ns 1 sigma description.
So yes, UTC from a GPS is now 20 ns (one sigama). What I said about
+/- 13 ns being noise relative to the spec still applies.
Yes, and at that point I think you have to start getting into more precise
language about whether you care about worst case, average, or "typical"
performance. One of the graphs that Tom referenced a day or two ago
seemed to show that the typical performance was better than 20ns, so is
20ns a guaranteed performance, a desired performance level (and better
than that is good), or the measured performance level?
Do you now see how measured GPS time/location can be very precise, but
UTC from a GPS less so? Have you read the entire 3.3.4?
Yes, and I do not really understand the "1 sigma" description. Is the
error really random? I'm not sure how the term 1 sigma applies to error
distributions other than a Gaussian distribution, so what "20 ns at 1
sigma" really means moment to moment for the time value I get from a GPS
receiver is not completely clear to me. At a simplistic level I would
interpret that 66% of the PPS ticks are within 20ns of the "true" UTC
tick, 33+% could be farther away than 20ns from "true" second tick.
The general interest in GPS based time transfer covers a wide range of
uses, so whether you actually care about absolute offset from UTC or not
needs to be made more explicit in discussions about vaguely defined
"performance." I think in earlier emails there was some confusion about
what "performance" actually referenced, since in a lot of use cases a
fixed error offset from UTC is less important than varying offset, some
people just need a well defined second tick, so whether the position of
those ticks is within 2ns, 20ns, or 200ns of nominal UTC may not matter at
all. Other uses may care about UTC, so there is not necessarily a one
size fits all single number for "performance" that everyone will agree
with.
--
Chris Caudle
On Wed, 8 Nov 2017 14:24:08 -0600
"Chris Caudle" chris@chriscaudle.org wrote:
On Wed, November 8, 2017 12:55 pm, Gary E. Miller wrote:
I knew about the errata, I left out that detail to see when someone
actually read my citation.
OK, I don't want to quibble about versions, and whether the "latest
version" is 200H or 200H including errata, but I think we both agree that
the currently operating performance would be described by the rollup
document, i.e. the offset information for GPS time to UTC time should be
within 20ns 1 sigma, as opposed to the older 90 ns 1 sigma description.
The GPS standard only specifies a target value, what they want to achieve.
The actual value has been consistenly better than what is described in the
standard for decades. Why standard not updated, you ask? Because in a
standard you want to be conservative. People rely on that value and if
anything happens and for some reason that value gets much worse than usual,
you still want tto be within specs.
Do you now see how measured GPS time/location can be very precise, but
UTC from a GPS less so? Have you read the entire 3.3.4?
Yes, and I do not really understand the "1 sigma" description. Is the
error really random? I'm not sure how the term 1 sigma applies to error
distributions other than a Gaussian distribution, so what "20 ns at 1
sigma" really means moment to moment for the time value I get from a GPS
receiver is not completely clear to me. At a simplistic level I would
interpret that 66% of the PPS ticks are within 20ns of the "true" UTC
tick, 33+% could be farther away than 20ns from "true" second tick.
This is what it means. The distribution is not completely gaussian.
There are some periodic (12h, 24h, and various others) contents that
look more sinusoidal than random, but if you look at the raw distribution,
without extracting any of the periodic components, it looks quite gaussian.
The general interest in GPS based time transfer covers a wide range of
uses, so whether you actually care about absolute offset from UTC or not
needs to be made more explicit in discussions about vaguely defined
"performance."
If you are really doing time transfer using GPS and you care about
performance. Then you are using at least common-in-view mode with some
heavy post-processing. This brings you close to a 5ns one-sigma uncertainty.
If you calibrate your GPS receivers frequently, you can get down to 200ps.
(over a few 100km baseline).
If you need better than that, you go to Timetech ( http://www.timetech.de/ )
and ask them to loan you one of the TWSTFT systems.
Attila Kinali
--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering. -- The Doctor