My dream is to contribute to freeing the Internet from it’s bondage to wires. This is something we’ll have to do if we ever hope to really battle Internet censorship bills like PIPA, SOPA, and now ACTA; Or to prevent the government from looking into your proverbial home-on-your-smartphone without a warrant.
That’s why on December 18, 2011 (one year ago this week), I decided to build something called a software defined radio. For those who don’t know what a software defined radio is, Eric Blossom, an early innovator in the space wrote this:
Software radio is a revolution in radio design due to its ability to create radios that change on the fly, creating new choices for users… Perhaps most exciting of all is the potential to build decentralized communication systems…. A centralized system limits the rate of innovation. We could take some lessons from the Internet and push the smarts out to the edges…. These user-owned devices would generate the network. They’d create a mesh among themselves, negotiate for backhaul and be free to evolve new solutions, features and applications.
After reading that, I started in earnest. Having a background in Computer Engineering and focusing on something called FPGA hardware design, I knew that I could build a device even though it was to be my first radio design. And a few weeks ago, I got my first transmission to come out of the antenna!
Let me take you through a tour of the board, so that way you can get a feel for where the project is at, where my issues lie, and what the next steps are.
Overview
Ther core of the system is the Microsemi SmartFusion series customizable System on a Chip (from now on called a SoC.) A lot of big manufacturers including Xilinx, Altera, Cypress, and Microsemi all have SoC devices that contain at least one ARM processor, as well as programmable logic. In my case, there’s a Flash based FPGA fabric hooked up to an ARM Cortex-M3, which I’ve used to do all (yes, all!) of the signal processing.
That’s right, since the whole system sits on a single chip, a high speed interconnect over Ethernet or USB to a host computer isn’t necessary. Everything happens on the board, with a theoretical maximum of 16 Gb/s interconnect between processor and FPGA.
I’ve realized a portable device, that I’m holding here running off of 4 AA batteries:

The SoC talks to a highly integrated radio frontend chip, the CMX991 quadrature transceiver from CML Microsystems. This IC transmits and receives from 100MHz to 1GHz. It’s designed to be the core of a P25 radio, which is the standard used in police radios, but since it’s quadrature and can mimic any mode, it can do so much more once hooked up to the SoC. I chose this chip because it covers the 2m and 70cm amateur radio bands, which are the two most popular VHF/UHF bands.
Development Environment
I really enjoy my development environment, thanks to the countless hours others have put into Open Source hacking, and especially the work done by the engineers over at Emcraft Systems. I have uClinux 2.6 running, and have access to a BusyBox shell via UART over USB, as well as the full networking stack connected to a 10/100 Mb/s Ethernet jack on the board. This allows me to load custom built kernels over TFTP, and to mount my development files over NFS. C files are cross compiled with GCC for the ARM Cortex-M3 target.
The programmable logic has been written in Python, and then transpiled to Verilog by a tool called MyHDL. This has allowed me to develop using high level constructs like unittests and object inspection. No small feat, if you’re familiar with coding Verilog. I’ve simulated the entire radio on my development system, including having it talk to a GNURadio receiver, all virtually. This means I can iterate on ideas quickly and verify their correctness before I go through the lengthy process of synthesis and programming onto my board.
I’ve written a simple C program that runs on the device, mainly to talk to the FPGA. I issued the following commands to get the radio to transmit:
$ radio power_down
Put the radio into a sleep state, in this state it consumes 120mA @3.3V, or 400mW. There’s an even lower power mode with the real time clock only turned on, but I haven’t gotten to enabling that mode yet.
$ radio power_up
Power up the DAC, ADC, Radio frontend, and warm up the VCOs. This state consumes 220mA.
$ radio mode tx_test
Put the radio into the tx_test mode, setting up the radio frontend registers. This also sets up the FPGA to flow a CW 1200Hz audio tone though an AM voice modulator.
$ radio dial 144.39e6
This dials the VFO to ~99.2 MHz (doh! check out below for my discussion on this issue), and bumps up the radio to consuming 330mA.
$ radio tx
This outputs a 1200Hz amplitude modulated tone for 10 seconds. I know this is bad in the real world, but the transmit power is at -36dB at the moment so it wouldn’t radiate out of my room. You can see my goal though - to build an APRS transmitter & receiver. During transmit, the device consumes 360mA, at 3.3V. This is ~1.2 Watts of power, for the entire software radio transmitting. Plenty of budget for a power amplifier!
Analog Signals
Lets follow the trail of a transmit using my oscilloscope to see what’s happening. First, when I issue the tx command, the 1200Hz wave comes out of the DAC thanks to the Direct Digital Synthesizer I wrote inside of the FPGA.

I would like to increase the dynamic range coming out of this circuit, as the radio frontend can take a full Volt peak-to-peak as input. I also need to add a low pass filter. I know, a rookie mistake!
The analog baseband signal coming out of the DAC is then up converted by two analog mixers in the radio frontend. First, the IF VCO:

