WSPR Transmitter — Transmitting WSPR Tones

This is a follow-on from WSPR Transmitter — keeping time.

Every two minutes the transmitter code optionally transmits a message as a sequence of WSPR tones.

First the frequency to transmit on is decided—this is a round-robin though the amateur HF bands. Whether a frequency is transmitted on was decided during the initial configuration via a UART connection. The decisions were stored in EEPROM and copied to ESP8266 memory from there.

The LPF is configured to filter appropriately for this frequency. More on this is a later post.

A random offset is added to the transmit frequency to minimise collisions with other transmissions. 

The tones are then transmitted which takes most of the two minute interval. The tones to be transmitted have been compiled into the code as an array using a useful tool. Thanks Scott! The tones are for particular output power. If the output power were changed the code would need to be recompiled. The AD9850 frequency tuning word (FTW) is loaded with the frequency (RF + AF) that is to be transmitted. The code waits for the length of a tone and repeats for subsequent tones. When all the tones to be transmitted in this interval have been transmitted the AD9850 FTW is loaded with zero which stops the AD9850 from transmitting.

The AF tone part of the frequency is according to the WSPR User’s Guide Appx B: The keying rate is 12,000/8192 = 1.4648 baud. The modulation is continuous phase 4-FSK with a tone separation of 1.4648 Hz. It occupies 6 Hz. Continuous phase means the phase isn’t set to zero at the start of a symbol. 4-FSK means it uses four tones.

With an AD9850 reference clock of 125 MHz you get 125^6 / 2^32 = 0.0291 Hz resolution. For WSPR we want 1.4648 Hz or better resolution so the reference clock can be as low as 125^6 x (0.029 / 1.4648) = 2.4836 MHz. The AD9850 can cope easily with this requirement.

Next up is how the LPF band switching is carried out …

Rotary Encoder Test for PIC

I’ve been playing about making simple direct conversion receivers using an NE602 for the mixer. These receivers have some sort of input network for the signal captured by the aerial, mix that with a VFO and amplify the (possibly low pass filtered) audio output from the mixer.

The “classic” version uses a Colpitt’s oscillator for the VFO. This is an analogue oscillator that feeds back via a voltage divider made by a pair of capacitors. This works well and tunes nicely and is magical in its own way. However, the tuning is quite coarse with the variable capacitors I have, and the cost of replacement variable capacitors is getting eye-watering. They can also be quite large.

So I’m trying a replacement VFO made from an Si5351a clock generator. The Si5351a will be controlled by a PIC, being my microcontroller of choice (and available in my junk box). The tuning will be done by turning a rotary encoder. 

I had a rotary encoder of the right size in my junk box and but had no way to find out how it performs. So I wrote a small test program for a PIC16F887 which drives the rotary encoder and shows on LEDs which way the encoder was turned, whether it was turned recently and whether the button on the encoder was pressed or not. I often use a PIC16F887 for tests like this as it has many i/o pins that can be digital or analogue and can be pulled up at will. I don’t think I’ll be using it for the VFO as it is quite big (40 pins!) but I’ll be able to re-use the code amended for whichever PIC is choose.

The schematic is simple: pins on the PIC PORTB are weakly pulled-up and are used for input from the encoder. Four LEDs are connected to PORTD each with a current-limiting resistor. One is the power on LED, the others show what is happening (or what the PC thinks is happening) when you play with the encoder. All the pins are digital.

Encoder Test Schematic

The built test is shown below. The wires you can see that are not shown in the schematic are connections to allow the programming of the PIC using a PICkit2. Ignore the LED on the bottom left as it shouldn’t be there.

Encoder Test on Breadboard

The code and make file is in this zip file. Changes made at the encoder by turning the knob are seen via interrupt. The button changes are polled. The LEDs are lit (or not) in the same polling loop.

Tune in later for the VFO itself.

Morse Sending Tutor Mock-up

I realised that now I’ve made a CW Sidetone Oscillator, a Morse Keyer and a Morse Decoder, I could make a useful tutor for testing my sent morse.

