2009-02-15: Paul's Softrock GNU Radio Experiments •
Last semester I had a wireless networking class at Western Michigan University. It was a 600 level class taught by Dr. Ala al-Fuqaha. (Incidentally, the captioned images are actually a bit larger than they appear, click to see full-res.)
I was tasked with sending video “or something” using some kind of radio gear (USRP or something cheaper) using GNU Radio. Dr. al-Fuqaha was mainly interested in whether GNU Radio could be used for research projects of his. He was particularly curious if it could be done using really cheap gear ... cheap enough for me to buy it myself ... so I did. The Softrock Lite kits (receive only) cost about $20 shipped, so I bought two. The RXTX kits are about $100, but they transmit and receive on almost any HAM radio frequency. (My prices could be way off too, so don't take my word for it.)
First of all, building the softrock gear was very satisfying and fun. Words cannot express how much fun it is to build something from scratch (or, from parts carefully packaged by Tony Parks). And speaking of Tony Parks (KB9YIG), ordering the gear was one of the more challenging parts of the project, right up until I learned his email address. I placed all my orders via email. His address is his ham radio ID (in parens above) at gmail.
Actually building the devices would be basically impossible for a newb without help. I first built two Softrock Lite devices, one 80m and one 40m. That got my feed wet. They're not too awfully complicated (schematic.pdf). Everything I needed to know was explained in detail in the extended build notes — which can be found in the Yahoo! Softrock group. (They also helped me out when I screwed things up.)
The Softrock RXTX+Xtall was quite a bit harder to build. The extended build notes are more like a life preserver than a rescue craft. I imagine experienced builders wouldn't find it too bad, but it was daunting for me — I'm still a newb (schematics: 1, 2, 3, 4 and 5).
There's no question that the RXTX kit looks much cooler than the Lite kits. These devices can transmit and receive on almost any HAM radio frequency. It's nontrivial to build a signal filter that covers that wide a buffet of wavelengths, so they didn't design it that way. They ship four receive bandpass filters with the RXTX. You simply plug in the module for the band you want to receive. The transmit filters (called PA Filters) are a little more involved, so you have to order them separately. I ordered one 80m/40m PA Filter for the transmit side. None of these modules are plugged in the image above, they are scattered around it instead.
The configuration I actually used is shown on the right. An interesting side note: The Softrock Lite 40m hears waves with a length of 40m with its center frequency right around 7.056MHz (7.032MHz - 7.080MHz with a 48k sample rate). On the other hand, when configured for 40m waves, the RXTX transmits with a center frequency of 7.046MHz (7.022MHz - 7.070MHz on a 48k sound card). I corrected this difference using a software mixer (the multiplier in the diagram below).
It would have taken me quite a while to figure out the frequency discrepancy without some kind of visualization aid — mainly because the Softrock Lite docs state the range as 7.032MHz - 7.080MHz while the Softrock RXTX docs state the center frequency of 7.046MHzi (definitely within the Lite's range).
For visualization, I used real time FFT plots. The math seems to be over my head, but GNU Radio comes with an excellent suite of tools — among them is an FFT calculator. The fft plot generator I used (fft.py) produces plots like these:
Really, it probably should have been obvious the center frequencies wouldn't line up between the two devices and had I calculated it, I would have noticed. But the FFT showed me my error either way. It helped with other things too. I was encountering an awful lot of noise and absurd amplitude dips depending on where my approximately 9ft antennae were located. At first, I assumed this was path loss (from the 40m signal bouncing around my office); but some guys on #gnuradio convinced me it was really “near field interference.”
In the end I was able to affect the receive signal very dramatically by simply walking around the room until the signal got better.
Initially I wanted to send the files using ODFM encoding. I managed to get that working when using files, but had a lot of trouble with it when I tried it over the wire. That is, at first, I tried to get the GNU Radio stuff working over a regular old headphone wire. I discovered that OFDM expects an awful lot more bandwidth than the 48k sample rate of my soundcards. I switched to GMSK, a technology from older modems (circa v.29). It's a kind of continuous PSK that is currently used in GSM.
Here's what the signal looks like after the sounds cards munch it up. Just imagine what happens to the wider OFDM signal. Then imagine what happens when you throw near field interference into the fray.
Anyway, my setup looked like this (diagram from the GNU Radio Companion):
Briefly, the packetizer source is really the blks2.gmsk_mod pkt_queue. The low pass Firdes filter stomps on the parts of the signal that are just noise surrounding the GMSK signal — this is superfluous, but beautifies the FFT, a band-pass filter on the recv side would make more sense. The 48k 7001Hz sine wave is multiplied, or mixed, with the gmsk at baseband to produce a gmsk signal at 7001Hz. The constant multiplier is my “amplifier.”
7001Hz was chosen because it's a prime number and I find that humorous, not because it's a good idea to use prime numbers for this sort of thing. Also, note that in my actual runs, I mixed down to -2999Hz because my transmit side has a center frequency 10k lower than my receive side (this is the -c option in the transmit.sh, see below). This may seem to be a backwards correction, but it's because the soundcards don't understand the radio center frequencies, so the translation manifests counterintuatively.
The GNU Radio Companion is an excellent starting point for building applications. I'm not sure I would have figured out how everything hooks together as easily without the system. It's unlikely I could have written any finished applications with it, but it does an awful lot of typing for the users. It also produces the diagrams like the one above.
Lastly, I was supposed to have to do a project demo before the class at some point. That part of the project got canceled, although I did get to demo the project for the instructor. Because I expected getting this stuff to work would take far longer than the eight minutes the demo was supposed to last, I built a boot CD linux distribution to help speed the process. I called it /eidolon/, a kind of ghost. It did turn out to be handy during the private demo for the instructor, since all his lab computers are Windows NT based.
I'm happy to announce that I got an A, probably just because my project took a lot more effort than the average one-semester project.
The sources for all this stuff (except the bootcd, which is a trivial
set of shell scripts) are available here:
git clone git://github.com/jettero/cs6030.gnuradio.git