Prototype Hardware for gnuradio


I am new to gnuradio but so far am very impressed with the design,
organization, and functionality of the software. Recently, I developed a
prototype of a small, relatively low cost, hardware platform for SDR
experimentation and wanted to make that information and my efforts
available to the gnuradio community. I’ve posted some basic information
and my initial efforts to integrate the hardware into the gnuradio
framework on the web at

Hardware summary:

Single input, receive-only.
27 MHz LPF and -5 to 43 db LNA.
Switchable LPF-LNA Bypass.
80 Msps 12 bit ADC/DDC (TI AFEDRI8201), 2.5 Msps IQ at minimum
Connector plugs directly into PMOD Ports on Digilent Nexys2 FPGA Board.
Approximate construction cost (single/small quantities) ~$80.
Construction possible using mylar solder paste stencil, “skillet”
reflow, a pair of tweezers, and a steady hand.
FPGA/USB Board – Nexys2 from Digilent ($99+$20 for 1.2M gate Spartan

Software (so far):

FPGA code (verilog) including FIFOs, Digilent USB-to-FPGA protocol, SPI
Master for AFEDRI8201.
nexsdr_source_c() block patterned after usrp_source_c().
Converted version of
Converted version of


WFM works great with antenna connected directly to input (no amplifier
or filter) with bandpass sampling (tune to f-80MHz), sounds better than
my car radio.
NBFM works great listening to several amateur repeaters on 2 meters
(~147 MHz) with antenna connected via 4 MHz wide BPF to input (no
amplifier) with bandpass sampling (tune to 160 Mhz-f).

The hardware is not Universal (USRP) or High Performance (HPSDR) or
super cheap (Softrock + sound card) but I’ve found it quite useful as a
platform for experimenting with gnuradio.

I’ll continue to document my efforts at the site listed above and,
again, thanks for a great open source framework for SDR. Your comments
and suggestions are welcome.


nexsdr_source_c() block patterned after usrp_source_c().
Converted version of
Converted version of

Congratulations on building your own high function SDR hardware!

Just a brief remark on the software. It’s great that you were able
to get it running quickly via replacing “usrp” with “nexsdr” in
various places, but that really shouldn’t be necessary.
The “fm radio” high level GUI and signal processing code should
not know or care what low-level radio interface is in use.

The WBFM application required removal of the subdevice code,
modification of the tuning code (removed the residual tuning), and
adjustment of the gain.

The prevalence of the USRP1 led us to be lazy about how GNU Radio
applications are structured. High-level code like
have the name and details of the low-level radio interface (“usrp”,
subdevice names like usrp_dbid.TV_RX_REV_3, etc) wired into them. Now
that we have USRP1, USRP2, HPSDR, and your new SDRtrack, this is
becoming more than inconvenient.

All the low level drivers implement the same interface class – the
rest of the code just needs to know which one to call, dynamically.
The high level GNU Radio software should be altered to receive from
“standard radio input” and transmit to “standard radio output”, so
that every application doesn’t need to be tweaked just to change the
device used. The standard radio input would be set in a tiny config
file (probably just a Python source file, unless the all-in-C++
faction wants to provide a parser), kept in your $HOME directory.

Then all the filenames wouldn’t start with “usrp”, wouldn’t need
to import the “usrp” class, etc. They’d import a class like “radio”,
the radio class would open the $HOME/.gnuradiorc file, and
it would import the USRP, USRP2, or whatever other module the
user had selected (manually, or in a small config GUI).

This is how audio works, it’s how video works, it’s how disk drives
are interfaced. You don’t run sata_mount for your 1.5TB disk drive,
pata_mount for your old 80 GB drive, and usb_mount for your flash
keychain; you just call “mount” and it figures it out. Modularity is
your friend.