The trick of sending good morse is in the timing. Getting the inter-character and inter-word gaps the correct length is quite difficult especially at higher speeds. So a tutor to check this could be a big help.

Morse Sending Tutor Diagram

So I lashed this together using a breadboard to do the connections. 

IMG 0070

And tested it as seen in this video: Morse Tutor Demo.mov.

As you can see it’s very rough and ready. If I were to make a proper version I’d remove the WPM and tuning aid on the top line which aren’t necessary. It would fit into a small box quite easily.

It was fun to throw together!

Simple Morse Keyer

My home-brew 40m transmitter only handles a straight key at the moment, but I use a paddle. I currently use a separate keyer but this is a bit clumsy. I found a simple keyer circuit that should do the job. The keyer is by N1HFX: see http://www.rason.org/Projects/cwkeyer/cwkeyer.htm. Thanks, Mike!

The keyer is not iambic, but that’s ok for me as I usually use a single lever paddle. When I’m using a dual paddle key I don’t squeeze.

I didn’t have the exact components so I tweaked the design to cope with what I did have. Here is the new schematic and layout. I guess you shouldn’t mix IC families, but it works!

40mtx Keyer Schematic

40mtx Keyer Layout

The circuit works like this. Firstly, the oscillator. 

R2 is the variable resistor between SPEED_POT_1 and SPEED_POT_2.

Assume pins 5 and 6 are 0 V, and C1 has no charge. Pin 4 will be at 5 V.
C1 will get charged through R2 and R1. 0nce most of the 5 V is across C1, pins 1 and 2 will be at 0 V and pin 3 will change to 5 V. Pin 3 is directly connected to pins 5 and 6 so pin 4 will go to 0 V. C1 will discharge and once discharged enough pins 1 and 2 will be at 5 V and pin 3 will become 0 V which is where we came in.
The speed of the oscillation depends on C1, R2 and R1. R2 is variable and is used to change the speed. The speed could be calculated by using the RC curve and seeing where it hits logic high and low. But I decided to do the calculations in MATLAB using these scripts. This gives a plot for R2:

Sidetone WPM

This suggests you can’t key faster than about 27 WPM. This isn’t yet a problem for me as I can barely do 17 WPM.

The keying logic is like this.  Assume the both paddles are up initially. The logic levels are like this for dots:

^ marks dot clock transition to high

                                               
CLK  N0R8     N0R9     D    Q    DOT Paddle
-    1        x        0    x    up
^    1        0        0    0    up
-    0        0        1    0    down
^    0        0        1    1    down
-    0        1        0    1    down
^    0        1        0    0    down
-    0        0        1    0    down
^    0        0        1    1    down
-    0        1        0    1    down
^    0        1        0    0    down
and so on giving equally spaced dots
-    1        1        0    0    up
^    1        0        0    0    up
and so on giving no dots.

Or, less analytically: the dot paddle grounds one input to the NOR gate and the output of this is clocked into the dot flip-flop. The Q output of the flip-flop is fed back into the other NOR gate input. This gives clocked dots.

Single Dot Screenshot
The dash flip-flop uses the Q signal from the dot flip-flop as its clock. So the dash ‘stays on’ for two dits. To make it three dits as required to make it a proper dash the ~Q from the dash flip-flop is fed to the dot paddle input making the dash have an extra dit (as ~Q will be low when Q is high thus pulling the dot paddle low).
Single Dash Screenshot

Keyer on Pad board

All this works fine. Breadboarding was fun, but I made the mistake of putting it on pad board and the soldering was onerous — there’s just too many connections between the two chips hidden under the board. Next time I’ll brush up my coding skills and use a micro-controller.

CW Sidetone Oscillator

My 40m transmitter doesn’t have any frills at all. It is CW only and so far I’ve been listening to its signal on the receiver that I’ve been using with it. This works fine as the transmitting aerial is completely separate from the receiving aerial and the transmitter power is only around one watt.

So I’ve added a sidetone oscillator to the transmitter so that I can hear what I’m sending for when I do proper transmit/receive switching with one aerial.

