Jon Jacky, May 2005
These are two separate issues.
Neither application is in the intended domain, but will probably work anyway.
I'm leaning toward yes and yes, but there could still be show-stoppers.
Excellent pedigree: MIT EE/CS mid-late 1990's
JSAC 96 and JSAC 98 papers from these projects provide nice description of motivation and architecture.
Two spinoffs, one commercial, one open source
Both apparently thriving now.
This technology has been shown to work well in its intended domain.
Active, technically savvy user community --- dozens build hardware, write code
Hobbyists and individuals, also university research groups and government labs.
High traffic mailing list with high SNR
One developer (Eric Blossom) currently manages core system,
project direction ---
but system appears sufficiently mature and robust to survive regardless.
Core software developed on PC with Linux, GNU tools
Much of the software has been ported to BSD, Windows, Mac OS X by other developers (all using GNU tools)
Complex, fragile development environment is a serious barrier to casual use. Must obtain, install, configure many prerequisites.
Many users write software which is not part of core, no systematic distribution (Sourceforge, email, author's web site, etc.)
A few commercial PCI ADC, DAC supported (most quite expensive)
A few users have supported custom hardware (one-of-a-kind)
USRP: Universal Software Radio Peripheral
Signal flow graph composed of signal processing blocks connected by wires
One-way flow from signal source (ADC) to sink (DAC, scope, ...)
No loops among blocks --- feedback must be modeled within a block
Any other restrictions? Not yet clear.
Wires can carry many data types, including vectors (spin simulation!)
Blocks can have multiple inputs, outputs
Blocks can run at different sample rates (decimation, interpolation)
Hierarchical blocks planned, not yet supported
Scheduling and buffering among blocks is complex and obscure.
Restrictions?
Key issues for our evaluation.
No detailed explanation in GNU Radio documentation. Inferred from MIT papers, mailing list traffic, code reading, observation
Create schedule for blocks by working back from sink to sources
Calculate each block by working forward from sources to sink, guided by schedule
Traverse entire flow graph to calculate each sample at sink (possibly no propagation delay from source to sink)
Calculate with whole buffers (4095 samples typically), not one sample at a time
On wires within the network, time is not represented in any obvious way
Depend on hardware clock to "push" data from source (ADC) and "pull" from sink (DAC).
Much buffering within flow graph. Implies FIFO at input and output. Implies latency through network, but no fixed lower limit on buffer/FIFO size.
Scheduling within flow graph managed by GNU Radio code, not OS
Flow graph computation is all in one OS process/thread. Multithreading has been discussed.
Not clear how GUI scheduling fits in
Three levels:
Documentation scant but usable
I can work with this. I've already debugged/modified in all three categories.
We're doing it
wxPython GUI seems fragile, lots of platform sensitivity, unlike the rest
Packaging issues
Short latency (cantilever control)
Concurrency, multiprocessing (spin simulation)
Neither issue is a problem in the intended domain ---
we're on our own
(but EB willing to offer advice)
Press on!
Finish and distribute port, gain experience, final decision later
Even major changes to scheduling etc. seem easier than starting from scratch
Revised June 2006
GNU Radio home
http://www.gnu.org/software/gnuradio/index.html
GNU Radio mailing list, discussion, searchable archive (very useful)
http://lists.gnu.org/archive/html/discuss-gnuradio/, also
2006-01/threads.html etc.
GNU Radio Wiki
http://comsec.com/wiki
USRP, GNU Radio hardware
http://www.ettus.com/index.html
http://comsec.com/wiki?UniversalSoftwareRadioPeripheral
http://lists.gnu.org/archive/html/discuss-gnuradio/2004-12/msg00088.html
GNU Radio GUI screenshots
http://www.gnu.org/software/gnuradio/screenshots.html
GNU Radio installation instructions
http://www.kd7lmo.net/ground_gnuradio_install.html (Linux)
http://staff.washington.edu/~jon/gr-osx/gr-osx.html (Mac OS X)
http://www.nd.edu/~mdickens/GNURadio/ (Mac OS X)
http://lists.gnu.org/archive/html/discuss-gnuradio/2006-04/msg00190.html
(Mac OS X)
http://www.olifantasia.com/projects/gnuradio/mdvh/mingw/
(Windows)
GNU Radio tutorial articles by Eric Blossom, with code samples
http://www.linuxjournal.com/article.php?sid=7319
http://www.linuxjournal.com/article.php?sid=7505
GNU Radio tutorials by other users
http://www.nd.edu/~dshen/GNU/
http://webpages.charter.net/cswiger/modules.html
GNU Radio users' web sites, with code and screenshots of experiments and applications
http://webpages.charter.net/cswiger/
http://www.kd7lmo.net/ground_gnuradio_software.html
http://web.media.mit.edu/~jcooley/gr_experiments/index.htm
http://viral.media.mit.edu/wiki/tiki-index.php?page=BPSK
http://www.olifantasia.com/pub/projects/gnuradio/
USRP hardware packaging and installation
http://web.media.mit.edu/~jcooley/gr_experiments/experiments/setup.htm
http://webpages.charter.net/cswiger/amps.html
(scroll to bottom of this page for picture)
http://www.lamarowen.net/pgallery/album?album_id=2060
GNU Radio at government and university laboratories
http://lists.gnu.org/archive/html/discuss-gnuradio/2005-05/msg00190.html
http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0435485
http://lists.gnu.org/archive/html/discuss-gnuradio/2005-04/msg00092.html
VuSystem, multimedia, MIT ancestor of GNU Radio (mid 90s)
http://tns-www.lcs.mit.edu/vs/vusystem.html
http://tns-www.lcs.mit.edu/publications/JSAC96.html
SpectrumWare/PSpectra, software radio,
MIT immediate ancestor of GNU Radio (late 90s)
http://www.sds.lcs.mit.edu/SpectrumWare/home.html
http://www.sds.lcs.mit.edu/~vanu/JSAC98.ps
Vanu, Inc., commercial spin-off of MIT SpectrumWare project
http://www.vanu.com/
http://www.vanu.com/resources/index.html
Readings and other resources
http://radio.dcarr.org
http://comsec.com/wiki?SuggestedReading