Matt Ettus’ presentation on the Universal Software Radio Peripheral (USRP) was awesome. He has been working on the GNU Software Radio project for a while, and was working on a device that he could hook up to his PC to use with the software. Eventually his hobby turned into a business, and the device that was meant for hobbiest experiments has turned into a testing a prototyping platform for professionals and shaddowy government agencies working on software defined radio projects.
Matt gave an excellent description of software defined radio, which I’m sure I would completely flub if I tried to reproduce it word for word. But it was basically that software defined radio is not an exact thing you can point at, but a continuum of radio technology. One side being completely static hardware designs, and blending into what is called “software defined radio”, where more and more of the functions migrate from hardware components into software functions.
Of course there are practical limitations to exactly how much spectrum you can cover with a software defined radio. As you want to cover more the cost goes up, or the precision decreases or the power consumption goes up. So any practical current software defined radio isn’t going to be completely generic, it’ll cover (perhaps large) swaths of spectrum, but it won’t be able to tune absolutely anything. I don’t really understand the raw modulation and power and encoding sides of this whole wireless gig all that well, so I’m always happy to hear more human parsable statements about cutting edge wireless stuff.
The USRP that Matt sells is open source hardware. The specs and schematics are all available online, so if you wanted to source and build one yourself you could. If you wanted to build it and sell it you could. You could even make them and give them away for free. However if you distributed the stuff based on his designs you would have to distribute information about your changes, just like what the GPL does for source code. I didn’t ask about hookups… if you used the design for his USRP and included it in something you made would you have to distribute or make available design specs? People work around that bit of the GPL by designing runtime interfaces instead of direct linking of binaries. What would be the equivalent in the hardware world? Does hooking to the same generic bus count? What kinds of bus would count as firewalling the IP of a design and which wouldn’t? Wishbone for instance frequently hooks together cores on the same chip, that seems like it might count more as direct linking than bus separation. Hmm.. that was just thinking aloud, I’m tempted to edit that out of the post… Nah. The open source hardware question has to come out at some point.. and many now people will have heard it here first ;-)
But for us mere mortals he sells completed boards. The units consist of the base, which communicates raw samples to your PC via a USB2 interface and plugin daughterboards capable of receiving and/or sending on particular chunks of spectrum. With something like a GNU Radio application looked up to the device you could record whole chunks of spectrum raw and decode them in software. For instance you could record all of FM radio at the same time and record all the channels to hard disk as audio. Neat. The GNU Radio part provides generic functions common to demodulating data (signal processing blocks) and some framework to orchestrate things like timing and parallelism. I’ve never used it, but it looked pretty cool. I’m really tempted to get me one of these things to play with.
The Sun folks where there talking about OpenSPARC as well. That was a bit less up my alley because I just can’t see getting a FPGA development kit and synthesis tools that would support something like a sparc core and interesting peripherals any time soon. Not to mention that I have almost no idea at all how something like that works out practically. Not that it normally stops me, but still, there’s only about 28 hours in a day (if you count the parts that can be parallelized effectively through a software agent). Hardware design unfortunately does not slot in there well.
What I did find interesting was why something like the OpenSPARC was being discussed at a mobile phone club. Cause the entire Niagara effort is about maximizing performance per watt for web applications. And maximizing performance per watt is definitely something that mobile apps need to do as well. So maybe there’s a chance for some crossover. Apparently a few teams have already taken the open designs that Sun has put out and started crunching them down for practical use in much smaller applications.
Niagra = best performance for watt for web apps – interesting summary of purpose.