[time-nuts] More ES100 WWVB Measurements

[paul swed]

This is good work and I have been following.
What caught my attention was the 2 X very fast codes. I remember talking to
the everset folks early on and the high speed code could be turned on. It
had not been. The ES100 will not track that code as mentioned. Did not
think they actually ever turned it on.
More likely a power cycle left the system turned on. A bit of humor. If
John Lowe is still around send him a email he could turn it off.
Regards
Paul
WB8TSL

On Mon, Dec 31, 2018 at 7:05 AM Tom Van Baak <tvb at leapsecond.com> wrote:

> Hi Graham,
>
> That's very nice work. And you have uncovered several unusual effects in
> the ES100. Bugs? Features? If we time nuts keep up the good work to
> evaluate this chip, we are likely at some point to get an informative
> response from the guys who designed it. They read time-nuts.
>
> So now both you and Tim have observed the off-by-one-second (or
> off-by-N-seconds) effect in the ES100. I wonder if this explains why some
> of my ES100-based La Crosse 1235UA Ultratomic wall clocks are off by a
> second sometimes.
>
> My main question: in your "Time Plot.PNG" plot, what is the cause of the
> sawtooth pattern? The points are almost all on a clear negative slope,
> though bounded by roughly +/- 75ms. Looking on the far left, I see a time
> drift of +50 ms to -25 ms over an hour, which is equivalent to a -20 ppm
> frequency offset; about -2 seconds/day.
>
> Do you think this is due to the 16 MHz onboard xtal? If so, how about
> changing the temperature of the eval board by a lot (say, several tens of
> degrees) for an extended time (say, 4 hours) and see if the sawtooth slope
> changes convincingly.
>
> Also, just to be sure, can you put a known independent timing signal
> (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 / ntpd
> time server / Python 3 / Excel stack to establish the validity of your
> measurement methodology? Very likely you did it right, but I always cringe
> when I hear "Linux" or "NTP" and "precise time" in the same sentence. Yes,
> sorry, forgive me; I grew up in the "trust, but verify" generation [1]. It
> applies pretty well to metrology also ;-)
>
> /tvb
>
> [1] https://en.wikipedia.org/wiki/Trust,_but_verify
>
>
> ----- Original Message -----
> From: "Graham / KE9H" <ke9h.graham at gmail.com>
> To: "Discussion of precise time and frequency measurement" <
> time-nuts at lists.febo.com>
> Sent: Sunday, December 30, 2018 6:03 PM
> Subject: [time-nuts] More ES100 WWVB Measurements
>
>
> > Attached are three graphs, plotting the results of two 24 hour runs of
> the
> > ES100 board.
> >
> > The ES100 can run in two modes. One for time acquisition, which takes 134
> > seconds, and a second mode for "tracking" which only takes 24 seconds to
> > execute, and returns only the "seconds" value.
> >
> > The tracking mode is intended for time sync of a receiver that already
> > knows
> > the time, and may need to compensate for oscillator drift. It can only
> sync
> > over a +/- 4 second correction interval, and must be started just before
> > the
> > top of the minute.
> >
> > The first plot, entitled Time Plot, is a plot of sequential time
> > acquisition
> > commands, which shows the time returned by the ES100, versus nptd time,
> on
> > a Linux (Debian 9.4) computer connected to the network. Due to
> asymmetrical
> > latency in a cable modem system, there might be some bias in the
> > Network time, but the bias should be constant for the 24 hour run.
> >
> > If the ES100 returned a "No Decode" for any single command, the value was
> > forced to -100 ms in the plot, and plotted on the line labeled "NO
> DECODE".
> >
> > The WWVB signal sends a 6 minute long highly encoded time signal at 10
> > Minutes
> > and 40 Minutes after the hour, which this chip can not decode, which are
> > the
> > clearly occurring repetitive "NO DECODE" bursts, twice per hour. To the
> > best of
> > my knowledge, there is no commercially available receiver or that can
> > decode this
> > 6 minute signal.
> >
> > The first time acquisition was within a few seconds of 0300 UTC, and ran
> > for
> > 24 hours. After each acquisition, whether successful or unsuccessful
> > decode,
> > the logging computer waited one second then requested another time
> > acquisition.
> > A total of 495 samples were captured and plotted.
> >
> > --
> >
> > The second test exercised the "tracking" mode.
> >
> > In this case, the logging computer requested a tracking update at 4
> seconds
> > before the top of the minute, every minute for 24 hours.
> >
> > The same results are plotted twice, once labeled "Track Plot ALL" which
> is
> > scaled to show all data, which includes some seconds returned as "valid"
> > but
> > are in error up to three seconds in time. It should be noted that there
> > were
> > only 13 of these events, and they all occurred during one of the six
> minute
> > highly encoded time signals, which this chip can not decode.  I let the
> > tracking sync requests run during these 6 minute signals.  If a real
> > application
> > knew not to ask for tracking sync during this time, the false "valid"
> would
> > not
> > occur. But it does suggest a problem within the error
> detection/correction
> > processes within the ES100 chip.
> >
> > To give a better view of the time "tracking" performance of the chip, I
> > plotted
> > the same data on a scale of +150, -100 milliseconds. This plot is labeled
> > "Track Plot Close-In Detail."  On this plot, "NO DECODES" are forced to a
> > value
> > of -150 milliseconds and thereby plotted on the line labeled "No Decode".
> > The 13 invalid decodes marked valid, all one second or greater in error
> are
> > off-scale on this plot, so not visible.
> > A total of 1440 samples were captured.
> >
> > --
> >
> > The logging computer is a BeagleBone Black. The logging computer time
> > source is Debian 9.4 ntpd time server. Control scripts are written in
> > Python 3.  If anyone wants copies of the raw capture files, the Python
> > scripts,
> > or the Excel Spread sheet that generated the plots, just ask.
> >
> > --- Graham
> >
> > ==
> >
>
>
>
> --------------------------------------------------------------------------------
>
>
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>