[time-nuts] New WWVB modulation format receivers

[paul swed]

Clint
I don't know if it was me or not the said the doubling scheme did not work.
It does work but profoundly unreliably at least on the east coast. If you
miss one cycle of carrier you loose phase making it useless. Jfor here on
Time nuts and I tried a lot of things to get around the issues because
simple is best. Now I do know that folks much closer to wwvb use the
doubling method. Someone posted that here.

You brought up a really interesting comment on the mix down method and I
have been curious about that and thinking about it. Especially since we are
looking for a 1Hz phase flip. You mention the 60.003 crystal as an
oscillator or filter?

Very hard to get those today, not so as little as 5 years ago. I found an
ebay supplier that sold something like 25 for $5 so picked up a pack hoping
that some crystals would actually work as a filter in the RF chain and they
actually do, but you actually have to hand pick them. As an oscillator
pretty poor behavior.

I have released a RF frontend design to time nuts some 6 months ago and
also a traditional costas loop using cd 4000 series chips. It does work and
does hold phase over multiple days. It can get tripped up. But all in all
for literally a few dollars does well. But I absolutely believe there is a
better way as you are suggesting.

Regards
Paul.
WB8TSL




On Thu, Feb 20, 2014 at 8:42 PM, Clint Turner <turner at ussc.com> wrote:

> Several years ago I spotted a clever PIC-based software (DSP-ish) approach
> to WWVB modulation - but it has thusfar defied my attempts to find it via
> Google.  It was from the late 90's, early 2000's - and I may have it in an
> archive somewhere.
>
> The exact details escape me, but I believe that it sampled at 8 kHz and
> was fed a crystal-filtered WWVB signal at 60 kHz, putting this
> bandwidth-limited, AGC-leveled signal directly into the PIC's A/D.
>
> If I've done my math correctly, that would yield a frequency-inverted
> alias at 4 kHz.  The A/D was then mixed and/or decimated significantly and
> a simple software-based carrier recovery scheme (a Costas loop, maybe?) was
> implemented in this rather low-end PIC.  Because the TRF bandwidth was on
> the order of just a few Hertz, it took a fairly trivial amount of
> horsepower to implement.
>
> Presumably, at just one baud it should be practical to do this on more
> modern PICs and AVRs using the same scheme.  The trick to homebrewing this
> is to find a 60.003 kHz crystal - but one of these could be swiped from a
> WWVB receiver module, or, perhaps, a source-follower could be used to
> recover the phase component of the received carrier, tapping off the signal
> from the BPF itself and making it available to the processor.
>
> * * *
>
> Another scheme - one that I believe was poo-poohed a while back on this
> list - is to simply take a bandpass filtered sample of around 60 kHz and
> throw it into a four-quadrant multiplier to yield a 120 kHz signal sans
> phase shift.  I believe that the initial critique of this was that this was
> not a particularly good way to recover a weak signal, but I found it to be
> quite useful on a project some (15) years ago.
>
> On this project, I had a 100 kHz pilot carrier modulated with NRZ BPSK
> telemetry data and this same carrier was used to convey the reference
> frequency to multiple, simulcast transmitters via a 33cm microwave link.
>  At 100 kHz, I simply had an L/C bandpass filter that was roughly 3-5 kHz
> wide on the transmit (to control the occupied bandwidth when XOR-gate
> modulated) and a similar filter on the receive end.  "Listening" to this
> 100 kHz center frequency, 3-5 kHz bandwidth was a 1496 configured as a
> multiplier, the output of which was passed through a simple filter
> constructed using 200 kHz crystals. The 200 kHz from the doubler output was
> then divided-by-two and used to synchronously demodulate the BPSK data
> (after being filtered with either a Bessel or Gaussian LPF) and this same
> recovered 100 kHz signal was then made available to the master 10 MHz
> frequency reference for locking.
>
> What impressed me was the fact that my input signal S/N could go about 40
> dB below the detection bandwidth of the BPSK signal and still maintain
> perfect lock on the 100 kHz carrier, despite the fact that the 1496 - which
> really doesn't make all that great of a doubler compared with other
> available (but more expensive!) devices was being pelted with 3-5 kHz of
> garbage when the S/N was purposely compromised.  IIRC, the detection
> bandwidth of the crystal-based carrier recover filter was on the order of a
> few 10ths of Hz.  Yes, the phase did vary with temperature, but the
> rate-of-change was fairly slow and this fact was inconsequential in our
> application.
>
> * * *
>
> The upshot of this is that it should be quite easy to do a simple
> doubler-based carrier recovery system at 120 kHz (or something else, if
> it's frequency-converted) and, since it may be a bit tricky to find a cheap
> 120.006 kHz crystal, use an SCF clocked from a VCXO (or a simple fractional
> divider/DDS implemented in software) to provide a very narrow detection
> bandwidth that would satisfy the dynamics associated with the usable signal
> range over which the WWVB carrier could be reconstructed and the phase data
> could likely be recovered.  The AM output of a standard WWVB clock module
> could then be used to aid in the windowing of a synchronous demodulator
> integrate-and-dump filter to recover the phase information and make these
> two pieces available to something like a PIC or an AVR/Arduino for
> crunching.
>
> In the (likely!) event of a signal that was too weak to recover the
> amplitude information from the broader-bandwidth WWVB receiver module it
> should be practical to oversample (say, by 8x) the output of the
> synchronous demodulator and then infer the timing of the phase change over
> a period of time since the minimum period of this is well known (1 second!)
> and such timing could be (initially) autonomously applied with very good
> stability until the timing of the phase change resolved itself - something
> that could be correlated with a statistical analysis of the output of the
> amplitude detector, as well.
>
> To a large degree, this sounds like a candidate for a "front end"
> consisting of good old 4000 CMOS logic and a few op amps with the output
> handed off to a fairly low-end, cheap processor module!
>
> 73,
>
> Clint
> KA7OEI
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>