Purpose of these pages

If you look at any radio magazine, you'll conclude that a useful transceiver for a beginner will run at least $500 - and ham radio suddenly looks expensive. It wasn't always so - if you have great skill, QRP CW will get all over the world with a simple VXO direct conversion set.

However, I can't do code - just can't. (I passed my theory paper for the full UK license aged 13 - I can build stuff - but morse and my brain won't mix - I waited almost 30 years to get on HF from England...)

The softrock is a modern direct conversion design, and there are many pages on how to receive with one. Far fewer on how to use the softrock transceiver (the old 6.1 version got me a working txrx for $50).

I'm a homebrewer - so I don't use Windows - I use Linux. My faithful FT-107 is pre-WARC, and I wanted to go on 30m. These pages describe how to make a working 1W data station - and that Watt has so far gone 13500 miles from a 1/4 vertical antenna 27 feet up. You won't get bored just working the locals this way. And <10 extra lines of code added a sub-receiver dedicated to WSPR.

Almost nothing here is originally mine - I've just harvested the huge richness of Open Source Software out there. I don't claim I've chosen the best software - but this setup does work, and you're welcome to make and modify your own copy.

What are we trying to make

My goal is to make a collection of software and simple hardware that can be interfaced to other devices as if it were a 'normal' radio. For voice the devices would be microphones and speakers, for data there are programs - I use fldigi. This expects to connect via an audio library for audio (I offer portaudio), and hamlib for rig control. If I do the job well, then you can interface other software of your choice.

Initially I support the old OSS interface, by generating a virtual soundcard device. This required a barely supported kernel driver (fusd - for user space devices offering ioctl), and it's too awkward to keep up with the kernel versions. Portaudio is quite widely used on more recent software, so that's my current choice.
The same driver allowed me to generate virtual serial ports, so old software could use (virtual) serial port control lines for PTT. For the decoding software I've modified hamlib to provide frequency and PTT control. (My softrock PTT is indeed still driven by a real serial port control line - however letting several programs fight over the same line is a bad idea)
The CUSE (character devices in user space) development may yield a supported replacement for fusd - the key is that we need support for ioctl, and the current kernel user space device driver package doesn't seem to have it.

A recent addition here was WSPR - a really fun way to see where the propagation is. WSPR wants to listen to a narrow band around 10141 KHz. Remember this is a soft radio - all you do is add another receiver (another copy of sdr-core), and a bit of magic to give WSPR 12kHz samples, and your rig has just grown a sub-receiver (in hardware terms). Soft radios are flexible, adding the WSPR receiver took two evenings (mostly fighting ALSA) - a total of about a dozen lines of code.

What do you need

A decent Linux PC - dual core is really desirable, 2 GHz is nice. No need for fancy graphics, at least 1G of RAM. (You can use less, but then you can't run anything else with the ham radio.) A second screen is nice, just because your radio front panel is now made of (quite a few) pixels
A decent sound card. Now what we want here is >16 bits, 96+ KHz sample rate for capture and playback. Minimum of 2 capture and 2 playback channels. Oh, and it must have Linux support. I use a well-established favourite in the software radio world, the Delta-44 - 4 channels in, 4 out on a PCI card. Can often be found on eBay. Delta44 details.
A softrock or similar radio. In essence this is two direct conversion transceivers in a box, driven with local oscillator signals on the same frequency, but 90 degrees out of phase. (Old-timers may remember the phasing method of SSB generation - this is just the digital version of phasing, but for rx and tx). I have the old 6.1tx/rx softrock, so there's no code to set the Si570 used for the LO in newer softrocks - my local oscillator selects which crystal using a toggle switch. [I have now got a 6.3 kit awaiting construction - this software will be updated once that exists]
Some test gear (or friendly locals) - you need to null out the image on tx, and that needs some form of second receiver. Realistically you need a frequency counter to be sure you're in band - but there are many second hand ones, and DIY PIC-based ones as well.
A wish to tinker in software as well as hardware. You will learn a certain amount about Linux and software building this station - you don't need to be a programmer. (Ham radio is supposed to be about learning technical things...) I have used the Python programming language, and I'd strongly recommend it for the type of 'glue-ware' that assembles radios from other people's parts.
An antenna - I use the half square from the ARRL antenna book - needs two support points, with feed taken from one. For me that's at the top of my house and a nearby tree. With only a Watt, you can't waste too much, and if you want DX then a low dipole is normally a bad idea...

Warnings and Notes

A word of warning - I used modified versions of portaudio, hamlib and jack, libraries which may be used elsewhere in your system. Installing this software may break other programs that need the normal versions. I use /usr/local, so simply removing my versions ought to restore normal operation
This software is not packaged (into ebuilds or rpms or deb or...), nor is it ever likely to be by me. I don't have packaging skills (and I only have Gentoo, so I could not test anything other than ebuilds) Feel free to package it neatly if you have the necessary skills
The changes I have made ought to be fed back to the parent projects. I will do this where time permits, but getting accepted as a developer in each community takes time, so this is likely to be a multi-year task
I have provided a single .tgz file to contain all the sources for convenience. This does not alter the various license arrangements in the software components
Please note that my python glue code is GPL v2 only, and uses Qt4. You must therefore use a version of Qt which is compatible with GPL2 - version 4.5.1 (which I use at present) is licensed under LGPL2.1. You may not use a Qt version which is only available under GPLv3.
At present I don't support tx on WSPR - partly because I don't have an easy way to offer a virtual serial port (but CUSE may fix this), mainly because my xtals drift a few Hz when the box gets hot, and that's not good enough for WSPR. WSPR tx using a softrock will likely need a PTC thermistor or better to 'oven' the oscillator.

Changelog

5 Sep 2009 - new version of hamlib - fix bug whereby replies from python glue got out of sync. Clarified initial setup of qjackctl. No longer distribute wspr - the latest version now compiles easily

Roadmap for these pages

Overall_structure.html describes how what the components do, and how they're coupled together

Build.html tells you how to build each component, especially those that I've had to modify.

code1.tar.bz2 is all the code (I hope) that is either unique, modified or requires to be a particular version.

I'd love to hear if anyone else gets a Softrock transceiver going based on these pages. The preferred way would be via the linuxham or softrock yahoo group, email is possible - djch-pages at whabbit dot demon dot co dot uk.