I looked at PIC-based and LM386-based solutions, but decided on the circuit in chapter 1 of “Experimental Methods in RF Design” by Hayward et al (EMRFD). The circuit is based on a 555 timer. It beats other circuits I looked at because it is simple to build, uses through-hole components and is plenty loud enough for my ageing ears. Although it’s a square wave oscillator it sounds fine. I may add an LPF as the harmonics are louder than the fundamental.

I didn’t have all the components specified in EMRFD so I substituted others that seem to work fine.

Here’s the circuit and layout as ‘designed’ in EAGLE.

Sidetone Board

Sidetone SchematicThe circuit works as follows. The morse key is attached to the JP1-KEY pin and when the key is keyed it grounds R2 making Q1 switch on. The 555 timer is configured as a multivibrator triggered through D1. The square wave output goes to JP2-HEADPHONE pin.

I will replace R7 with a trimmer pot as the current value makes the output too loud even for me. 

Tuning a loop with nanoVNA

One of the aerials I use is a small transmit loop. These loops have a really narrow bandwidth which is good and bad. Good in that you get much less noise, bad in that you have to keep retuning. If you stick to one frequency such as with some digital modes it is ok as you don’t have to retune too much. Other modes such as SSB and CW are less easy to use with a loop.

You can tune the loop by transmitting into it and tuning the loop until the SWR is good. This is a bit anti-social as you can be transmitting for quite some time as you tweak the tuning. I used to use a noise bridge which works quite well as long as your ears don’t get tired. The nanoVNA offers easier, more visual way of tuning. 

nanoVNA loop tuningThe nanoVNA sweep is quite slow so you need to have a fairly wide sweep span so that you can see the dip in SWR when you are tuning the loop. So you set the centre frequency and then the span and then tune until you see the dip disappearing off one end. Then you fine-tune the loop and end up with the dip at the centre frequency. The loop is now tuned as in the photo above.

This works fine with the nanoVNA GUI, but as I am nearly always running a Mac when I’m on the radio I wrote a Matlab script to do the tuning. The script is run and sets the centre frequency and span for you.

Here’s a sample tuning transcript (user input in green):

>> ajfTuneLoop
connect: Serial-/dev/tty.usbmodem4001
status:  open
press RETURN when loop is connected to ch0
Frequency to tune to (MHz) ? 7.074
tune loop for dip at the marker, press RETURN when tuned ok
close
>> 

The script is ajfTuneLoop.m.

nanoVNA, MATLAB and (short) cable length

There are various methods of determining the length of a cable acting as a transmission line. The one I’ve used up until getting the nanoVNA is to inject a fast impulse into the cable and measure the reflection time on an oscilloscope. As usual, Alan W2AEW has a good video about this: #88 Cheap and simple TDR using an oscilloscope and 74AC14 Schmitt Trigger Inverter.

Alan also shows a good method of using the nanoVNA to measure cable length: #316: Use NanoVNA to measure coax length – BONUS Transmission Lines and Smith Charts, SWR and more

The author of the code I used in my previous post about nanoVNA and MATLAB, Alex, has as part of his code the use of a TDR Step Response. With this you can look at the step response graph and derive a cable’s length by looking at the dips in the response.

TDR Short Cable

It seemed to me that his code could be extended so that the cable length could be worked out in the code with no need to look at the graph other than to check that it was all ok. Here’s the script that does the calculations: ajfCableLength.m. Make sure you read on to the end of the post to understand its limitations.

You connect the cable you’re measuring to the S11 port of the nanoVNA and run the script. Here’s a sample MATLAB session using one of the cables supplied with my nanoVNA:

>> ajfCableLength
connect: Serial-/dev/tty.usbmodem4001
status:  open
freq: 101
s11:  101
s21:  101
Measuring cable connected to ch0 ...
Velocity factor of cable? 0.66
The calculated cable length is 0.19775 metres.
Show TDR Response plot (Y/n)
close
>> 

