Radio - WiFi - Phone OPEN SOURCE

Interview: Michael Shiloh of OpenMoko
Written by Steve Lake
02.06.2008 at 06:30am
Section: Editorials

I had a chance to talk to Michael Shiloh, head of developer relations for OpenMoko, the totally open source mobile phone platform. After a few words, I could tell that the project he was engaged in was very interesting.

RR: Tell us a little about yourself

MS: I'm sort of a tinkerer and a hardware hacker. When I went to college I did straight up electrical engineering and sort of half way through I discovered computer science and realized that was also something I wanted to do. So I graduated with a degree in Electrical Engineering and Computer Science. So what that meant was that my career was now bouncing back and forth between hardware and software, and I was especially interested in the areas where the two meet. I often found myself working with device drivers, interfaces and technologies that allowed the computer to connect to the outside world. And that's always kept me in the world of unusual devices that can be hooked up to a computer. And over the next twenty or thirty years I did a number of things in that general area and that's kind of what got me interested in OpenMoko more recently.

RR: What is OpenMoko?

MS: OpenMoko stands for "Open Mobile Computing" and it was originally a project started inside the company FIC (First International Computer). Their idea was to start a Linux distribution that will be targeted to mobile platforms. They used the term "Mobile Platform" because they wanted to be able to address the much wider world than just cell phones. Their original target was any small hand held thing, whether it was a cell phone or a PDA or perhaps those things that are looking like the Nokia tablet PC's, but smaller. But what they've realized is that they're really interested in was the extensive ubiquitous computing environment that at some point in the next five years or so. There will be computers all around us, and we'll pull something out of our pockets and won't even think about it being a computer. We don't even know what those will look like now. People talk about wearable computers and those kind of things where it's embedded in your cloths, the house around you, or built into your car. But it's that concept of computers that just melt into the background, and they're around you, but they don't look like what we think of now.

The reason this becomes kind of complicated is that there isn't one strict definition of what OpenMoko considers mobile computing. But there are specific elements that are typically present. It's pretty small and portable and has some kind of internet connection over a cell phone or wifi. In fact it should have as many kinds of connectivity as possible. So that if you walked past it with a bluetooth headset, you'd be able to pick it up. If you're connected onto the cell phone network and you walk into a coffee shop that has wifi, you ought to be able to take advantage of that. It should have things like a USB port because a lot of people have USB devices. You'd like to be able to include those in the list of peripherals you'd be able to use with this device.

So the idea is that it's something that has this wide range of connectivity options so that anything that falls into it's zone of potential connectivity can be used with it. It should also be aware of its location. So GPS also becomes important. So a given OpenMoko device may or may not have every single one of those items. But the more of those items that are present, the more we would consider it a prime candidate to be an OpenMoko system. And the reason we define it in that way is that what we're looking for is the kind of applications that would be useful in that kind of world. It's kind of a bit of a circular dependency. The kind of applications that would be developed for ubiquitous computing would definitely be different applications the more different interface options there are. And people won't build hardware with more interface options until they kind of know what those applications will be. So we're trying to jump start it by saying we're not exactly too sure what it will look like, but we're going to develop the Linux environment and the hardware to have as many of those things as possible just to kind of see what happens next. Just to give a jumpstart to the applications.

RR: What operating system does this run on? Is it Linux or a custom built Open Source system?

MS: It is Linux. We wanted to develop the ubiquitous computing devices of the future, and we quickly realized that if you tried to organize a bunch of focus groups to pull these kind of things together, you would still be somewhat limited by the environment that you built those groups within. People would come into those groups with a set of assumptions. The idea was that by going to the Open Source community, instead of trying to do this within a company, you tapped into a much, much larger number of people who have very large and broad imaginations who tend to be very creative and tend to come from many different kinds of backgrounds.

