Re: [time-nuts] Q/noise of Earth as an oscillator

42 On Sat, Jul 23, 2016 at 7:59 PM, Hal Murray wrote: > > t...@leapsecond.com said: > > Earth is a very noisy, wandering, drifting, > incredibly-expensive-to-measure, > > low-precision (though high-Q) clock. > > What is the Q of the Earth? It might be on one of your

Re: [time-nuts] Venus838LPx-T opinions?

In timing mode, you care very much about the quantization error messages. Bob  - AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Gary E. Miller To: Mark Sims

[time-nuts] Q/noise of Earth as an oscillator

t...@leapsecond.com said: > Earth is a very noisy, wandering, drifting, incredibly-expensive-to-measure, > low-precision (though high-Q) clock. What is the Q of the Earth? It might be on one of your web pages, but I don't remember seeing it. Google found a few mentions, but I didn't find a

Re: [time-nuts] Venus838LPx-T opinions?

Yo Mark! On Sat, 23 Jul 2016 17:13:27 + Mark Sims wrote: > Yes, no Venus binary messages for sky view or sawtooth correction. > Those are only available in NMEA. But to make effective use of a > timing receiver you should be running it in binary where you can >

Re: [time-nuts] Precision DACs (was: NCOCXO anyone?)

The AD5791 evaluation board has an unpopulated area for what appears to be an LTZ1000 reference circuit. Bruce On Sunday, 24 July 2016 7:00 AM, Attila Kinali wrote: On Fri, 22 Jul 2016 12:15:25 -0500 David wrote: > If you expect analog

Re: [time-nuts] NIST UT1 NTP server results

Hi Mike, > Interesting plots. A couple of points. > 1. These look like the data points are taken at 0h and without intermediary > measurements as the data points are connected by straight line segments. > If we don’t know what the intermediary data points are, the plots, to my mind, > should be

Re: [time-nuts] NIST UT1 NTP server results

On Sat 2016-07-23T12:36:21 -0700, Tom Van Baak hath writ: > I've always been curious about the conflict between accuracy and > stability with these various time scales. > > If the purpose of a UTx clock is long-term timekeeping, then I can > see that smoothing is helpful. OTOH, if the purpose of

Re: [time-nuts] NIST UT1 NTP server results

> Le 23 juil. 2016 à 21:56, Tom Van Baak a écrit : > > To further clarify my question about which UTx timescale to use with NTP, or > if or how to interpolate the values I've attached two plots from IERS for the > past 60 days. > > BTW, notice last week we had another

Re: [time-nuts] NIST UT1 NTP server results

To further clarify my question about which UTx timescale to use with NTP, or if or how to interpolate the values I've attached two plots from IERS for the past 60 days. BTW, notice last week we had another rare moment -- where the Earth had a near perfect 86400.0 second day! My question

Re: [time-nuts] NIST UT1 NTP server results

> If this turns into a serious thing then it deserves consideration > whether such servers should be UT1, or instead UT2. Hi Steve, I've always been curious about the conflict between accuracy and stability with these various time scales. If the purpose of a UTx clock is long-term

[time-nuts] Precision DACs (was: NCOCXO anyone?)

On Fri, 22 Jul 2016 12:15:25 -0500 David wrote: > If you expect analog specifications in line with the claimed digital > resolution of ADCs and DACs, you will be disappointed. 20 bits is > about where they top out no matter how many bits are available; the > best you can

Re: [time-nuts] LSEM (Leap Second Every Month)

Hi Tom: I'm not worried about a single second, but rather an accumulation of them over many years leading to making sundials obsolete. The map is centered on China (PS the Chinese symbol for china is a circle with a vertical line i.e. China is the center of the world) and all of China is on

[time-nuts] Venus838LPx-T opinions?

Yes, no Venus binary messages for sky view or sawtooth correction. Those are only available in NMEA. But to make effective use of a timing receiver you should be running it in binary where you can properly monitor and control it. Whoever did the Venus binary commands did not think things

Re: [time-nuts] NIST UT1 NTP server results

HI I agree that there are more considerations than simply changing the world over to UT1. My guess is that the TimeNuts list is unlikely to answer those questions. We *could* get a handful of servers running. Experimenting with them is likely a prerequisite to any change down the road. Bob >

Re: [time-nuts] NIST UT1 NTP server results

On Sat 2016-07-23T10:10:07 -0400, Bob Camp hath writ: > Ok, so now what we need are at least 5 other public UT1 NTP servers so you > can properly > synch up to a set of them. If this turns into a serious thing then it deserves consideration whether such servers should be UT1, or instead UT2.

Re: [time-nuts] NIST UT1 NTP server results

Hi Ok, so now what we need are at least 5 other public UT1 NTP servers so you can properly synch up to a set of them. Bob > On Jul 23, 2016, at 8:47 AM, Mike Cook wrote: > > As I suspected NTP client handles the UT1 data ok if there is just that > server configured. >

Re: [time-nuts] NIST UT1 NTP server results

As I suspected NTP client handles the UT1 data ok if there is just that server configured. The only issue is that the current UT1 stream has steps at 0h which NTP takes time to sync to if slewing is enabled. About 2000s in fact. The step size is far less than the max offset allowed and so

Re: [time-nuts] Venus838LPx-T opinions?

Mark wrote: Oh, and besides the lack of a binary message with satellite position/signal levels, there is none that reports the sawtooth error. How in the world can they call it a "timing receiver" if it doesn't even support sawtooth correction?? Good grief. Also, I see they claim 6nS

Re: [time-nuts] Venus838LPx-T opinions?

The NMEA STI,00 message gives a sawtooth correction. I believe what Mark was saying was that there was no *binary* message that said so… maybe? I dunno. But the datasheet clearly talks about PPS quantization error compensation: STI,00 – 1 PPS timing report An output message, id 0x0, contains