[time-nuts] ES100 BPSK WWVB jitter data

[Tim Shoppa]

I let the Universal Solder ES100 board run overnight in my basement in
Maryland for 10 hours, its little loopsticks at least 5 feet from switching
power supplies, and it often could get successful WWVB BPSK decodes.

This is a feat in itself. No non-BPSK WWVB clock antenna has ever produced
a useful  antenna has ever decoded anything in my basement before.

It was connected to an Arduino Nano, which had its own internal
crystal-derived millisecond clock. (Actually a cheapo $3 Nano clone. I love
these cheapo Nano clones. They are to me, like 555's or 2N2222's.)

The IRQ out of the ES100 is supposed to be good to +/-100ms of the second
edge.

I had it do a new acquisition cycle continuously overnight (around 2
minutes per attempt). At the end of every acquisition attempt it printed
the Arduino's millisecond clock timestamp of the IRQ, success or not. And
when it was an acquisition success,  it also printed the UTC decoded. The
Arduino code is in the zip file and is called 'es100_arduino2.c'. It is
just a slight tweak on the Arduino code supplied by Universal Solder.

The Arduino was connected to a PC that logged the Arduino's serial data.
The serial data is in the zip file called 'es100.txt'.

A perl program 'anal.pl' reads the serial data and produces two column
data, output to 'plot.out'.

Over the 10 hours, there were 142 successful ES100 acquisitions of WWVB  in
281 attempts.

What I did, is for each successful acquisition, plotted the millisecond
clock (x axis) vs the millisecond clock minus UTC seconds*1000 (y axis)

I am attaching the Arduino sketch, the serial data produced, a perl program
that analyzes the raw data (and subtracts UTC seconds*1000), and two graphs.

You can see in 'drift.pdf', that over the 10 hours, the Ardunio's
millisecond clock drifted by about 2.8 seconds. So  the offset of the
Arduino's crystal clock seems to be 78 ppm.

You can also see the scatter in the residual, in graph 'jitter.pdf',
showing the ES100's jitter on the IRQ second edge. Only twice did it go
just a little beyond the spec sheets +/-100ms specification and usually was
less than +/-50ms.

I don't see any sawtooth or other weird stuff going on in the residual.

Tin N3QE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drift.pdf
Type: application/pdf
Size: 11267 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181225/51c28928/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jitter.pdf
Type: application/pdf
Size: 10535 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181225/51c28928/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: es100code-and-data.zip
Type: application/x-zip-compressed
Size: 8289 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20181225/51c28928/attachment.bin>