Become a fan of Slashdot on Facebook


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Eric Blossom on GNU Radio 56

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

  • 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";

(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 (
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 for background info on ultra-wideband technology.
This discussion has been archived. No new comments can be posted.

Eric Blossom on GNU Radio

Comments Filter:
  • You then effectively have "Open XM" digital radio. This would also boost the demand for hardware OGG decoders and give OGG some much needed exposure.
    Ofcourse, after that, "Open TV" won't be far behind.
  • Why not GNU television ?
    • by Anonymous Coward
      um, television is essentially a type of radio transmission .. so "GNU Television" would actually be a subset of GNU Radio
  • In a recent post to Slashdot, the God of GNU explained that Linux should be called GNU/Linux, because Linux is made up of many parts, and some of those are GNU components.

    However, while the GNU wants everyone to call Linux by a new name to respect GNU's contributions, GNU themselves ignore the parts that make up their radio system.

    • tar and unzip are required to get the source to the software.
    • a digitizer is required to receive the signals, Eric Blossom keeps harping on about a kit from TAPR
    • Marconi invented radio waves.
    • Lots of components are also used in the interfaces and a CPU is used to run the software.
    • Audio is used.
    • Windows are used to display the app.
    Therefore I recommend GNU Radio be renamed to:


    Or GNU/TwatCum for short.

    It's only fair.
    • If you run a system that uses the Linux kernel, then almost certainly the tar that you run is GNU tar, developed mostly by John Gilmore, who at the time was so dedicated to the GNU project that he used "gnu" as his login.

      And Marconi did not invent radio waves, you dork.

    • Marconi is given credit for transmission of information over radio waves. But Tesla had been using these ideas long before. Of course we don't need another T here, so I guess Marconi will have to suffice. But it would be better to call him "father of radio" rather than inventer of radio waves.
  • Will the casual Linux user (people running it as a browser/email/word processor desktop at home or whatever) be able to take advantage of this or is it a hacker's domain? I'd love to receive radio directly, and even record some programs to hard disk occasionally.
  • A genuine question. Radio receivers, for everyday uses at least, are extremely cheap. GNU Radio sounds like an interesting idea, but what practical problem does it solve? I guess this may be a cheaper solution for radio transmission in certain circumstances, but is this the only point?

    • One practical problem is that instead of having multiple hardware for different uses (AM/FM, cell phone, GSP, police, weather, garage door opener, keyless entry, etc.) you could have a single device that could theoretically handle them all. And as new bands or methods were developed it could be updated by software to handle those also.

      One device to rule them all.

      And if you get into applications requiring multiple channel decoding, e.q. a cable set top box that could serve multiple TV channels, it might be cheaper than duplicating tuner hardware.
      • Military (Score:3, Interesting)

        by Detritus ( 11846 )
        That is supposed to be why the military is interested in software defined radios. They could replace a large number of incompatible radio systems with a single generic box that could use a wide variety of frequency bands and modulation techniques. It could also support applications such as GPS and data networking.
    • Another purpose of GNU radio that piggy-backs signals on top of one another, would be to radically increase the amount of radio stations on the bandwidth available to license them. Right now, the bandwidth limits the number of radio stations, and the bias is toward existing radio stations that are mostly owned by media conglomerates which bring us uninteresting and repetitive music playlists. Anything that encourages radio transmission in this direction is a good thing for people bored by mainstream radio.
  • Some thoughts (Score:5, Informative)

    by dmlb ( 123349 ) on Friday September 27, 2002 @12:54PM (#4345002) Homepage
    First off, I'll just mention that for the past seven years I've been designing RF chips for a variety of systems such as GSM, Bluetooth,
    802.11 and other stuff as my real job.

    Software defined radio is a big research topic in the commerical RF world. There are currently two big problems that people are trying
    to overcome. The first is the ADC requirements and the second is the MIPs requirements for any two way system are really beyond the ability of most current general purpose technolgy. It will get
    there but not yet.

    I want to add my own thoughts to the questions and answers people asked. They are meant to point out how much work there is to do, and also some
    of the legal implications of trying to do them.

    1) Hardware requirements

    For GSM you will need about 13800ks/s if all the channel filtering is implemented in the radio. If not, reckon on about 16bits and 13MHz.

    3) Winmodems etc.

    Eric raises a hugly important point about the real time nature of many RF systems. For example, 802.11a requires that turn around time on ACKing packets is in the order of a few micro-seconds. This includes decoding that packet and generating the reply. It is hard enough to do this in custom hardware, and CPU interrupt latencies are just too
    high. Many 802.11a chipsets use two ARMs to meet these timing requirements, one running real-time code the other dealing with the protocol.

    Oh yeah, a protocol stack for GSM is usually larger than a Linux/FreeBSD kernel in terms of lines of code...

    BTW, if you hunt around the net, you can find the signal processing for GSM available as a matlab library. It includes all the vocoders and channel coding and viterbi's.

    9) Interference etc.

    Eric seems to not have much experience of type approval testing for devices such as cell phones. There is no way it will be legal to develop your own GSM cell phone on a PC and use it in Europe for example.

    Every GSM handset must be type approved before it is allowed to be used on a network. This costs a good few kbucks. You must be licensed to transmit in the bands etc.

    On the hardware side you have issues like the fact that it takes lots of RF design experience to build a circuit that meets the spurious
    emissions requirements, and standard PC hardware will not meet some of the basic timing requirements of 0.5ppm tracking to the BTS and that you must use the same crystal for frequency generation and timing.

    10) Patents

    Most protocols are covered in patents. GSM is a minefield and every cell phone has royalities paid on them. Qualcomm are the patent owners for IS95.

    11) UWB

    UWB will need samples rates >10Gs/s to do digitally. At present the Rake receviers are implemented as part of the RF.

    • Some more thoughts (Score:2, Informative)

      by adapt ( 105738 )
      Matlab and Simulink and toolboxes are a great start (there are student prices). GSM and IS95 can be modelled fairly accurately (the whole transceiver chain, from analogue signal input to output). It is not cheap, but much cheaper than COSSAP. Octave is not really an option, unless you want to write all the code yourself. The best sellign point is that you can implement any type of receiver algorithm and start playing with UWB. I am not really sure a PC can do real-time decoding, especially in a wideband multiuser scenario... ;-)

      But this is baseband signal processing, done on PCs. For real time applications, you need DSP or FPGA. Texas has some "entry" or "student" packs with evaluation boards and Code Composer, but it's not cheap for a hobbyist, and there's a learning curve... (read: you have to debug a lot)

      The not-so-nice aspect of software radio is the hardware part. Tx and Rx design for wideband communication systems is not easy and definitely not cheap. Some kit is available on the market (for example from Spectrum) as add-on boards, and antennas can be manufactured or bought.

      While both reception and transmission would be nice to have, it is much easier to do the reception part, due to strict regulations for transmitters (as dmlb noted, it is something that can land you in jail very fast - or have a van from the local telco come by and do some measurements :)

      Books on the topic (all with shortcomings, none with magic bullet solutions):

      H. Harada, R. Prasad "simulation and software radio for mobile communications" (CD included), Artech House, London, UK, 2002.

      W.Tutlebee "software defined radio" Wiley, 2002.

      J.H. Reed "software radio" Prentice Hall PTR, 2002.

      J. Mitola III, "software radio architecture" Wiley, 2000.

      All in all, this is a great hacking project. A collection box for the $10000 needed for the RF and DSP baseband processing should be set up!

  • Electrical engineer (Score:3, Interesting)

    by cybermace5 ( 446439 ) <> on Friday September 27, 2002 @01:00PM (#4345046) Homepage Journal
    Why does this sound familiar?

    CS's make software for hardware that doesn't really exist yet, but we're supposed to figure it out and also make it cheap.

    Seems like this is project that should have started from the hardware end. What if the hardware required is never developed? Then all of their work is useless.
    • No, I don't really agree, and I have a degree in electronics, and I've studied DSPs. The sampling hardware needed isn't that special. I think that what he's doing will basically work.

      There are issues- interference could be an issue, but I suspect that some filters will mostly solve the issues.

      I actually think it isn't ambitious enough! He should be working on two-way comms. A software radio with beam-forming is going to be needed in the next few years; there's some theorems that if you do directional antennas, power control, routing algorithms and you can handle multiple frequencies, then the network capacity scales basically proportional to the number of users on the network. i.e. more users doesn't slow the network.

  • Done by Vanu Inc. Vanu Bose of MIT founded the company. See: [] Has quite a bit of technical information of software radios.
  • ECPA (Score:4, Interesting)

    by AB3A ( 192265 ) on Friday September 27, 2002 @01:20PM (#4345217) Homepage Journal
    Free software has no problem complying with such regulations... [such as the ECPA]

    One of the recent modifications to 47CFR15 (FCC part 15 regulations on receiver coverage among other things) concerns making receivers difficult to modify so that they can't receive cellular telephone calls. Specifically see part 15.23, and part 15.121. []

    I don't know how you can call a snippet of code like this a reasonable prevention.

    Please don't misunderstand me, I think these regulations are utter balderdash. Unfortunately, I see no reason to think those regulations are unconstitutional, despite the stunning ignorance and stupidity behind them. I don't understand how Eric and company can work on a project of this sort without violating these regulations and thus I don't see how the GNU copyleft can remain in force.

    Doesn't anyone see a conflict here? And if not, why?

    • In the spirit of this thread (I am not flaming the community here) I really think it is becoming fashionable to have sheer contempt towards government policies, even if it means losing objectivity.

      Besides that, when does the government ever got the policies right for the first time?

      I'm sure the software radio is going to give some sleepless nights for the FCC and the concerned parties (like cell phone operators)
      • In the spirit of this thread (I am not flaming the community here) I really think it is becoming fashionable to have sheer contempt towards government policies, even if it means losing objectivity.

        Is it fashionable in government to craft legislation that contradicts 60 years of common sense and technological policy?

        Besides that, when does the government ever got the policies right for the first time?

        How about The Communications Act of 1934? That was the act which created the Federal Communications Commission. It also defined policies which are widely respected today, such as "Radio Secrecy" (not the "Radio Privacy" foolishness you find in the ECPA).

        I have very little patience with legislators who craft laws with no basis in common sense, practicality, past policy, or even future trends.

        Courts profess that "ignorance is no excuse for the law." Well, in the case of legislators: "Ignorance is no excuse for an impractical or poorly crafted law." If we are to continue building an honorable and productive society, the law needs to make sense, be enforcable, and it needs to respect everyone's rights. Clearly the ECPA fails that smell test on all counts. The DMCA is yet another that fails the smell test.

        I don't stand for this kind of treatment from my government and neither should anyone else.

    • If source code is speech (as several courts have ruled), then it's difficult to see how the distribution of the code could be banned. Operation of the code on hardware capable of RF input or output could be banned, as there's no constitutional right to do that.

  • Sofware Defined Radio Transceiver Subsystem SDR 3000 [] from Spectrum Signal, now shipping! :)

    Santa, we want one. Obviously, to test some nice sofware on it.

  • > We've also thought about Gig ethernet.

    Consider defining a general-purpose RTP
    packetization for IF radio, and running
    through the IETF. This would let hardware
    folks innovate to a known stack: Gig
    etherframes, UDP, RTP w/ your packetization.
    You could also spec out a SIP framework,
    so the hardware can start up its own sessions.
    • Yeah, I was thinking that using gig ethernet raw frames would make a pretty good data transport mechanism, but I don't know how feasible it is to read raw frames from a typical gig ethernet adapter. (If anyone wants to weigh-in on this question, it would be appreciated...)

      It would be nice to not have to do arp or deal with any real buffering, but just build the frame as you go, and stuff the CRC at the end. Send the frame as a broadcast packet. Maybe you could have two single-frame buffers, and fill one while you send the other, etc.

      If you can keep the hardware design job really simple, maybe the cost of the ADC and transport cold be kept reasonable. I am thinking, one PLD or FPGA, one or two SRAM's if necessary, one ADC, and one gig-e PHY device. I am thinking that in very small quantities, this could be done for a few hundred dollars in chip costs. Boards, as always, will be a problem.

      Actually, I might be willing to work on this. It sounds like fun.

      • > It would be nice to not have to do arp or
        > deal with any real buffering, but just build
        > the frame as you go, and stuff
        > the CRC at the end. Send the frame as
        > a broadcast packet.

        I was thinking about going one (very thin)
        layer up -- and really making UDP IP packets,
        unicast or multicast, in those GB Etherframes,
        and have those UDP packets use RTP. This way,
        IF radio becomes "just another RTP media type",
        along with all the audio and video codecs. If
        you define the RTP packetization the right way,
        all sorts of radio hardware and applications
        could conform to it. Yes, it would be the most
        bandwidth-intensive RTP packetization to date,
        however, the SMPTE HDTV uncompressed packetization
        that's underway in AVT now is moving a fair
        number of bits, so 12-bit quantization of a
        20Mhz IF is not too far out of the mainstream.
        • You are right. UDP is clearly better than raw ethernet.

          What is RTP?

          As a first step, the UDP packets could be totally hard-wired. That is the source and destination MAC ID's could be stored in a configuration rom, as could all the IP's. This would allow the whole thing to work without ARP. I am trying to stick to total one-way communication and avoid having do an actual TCP/IP stack.

          I don't know enough about TCP/IP to do even a minimal implementation in an FPGA. If I need the whole stack I'll have to go to an embedded processor running linux or uClinux or something. For now I want to avoid that.

          In the long run, someone (possibly me) could do a standards compliant FPGA, that could at least do ARP, and maybe deal with some ICMP messages if that is required by whatever standards apply.

          It is always nice to be able to ping devices on a LAN.

          I have basically decided to actually do this. I'll do some mail-list searching and lurking for a bit and then probably make contact with the SDR guys.

          • RTP is the real-time protocol -- it's how
            media streams (video, audio, etc) get
            sent around UDP networks in the IETF
            view of the world. See:


            RTP scales upwards OK in bandwidth --
            there are uncompressed SMPTE packetizations
            for HDTV in progress, which is a fair number
            of bits moving through the pipe. The
            advantage of designing to RTP (as an industry,
            if not for your current prototype project) is
            that an IF stream is a media stream, and so
            a lot of the associated tools RTP offers are
            a perfect fit (session management tools,
            security tools, etc). So, the standards
            writing job in minimized to just the basics
            needed to describe the radio-specific stuff.

If it is a Miracle, any sort of evidence will answer, but if it is a Fact, proof is necessary. -- Samuel Clemens