I’m saving a link to this page, because I think I may have something misconfigured in my own attempt to use the EMU-0202 sound card for software defined radio. It’s probably not of much use to you if you don’t have that sound card, but… I do, so I am saving this.

Genesis G40 SDR Radio Transceiver QRP Kit.

Jeff (KE9V) posted an interesting commentary on an article by G4ILO about why he’s not excited by software-defined radio. My comments are mostly directed to G4ILO’s original statements.

Before I begin the rant proper though, let me say that if something in ham radio doesn’t appeal to you, you should by no means think that I’m asking you to change your feelings. Everyone is free to explore and experience their hobbies in a way that maximize their own personal enjoyment, without any kind of justification or rationalization required.

But somethings I thought that G4ILO were just a little off target, and as someone who is excited by software-defined radio, I think its good that I air the counterview.

G4ILO begins with:

I say this even though I am a programmer of sorts. I have tried to learn how SDR works with the idea that if I could write my own SDR software it might become an aspect of the hobby I could get interested in. But I can’t. The math is totally beyond me and I just can’t understand how it works at all. The majority of radio amateurs without any knowledge of programming don’t have a chance. Which makes the limit of most people’s technical challenge in an SDR future that of getting somebody else’s SDR software to work. And after a lifetime working with computers frankly I don’t find faffing about with PCs very much fun.

In some sense of course, this is entirely correct. If we compare the number of users of PSK31 to the number of people who understand the modulation technique in sufficient detail to write their own working implementation, I’d say the ratio is likely 1000:1 or 10000:1. But I think it is odd to say that someone “doesn’t have a chance” at understanding software defined radio. I’ve managed to work it out. Most software defined radios are just big down converters, using the principles of phasing that are well exposed in the ARRL handbooks and in books like Experimental Methods in Radio Frequency Design. Once you understand how the digital down conversion works, you can work on designing good low pass filters. Again, the math is a bit heavy, but it isn’t completely impenetrable. Once you have those two bits, making a SDR that receives CW and SSB signals isn’t particularly difficult. The overwhelming majority of hams won’t ever do that, but so what? Isn’t it great that we are able to do so?

G4ILO continues:

A basic understanding of electronics is one of the prerequisites of getting a ham radio license. Although most of us could not design an Elecraft K3 and many of us choose never to design or even build any part of our station, most of us can understand how radio circuits work and quite a few of us can build simple circuits from a schematic. Some of us can even design circuits from scratch – a lot more of us I’d wager than could write their own SDR software.

Again, this may be true, but I also suspect that it is because there isn’t nearly the overlap between ham radio operators and experienced software engineers. The ham radio population as a whole isn’t actually all that computer saavy: there are exceptions naturally, but in general most software written by hams is pretty crufty. Designing feedback amplifiers and impedance matching networks isn’t particularly easier than writing software defined radio software: it’s just different. Everything is hard when you don’t know how it works.

I also expect that while most hams think they understand how lots of things in their radio work, the number who actually do and are able to design bits of their own radio gear effectively is quite low. Guys like SolderSmoke’s Bill Meara who’ve been hams for 20 years are still working to really understand mixers and amplifiers, and benefit greatly from luminaries like Wes, W7ZOI and Rick, KK7B.

The reason I don’t like SDR is that it reduces the majority of us to the role of appliance operators. That may be fine for those who are happy being appliance operators and just want the best technical solution for working weak DX or amassing the most contest points. But for the tinkerers and builders SDR doesn’t leave a lot to experiment with, because most of the interesting stuff happens in software, inside the computer, where we don’t have the tools or the knowledge to tinker with it. If you are using a SoftRock or a top of the line Flex you will be looking at the same software user interface. And I don’t find that a very enthralling prospect.

The majority of amateur radios are already appliance operators. That trend is at least 40 years old, and it shows no sign of slowing. Most of the gear that you can buy now already has a large software component, hidden deep inside the unit where it is not only difficult but literally impossible for you to examine it. The glory of things like the Softrock is that even if you have a modest understanding of electronics, you can figure out what how it works, and can use your ordinary every day PC to process the signals from it. If you only use Rocky, well, then you’ve built a $15 receiver that can do AM, FM, SSB and CW with varying filters. If you examine the circuit, you”ll learn how Tayloe detectors work, and why they are a good idea. If you spend a bit more of time, you might begin to understand how sampling works, what the Nyquist limit is about, and how you can construct good heterodyne filters in software.

