×

Message

EU e-Privacy Directive

This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

You have declined cookies. This decision can be reversed.

Have you ever thought about running your own DX cluster node? I must admit for a long time I didn't use to think I needed it until recently when, in order to speed up NKCCluster development, it became apparent to me that a DX cluster node I could easily deploy in a CI environment would considerably speed up my development process.

Although DX Spider Installation is well documented, I wanted something that I could "fire & forget" and spin up a running DX cluster node in seconds. It seemed to me that a Docker image would be a very convenient way to achieve this. After some googling, I couldn't find anything on the Internet, although on GitHub there exist several repositories whose contents suggest others had similar idea (unfortunately, with no tangible results).

I thus decided to develop the DX Spider Docker image myself. Although it is still in its early stage, it is already functional enough to bring up a working DX Spider node in seconds. Its source code is in GitHub repository kconkas/dxspider-deployment and the image itself is available in identically named DockerHub repository.

Give it a try and see if you like it. GitHub pull requests and bug reports are very welcome.

Note: this image will only get you a running DX Spider node, but will not link it with any other nodes. If you'd like to link it with another node, you will need to agree this with an owner of another active node and configure your connect file for it. You can find more details about it on the DX Spider Wiki.

Credits

Huge thanks to Dirk Koopman (G1TLH), the author of DX Spider, for this invaluable piece of software.

Relatively low pass, from AOS to ~20 deg. elevation for this picture.

Equipment:

  • FT817
  • 3-el Yagi (hand-held)
  • QSSTV on Fedora Linux

PD120_20180402_174208

After initial delay, ARISS SSTV commemorative event continues being well received across the globe. These picures were recorded on 12th April 2016 at about 20:15 UTC in IO91:

PD180_20160412_215052

PD180_20160412_221548

Note this pass wasn't very favourable for my location, at its highest elevation (and, conversely, the strongest signal) a 3 minute off period (when no signal is transmitted from the ISS in order to allow the gear to cool off) kicked in. Therefore in this pass I could only record the end of one image and this one in which the signal slowly drifted into white noise as the ISS was reaching my radio-horizon. Still, I'm pretty pleased with this picture.

Received using:

  • Yaesu FT-857D
  • Fedora linux, Gpredict and remote hamlib for radio control (Doppler)
  • Raspberry Pi + Raspbian attached to radio for hamlib remote control and for audio capture
  • QSSTV (learn how)

Excellent signals in IO91 in a pass starting at around 17:40 UTC.

PD180_20160413_180335

Received using:

  • Yaesu VX-7R
  • QFH antenna

I find ARISS SSTV events very exciting. To me, nothing beats receiving signals from space. But these events also provide a nice opportunity to experiment with receivers, antennas and decoding software.

I usually record the audio and then decode it after the event. This is immensely easier than waiting for next suitable ISS pass in case I've forgotten to set up something. This is also convenient because once I've recorded audio, I can experiment with various ways to decode it.

So, the basic idea is very simple - I'll record audio and decode it later at my own leisure. Problem is many popular SSTV packages only support decoding from audio input devices and thus a virtual software audio device which "sits" in-between an application that plays received audio and an application that decodes SSTV (and behaves just like any other audio device to both applications) needs to be used. 

I successfully tested this approach on several platforms:

But my preferred platform is still Linux, I've got several laptops running Fedora around plus another few Raspberry Pis running Raspbian. I started wondering how to do this on Linux. Finding a Linux open-source SSTV application was easy - there is an excellent piece of software called QSSTV, developed and maintained by Johan, ON4QZ. Unfortunately for me, even though in its Sound options it is possible to select Sound Input -> From File, I could never decode any of the recordings I'd made. Maybe I just failed to understand what this option was about, or perhaps I was just not using it correctly, I don't know. So I started wondering whether the virtual audio cable approach would work on Linux. And this is how to do it:

 

Software you will need

  • Pulseaudio (it may have already been installed with your Linux distribution, if not simply install it from your distribution)
  • Audio player that supports selecting an output device (in this example I am going to use VLC) - again, the simplest approach is to install it from your distribution
  • Qsstv 9.x (lower versions do not support the audio device selection). If you can't find it in your favourite distribution, you can build it from source code, the instructions are on http://users.telenet.be/on4qz/qsstv/manual/installation.html)

 

Setting up a virtual audio device

Firstly, you will need to load a PulseAudio module called "module-null-sink" (if you're interested in having it included permanently, take a look at your default.pa file).

To load it manually when you need it, from your shell screen run:

$ pactl load-module module-null-sink sink_name=virtual-cable
29

Provided there were no errors reported, you can ignore the number printed out by pactl. Although Pulseaudio can best be tweaked from command line, I find the pavucontrol GUI very handy and a real time saver. Run it as:


$ pavucontrol


If your module-null-sink loaded correctly, you should now see it in the GUI:

 

Start qsstv and click Options -> Configuration -> Sound. Ensure PulseAudio interface is selected:

 

Return to pavucontrl window. Click on the Recording button (remember: our Qsstv needs to record audio from our file!). 

 

Click on Built-in Audio Analog Stereo (or whatever your device is called) and from the pulldown menu select the pulseaudio virtual device previously created:

Our virtual cable is now connected to Qsstv input, the only remaining step is to play our file to this virtual source. There are numerous Linux applications that can play audio to a specific device (this can be done from command line too!).

 

Playing audio to null-sink using VLC

VLC is one of the simplest applications to use for this purpose, from Audio -> Audio Device menu simply select your virtual device, load the file and you're good to go.

 

Playing audio from command line

As simple as it can possibly be:

$ paplay -d virtual-cable iss_2016-04-12_2109.wav

 

And proof of the pudding....

This is a screenshot of a decode in progress from a recording of an ISS pass over my QTH on 12 April 2016. The pass was somewhat unfavourable, with a 3-minute time-off period kicking in slap-bang in the middle of a pass (hence the fading and blurred lines as the pass was coming to a close).