Slashdot Mirror

Malvineous writes "Don't have $1500 to drop on a USRP? A Linux kernel developer has discovered that a Realtek digital TV tuner chip has an undocumented mode that turns it into a software-defined radio, with a frequency range of 64-1700MHz. The going rate for one of these USB devices can be as low as US$11. If you're unfamiliar with software-defined radio and have 20 minutes to spare, Balint Seeber has a great video introduction."

Nethemas the Great writes "The Universal Software Radio Peripheral or USRP created by Matt Ettus and Eric Blossom gives a new perspective on the radio spectrum, as in just about all of it from DC to 2.9Ghz. With the right software and daughterboards, their USRPs can capture FM, read GPS, decode HDTV, transmit over emergency bands, track peoples movement via their mobile phones, and much, much more. With prices starting at just $550 this new toy is accessible by most anyone."

Eric Blossom has responded to your questions about GNU Radio. He notes that he's gotten a lot of inquiries from people wanting to help out, and that they have their "hands full with the software and are hoping that some other folks will chip in on the hardware", so if you're interested in assisting, go to it.

1) Hardware requirements
by wowbagger

The GNU radio page is a little thin on the hardware requirements to run the code - could you spell them out?

I realize this might be complex, and that the answer might be of the form:

"to demodulate a 16QAM signal at 115.2kBaud, you would need an XYZ digitizer card reading the 455 kHz IF and a AAA GHz Athlon CPU. To recover standard multplex FM, you would need a 123 digitizer reading the 455 kHz IF and a BBB GHz Athlon. To decode GSM you need a FFF digitizer reading the 10.7 MHz IF and a quad Athlon."

But as both a ham and one who designs SDRs, I'd like to know where this resides on the Home Hacking Scale....

Eric: There are two basic paths down the software radio path. One I'll call "narrow band", and this corresponds to most of what you're seeing sold as "DSP enhanced" transceivers. The TAPR DSP-10 kit would fall in this category. In effect, these are conventional radios which are down converting to baseband, or near baseband, and have an IF bandwidth in the 20 kHz range.

For narrow band work with GNU Radio, you'll need some kind of RF tuner/transverter. Someone pointed out that in one of the latest issues of QEX magazine there's an article about a kit that is designed to be the RF front end for a software radio that connects to a sound card. I haven't seen the article so I can't comment. The TAPR DSP-10 would also work. Just leave out the Analog Devices DSP and plug the kit into your sound card. You could wiggle the control lines using the parallel port.

To summarize, for narrow band software radio work, you'll need your sound card and some kind of RF front end. Pretty much any contemporary Pentium/Athlon machine will have plenty of horsepower.

The other path I'll call "wide band". This is personally the area that I find most interesting because it is with wide band that you are able to do things that you can't do with a conventional radio. Chief among these is the ability to concurrently receive (or transmit) multiple channels/stations/frequencies. In the examples directory of the GNU Radio code, you'll find an example that receives and demodulates 2 FM broadcast stations and puts one out the left channel and one out the right. Matt Ettus, another GNU Radio developer, has built a demo that receives 4 narrow band FM channels concurrently. These demos run fine on a 1800+ Athlon, or 1.7 GHz P4.

For the wide band stuff our "standard configuration" is a TV tuner module designed for cable modems that tunes from 50MHz to 890MHz with an IF of 5.75 MHz. The module is a Microtune 4937 DI5. We connect the output of the tuner directly to a 20M sample/second 12-bit A/D converter. The converter we're using is the Measurement Computing PCI DAS4020/12. It'll do 4 channels at 10M sample/sec or 2 channels at 20M sample/second. From the hobbyist's point of view, it's not cheap, about $1300, but it is the cheapest, fastest off the shelf solution that we found.

With our "standard configuration" we ought to be able to handle IS-136. GSM would be possible if our RF front end would cover the 1.9 GHz range. Vanu, Inc has a GSM receiver running on a 1GHz pentium laptop, so we know it's possible.


2) Re:Hardware requirements
by d.valued