And frankly, the idea that software defined radios don’t leave much room for experimentation makes me blow milk out my nose. If it isn’t the kind of experimentation that you are personally interested in, so be it, but there is lots to do. I’ve been working on my own code for detecting QRSS beacon activity. I’ve got a perverse interest in modes like Hellschrieber, and thought that making a compact, self-contained rig to do Hellschrieber would be a fun thing to do, and could be powered by something as cheap and inexpensive as a dsPIC. Even if you just like RTTY, you could probably make a small self-contained rig that could decode multiple RTTY signals simultaneously. Or, you can develop (or someone can) really nice PC interfaces, like the one from sdr-radio.com. I’d like to see a SDR kit or design that includes the analog capture as well (we should stop relying on sound cards, which have characteristics which aren’t always in tune with our needs) so we can sever the ties with our laptops. I’d like to see software defined radios with wide bandwidth available at VHF+ (but perhaps cheaper than the ones available from ettus.com).

Software defined radios aren’t a panacea. They don’t solve all possible problems, or even any given problem in the best possible way. They do however give hams a set of tools and techniques that are versatile and exciting, and I welcome their addition to ham radio.

G3XBM posted a link to VE7SL’s nifty LOWFER beacon transmitter, setup to run around 188khz. I’m still fascinated by LF operation under Part 15, and this circuit is just about as simple as you can get. Very neat. Preserved for later consumption.

It’s too late, I should be in bed, but once again I’m reading up on low frequency radio communication, another of those oddball interests you pick up when you read too much. I blame tuning around with the SDR-IQ this evening, where I found that a number of DGPS beacons were easily heard down around 314Khz. Trying to find more information lead me to W3EEE’s excellent LF website, which makes me think that perhaps I should try receiving NAVTEX beacons sometime. Good stuff.

W3EEE – Mt. Gretna, PA, U.S.A.

Diane, VA3DB passed along this excellent page detailing the inner workings of the Gilbert Cell mixer. I was interested in these primarily because I was trying to understand the inner workings of the NE602/SA602/SA612, and was looking at an LTSpice model of it, and couldn’t understand the way that the various transistors were biased. I haven’t had time to read over this page too closely, but amidst the math I suspect the answer can be found.

Gilbert Cells.

I was driving around a bit yesterday (I needed a new hand nibbling tool to punch some holes in a project box, and wanted to get out of the house anyway, so a jaunt over to Harbor Freight seemed like a good way to kill two birds with one stone) so I did what I normally do: I downloaded a couple of amateur radio podcasts, and fired them up on my car stereo.

One of the podcasts I listen to is the Amateur Radio Newsline, and they were running a story entitled RESTRUCTURING: WIRELESS BROADBAND WANTS MORE SPECTRUM FROM ANYONE. The basic gist (go ahead and listen to the podcast if you like more information) is that Rick Boucher (D) is asking that the federal government undertake a complete inventory of radio spectrum for the purpose of determining reallocations to satisfy the growing need for additional wireless data services. In addressing the possible threats to the amateur service:

Its when you get to 200 MHz and above that the hunt will likely be focused and right there lies the relatively silent 222 to 225 MHz allocation. Above that is the 70 centimeter ham radio allocation which is secondary to the Federal Government. If the government were to decide to move completely out of 70 centimeters it could put a lot of weak signal operators and repeaters in a fight to keep the spectrum on which they now reside.

But likely the real losses would be up in the microwave range where hams hold a lot of spectrum that to date is used mainly by experimenters. And a lot of it sits adjacent to bands used by other services that might eventually be pushed by government decree into moving elsewhere or simply told to disband to make way for more wireless broadband services.

For amateur radio as an FCC licensed communications service this means being vigilant about attempts at reallocations that might include any bands that we use. It also means making certain that our ham radio political leaders are aware that every hertz from DC to light will be under scrutiny by both the wireless broadband industry and the government in the coming months and years.

So, here was my thought: that amateur radio use at UHF+ is actually on very thin ice. The reality of amateur radio at UHF and above is that it’s an incredibly fringe activity. I just used K5EHX’s repeater search engine to find all repeaters which provide coverage to my QTH. There are 85, but only two are not in the 2m or 70cm band. One is on 6m, the other is on 1285 Mhz. While this isn’t the whole story with respect to microwave operation, I think it is indicative of the kind of numbers were are talking about. Probably only one percent of ham radio takes place on the bands above 70cm, and that is probably being rather generous.

