RaspberryPi WSPR

From George Smart's Wiki

This page details my attempts of Compiling WSPR on the Raspberry Pi. The basic method used to compile WSPR on any other PC works here, but there are some slight changes required on the Raspberry Pi. This page is a bit brief and should be used in conjunction with my Compiling WSPR page.

Contents

Dependencies

So, to start with, I install exactly the same dependences as before. Please note, the "\" indicates that the command continues on the next line. Remove the "\" when copying and pasting, and put all the programs on one line.

Once the download is finished, cd into the newly downloaded WSPR source code folder, wspr/ and get ready for action!

Modify Source

This step is somewhat unofficial, and shouldn't be required. It is to overcome a bug in the current (revision 2996) version of the SVN code.

nano wspr0.f90

Comment (!) line 16 and 17 out in the wspr0.f90 source code file. This is the easiest way. You can of course trace the real issue of the code, but unless you're going to be using the command line processing version of WSPR then it doesn't really matter. Left is the original and right has been modified.

Find PortAudio & Configuring

You'll need to find the path to libportaudio.so before you can compile newer versions of WSPR on newer versions of Linux.

cd /usr/lib/
find -iname "libportaudio.so"

This path then needs to be fed to the ./configure script:

./configure --with-portaudio-lib-dir=/usr/lib/arm-linux-gnueabi/

The script should finish within a little time:

Compiling

To compile, simply run:

make

and then go to make yourself a nice tea. The compile took around 3 minutes so you should finish about right!

A this point, you have the compiled version of WSPR ready to go. BUT You probably don't have enough RAM on the Raspberry Pi. I have the 256 MB model (an early model B with network). The trick is to make a swap file in the file system to use as memory... You'll see an error message saying that python "cannot map zero-fill pages: cannot allocate the memory". If this is the case, the next section will solve it!

Making A Swap File

Before we go any further, some words of caution! SD cards have a limited number of write cycles - i.e. you can only write to them so many times before they die. Using an SD card as RAM is a good way of quickly approaching the write-limit of an SD card. The Linux kernel does everything it can do to avoid using the SD card swap file because it's very slow. It really is the only way here. If you have an external USB HDD, almost certainly use that, as HDDs have an almost infinite write count (they're even slower than SD cards, but don't burn out). Continue at your own peril! I haven't tested with the 512 MB version of the newer Raspberry Pi. I also have no idea why WSPR needs that much RAM. Here's what I get when trying to load WSPR without the swap file:

The first thing to do is to create the swap file. You need an empty file, all zeros, somewhere in the file system. I decided to create a 512 MB swap space, giving me a total of around 700 MB of 'RAM'. 512 MB * 1024 bytes = 524288 blocks. Use dd to create the file:

sudo dd if=/dev/zero of=/var/swap512 bs=1024 count=524288

Then you need to make the file a swap file:

mkswap /var/swap512

You then need to change the ownership and permissions of the swap file:

sudo chown root:root /var/swap512
sudo chmod 0600 /var/swap512

Finally, turn the swap files on. You will need to do this every time you reboot your Pi, or add the swap file to your /etc/fstab file to do it for you:

sudo swapon -a
sudo swapon /var/swap512

And there you have it. You've now got a swap file of 512 MB and it's enabled.

Running with Swap

Now we can run WSPR as expected.

We can peak at how much CPU and RAM WSPR is using with the ps command. This command is a kludge of various commands, but it shows the details for WSPR (python):

This tells us that the swap usage is 0. The computer isn't using the swap we've created; but, it can allocate that if it decides something is more deserving.

Other Useful Bits

Try installing gnome-alsamixer for graphical audio mixer controls in LXDE. You can also use alsamixer on the command line to control the sound cards. I use a cheap USB sound card to interface to my Icom IC-7000.

Receiving on 30m

At the time of writing the above section, I wasn't able to receive much on 30m. However, I left the RPi running overnight and it had gathered a good few signals. The antenna here is just a short wire around the window frame, un-tuned. The main antenna was on 472 kHz WSPR. The signals are weak, but the decode process is working!

With a larger number of signals received per 2 minute time interval, I have noticed the decoding process taking around a minute for about 5 weak signals. I am unsure how long this process would take were there more stations or if they were weaker still. Typically, the decode process takes around 5 seconds.

FunCube Dongle

THIS SECTION IS NOT FINISHED YET!

Before we get too far into this, it is important to have a good, clean, power supply. I made a linear PSU (High Current 5V Regulator) to power the Pi and thus FCD and up converter.

After this, we come to the software. The first thing we need to do here is to be able to control the FCD's local oscillator, and the program I find best to do that is OZ9AEC's Qthid. Ideally, I'd like to compile the latest version from source code here, but having made several attempts to compile version 4 of Qthid on the RPi, I have given up. Every version seems to compile but none ever connect with the FCD. The version in the repositories works fine, but is quite old.

To compile this for the Raspberry Pi, we first need to get the source code. And to get this, we need to install GIT to download it.

sudo apt-get update
sudo apt-get install qthid-fcd-controller

This will take some time to complete and install, but once it does, you can quickly test to see if it's working! The qthid-fcd-controller package includes two binaries, qthid (version 3) and qthid-2.2 (version 2.2). Version 3 seems somewhat intermittent (though I have seen it working). Version 2.2 works more reliably but is even older. As mentioned previously, I compiled version 4 which seems more responsive and quick, but it never sees the FCD despite the same version working flawlessly on my desktop.

If all goes well, then you should see (as above) the status of "FCD active" which tells us that Qthid has found the FunCube Dongle and is ready to roll!