Tangential to this.. is there any talk amongst the GNU Radio folks on building a piece of hardware that complements this software project, or is supposed to work with whatever devices the user has on hand/will build?

Eric: This question comes up frequently. Mostly we've got our hands full with the software and are hoping that some other folks will chip in on the hardware. From our software point of view, we'll talk to any hardware that you can provide a driver for. Fundamentally all we need is a way to get samples into and out of memory.

We do have some ideas about our ideal hardware. See ettus.com/sdr/. The key items are:

• 14-bit A/D converter 40-100 Msamples/sec (e.g., AD6645 or AD9244)
• 14-bit D/A converter 40-100 Msamples/sec
• FPGA (digital downconverter / upconverter / bus interface)
• some kind of bus interface, either 64-bit PCI or USB-2

For flexibility, we keep the RF to IF conversion on a separate board.

There are also a few threads in the mailing list archives about ideal hardware.


3) Sounds familiar
by FreshMeat-BWG

As in WinModems doing the modulation/demodulation. These devices were a nightmare. After trying several I went back to a good old hardware-based-modulation modem.

Are there parallels to this technology? and if so, how will GNU Radio avoid those pitfalls?

Eric: Part of the problem with WinModems is the "Win" part of the equation. Modems place pretty substantial hard real time demands on the OS. It's not necessarily the total amount of CPU that's a problem. It's that it the code needs to be run on time or it's no good at all.

So far most of our work has been receive only, and we dodge the bullet by using the Measurement Computing A/D card which combined with the driver I wrote DMAs directly into user space. Given say, 16 MB of buffer, you can cover all sorts of non-real time problems. The driver is written so that it only needs service about once every 10ms, no problem on today's hardware, and will sustain 80 MB / second across the PCI bus.

When we attempt a TDMA transceiver, we may need hardware that will support time stamps so that we can synchronize our input and output streams. See above for ideal hardware with FPGA.


4) What external hardware?
by Consul

I read through the GNU Radio website, and even though I found it informative in terms of the basic idea and examples, I couldn't find anything relating to what extra hardware is needed. (Maybe I just didn't look long enough?)

What extra hardware is needed in addition to a computer? Are we talking DSP chips and boards, or something a little more exotic?

Thank you for a potentially exciting project, though. This makes me want to renew my ham radio license.:o)

Eric: See above. No DSP chips or boards. Today's commodity PC hardware kicks ass on just about all DSPs as long as you're not worried about power consumption. You'll need some kind of RF to IF transverter and A/D & D/A converters (either a sound card, or something with more bandwidth, depending on your interest and budget.)


5) Describe your dream hardware for a software radio
by geirt

I want a feature list containing all the geeky details:

Frequency range.

Eric: 30 MHz up to about 2.5 GHz.

Coverage in the 5 GHz unlicensed band would be nice too.

Bandwidth (do you want to sample the whole FM band (or GSM/GPS/CB/ham bands), or just a single channel/station).

Eric: Whole swaths of the RF spectrum!

12.5 MHz would be nice.

Sample frequency and depth (ie, fast and few bits, and do decimation in software or slow and many bits with less CPU overhead)

Eric: For 12.5 MHz we'll need about 31M samples/sec, call it 40M samples/sec. 14-bits. More is better.

Necessary spurious free dynamic range, or some other dynamic range specification.

Eric: More is better. The best part I know of is the AD6645, and they're claiming 100 dB multitone SFDR.

Interface to the PC (PCI, firewire, USB...).

Eric: 64-bit PCI would work, but it's a lousy interface for a laptop. Maybe USB-2. Firewire would be OK, but I think it's got more hair on both ends. We've also thought about Gig ethernet.

Antenna connector (OK, I know that one: BNC)

Eric: BNC.


6) Convergence Devices
by Nomad7674

This technology sounds like the kind of thing which could greatly add to the convergence of devices that clutter the electronic life. You could extend convergence not only as a Smartphone but have in one device (though perhaps not simultaneously):
1. Cell phone
2. Computing power (PDA)
3. FRS radio device
4. 802.11x network device
5. Police scanner
6. Television reciever
7. etc.