So whether they're into computing because that's their daytime job, or because it's their hobby and their daytime job is in the medical field or something else, they bring to it their knowledge from the computer field, as well as other things not related to computers. And that interaction of creativity and imagination from the ones with very different backgrounds we think is what will lead to the applications we can't even imagine right now. So once we decided we wanted to go the Open Source route, then you want to base it on something that is as easy as possible for as many of those people as possible to get involved in. So then the natural choice of Linux becomes quite obvious. And then that drove a lot of the other decisions we made.

There were cases where we could choose one type of software that would be smaller and more efficient, but it would be less popular. Or we could choose something that was a bit larger and required more resources, but it was known by a larger group of people. And we would choose to go with the latter just because we could get more people involved.

RR: The OpenMoko platform has more than just software. It has hardware, right?

MS: Yes, that's a good distinction. We were talking about that just last week. So we decided that OpenMoko was going to be two things. First of all, FIC originally founded this project as a product within their company. They then decided to spawn off that project as its own company, a subsidiary of sorts, and that was done to give it a bit of independence so that it wouldn't be tied just as closely with FIC hardware. So OpenMoko is the name of that company, which is completely owned by FIC currently, and OpenMoko is also the name of the Linux distribution we are creating. Those are the two things we are officially calling OpenMoko.

Also, OpenMoko is partnering with FIC to create hardware. That hardware we do not call OpenMoko hardware. It's generic hardware. We're calling the product like the "Neo" and there are two models in that right now. There's the first phone we came out with which was the Neo 1973. And then there's the next one we're going to release in a month or two and that's the Neo FreeRunner. Now the Neo was designed specifically to run the OpenMoko Linux distribution, but in a sense it's independent. You could run any kind of operating system on it, if you can find the appropriate drivers. And in contrast, the OpenMoko Linux distribution could be run on any other kind of platform. It doesn't have to be OpenMoko designed hardware.

RR: Well that's always good.

MS: Yes. In fact, there's a group who's already ported OpenMoko to one of the Motorola phones. So that's an example of the OpenMoko distribution running on completely different hardware. There's another example going the other way around. Qtopia, the Linux distribution put out by Trolltech was originally designed to run on their phone, the green phone, but they decided to stop making the green phone and instead support running their Linux distribution on the OpenMoko hardware. So Qtopia runs on the Neo 1973.

RR: So is all of the hardware you have for this FCC certified and ready to use on different networks?

MS: Yup. Absolutely. Now it is a GSM based phone, both models, which means they both use a sim card and the GSM network which is pretty common here in the states, but much more common in the rest of the world. But there are some areas in the states that don't have coverage for that. But that's pretty small. In fact, I think it's virtually negligible.

RR: What market is this aimed at? Or what specific cell phone provider? For example, Nextel, Motorola, CenturyTel, etc.

MS: That's a good question. When this project was originally thought up, they weren't thinking specifically about finding their way into one of those particular channels. The idea was that the developers and the Open Source community would be the first users of the device until they developed the consumer version. They were distinguishing between a developer launch and a consumer launch. But the whole project really got a lot of attention and a large number of the cellular network providers began contacting us and wanting some of the hardware for testing. I can't say who specifically, as I'm not allowed to, nor am I privy to that information, so I don't know who they were. I don't think this is them wanting to use it or sell it, but more of a facts gathering thing where they ask "What is this?" and "What does it mean to me?", "How am I to change the way I do business?", or "Is this something I want to get involved in?"

It's likely conversations of that sort or nature. Which leads us to the next question. If we're not going through the cell network providers, how do we expect to make money? There are two parts to that answer. In the rest of the world, you buy your cell phone independent of your cell phone provider. So whether we sell through a chain of stores or sell through a website, people can still get their phone and use it right away. Another thing we're finding that this device is really well suited for is any kind of a niche market, and we have any number of interesting projects coming up, sometimes out of curiosity and sometimes out of really specific needs. This is where people have a very specific application in mind, but their market is such a niche, they can't get the attention of the big cell phone manufacturers or the bill cell phone network providers.

