Summary

Since the code and electronics are working now, I am considering work on this project to be complete (well, for the time being at least).  What follows are thoughts on follow-on projects and future directions.

Deets

This project began primarily as a testbed for my working with the Si5351A clock generator chip, and secondarily as an experiment in seeing if a WSPR encoder/modulator could be produced with the 'minimal system development board' (BluePill).  I did not intend to produce a stand-alone WSPR transmitter as an end in itself.  Given that, I consider this project completed, and now it's time to tear down the circuits so that they can be re-used in other things.  However, the experience has spurred some new thinking....

Not Going to Make a PCB

As mentioned, I don't intend to make a PCB for this stand-alone WSPR transmitter, however, along the way I got a small amount of exposure to KiCad.  I had been planning to investigate KiCad for years but had never gotten around to it.  When I actually was an EE decades ago I used a very quirky Swedish CAD called 'EE Designer III'.  It was written in compiled BASIC, lol!  (well, the graphics kernel was in something else).  Anyway, these days we have usable open-source options, and I liked that KiCad also does not have limitations.

In this project, I had used it to drive a SPICE simulation of the low-pass filter for harmonics rejection

    Harmonics
and I think they have a ways to go in their SPICE integration, but still it is somewhat serviceable -- maybe much more so with practice.

Also, as part of testing 

    Acid Test
I crufted together an HF-radio-to-PC interface so that I could use the 'official' decoder to prove my modulator.  This tangential mini-project is something that I need to have all the time, and in a robust enclosure, so I think I am going to try my hand at laying out a board for that stuff.  This board should be quite simple (maybe single-layer), so I think it is small enough a project to give me experience with creating symbols and using the tool from start to finish.

Need to Do Further Work on Class E PA

I attempted to make a class E power amplifier

    Power
but it is quite inefficient, which rather takes away from the charm of class E.  I am pretty sure this is due to the driving of the switching MOSFETs, but I need to prove that.  The class E operation is interesting to me if I can get it live up to its potential because that would be more battery-friendly for a transmitter for use in the field.

Switchable Band Filters

In this project I punted on implementing multiband operation in the RF section, opting instead for single-band operation on 20 m (14 MHz).  The software and modulator work just fine on all the bands, but the harmonic output has to be corrected before hooking it to an antenna.  However, I'd still like to have one unit be able to transmit on all the bands without physically swapping out stuff.  Looking at commercial offerings, it seems that most multi-band filters operate simply by having a band of single band filters that are switched in and out -- often via relays.  I'm not personally fond of relays, but they do work.  I might try to make a multi-band filter bank using semiconductor switching, though.  I probably need to look into PIN diodes.  I don't know that I strictly need PIN diodes since the frequencies for the HF bands are pretty low, but nonetheless, this is an area of future investigation.  Plus I get to make more callouses on my fingers winding a bunch of toroids!

Receiving WSPR

Encoding and modulating WSPR is pretty easy:  do the transformations of the data to produce the 162 symbol stream and clock out the symbols as tones.  Very little RAM and CPU overhead are involved, and this is why the BluePill was more than sufficient for the task.  (Most of the Flash was used in soft float support, and the STM32 HAL libraries which are not particularly light.)  Receiving and decoding I think will be quite a different challenge.

For receiving, I will need to have a somewhat more complicated RF analog section, and then that signal will need to be digitized to get it into the mathematical domain for more processing.  This will involve a boatload of CPU overhead (probably floating point will help a lot), and lots of RAM.  This will also be a real-time process.  The BluePill is clearly not up to it, but I wonder if the STM32F4xx can do it?  It has hardware (single precision) floating point, runs at 168 MHz, and more RAM.  Not a ton of RAM, but 128 + 64 KiB.  I was thinking about using this sort of board:

    STM32F407VET6 development board

It can be had from various places for about USD $9 or so if you're willing to wait for the slow boat from China.  I do wish they had not chosen to save $1 by using the part with half (512 KiB) flash, but 'oh, well'.  Hopefully that is still enough.

I think the big challenge will be in the real-time signal processing.  The board has what seems to be a large 192 KiB RAM, but really this is not enough for a naive re-implementation of the 'official' WSPR code.  That code first stores the entire baseband signal sample in RAM, then commences processing during the last 9.4 seconds before the next transmission interval.  That's 45,000 IQ float pairs, which is 360,000 bytes.  I think I will have to do some clever partitioning and rearrangement of the various algorithms so that I can perform the processing at least down to the symbol demodulated level (the 162 MFSK symbols) to have any hope.

Additionally, I'm not sure if the 12-bit ADC will have enough resolution (if there are even 12 usable bits) to provide the dynamic range needed to decode the weak signals.  Since halving the sampling rate through decimation will give you half a bit, I can create 4 extra bits out of time by oversampling:  4 / (1/2) = 8; 2 ** 8 = 256.  So 256x oversampling!  Yikes!  Feasible?  Unknown.  The ADC's on the device can go up to 1.25 Msps, so that divided by 256 would result in 4.9 Ksps, or a Nyquist bandwidth of 2.4 KHz, so that is workable.  But will that be way too much math for the CPU?  Unknown.  I can punt and use an external ADC like the PCM1808, but where's the fun in that? lol.

Also, unlike the transmitter, where a sub-band frequency is chosen and then modulation proceeds, the receiver is mean to find, track, and demodulate all the transmissions in the 200 Hz WSPR band.  So even more complications regarding buffering of data.

Lastly, the receiver is meant to upload the spot data somehow.  So that implies networking and is yet another thing to fit in.

So, in all, I think the receiver will be much more challenging than the transmitter, but I have to admit being intrigued.  If I do pull off the receiver, then I might combine the two projects consider making a dedicated unit out of them.

Next

fin