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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