Eric: I believe that convergence is ultimately where we're headed. We're a way off, mostly with respect to power consumption, but I believe that that will take care of itself eventually. The MIPS/Watt of programmable hardware is unlikely to beat that of dedicated ASICs, but ultimately, if my universal reconfigurable communication device runs all day on a single charge, who cares?

Have you been approached by police departments, FedEx, etc. to develop devices to allow their people to do more stuff in fewer packages?

Eric: We haven't. I can see a scenario where somebody else is building the hardware and we're providing the software.


7) As a college student, how do I get involved? by McCart42

If I'm interested in doing research in this field someday, and I'm currently a computer engineering major, what are some good electives that I might take? Aside from general programming necessities, what sort of signal processing courses are necessary to understand the underlying aspects of software-defined radio?

Eric::

• DSP fundamentals, filtering, FFT, freq-vs-time domain, etc.
• Basic RF might be useful; you don't need to be a specialist
• Digital comms. Builds on the DSP stuff, but adds specifics for communications. Coding theory, ideal receiver design, channel capacity, phase lock loops, etc.
• Anything about protocols in general. Once you get up above the raw bits, software radios don't look that much different than any other layered communication protocol.

8) FCC vs. Software Radio
by minddog

I was recently at H2K2 and heard this forum which right away made me ecstatic(sp?). An issue that was brought up was how this can impact the DMCA, FCC, and the big corps. You guys were saying Sony, and the other conglomerates were forming a committee that would do a digital signature to say what was allowed to be copied, and not through a dual channel checking...My question is what is the status of digital radio and its rights in the present world? To my understanding you can have a very high number of digital channels inside a single band which makes licensed analog frequencies just a waste of money to corporations if they use GNURadio as a means to transmit data long distances. Anyways, looking forward to some feedback and goodwork, I'll be joining this revolution soon, just got the dual server built;)

Eric: Here are three subtopics under the "FCC vs Software Radio" flag:

(1) General prohibition on receiving certain signals

The FCC, throwing a bone to cell phone operators, banned the reception of certain frequency bands used by cellular phones. In addition, the Electronic Communication Privacy Act (ECPA) expanded the ban to include other communications such as pagers. These provisions have been called by others "The Foreign Intelligence Empowerment Act". That is, they ban the interception of signals that are trivially interceptable, as if making it illegal would "keep the customers safe". In fact, this same sham extends into the world of digital cellular, where the signals are still effectively in the clear, and are vulnerable to eavesdropping.

Free software has no problem complying with such regulations as the code below illustrates:

#ifdef IM_IN_THE_USA
if (freq >= 825e6 && freq throw "Forbidden Frequency";
#endif

(2) ATSC Digital TV "Broadcast Flag" MPAA/CPTWG/BPDG

Alphabet soup:

ATSC: Advanced Television Standards Committee (digital broadcast TV)
MPAA: Motion Picture Association of America (Disney, Fox, et al)
CPTWG: Copy Protection Technology Working Group (www.cptwg.org)
BPDG: Broadcast Protection Discussion Group.

Short form: Certain content providers (MPAA) want TV broadcasters to set a bit, called the "Broadcast Flag", in the MPEG transport stream that TV stations are broadcasting in the clear (i.e., no crypto). The flag is intended to mean "Don't copy me". The MPAA/CPTWG/BPDG folks are then trying to convince the consumer electronics manufacturers that it is in their best interest to build crippled devices that honor the bit, and finally, since it's not obvious than any consumer would buy such a damaged device, they want to ban non-compliant receivers.

After conversations with MPAA/CPTWG/BPDG, we have been unable to find any solution where open source or free software can comply with their proposed "Robustness Requirements". Hence, open source and free software implementations of ATSC receivers, VSB demodulators and VSB modulators would be banned under their proposals. Several fundamental issues are at stake: freedom of choice, freedom to innovate, and software as protected first amendment speech.

The FCC has issued a "Notice of Proposed Rule Making" about the Broadcast Flag. In addition, it is rumored that a bill is being drafted in case the FCC won't play along.

The EFF has a wonderful blog covering this topic in detail.

(3) SDR upgrades and FCC

Recognizing the importance of SDR, the FCC, in its First Report and Order dated September 14, 2001, created a new class of equipment and associated authorization procedures. In its Report the Commission stated, "We anticipate that software defined radio technology will allow manufacturers to develop reconfigurable transmitters or transceivers that can be multi-service, multi-standard and multi-band." Continuing, the FCC stated, "These changes will facilitate the deployment and use of this promising new technology, which we believe will facilitate more efficient use of the spectrum."

From the free software point of view, what remains to be seen is what kind of "authorization procedures" will be approved. What is envisioned is some kind of digitally signed configuration or executable that can be loaded into the existing hardware. In an free software/hardware world with no clear administrative hierarchy, it's not evident who gets to say what signatures the hardware will accept. This looks like a ruling that "software radio is OK for the incumbents", but doesn't really spell out what the situation is for the free software / open source / open spectrum point of view.


9) Re:Interference
by Louis_Wu

