Forum: GNU Radio Prototype Hardware for gnuradio

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A7e1721f705e02d4328c0ccdedb4c796?d=identicon&s=25 unknown (Guest)
on 2008-11-03 16:32
(Received via mailing list)
All,


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 http://sdrtrack.drupalcafe.com.


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
decimation.
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
III).


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 usrp_wfm_rcv.py.
Converted version of usrp_nbfm_rcv.py.


Results:


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.


John
891c140a55f53b9a238adcb9cc5febb6?d=identicon&s=25 John Gilmore (Guest)
on 2008-11-05 13:37
(Received via mailing list)
> nexsdr_source_c() block patterned after usrp_source_c().
> Converted version of usrp_wfm_rcv.py.
> Converted version of usrp_nbfm_rcv.py.

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 usrp_wfm_rvc.py
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.

  John
This topic is locked and can not be replied to.