When we say that our “ham radio political leaders” should remain vigilant against possible spectrum reallocation, I think that we are shifting the responsibility (and in the future, likely the blame) to them, when the responsibility really lies with us. We as radio amateurs are simply not doing enough to justify our use of UHF+ spectrum. When we rely on political action committees to justify our use of this valuable public resource, we should be working hard to provide them with every possible justification that they can use. It isn’t Congress who is placing these frequencies in peril: it is our own inactivity which does so. If we lose 1.2GHz, or 220Mhz, or any of our other allocations, it will be because we frankly aren’t using them enough. If I thought that these frequencies could be effectively used to give Internet broadband to millions of underserved Americans, I’d have to say “take those frequencies, we will miss them, but we had our chance with them”.

What do you all think?

I was surfing around the web today looking for an LTSpice model for the NE602, and came across the Elmer 101 FAQ, which is basically an explanatory supplement for the Small Wonder Labs SW40. I haven’t read this carefully yet, but it looks awesome, including much discussion of how the various circuits were designed and work, along with hints on how you might simulate them with PSpice (or LTSpice, presumably).

As I was chatting on the QRP Echolink conference tonight, the subject of code practice oscillators came up.   I think it was Bob, AD7BP who first mentioned the  NT7S Code Practice Oscillator which I hadn’t seen before, but seemed like a very simple and easy to assemble circuit.  We also discussed the fact that the latest issue of QST has started to use LTSpice in their Hands On Radio column.   As I was waiting for my turn at the round table, I went ahead and entered the circuit into LTSpice to see how it worked.     Here’s the schematic I came up with.

Go ahead and click on it to make it bigger.   There are some small changes.    I went ahead and added a load resistor R9 (I set it to 32 ohms here, with the idea that the oscillator would be hooked to a set of low impedance earphones) and instead of modelling the key switch, I instead powered it with a pulsed voltage.   I was mainly interested in seeing what the shape of the output signal was, so I set it up to a transient analysis.   Sure enough, it generates a nice sine wave.    I set the input pulses to be about 50ms long, which should be about the same as the dits at 24wpm.

Here’s the resulting simulated circuit:

NT7S Code Practice Oscillator Waveform

Running an FFT on this output data shows that the oscillator frequency is right around 680 Hz, with an output power of about 0.5mw, and the second harmonic over 20db down, and the 3rd harmonic 30db down.   I’d say that qualifies as a pretty reasonable waveform.  I thought that the output power was a bit low, but the oscillator is normally used with either ear buds, or with an external amplifier.   I suspect it will work reasonably well.

It was a fun experiment in using LTSpice.

Addendum: It dawned on me that simulating the keying by pulsing the input voltage wasn’t entirely correct: in the original circuit, the keying is provided by grounding the 560 ohm resistor, while power is continuously applied.   Even intuitively, one might see how that makes a difference, because various capacitors in the circuit will remain continuously charged.   This morning, I decided to go back to a straight DC power supply for Vcc, but then installed a small switching transistor between the 560 ohm resistor and ground, and fed <em>that</em> with a pulse through a current limiting resistor.   The waveform cleans up a bit at the beginning: we have a nicely shaped ramp up, without the overshoot that we saw previously.

Addendum: I was wondering if I could use this information to find out what this circuit would really sound like: in other words, I wanted to convert the raw LTSpice output into a .WAV file that you could play back on your PC.   It turns out that LTSpice can export the waveform in an ASCII format, which includes a bunch of lines which have two numbers: a time, and a value.   The slightly annoying thing is that the times are not evenly spaced.   So, I wrote a tiny chunk of Python that takes in this file, and resamples it to evenly spaced times.   I write this out again as an ASCII file, adding a small header so that the “sox” sound utility can read it, and convert it into a wav.    I then use my normal “lame” command line mp3 encoder to convert it into an mp3 file.

The following sound file was converted from the real data, and consists of three groups of ten dits, sent at 24 words per minute, with some space in between:

Simulated sounds of the NT7S code practice oscillator

I also found out that sox can actually draw spectrograms of wav files. It’s not quite as versatile as the homebrew code that I wrote, but it works. Here, the individual dits kind of run together, but it shows that the second harmonic is at least 40db below the primary frequency, so the dits are pretty clean:

Spectrogram of the NT7S Code Practice Oscillator