[time-nuts] More ES100 WWVB Measurements

[Graham / KE9H]

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

==
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Time Plot.PNG
Type: image/png
Size: 40798 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181230/51ac2c1a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Track Plot ALL.PNG
Type: image/png
Size: 39033 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181230/51ac2c1a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Track Plot Close-in Detail.PNG
Type: image/png
Size: 46869 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181230/51ac2c1a/attachment-0002.png>