brainwagon

I try to surf a lot of different ham radio blogs, mostly for inspiration about projects. My own life has been a bit hectic lately, and isn’t really likely to calm down until summer is well underway, but I am still reading. Today’s posting was inspired by a posting over on G4ILO’s blog:

G4ILO’s Blog: Scratching the SDR itch.

Surf on over and read, then come back. Please, come back.

I empathize with the opinions to a large degree, but overall I can’t help but think that it’s a very “doom-n-gloom” viewpoint that requires some criticism to put it in perspective.

First of all, I think it’s important to understand that for at least the last twenty years, computers and software has been a part of radio. Sure, mostly they have just monitored buttons and updated displays, but increasingly they provide sophisticated filtering and signal processing that would be difficult, costly or simply impossible to provide any other way. Software-defined radios are merely the next logical step in a continuum of software design in radio. And just like we aren’t going back to spark or tubes, we are aren’t going back to radios without microprocessors in them: they are just too cheap and too useful.

When Julian says that “general purpose computers are just too much hassle”, he’s probably right, but that isn’t an indictment of software defined radio so much as a indictment of the means by which we currently consume it: namely by using an operating system which wasn’t very well designed for the purpose that we have co-opted it for. Let’s face it: 99% of the annoyance of current SDR stuff is related to sound card issues, and that’s mostly because Windows (doesn’t matter what version) basically sucks for sound handling. Each card implements a different set of controls which can’t be reliably configured for a dedicated application.

But there is more than just sound cards: Windows isn’t very well suited to the creation of interactive interfaces. Yes, using drop downs and mouse is annoying compared to just turning knobs. But that’s not to say that better interfaces can’t exist. And, in fact, there is considerable reason to believe that once you involve software, better interfaces can exist. Being able to display 200khz or more of spectrum, and select individual signals just by pointing is a blast. Being able to design bandpass or notch filters by drawing or adjusting the filter responses interactively is great. Being able to configure soft buttons to switch settings for different monitoring tasks is cool.

Lastly, when Julian says “With real radios you can look at the schematic and get in there with your soldering iron and make modifications and or fix faults”, but that somehow that isn’t possible with SDR, it’s mainly a matter of perspective. Modifying software isn’t particularly any more difficult than modifying hardware: in fact, the nice thing about software is that it is usually easier and less expensive to distribute your changes. Understanding how to use an FFT or frequency shift and filter signals isn’t really that much harder to understand than (say) the details of how a Gilbert Cell mixer works. It’s just a different set of skills, one that we can nurture or not as we see fit.

I want to see more rigs which provide generic USB interfaces for sound and serial control (or if you need the bandwidth, how ’bout gigabit ethernet?). I’d love to have a radio with all the normal front end, but when I plug it into my computer, wide band sound data is available via USB and a serial tty port becomes available on my Windows, Mac OS or Linux box. It’s totally doable, and would allow us the best of both worlds.

I have an SDR-IQ, and it’s a nifty little gadget (although does require special driver support, which is a teensy bit annoying, although the drivers do exist on Windows and Linux). It literally is a black box, with a USB cable and an antenna port, and a single LED. It’s incredibly versatile, and one of the principle uses they have for them is to provide an wideband panadapter interface at the IF of conventional HF rigs. There is no reason that it has to be a separate box: it could be built into more conventional rigs.

I for one embrace our increasingly software defined future, and the new era of experimentation that it will bring. I think the real challenge will be to either acquire the necessary skills and imagination to create the applications that we all want, or to at least encourage a generation of younger software engineers to invest the time to do it.