[Discuss-gnuradio] Slashdot Q & A / Beginning of our FAQ

[Eric Blossom]

Here are my responses to some questions posed on slashdot last week.
They make a good beginning for our FAQ.

Eric

----------------------------------------------------------------

> 1) Hardware requirements (Score:5, Interesting) 
> by wowbagger on 2002.09.09 13:58 (#4222011)  
> 
> 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....

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 (http://www.tapr.org/tapr/html/Fdsp10.html).  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 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 horse power.

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 (Score:4, Insightful) 
> by d.valued (ripco bang acerx) on 2002.09.09 20:27 (#4224566)  
> 
> 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?

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 harware.  See http://www.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 Msampels/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.  http://mail.gnu.org/pipermail/discuss-gnuradio/
    

> 3) Sounds familiar (Score:4, Interesting) 
> by FreshMeat-BWG on 2002.09.09 13:58 (#4222017)  
> 
> 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?

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? (Score:4, Interesting) 
> by Consul on 2002.09.09 13:59 (#4222020)  
> 
> 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)

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 (Score:4, 
> Interesting) 
> by geirt on 2002.09.09 14:18 (#4222170)  
> 
> I want a feature list containing all the geeky details:
> 
> Frequency range.

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

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)

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. 

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

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

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)

BNC.

> Radio design is about trading features against each other, eg. if you 
> want a large frequency range, you will usually end up with noisy 
> oscillators giving you poor large signal handling, and low selectivity 
> (ability to listen to weak stations close (in frequency) to a strong one. 
> If you want good sensitivity, you loose large signal handling. If you 
> want narrow filters, you get lower sensitivity (ok, this is a software 
> radio, so you can do extra filtering in software, so this might not 
> apply). You get the idea. Always compromises.
> 
> 
> 6) Convergence Devices (Score:4, Insightful) 
> by Nomad7674 on 2002.09.09 14:24 (#4222214)  
> 
> 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.

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 reconfigable 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?

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? (Score:4, Insightful) 
> by McCart42 on 2002.09.09 15:44 (#4222498)  
> 
> 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?

* 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 (Score:3, Interesting) 
> by minddog on 2002.09.09 13:57 (#4222004)  
> 
> 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;)

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 <= 850e6)
     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 ammendment 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.  Please
see http://bpdg.blogs.eff.org/


(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
encumbents", but doesn't really spell out what the situation is for
the free software / open source / open spectrum point of view.

> 
> 9) Re:Interference (Score:2) 
> by Louis_Wu (address@hidden) on 2002.09.09 14:40 (#4222326)  
> 
> "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!"

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? 

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? 

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 requirments 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?

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"
http://www.reed.com/openspectrum

> Louis Wu
> 
> 
> 10) Hardware patents? (Score:3, Interesting) 
> by cornice on 2002.09.09 17:01 (#4223177)  
> 
> 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?

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 (Score:2) 
> by wfrp01 on 2002.09.09 14:41 (#4222337)  
> 
> Will GNU Radio support Ultra Wide Band? Soon, someday, never?
> 
> Great project. Thanks.

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 http://www.aetherwire.com/CDROM/Welcome1.html for background info
on ultra-wideband technology.