The script is perhaps worth explaining. The first part is the difficult bit which Alex provided. The S11 scattering parameters are obtained from the nanoVNA. These s-parameters are converted into a MATLAB rationalfit object which is a mathematical representation of the s-parameter curve. This rationalfit object is then used to derive the TDR step response mathematically. The second part, which I added, looks at the step response to find the last dip in the curve. This gives the return trip time just like in a real TDR. Given the return trip time the cable length is calculated using the velocity factor which the script has already asked the user to provide.

This all works well for short lengths of cable, say up to 2m. But beyond that it all goes haywire and the results are not correct. I fried my brain reading books (see below) on TDR step responses to find out why. I haven’t managed to understand it properly yet. So it’s a matter for further study.

Some of the books I looked at are:

  • Electromagnetics by Kraus. An excellent book, Chapter 12 is the pertinent part.
  • Electromagnetism for Electronic Engineers by Carter.
  • Signals and Systems by Hsu.
  • Techniques for Advanced Cable Testing which is on the Keysight web site.

None of these are easy reading and all assume an understanding of vector arithmetic and calculus.

Easier, is:

  • Practical Digital Signal Processing using Microcontrollers by Ibrahim.

The nanoVNA and MATLAB

The nanoVNA is a cheap but usable vector network analyser. It is good value and very useful for all sorts of RF design and radio ham activities.   I suggest you buy a nanoVNA from a reputable dealer as there are plenty of clones which don’t work as well as the original. The model I have has a tiny screen which I can read adequately but it isn’t as comfortable as reading a computer screen. The NanoVNA is a touchscreen device so you need to tap on tiny text to do anything. Again, this is possible but far from comfortable for those of us with ageing eyes. There’s also a bit of screen reflection.

nanoVNA

The nanoVNA can be driven from a PC using a program called nanoVNA-saver which is pretty good. Unfortunately it runs on Microsoft Windows and as I don’t have a PC running Microsoft Windows I have to run it in a VirtualBox VM on my Mac Mini. This works but is a bit clunky and to be honest my Mac mini is a bit long in the tooth and struggles to run virtualised Windows 10 at a reasonable speed.

There is a cross-platform solution based on Python which looks promising. It uses Homebrew on MacOS which clashes with MacPorts which I use. I tried to make it work under MacPorts but fell into the usual maze of incompatible library versions causing the make to fail. So I gave up as I want to play with electronics and not software building. [Update: Rudi, DL5FA kindly helped with this and it looks like the Python Virtual Environment will help when I’ve got the time to try again.]

MATLAB to the rescue! — alex_m has created some MATLAB scripts which allow you to interrogate and control the nanoVNA from MATLAB. Thanks Alex! So if you have MATLAB this may be useful. If you don’t you may be able to convert much of this to Octave but it does use the MATLAB RF Toolbox so you may end up doing a lot of work.  Alex’s scripts produce LogMag, Smith Chart and TDR Step Response graphs. 

Here’s a graph showing my 40m LPF characteristics made using Alex’s scripts.

40m LPF LogMag

I’ve written a couple of scripts based on Alex’s work which I think makes using the nanoVNA easier. Both scripts need an edit to configure the serial link to the nanoVNA. You’ll need Alex’s code too.

The first script ajfCalibrate.m calibrates the nanoVNA for a particular sweep on the S11 port. You have to do this before every measurement that changes the sweep values, so you do it a lot. Here’s how it looks in the MATLAB console. The inputs are in italics.

>> ajfCalibrate
connect: Serial-/dev/tty.usbmodem4001
status: open
Sweep start (MHz)? 7
Sweep stop (MHz) ? 7.2
Calibrating...
press RETURN when S11 is open
press RETURN when S11 is shorted
press RETURN when S11 has 50 ohm load
Save [0-4]? 4
close
>>

The second script ajfVSWR.m produces a chart of VSWR against frequency. Most radio hams are happier with this than the LogMag chart preferred by RF designers. 

I used ajfVSWR to measure my small transmitting loop tuned to the 40m FT8 frequency. As expected it shows the narrow bandwidth in low VSWR that is the drawback of small transmitting loops. 