So for instance, one that keeps occurring is in the medical field. And again, there are some companies we are talking to specifically and some who are just curious. And you can imagine a sort of general purpose thing where they're inside of a hospital and they can carry it around with them and it has wifi connectivity for them, and when it's outside of the hospital it can use the cell phone network. And they can use it to alert the various health care providers. If one of their patients has some kind of emergency, and they can access all of their medical records. And there's another side to that in addition to providing all of that network connectivity, there can be sensors mounted to the patient for things like EKG, blood pressure, or glucose levels, and all of that information can be sent to the phone and have it update the providers in the appropriate way.

So that's the kind of specific hardware that is easy to do with an open platform like our, that the closed platform has a really hard time justifying. It's not worth it for them to spend the time and energy into looking at these special projects unless the numbers are really huge. And in our case we can say, here are the device drivers, here are all the source code, if you need to add a special device driver for your glucose monitor, no problem. We can add that driver for you. For a little bit of money you can find some independent provider to give you that driver, or you can do it yourself. But because 99% of the rest of the work is done, and all they need to do is add that one driver, it becomes something that is feasible for a small company to do.

RR: Right, and then they just write the necessary applications to read the data from those glucose meters.

MS: Exactly. And whether that application is going over the wifi network or the GSM network, or it could even be a tiny webserver on the phone that's collecting that data. And that's something you just cannot imagine doing with a Nokia or a Motorola and one of the standard cell phone providers. It's not that they can't do it, but the numbers aren't big enough to justify them doing it.

RR: Interesting. How user friendly is the platform from an end user's perspective?

MS: Ah, I was afraid you were going to ask me that. That's perhaps the one sticking point we have right now. In a way we are victims of our own success. The idea was that the first launch of the phone would be aimed just at developers. So the stereo-typical Linux geek, the various hardware hackers, and the developers of new applications. And together we would develop the really interesting applications that would appeal to the mass consumer. Now we haven't actually done that yet. But we seem to have captured a lot of interest, so we get a lot of requests from people who want to review the phone as a consumer device, and we have to say it's not there yet. We have a very, very basic cell phone functionality to it. You know, you've got your dialers, your address book, the calendar, your notes. It's really not meant to be an end user product. It doesn't compare very favorably next to things like the latest Nokia phone or the latest Motorola.

Certainly not compared to things like the iPhone. And I mention the iPhone as sort of a special case, because people look at the iPhone and say, "Well, that's based on OSX, therefore it's theoretically open." There are some physical resemblances also. We have a very big screen that's a touch screen, and we don't have many buttons. It looks a lot like an iPhone. People tend to hold up our phone next to an iPhone and say, "Why should I choose yours over theirs?" The answer is that it's not really a device question yet. Because if you compare them side by side, our applications will not compare favorably. The real comparisons is what kind of applications can be developed on ours because it's all completely open source. And where will this thing go in the future? And what can we bring to that hardware, because we have such a huge base of open source developers who are working with our phone. Where creativity and imagination can do things that are not possible with a closed platform.

RR: Does the hardware side of it use open hardware, or is that going to be somewhat proprietary?

MS: Yes, that's been a tricking thing we're still trying to navigate. And it's a regular topic that comes up in our internal meetings. So the quick answer is, at the moment the hardware is not open. We would like to make the hardware open at some point. Part of the problem is that the hardware isn't completely all ours. We've developed the hardware in cooperation with the parent company, FIC. And while they sponsored our project, they're not an open source company. And for a lot of hardware manufacturers, there's this feeling that if I open up the hardware, if I publish the schematics to my hardware, theoretically anybody else can go off and duplicate that. And specifically, you can imagine some company saying, "I can make this hardware cheaper," and they would make a Neo knockoff that would then undersell our phone. Now the only reason to do that would be if the market for Neos was so, so huge that it was worth it for them to do that. It's simply not there yet. The hope is that we will be at some point, and we will be that successful. And then there will be motivation for somebody to try and undersell us.

