Hi

Backing up a bit …..

The WWVB modulation is very predictable. Once you have lock,
you can guess just about every phase reversal you will see. If you
have an “approximate lock” ( = a time pre-load that is within a few
seconds) you can guess a lot of them. (There were a few aux data bits
in the stream last time I looked).

In the case of the pre-load, you still need to get your local stream
lined up with reality. In all cases, the ionosphere will move things
enough that some modest amount of servo would be needed.

The point of this being that you could pre-flip the data before it
went into a buffer. That way the buffer integration time constant
could be quite long.

The main penalty is a bit of work getting it all locked up in the first
place. If this is a precision timing receiver (as opposed to a wrist
watch) that may not be a problem.

Bob

Ray Yes you have it correct. The flipper is bidirectional. It either adds
flips or removes them.
It does read the nema second per minute in the 59th second. Then depends on
the 1 pps for an accurate phase flip. The flip is 100 ms into the second
and by propagation delay to the east 5-7ms. Though the reality is if the
flips not exact the phase tracking receivers work just fine.
But beyond the simple reading of the nema sentence its the magical
conversion to the new wwvb message format thats quite difficult. Then they
turned on teh slow code and Rodger and I worked that issue. That actually
took some months to resolve the fast and slow code integration.
So as a transmitter put the software on an arduino or bluepill. Since you
are just doing work locally the nema sentence can be repeated over and over.
Regards
Paul
WB8TSL

On Fri, Jul 31, 2020 at 12:01 AM rcbuck@atcelectronics.com wrote:

Back in December 2018 there was a WWVB thread.

"While everyone's been talking :-) , I recorded some WWVB IQ data for
folks to play with.  You can download it from

http://febo.com/pages/wwvb/

The receiver ran at 48 ksps and was centered on 80 kHz (to allow a 20
kHz IF to move away from 0 Hz crud).  The data was taken in early
afternoon in Dayton, Ohio.  WWVB was easily visible in an FFT."

I ran the python code posted by Poul-Henning with the WWVB IQ data.
The resulting file 'out.txt' has columns for sample time, amplitude,
and phase.  It was used for the plots below.  There is about 10
minutes of data.

initial data: n8ur_rx_center=0.08MHz_rate=48ksps_start=2018.12.05.13.57.54.bin
(236 MB)
plotted data: out.txt  (2.4 MB, 61,000 datapoints)

I hadn't looked at phase data before, and it took a while to make any
sense of it.  It's surprising how well the bit per second data came
through, compared to amplitude modulation.  Different filtering will
likely improve the AM performance, but the phase plot looked good now,
so here it is.

The first graph shows the +90 degree phase shift (top line) and -90
(bottom line).  The SDR clock appears relatively stable at first, but
drifts lower in frequency at a fairly steady rate until about 550
seconds, when it flattens out again.  Overall a bit over 180 degrees
more than expected.  A half cycle at 60 kHz, or about 8.3e-06 drift in
10 minutes.  The unpleasantness at about 470 seconds is reflected in
the 10 minute plot during minute 7 (3 lines down from the top).  I
removed the 'drift' in a crude manner, and it's a wonder it worked as
well as it did.

The middle two graphs are the same data at different time scales.  I'm
not sure if the short term phase variation has any meaning, or if it's
'just noise' at this level.  The WWVB phase change actually takes
place 0.1 seconds after the start of the second, but it fit just right
for display as is.  The real minute begins at second 6, and this is
adjustment is made in the 10 minute waterfall plot.  The first few
seconds of data are at the bottom left corner.

Green denotes binary 1, phase shift +90 degrees.
Red is binary 0, phase shift -90 degrees.

A simplified description of WWVB phase-modulated time code:

seconds  0 - 12  fixed sync  0, 0, 1, 1, 1, 0, 1, 1, 0, 1, 0, 0, 0
seconds 13 - 18  time parity (ECC)
seconds 19 - 46  binary minute of century
seconds 47 - 58  DST and leap sec
second  59      fixed sync  0

