[time-nuts] More ES100 WWVB Measurements

[Tom Van Baak]

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.
>