[time-nuts] ublox NEO-M8T improved by insulated chamber?

[Chris Caudle]

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