The reality is that it's not so easy to take a schematic and turn it into a working phone. For example, one of the very simple common things is the high frequency stuff. The stuff that has to do with the radio section. So there's the GSM radio that talks to the cell phone network, the GPS radio that talks to the GPS satellites, and when you get up into those high frequencies, all kind of issues occur. Like two signals that are passing next to each other, and one will radiate onto the other one and you will get interference. So when you look at the schematic, it doesn't tell you how the signals are going to behave. It's the way you lay out the circuit that will have a tremendous amount of influence. So just from that little example, simply publishing the schematics doesn't allow you to go and manufacture a device that will work with a high degree of certainty out of the box. So there's a typical kind of thing that is an example.

So that's a round about way of saying we currently can't Open Source our hardware partially because it's still the tradition of fear that if we Open Source the hardware, somebody else will go and undercut it. Plus we don't own it completely. It's partially held by FIC. And partially because other companies don't do it. Now the flipside of that is that it's very possible that all of these reasons are bogus and it's just fear and inertia that are holding people back. There are in fact one or two companies that specialize in hardware that is designed for Linux who are Open Sourcing their hardware. And it would be interesting to go to them and say, "Is this fear true? Have other people gone and tried to undercut you?" There is one company out there who is actually making and selling an Open Source media server. They are actually even publishing the schematics for it. It would be an interesting question whether or not someone has copied that hardware and tried to undercut them.

And since you're asking about hardware, the next question becomes the chip. That's an interesting parallel because if we're going to open source the software and open source the drivers, we need to have enough information on the chip to write those drivers. And the same kind of reluctance to release schematics also exists with some of the chip manufacturers that have very highly specialized chips. So for instance if you go to Nvidia or ATI, and say you want to design a new video board and you want to use their high end video chip, they will not give you the specs on that chip until you sign a non disclosure agreement. Now supposedly their reason for doing that is that if you were a competitor, you might be able to deduce from the specifications how it is that they do especially accurate graphics. Or especially high speed motion.

The big market for the chips is games. They need to have the ability to rapidly draw scenes or quickly render different textures or environments. And they put a tremendous amount of research and development into those chips. In a very real sense that intellectual property translates into some very real dollars for them. And if they felt that someone could deduce their secrets, then they would essentially loose their edge. So that's the official reason those companies have a lot to worry about the release of the specs of the chip. Unofficially it's not at all clear that you really would be able to do that. And it could be just another matter of momentum and nobody wanting to take the risk that it will happen. Now the question is, if we want to develop a completely open source Linux distribution, we need to have device drivers that are open source, and the only way we can open source those device drivers is to use chips where either the company will give us the data sheet, or they will allow the data sheet to be published publicly so that everyone can look at it.

Or these companies will provide device drivers to us that they will allow us to open source. And that turned out to be non-trivial. We did eventually do it. And that is how the Neo handset came out with that particular set of chips. Because we had to choose chips for which we could get or create those open source drivers. And that's a very different situation than a cell phone manufacturer saying, "I'm going to build a cell phone and I need to choose the chips I'm going to be putting in there, but I'm not going to open source it. Thus they have access to a much wider range of chips they can use.

RR: Interesting. Do you know when this will be publicly available for sale or to the general public?

MS: Officially, no. Officially we found that it's difficult to determine how long it takes to do this work. Unofficially, we're looking at somewhere within half a year or so after we release the developer version. So the developer version is going to come out in the next month or two. And this is all unofficial. And then I believe somewhere about a half a year after that we'll be able to release a phone that is consumer ready. What will change in that half year is unknown right now. As I said, that software is functional, but it's not very pretty. And what we'd like is Open Source software that you can put in a cell phone and it will compete favorably with all the top notch hardware out there. We don't want anybody to look at it and say it's horrible. We want people to look at it and say, "I'm having to make a real tough decision between this phone and some other phone."