I’ve got three issues of note here:
- This should be a hard 180MHz signal, but for some reason it seems to vary anywhere from 170MHz to 190MHz depending on the moons and the tides (in other words, I’m at a bit of a loss on to the stability issues here.) Also, I need a spectrum analyzer to really get a good sense of what frequency is really coming out since the oscilloscope says two different frequencies on the same display. Slightly maddening.
- I need to make the traces wider for this section of the board, as you can see the 3.68mVp-p with a 50ohm impedance oscilloscope probe is just squeaking by as a signal. Yeah, I know, I didn’t impedance match the RF traces yet.
- I missed a resistor in the negative resistance amplifier filter, so I’ve had to cut the board with an exacto knife, and have a rogue through hole resistor flying off into the third dimension. This really limits the portability, as I seem to snap it off even when I move the board across my desk!

The IF VCO is divided by four, and then mixed with the incoming signal from the DAC. It is then mixed again from this intermediate frequency with the RF VCO, this time divided by two. Here’s a snap of the RF VCO:

I also have a frequency problem with this circuit. When I tune it to the lowest frequency, 35MHz, it runs like a champ. But when I go higher, things start to drift off from ideal. In this case, I had dialed into 198.78MHz, which is what I need to dial to the APRS channel 144.39MHz. But alas, it is off by a wide margin.
So, finally, here’s the fully mixed RF signal:

That’s the 1200Hz tone I explained in previous posts, but now it’s been upconverted and AM modulated to a 99MHz RF carrier. There’s definitely some noise in there, and this is where I think the “rf black art” is starting to come into play.
Next Steps
I’ve turned on the receiver part of the circuit, but haven’t gotten too far into it since I can’t lock onto a real transmission with my VFO. This means, my most immediate concern is figuring out how to get the VFO to hit the mark.
I was concerned that I will have signal integrity issues, and I’m sure that if I cranked up the dial to the theoretical 1GHz maximum I would be in problems. I will go back and impedance match to a good circuit board material for the next revision.
But for all of those issues, I have to say that I’m quite pleased with what I’ve accomplished in one year. I built this board even though I knew there’d be problems, but I wanted to prove two things:
- That I could assemble all the parts and get them to work together.
- That the device would run off of batteries.
I’ve accomplished both of those tasks. Now, it’s going through the motions to fix the known issues. I bet with the help of the right RF engineer and a design review or two of my circuit board, I could produce a second revision of the board that worked quite well.
It’s still a “test device” since it’s not a fully packaged radio, but the novelty of having the whole software radio fit in your palm is exciting. I think this is an RF hacker’s dream. So if anyone wants to help me debug these issues (please, please PLEASE!) I would be happy to hook you up with a second rendition of the board for your help. Any takers please email me testac (at) <google’s public email domain>.com
I’ve also thought extensively about what the software is that I want to run on the ARM and FPGA. I’ve even sketched how to fit the whole AM/FM/SSB/CW/APRS & more inside of the chip. I still have lots of testing to do to find the best mix, but expect some posts on this stuff soon.
Thanks
I’d like to send a shout out to a bunch of people who’ve helped me get to this point:
Julia Cameron, author of the Artist Way book series, which got me to follow my boyhood dream of designing circuits.
Aaron Schulman @ University of Maryland, Ye-Sheng Kuo @ Unversity of Michigan, Thomas Schmid @ University of Utah, and Prabal Dutta @ University of Michigan. Without their help, Open Source mindset, and access to university equipment I wouldn’t have made it this far.
The TAPR and Amateur Radio organizations for their interest and helping me along the way, especially Steven Bible and John Ackerman. I also need to thank Bruce Perens who’s inspiring talks helped guide me over the years.
Important figures in software radio including Eric Blossom, Matt Ettus, and Tom Rondeau, who’s achievements make anything seem possible.
To Google and YouTube for teaching me the ways of really engineering a solution to a problem. To the Adly team, especially Derek Rey who’s been an incredibly supportive friend and colleague. And to my parents for being there, always there, no excuses.
Thank you all!









Amazingly, man has been synthesizing a wide range of nano-scale materials since Prometheus taught us how to control fire. Light a candle and trap the burned exhaust above the flame, and you’ve collected a wide assortment of carbon allotropes. Protein processing techniques can then be used to segment these byproducts, called nanoflorescents, by mass and charge. Different types give off different colors when UV radiation is applied (image of segmented nanostructures and the light emitted frequencies on the right). [1] But what about the production of homogeneous nanostructues, like Single Walled CNTs or macro-scale diamonds? Larger scale production of pure allotropes is becoming easier since chemical vapor deposition started to be used in 1993, and efficiency gains in production continue. [2]
CVD has even lead to the synthesis of pure diamond blocks, developed by Apollo Diamond Inc and purchased by Scio Diamond Technology this year (there’s one on that guy’s finger!) [4] A whole new world of carbon-based processors are on the horizon, which promise another breakthrough in processor frequencies (30GHz processors please!) As you could guess, DeBeers is rumored to be quite anxious about this development, and developing techniques to recognize flawless aka “counterfeit” diamonds for jewelers. That’s fine by me, I want to use diamonds to improve technology and society, not amass blood money.