40m FT8 VSWR

The graph can be zoomed in MATLAB and have data cursors added to show more details.

40m FT8 VSWR 2

The VSWR could be lower. I think I left a metal step-ladder in the attic which is affecting the loop.

ajf? My initials.

X-Phase — More theory

The advert is from Practical Wireless February 1987.

In my last blog I tried to explain how a QRM Eliminator works. Here’s some more information.

Suppose the signal you are trying to hear is a sine wave (shown in blue). The signal as received (shown in red) will have some noise added as it travels to you.Original noise

The QRM eliminator allows you to pick up the noise with your noise aerial and phase shift by 180º. As shown in this chart.

Noise

If you add the blue and red signal together you’d get a zero signal. So if you mix the inverted noise with the noisy signal as received you’ll recover the original signal.

Recovered

Of course reality is different and the recovered signal won’t be as clean as that. Also if you don’t match the noise and main signal amplitudes properly, you’d then get something like this.

Recovered loud

These charts were made with MATLAB using this script.

X-Phase QRM Eliminator

I bought an X-Phase QRM eliminator a while back, tried it out with a receiver and was quite impressed with its performance. It’s only recently that I’ve connected it to a transceiver because without care it is easy to damage the unit when transmitting.

QRM eliminators have been around for many years. I was recently looking at an old Practical Wireless from 1989 and S.E.M. were selling one then in the adverts at the back of the magazine. (And, yes, we used dots in abbreviations back then). If you were to be picky you might say it should be called a QRN eliminator, but it isn’t. I quite like the idea of an actual QRM eliminator though I’m not sure how you could implement it. 

Advert for QRM Eliminator

A QRM eliminator works like this: signals from the main aerial are mixed with signals from a noise aerial. The signals from the noise aerial can be shifted in phase. The idea being that you mix the main signal with the noise signal 180º out of phase. If the signals are the same you’ll just get a zero signal. But if the main signal comprises a good signal and some noise signals and the noise signal is predominantly the noise signals, you’ll end up with just the good signal. Of course, to make this work you need to be able to make the noise signals from the main and noise aerials be the same amplitude so the QRM eliminator has controls to adjust the gain of each. As you want the signals to be 180º out of phase there is also a control to adjust the phase.

front of X-Phase

The three blue knobs in the photo are these controls.

There are several QRM eliminators on the market. I got mine from Poland on eBay from the seller urbania2. The unit is solidly built in a neat aluminium box with pleasant to use control knobs and strong connexions on the back. 

The instructions are in a quaint mixture of Polish and English but I found them understandable enough as a circuit diagram is included.

I have done some quick tests on 20m with the unit and it seems to be able to reduce the background noise by about 3 S-points as shown on my TS590S transceiver. I also made some measurements using received FT8 signals. This showed an increase of about 4dB in the signal strength of CQ signals as reported by JTDX over 15 minutes with the QRM eliminator being on each even minute and off each odd minute. None of this testing was particularly scientific though. I was using a 4m length of loudspeaker wire as the noise aerial, just lying on the floor of the shack.

connexions at back of TS590S

I mentioned that it’s easy to damage the unit when transmitting. It has three wires. Red and black are for the DC supply, and the yellow wire is for the PTT. When grounded the eliminator passes the main signal straight through avoiding the damage.

This Is how I connected my TS590S. The EXT-AT connector on the TS590S provides a nominal 13.8V DC. So I used pins 1 and 6 to power the Eliminator. I got the EXT-AT plug from an eBay supplier asia_uk.

TS590S EXT AT Connection

The remote connector on the TS590S isn’t particularly well documented, but connecting the yellow wire from the Eliminator to pin 4 works, but only if menu 53 on the TS590S is set to 2. Pin 2 on the remote connector, the common terminal needs to be grounded so I connected it to pin 3 on the EXT-AT seeing it was spare. I got the required 7-pin DIN plug from RS Components.

TS590S Remote Pinouts