RR: Really quickly, what are some of the specs of the phone, such as screen size and things like that?

MS: Yes, good question. First of all, the most striking thing is it's a full vga screen. 640x480. What that means is that the graphics on it is just amazingly sharp. What it also means is that applications will be able to take advantage of that which simply couldn't exist before because we couldn't get that kind of resolution out of those kind of screens. It's touch screen. It has a stereo sound system when you plug in your headphones. There is only one speaker on the unit itself. I mentioned before that the cell phone's hardware is GSM, so that limits you to Tmobile and AT&T. It has GPS built in. So we're looking forward to seeing a lot of applications related to that. So if I want to go to a restaurant, the phone will already know where I am and suggest restaurants within my area via Google maps. It also has wifi built in. You'll be able to use it as a voip phone whenever you're close to wifi.

It has a 400mhz arm processor. It has 2D and 3D graphics acceleration. So we're looking forward to having nice graphics on this. We will also have a pair of accelerometers on it to measure the orientation of the device relative to the Earth's gravitational field. Some of the applications of this is if you were driving, and you were moving really, really fast, and you had to slam on the brakes, and you got an incoming call, the phone would send that call directly to voicemail rather than ringing the phone. While it's a really specific applications, it's one of those things were you have all of these interesting extensions in the box and you go, "Wow, what all can I do with these that I couldn't do before?" And of course, once you put ideas like that out in the Open Source community, they really go wild with it and come up with all kinds of really crazy ideas. Because for everyone one hundred crazy ideas, there are always one or two gems in there that could potentially become real breakthrough applications.

The fun part of it all is coming up with those crazy ideas. Because the sooner you get past the crazy ones, the sooner you'll get to those one or two gems.

RR: How can people contribute to the project?

MS: There is a website. openmoko.org. We actually have two different websites. openmoko.com and openmoko.org. Generally speaking, we try to keep all of the community and Open Source related topics on the .org website and we tend to keep the .com website more for the business end of things. That's where you'd contact the marketing and sales department, that's where you'd purchase phones, etc. We're working on a list of distributors and resellers who will be on the .com site. So the first step if you want to contribute is you go to the .org website. And what you will find there is that we have a wiki and about a dozen mailing lists. The main mailing list there is the community mailing list. That's the most active one.

That's the one where people like me update the community with what's going on inside of the company. It's also a place where the community raises all kinds of questions, concerns, ideas and suggestions. It's a place where the community suggests, "Hey, I'd like to go and build this application. Who'd like to help me with it?" And then they might go off and form their own group to do that. It's a place where we discuss updates, letting people know what state we're at in getting to that developer release that's in a month or two. We announce bug fixes. We do our new releases of the software. There's a tremendous amount of discussion. One of the things that will happen often is a new person will come along and say, "Hey, I just joined. How can I help?" And very often we've had people come along and say something like, "I'm not a software developer, but I love the concept. What can I do?" And the answer is that there's all kind of different various things to do. In fact, one guy joined and he said, "I'm an artist. I can't write code. I don't suppose I can contribute?" We all jumped at him and said, "Are you kidding? You could be designing the icons and the graphics and things like that."

We had a musician actually who suggested he could be helping us with ringtones. So there are many, many different ways to contribute. I'm looking forward to some documentation people joining the project to help us document this. Because there are a tremendous amount of ideas in the community and the wiki has a lot of details on the hardware and the software, but it's all written by engineers. We need someone who knows how to explain this to explain it in a rational way. To "de-nerdify" it. So yes, we welcome people to the community and there are many, many different ways to contribute. I should mention another thing about it. There are a number of other Open Source distributions that target embedded hardware or mobile hardware. And in order to get involved many times, you either need to sign an NDA, or you need to purchase the hardware, or you need to register in some way. And we made a very conscious choice not to have any of those barriers.

So people can join the project without having to get qualified as a developer in any way. They don't need to sign anything and there is no requirement to purchase the hardware in order to get access to the software or be part of the community. We welcome participation. Anyone interested can contact me at michael*a}openmoko.org And again, that was a conscious choice to make sure that it would appeal to the larger number of people, and it also shows that we want this software to be available to other hardware as well. We're not targeting this software only at our hardware.

RR: Is there anything else you'd like to share with us?

MS: Nope, I think that about covers it.

========================

Hardware for Your Software Radio By Stephen Cass

How to get to the cutting edge of radio technology

Radio Star: Univeral Software Radio Peripheral designer Matt Ettus poses with his invention and some of the daughterboards used to operate in different frequency ranges.

What.s going to be the next big thing in wireless technology? My bet is software-defined radio, and thanks to a piece of hardware called the Universal Software Radio Peripheral, or USRP, you can get right to the bleeding edge today.

Currently, adding an audio, video, or data stream to a radio signal so it can be broadcast.a process known as modulation.is nearly always done by dedicated electronics. The same is true with the reverse process.demodulation.required to receive a transmission. Radio waves can be modulated in any number of ways, and each way requires different circuitry. This is why you can.t, say, use a TV designed for the U.S. NTSC broadcast standard and expect it to work in Europe, which uses mostly the PAL standard.

The idea behind software-defined radio is to do all that modulation and demodulation with software instead of with dedicated circuitry. The most obvious benefit is that instead of having to build extra circuitry to handle different types of radio signals, you can just load an appropriate program. One moment your computer could be an AM radio, the next a wireless data transceiver.and then perhaps a TV set. Or you could leverage the flexibility of software to do things that are difficult, if not impossible, with traditional radio setups. Want to broadcast an emergency message on every FM band? Scan a dozen walkie-talkie channels at once? Or design and test a new wireless data protocol? No problem with the software radio.

Researchers are currently using software radio.based systems to help them work on problems in realms that include radio astronomy, telecommunications, and medical imaging. Already a number of commercial products rely on software radio.

While software radio is still very much a work in progress, and ­general-­purpose processors still lack the computing power to fulfill all the dreams of enthusiasts, you can get a taste of the future with the USRP. The hardware works in concert with free software developed by the GNU Radio project, an international collaboration of programmers who donate their time and skills.

The USRP acts as an RF front end for a computer running the GNU Radio software, converting radio waves picked up by an antenna into digital copies that the computer software can handle or, conversely, converting a wave synthesized by the computer into a radio transmission. I tested GNU Radio and the USRP together on both Linux and Mac OS X computers, but the GNU Radio software will also work with other RF front ends, and it can be used with prerecorded signal samples in the absence of any radio hardware. Likewise, the USRP can be used with proprietary software such as Matlab and LabView, or with home-brewed code.

The USRP is made by Ettus Research, in Mountain View, Calif., and costs US $550 for the basic motherboard. This square motherboard, 16 centimeters on a side, houses a field-programmable gate array (FPGA) to do heavy-duty signal processing, as well as the circuitry required for talking with a Mac or PC via a USB 2.0 connection.

The motherboard has four expansion ports.two for receiving radio signals and two for transmitting signals. Various daughterboards sold separately by Ettus Research are plugged into these ports; different daughterboards handle different frequency ranges, giving the USRP an overall potential range of 0 hertz to 2.9 gigahertz, which covers everything from AM radio, through FM and television, to beyond Wi-Fi.

Daughterboards sell for $75 to $275 each; a typical example would be the TVRX, which can receive signals in the 50- to 870-megahertz range and sells for $100. The USRP is not restricted to tuning in one frequency at a time, because it can handle signals as wide as 16 MHz. The architecture also supports MIMO.multiple input, multiple output of simultaneous radio signals.which is the underlying technical approach behind next-generation wireless data and cellphone standards.