these seconds are notable here:

43, 44, 45, 46 contain changing binary minutes 3, 2, 1, 0
19  a copy of binary minute 0
29, 39  Reserved, but also a copy of binary minute 0 in this sample.

I'm using python, numpy, matplotlib, and Pandas.  It all runs pretty
quick on my machine, only a few seconds to load, calculate, and
display the graphs.

I'm going to try looking directly at John's IQ data to see the effect
of the larger dataset on results and calculation time.  It's a big
help knowing what the processed IQ should look like.  Thanks for the
data and code,

Rob

On Fri, Jul 31, 2020 at 7:00 AM paul swed paulswedb@gmail.com wrote:

On 7/31/20 11:25 AM, Scud West wrote:

Nice looking plots..Did you generate the colored red/green "fill to
baseline" in matplotlib, or is that out of Pandas?

The stacked plot is also very nice.

Good looking plots really help to understand what's going on.

(and of course, a shout out to Edward Tufte, who I am often inspired by)

The coloring is from matplotlib.  Sometimes I forget what's what. I'm
really not using pandas for much here.  Most of the code in plotting a
minute of data is in making it look fancy.

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.ticker as tkr
import matplotlib.mlab as mlab
import pandas as pd

sFile = 'out.txt'  # in current directory, or give full path

df = pd.read_csv(sFile, header=None,
names=['sample_time', 'amplitude', 'phase'],
sep=' ', index_col=0)

phase_deg = np.rad2deg(df_phase.phase)  # phase_deg is a series

plt.subplots(figsize=(15, 3))
ax = plt.subplot(1,1,1)
plt.title('WWVB Phase    5 - 70 sec')

ax.plot(phase_deg.clip(-120, 120), lw=0.4)

plt.xlim(6, 71)
plt.ylim(-150, 150)

ax.fill_between(phase_deg.index,
0,
phase_deg.clip(-120, 120), where=phase_deg>=0,
color='green', alpha=0.15)

ax.fill_between(phase_deg.index,
0,
phase_deg.clip(-120, 120), where=phase_deg<0,
color='red', alpha=0.15)

ax.xaxis.set_major_locator(tkr.MaxNLocator(8))
ax.xaxis.set_minor_locator(tkr.AutoMinorLocator(n=10))
ax.grid(b=True, which='major', c='g', linestyle='-', linewidth=0.7)
ax.grid(b=True, which='minor', c='g', linestyle='-', linewidth=0.2)

sSave = 'wwvb_phase_5_70.png'
plt.savefig(sSave, bbox_inches='tight', transparent=False, dpi=100)

Rob

On Fri, Jul 31, 2020 at 1:15 PM jimlux jimlux@earthlink.net wrote:

Bob kb8tq writes:

I would just use two buffers and decide which one based on the
prediction, that way DC-offsets will not cause trouble.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi

It also very much depends on the stability of your local reference and the
stability of the ionosphere. Unless both are “pretty darn good” a hundred second
integration is utter nonsense

Bob

Bob kb8tq writes:

This is why Loran-C was so superior to any and all CW based modulations.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

What may be helpful to the wwvb projects is what is always fixed. This
comes out of the NIST document. Assume you have a fairly good oscillator.
If it can hold within 1/2 cycle of 60 KHz (10 us) for 47 seconds you can
simply sample the top minute sync word. Thats from 59-11 seconds. Always
fixed. But thats a bit too easy. NIST gave us a bit more of a challenge. At
10 and 40 past the hour the slow code runs and its format is different. But
has a 106 second sync word thats always fixed and always at the same
location.
If you have a locked oscillator then the timecode recovery is reasonable.
Decoding the actual timecode is a serious pain.
Good luck
Paul
WB8TSL

On Fri, Jul 31, 2020 at 6:07 PM Poul-Henning Kamp phk@phk.freebsd.dk
wrote: