WWVB Reception: 60 kHz Tuning Fork Resonator Filter

Some early morning data from the WWVB preamp with the 60 kHz tuning fork resonator filter in full effect (clicky for more dots):

WWVB - xtal filter - waterfall 5 fps RBW 109.9 Hz Res 0.02 s - gqrx window - 20171116_103542

WWVB – xtal filter – waterfall 5 fps RBW 109.9 Hz Res 0.02 s – gqrx window – 20171116_103542

The dotted line comes from WWVB’s 1 Hz PWM (-ish) modulation: yeah, it works!

The filter cuts out the extraneous RF around the WWVB signal, as compared with a previous waterfall and some truly ugly hash:

WWVB - 24 hr reception AGC - 2017-01-16 to 17 - cropped

WWVB – 24 hr reception AGC – 2017-01-16 to 17 – cropped

Well, not quite all the hash. Enabling the SDR’s hardware AGC and zooming out a bit reveals some strong birdies:

WWVB - xtal filter - waterfall - hardware AGC - 2017-11-16 0612 EST

WWVB – xtal filter – waterfall – hardware AGC – 2017-11-16 0612 EST

The big spike over on the left at 125.000 MHz comes from the Ham-It-Up local oscillator. A series of harmonics starting suspiciously close to 125.032768 kHz produces the one at 125.066 MHz, just to the right of the WWVB signal, which leads me to suspect a rogue RTC in the attic.

There is, in fact, a free running “Test Signal Source” on the Ham-It-Up board:

Ham-It-Up Test Signal source - schematic

Ham-It-Up Test Signal source – schematic

Although I have nary a clue about that bad boy’s frequency, measuring it and cutting the inverter’s power trace / grounding the cap may be in order.

The SDR’s AGC contributes about 30 dB of gain, compresses the hottest signals at -25 dB, and raises those harmonics out of the grass, so it’s not an unalloyed benefit. Manually cranking on 10 dB seems better:

WWVB - xtal filter - waterfall - 10 dB hardware preamp - 2017-11-16 0630 EST

WWVB – xtal filter – waterfall – 10 dB hardware preamp – 2017-11-16 0630 EST

The bump in the middle shows the WWVB preamp’s 2 kHz bandwidth around the 60 kHz filter output, so the receiver isn’t horribly compressed. The carrier rises 30 dB over that lump, in reasonable agreement with the manual measurements over a much narrower bandwidth:

60 kHz Preamp - Bandwidth - 1 Hz steps

60 kHz Preamp – Bandwidth – 1 Hz steps

With all that in mind, a bit of careful tweaking produces a nice picture:

WWVB - xtal filter - waterfall - 10 dB hardware preamp - 2017-11-16 0713 EST

WWVB – xtal filter – waterfall – 10 dB hardware preamp – 2017-11-16 0713 EST

I love it when a plan comes together …


, ,

  1. #1 by Robert Gast on 2017-11-17 - 16:09

    Hey there this is a cool project. Do you plan on decoding your WWVB signal?

    I also have an obsession with WWVB, right now I am building a 3 channel GPS disciplined VFO, with a DIY ovenized .5ppm TCXO. I even decided to throw in one of those WWVB modules (like the one you used to build your led clock), so I could add a feature telling me the difference in GPS time vs WWVB. But in the future I plan on building a WWVB only SDR, the plan is to use a SoftRock Light 2 kit ( that I have sitting, and waiting for a use. Im going to modify the filtering and LO to work at 60khz, and connect it to a 96khz audio codec. This should give me 48khz of instantanu eous bandwidth at -123db dynamic range, which with good filtering will hopefully kill any chance of overloading liuke you are seeing.

    What I think is coolest about your project is the pre-amp based on an instrumentation amp! Is it all an original idea? Im wondering what made you go down the that path instead of using one of the proven LF transittor preamp design that have been tested and simulated to death, and have known results? Now that its all built and set up what do you think of the preamp, would you change it?

    So here are some ideas, that might help your system out, in the end its probably more work to go back and implement things different than its worth depending on much you use the SDR.
    TOSS VNC, maybe its my opinion but remote desktop systems are just to clumsy and slow to use for much more than admin tasks. But I guess if your hooked up on 1gig Ethernet its probably a lot smoother.
    GQRX and SDR# both supply server applications that will run on your pi and most other ARM single boards. Basically they just take the USB data from your SDR and then package it up and send it over the network to a computer running GQRX or SDR#. This would allow you to sit at your PC and just open up GQRX, without logging in to the pi, etc etc. If you are on windows and willing to use SDR# its server is really optimized and uses some tricks to send all that SDR data over limited bandwidth.

    Next the HamItUp v1.3 is the most awful piece of hardware I wasted money on! At least for me I cant receive anything under 500khz(as advertised) its all a bunch of crazy noise at 125.0 to 125.5mhz. I dont do much under 1ghz anyway so I actually bought it for the noise source, and that is also awful, the 10 dollar Chinese noise source I bought works 10x better! Lastly weather I have pass through on or off, I get huge harmonic spikes from the 125mhz LO all over the spectrum up to about 1ghz if I remember right. My idea to you is to just get that UpConverter out of there and buy a SpyVerter which mixes in a totally different way and you almost cant tell its there it has so little effect on things. If you don’t wanna spend another 50 on a an up converter look in to doing the Direct Sampling mod to your SDR it works fairly well from spectrum shots I have seen. GQRX and SDR#, along with there server packages both support using the RTL-SDR in direct sampling mode.

    Lastly if you haven’t already, set your RTL-SDR sample rate way smaller the 2.4mhz, it can be set way down to khz instead of mhz. The SDR can still see out of band stations due to what is called folding and up sampling, but they will be greatly attenuated and this should hopefully stop any residual overloading that slips through the front end hardware filter.

    Kind of a long winded post, sorry.

    • #2 by Ed on 2017-11-18 - 10:46

      Long, but well-thought: thanks!

      The instrumentation amp topology came from a Jan 2016 QEX article. I tweaked it a bit and It Just Worked. Running op amps at 60 kHz with high gain is just barely feasible, though, so I’m not sure it has any much benefit over more conventional LF designs. Search the blog for obvious keywords to get the backstory.

      I must do long-term monitoring to see how it copes with real-world signal variations & interference, which depends on forcing GNU Radio onto an RPi and logging the results. I tried running an IQ server on the Pi a while ago and had zero success, although knocking the sampling rate down should improve the situation; the doc I’ve seen suggests 900 kHz as an absolute minimum, with experimentation in order. I may as well keep it all on the Pi to reduce the number of computers required for logging.

      Oh, and Windows is not an option, for a number of reasons.

      The Ham-It-Up really only “works” for signal under 60-ish MHz, with upconverted output from 125 to 180-ish MHz enforced by a bit of filtering. Everything from 60-ish to 125 MHz is the negative-frequency upconverted range and everything upward from 180-ish MHz will be aliases, so all that mush you’re seeing is “broken as designed”.

      Anyhow, it’s been a fun project and served as the McGuffin for half a dozen Circuit Cellar columns, so I’m calling it a win. [grin]

      Again, thanks for the suggestions; keep ’em coming!

  2. #3 by madbodger on 2017-11-17 - 18:20

    That is truly gratifying.

    • #4 by Ed on 2017-11-18 - 09:46

      You can only begin to imagine the Happy Dance … [grin]