Creating a Custom WSPR Spot Server

WSPRNet is a great free service and resource for aggregating WSPR spot data. It provides archives of the data which can be downloaded and analysed, and I have done this to some success previously (see here and here). However one thing this approach lacks, is the ability to view and analyse spot data in real-time. The existing method is inherently limited to the schedule at which I can download the data from, which in the interests of politeness is 1 month (when I remember).

Unfortunately, there is no publish api I could subscribe to get a feed of spots in real time. If you know of one, drop me an email. This left me with a couple options, download the data frequently from WSPRNet, which is not very polite and generally in poor form. Or try and stand up my own spot aggregation service.

Modifying WSJTX

To make this work I modified the original WSJTX and WSPR applications to upload to my spot service. Ideally this would be done in addition to uploading to WSPRNet, but in the interest to time, and to see something work. I made the existing code take an extra parameter of where to upload the spots too. This involved building WSJTX from source as outlined here, editing the code which does the uploading, as well as adding an extra field to the configuration menus to allow for setting where to send the spots to. Below is a screenshot of the additional field

Screenshot of the modified WSJTX with additional field for the Spot URL

Saving the spots

I made use of Googles Cloud functions and Data store to create the service to store the spots, now that I had the ability to upload them where ever I wanted. These tools were chosen, as I didn't have to worry about infrastructure or servers, and more importantly they had a generous free tier which should do nicely for this.

WSJTX makes a simple HTTP GET request to the service, with the data for each spot as query parameters. When I get some time, I might modify WSJTX to batch up spots as it makes a request for every station heard which is a little excessive in my opinion. But for now I just wanted something which worked. I also ensured that I made a request out to for each spot, to ensure that everything was counted correctly.

Putting it all together

To make use of this, you will need to build WSJTX from scratch, following the instructions here, with one small change. Once the code for WSJTX has been checked out apply this patch file, before continuing the build.

Once WSJTX is built and configured, simply set the spot upload URL to:

and that's it. You shouldn't notice any difference, and spots should still appear on WSPRNet as usual. Once I've created a way of viewing them I'll update these instructions.

DSD and the Rapsberry Pi

This is a work in progress, and as such is more a journal of things that didn't work

I got DSD+ compiled without any issues, just following the instructions as George M1GEO did, however I did run into a couple of issues trying to decode anything and have been unsuccessful as of yet.

The first was an error “Fatal unable to get cpu freq from /proc/cpuinfo” when running ‘dsd -a’ to list the audio devices attached. I tracked this back to being a problem/bug/feature of the jack package, which is resolved in JACK2. Building and installing that following the instructions here: -cpu-mhz-in-proccpuinfo/

There is a JACK2 package in the raspbian repositories which I also installed for good measure, but found that the portaudio19-dev package will complain about it, but if you’ve already got dsd built you can ignore portaudio19-dev (the actual library is in the libportaudio0 or libportaudio2 package).

As an aside, this should also have fixed wspr, fldigi and anything else that uses portaudio.

This is where I ran into my next hurdle, dsd tries to open the soundcard at 48K, which the cheap Chinese usb sound card I was using didn't support so the program ungracefully segfaults, spitting vast quantities of errors to the screen. I did bodge round this by creating an upsampling virtual device, which did at least run. But as you’d expect nothing would decode given the limited bandwidth.

George reports that using 96K worked better for him, and he has a trick for making it work which escapes me atm.

Undeterred by this, I next tried to use an rtl sdr as the receiver rather than the ft857 I had been using before. This however proved to be unsuccessful. However I will detail how I attempted it and you may find it of some use.
From the dsd wiki it outlines that you can pass it raw data via STDIN rather than using an audio device, and the format happens to be compatible with that written by rtl_fm to std out. I should therefore be able to do the following:

rtl_fm -F 145.150M -s 48K -M fm | dsd -i - -o pa:0
and this should decode any dstar on 145.150 MHz, however I was never successful at decoding either the two local repeaters VK3RWN and VK3RMM, or a local transmission. I believe the problem to be with the audio level output from rtl_fm. Playing it back it is significantly lower than the volume of the noise, however there are no options to adjust this. There is a tuner gain option for rtl_fm however none of the values I tried 1 to 10K had any effect.
I would suggest maybe if your going to go down the rtl sdr route to use something like gqrx to demodulate the fm and raise the level before presenting it to dsd. However I haven’t had a chance to do so.

2.2" ILI9340C TFT and the Raspberry Pi


This page describes how I went about connecting a small 2.2" TFT display to the Raspberry Pi. This page is mainly for reference about what chip is in the display and what modules are required to make it work.

X server running on the 2.2" TFT in portrait mode.
X server running on the 2.2" TFT in portrait mode.

The hardware

The display is I purchases is a 2.2" Colour TFT with a resolution of 320x240. It is controlled with the ILI9340C LCD driver chip via the SPI bus and runs on 3.3v.  They can be found on eBay for a ~$6 AUD.

Continue reading 2.2" ILI9340C TFT and the Raspberry Pi