"This is one project where hacking the code can kill people or land you in jail. Don't broadcast on the wrong frequency! Keep this away from radio telescopes!"

Eric: OK.

That brings up a good question. Are there going to be some software restrictions on which frequencies you can use? Would those restrictions be in the source or options you can change on the fly?

Eric: Ultimately the frequency range that can be transmitted depends on the RF hardware, not the software. The vast majority (all?) of the code in a software radio has no idea of the final RF frequency. It's doing its processing at some IF frequency, which is ultimately up converted once the samples leave the CPU.

It seems like a good idea to put at least one barrier between users and transmitting on police frequencies. But what kind of barrier? Should any restrictions prevent listening as well? What about military transmissions? Or air traffic control frequencies? Or the band the Secret Service uses?

Eric: In general, my philosophy is that if people don't want their communications listened to they should encrypt them. This has been standard practice for thousands of years (see Kahn, "The Codebreakers").

I agree the that hardware should be designed such that accidents are minimized. One possible route for hobbyists would be to design the RF hardware such that it would only transmit on one of the unlicensed bands. There are still requirements about transmitted power, and these requirements vary depending on the band and the modulation strategy, but that would at least reduce the chances of accidental interference.

Note however, if you're building a software radio that bridges between different public safety networks, you'd certainly want to be able to transmit.

Where should the line be drawn? What does the law say?

Eric: Do no evil? The law of what land?

For another perspective on "interference" and who "owns" spectrum, I heartily recommend the "Open Spectrum Resource Page".


10) Hardware patents?
by cornice

Up until now, free software has mostly threatened closed commercial software. GNU Radio, however, might make some hardware manufacturers squirm a bit. If I can use a generic device along with GNU Radio to emulate a range of devices how will this impact the makers of those devices and are you (or users of GNU Radio) possibly violating patents for some of those devices? It seems that GNU Radio will stir up more mud in the IP and DRM debates. What are your thoughts on this?

Eric: Since the hardware manufacturers make their money selling hardware, and we want to buy hardware I don't really see a problem. I'd just like them to build some nice, inexpensive, fully documented hardware on which I can run my free software.

Yes, we will be able to emulate a bunch of devices, and it might cause some heart burn for certain folks. For example, I don't generally want to be carrying around a GPS receiver, but in the moment that I want to know where I am, it would be handy for my universal communication device to configure itself as one and figure out where we are. I'm not sure of the patent specifics on that particular application, but I understand your point nevertheless.

I think the mud will be stirred far and wide. I think that this is a good thing. General purpose hardware keeps getting more useful and powerful, and hence valuable to the end user. At the same time, in certain situations, dedicated devices clearly win over the general purpose in areas of convenience, size and ease of use. I think this tension is good, and better products will emerge from it.


11) Plans for UWB
by wfrp01

Will GNU Radio support Ultra Wide Band? Soon, someday, never?

Great project. Thanks.

Eric: We currently don't support Ultra Wide Band. GNU Radio is a signal processing toolbox. If you had the appropriate UWB RF front end, you could use GNU Radio for the signal processing.

See aetherwire.com for background info on ultra-wideband technology.