The USRP is clearly a labor of love for Matt Ettus, the man behind Ettus Research, and the motherboard and daughterboards are an engineer.s delight. Plenty of interconnects for hardware hackers are provided, and detailed schematics, along with the Verilog code that configures the FPGA, can be downloaded from the Ettus Research Web site at http://www.ettus.com.

Aside from the cable woes, setting up the hardware was easy. Unfortunately, the software side didn.t go as smoothly.

The GNU Radio software, in addition to its own code, relies on a lot of third-party software from other free and open-source projects. Getting all this additional software up and running is actually the trickiest part of setting up GNU Radio, and the difficulty was compounded by both a lack of reliable documentation and out-of-date software.

In the end it took many frustrating hours, lots of Googling, a phone call to Matt Ettus (who is also a contributor to the GNU Radio project), and several false starts to get my Linux-based system up and running properly.

The root of my problem was twofold. First, the official release of the GNU Radio software provided on the project.s Web site (http://www.gnu.org/­software/gnuradio) was obsolete, as was the installation tutorial the site linked to.which led to my second problem. Following these instructions, I had tried to install all the supporting software by compiling it from source code: a long, difficult process that I never got to work quite right.

Finally, following tips from Ettus, along with parts of the available documentation that still seemed to make sense, I started over with a blank slate, using a fresh install of Linux Mandriva 2006 Free Edition as my operating system. My plan was to download the supporting infrastructure in the form of prebuilt binaries that didn.t have to be compiled, and then download and compile the latest version of the GNU Radio software directly from the developers. own source code repository.

Two and a half fairly pain-free hours later, I had a local FM station blaring from my computer.s speakers. [For a step-by-step description of what worked for me, see . Installing the USRP and GNU Radio..] As a more advanced exercise to make sure everything was working, I downloaded and installed additional code for viewing analog TV signals; while I was able to get it to run pretty easily, I still couldn.t produce a watchable picture, because this feature is so new that no one.s yet written the code to de-interlace the raw TV transmission! (There is code available for watching HDTV digital transmissions, but because of the performance limits of current processors, the signal can.t be decoded in real time.)

Incidentally, I had first installed the USRP and GNU Radio system on my OS X system fairly easily, mainly thanks to a good installation guide (http://staff.washington.edu/jon/gr-osx/gr-osx.html). Unfortunately, I.d used the official release of the GNU Radio software, which did not include sound support for OS X at that time.

To be fair, problems with third-party code, rapidly evolving software, and documentation are endemic to free and open-source software projects. Still, there is no getting around the fact that installing GNU Radio is a particularly difficult process for those new to it. Ettus says the GNU Radio project hopes to establish a stable working official release before too long, and the project will soon replace, or at least remove, the dead-end software and documentation that.s on the home page.

Once you have the software up and running, you.ll need to know that programs for GNU Radio are written using the C++ and Python languages. The conceptual approach is to treat the various parts of the system as modules that send information to one another, allowing programmers to concentrate on whatever piece they are interested in, while treating the other modules as black boxes.

Routing between modules is done with Python, so that a developer might write a Python program that uses an off-the-shelf .source. module, which grabs a chunk of radio spectrum from the hardware, and a similar .sink. module, which sends the output of the program to, say, a set of speakers or a radio transmitter. In between the source and sink modules the developer could put a custom signal-processing module, which itself would be written in C++ (signal processing is not done with Python for performance reasons). This gives developers the ability to assemble working systems rapidly. Plenty of sample programs are included with the software to give new developers a head start.

Ultimately, despite the installation headaches I encountered, it is clear that the USRP and GNU Radio have immense potential, and the full range of possible applications is not yet foreseeable. For those who have the technical chops and want a sneak preview of things to come, the USRP and GNU Radio deserve attention.

==================

GNU Radio is a free software toolkit for learning about, building, and deploying software-defined radio systems. Started in 1998, GNU Radio is now an official GNU project. Philanthropist John Gilmore initiated and has sustained GNU Radio with the funding of $320,000 (US) to Eric Blossom for code creation and project management duties.

========================