The Journey of Radios From Hardware to Software

An anonymous reader writes "The New York Times is carrying a story all about the process of replacing radios with software. The article tells the tale of Vanu Bose, son of the man who started the Bose company, and his quest to bring software to what was previously a hardware-only enterprise. He met a lot of resistance in the 90s to his ideas, because processor technology was not up to the task. Now that technology has caught up with Vanu, his software (and other products like it) are increasingly replacing now-outdated hardware components. 'Well-established companies like Motorola and Ericsson now use elements of software-defined radio for their base stations. But Mr. Bose was the first to come to market with software that could handle multiple networks with the same equipment. Software radio appears to offer an elegant solution to what has been a vexing problem: how to have a single handset, like a cellphone, communicate across multiple networks. For instance, the G.S.M. standard, for global system for mobile communications, is used broadly in Europe, and most notably in the United States by AT&T.'"

An interesting idea

[FlyByPC]

It's amazing what can sometimes be done in software. You can make a simple AM-band transmitter using a microcontroller and two resistors -- with everything done in software. MCUs are fun!

Maybe use block frequency converters?

[Kadin2048]

The 'true software receivers' are interesting, but ultimately I think they're overkill once you get out of the HF bands. Maybe this will be one of those 'who needs more than 128k?' comments, but I really don't see any reason why you need to sample the RF directly when you're dealing with VHF or UHF, it just seems excessive. If you want to digitize a 1GHz input, you're going to need to sample it at least 2GHz, and probably significantly higher if you want to do any cool DSP-type stuff. That's gotta start doing nasty things to the system's power consumption.

The satellite communications people have been using block downconverters for decades; every pizza-box satellite dish has one, to take the incoming signal from the feedhorn and drop it down to a level that can be sent down the coax to the set-top box without huge line losses. Some of them can work on fairly broad frequency ranges (like several GHz at once, for some of the Ku-band ones), and are real engineering marvels.

That seems like a much more practical approach for cellphones than a direct-digitization one. I don't know if you'd be able to make one block downconverter/upconverter that would cover all the bands currently used by GSM phones (800-1200 MHz, I think?), but if not, it would be the only part you'd need to change when designing for one region vs another. As long as it used the same IF output, the SDR would only have to be designed around one frequency range, and could be heavily optimized in order to improve battery life.

Looking in the wrong section.

[zippthorne]

Buy an alarm clock from a drug store. They often have AM/FM radios thrown in there.

Why does it have to "not look like crap?" Why can't it look like you didn't overspend on sony quality?

Now.. whatever happened to mass-produced small crystal radios? Those'd be interesting for hurricane kits, especially if they could tune the broadcast FM band (but obviously not as an FM receiver. You can still hear FM with an AM reciever, it just doesn't sound all that great. Voice is fine, though.)

Cell Phones

[rebelcan]

I'd really like to see this sort of thing being implemented in cell phones. Unfortunately, where I live, the provier with the best rate plans uses CDMA for their network. All the cool phones I'd like to have use GSM. Having a phone that could switch between the two would be freaking awesome.

didn't someone ...

[sideswipe76]

Come up with a new division algorithm for sampling RF? Like, divide 3 instead of 2? I am not an EE but I remember reading it

Re:didn't someone ...

[Man On Pink Corner]

Something many people don't understand is that the Nyquist criterion applies to the bandwidth of the recovered signal, not to its carrier frequency. So if you want to recover a 10-kHz wide signal at 800 MHz, you don't need to sample at 1600 MHz... you just need to sample at 20 kHz, using an ADC with lots of front-end bandwidth.

That's an oversimplification, but it may be what you were thinking of.

Not the first time I noticed this

[Duncan Blackthorne]

I think the title of this posting could be construed as a bit misleading, in that it says 'radio' but when you read the attributed article, they're talking about cellphones, not things like broadcast radio or other areas where RF transmission and reception are necessary. It may or may not be obvious to anyone, but there's no way that tuned RF circuits can be completely eliminated, at least if you're talking about over-the-air transmissions; you still need to at least provide amplification (which must be a tuned circuit) and impedance-match to your antenna (which again must be a tuned circuit).

Re:Two Words

[Duncan Blackthorne]

What I find interesting (and horrifying at the same time) from that site, is that the MPAA and the FCC are actually discussing legally limiting who can purchase fast ADCs in order to protect their IP. So, what, if they got their way, I'd have to get some sort of license to purchase an integrated circuit because I might use it to build an HDTV receiver that they can't control? What a bunch of jerks!

Emergency Communications

[Detritus]

I'd like to see the technology used to solve some of the inter-agency communications roadblocks that afflict the USA. Every agency has their own frequencies, protocols and hardware. In an emergency, they often find that they can't talk to any of the other responders. In addition, it would be great if the radios could work with the current cellular networks. This is one of the reasons that the military is investing money in SDR. Many people still remember the soldiers in Grenada who had to request close air support by using a phone card and making a call on a local wireline phone to Fort Bragg.

The DoD's new Software-based Radio

[flydpnkrtn]

The Joint Tactical Radio System (JTRS or 'jitters') is currently being tested by the US Army... it aims to be "everything in one box," and it was "originally planned to span a frequency range of 2 megahertz to 2 gigahertz. JTRS has been expanded to frequencies above 2 GHz to satisfy space communications requirements"

That's a direct quote from the Wikipedia article (which looks like it's pretty accurate), located here: http://en.wikipedia.org/wiki/JTRS [wikipedia.org]

I'm in the Army, and buddies of mine have played with it and can attest that "it's pretty cool" :)

Software radio scaners

[rec9140]

Any one interested in creating a new breed of software based radio scanners (those radios used to monitor police, fire, ems, and other signals) for modes not supported on current scanners or to add features can bring their skills to:

http://groups.yahoo.com/group/gnu_radio_scanner/ [yahoo.com]

This is a group looking to build on the GNU Radio blocks.

Software replacing hardware...

[evilviper]

In theory, software (solid-state digital circuits) has huge advantages over hardware. Software offers extreme flexibility, no wear-and-tear, etc. If it worked as well as it should, in theory, there wouldn't be mechanical linkages just about anywhere, anymore. All the controls in your car would be electric, and a significant portion of your car's engine would be gone (no more cam shaft). The same would be true of most everything... If not replacing significant numbers of mechanical components, at least using software to precisely control it, and getting much better efficiency as a result. Yes, your refrigerator, microwave, etc. could all greatly benefit from software control.

There are just two big problems that have made software control a non-starter.

First is customization. Put a spring in the mechanics of an engine, and I can replace it with a shorter/longer/stronger/weaker spring. I can heat it up to weaken it, grind it down, etc... With software, you are given a black box, binary-only, with no documentation on how it works, and definitely no common interface to access and modify it. So every time car companies add another function to their cars' onboard computers, and take away mechanical systems, there's extreme resistance, as buyers know they're out of the loop, and if they want to adjust anything, or if something should go wrong, they can only take it to the select few company-blessed shops, which have paid the necessary bribes to get enough info to do just a few basic things with the onboard computer. And you're entirely screwed if you want more changes than that, because the company doesn't WANT you to, and without man millions of dollars on the line, you're not even a blip on their radar.

Despite what many believe, cost is almost never a problem. For low cost products, low-end micro-controllers can be found for pennies, and even cheaper are the basic I/O elements like thermistors, power meters, transistors, relays, etc. Yet even the dirt cheap processors sold today can do many millions of calculations per second, far faster than could be needed for damn near any products.

Second, and perhaps more important, is reliability. Computer hardware is EXTREMELY reliable. You can go buy a dirt cheap commodity CPU, RAM and MOBO, and be pretty damn sure it will run for 20 years without a SINGLE error. The only big exception to this is power supplies... a marginal one, not supplying enough power will cause a crash, but that generallyonly happens in the case of the cheapest no-name junk. What's more, go up a small step to a high quality MOBO, ECC RAM, redundant PSUs, UPS, etc., and you'll never ever see a hardware-induced glitch.

The reliability problem comes ENTIRELY from poor software, and mostly commonly available kernels, at that. People don't want to believe that, but the facts are that computers are 100% pure math machines, and math is 100% accurate. A computer will do exactly what you tell it to do, but most people are trying to program their computer through several million lines of indirection... If you write, in hex, a simple loop with a bit of processing, a computer will run it error-free, from here until doomsday, but programing a complex system in hex is much too hard, and human programmers aren't perfect enough to do so.

The only real possibility to ensure reliability with reasonable development time is something very much like a micro-kernel. You need a tiny bit (a few hundred KBs) of EXTREMELY-thoroughly audited code, that can very strictly manage memory, do strict input and bounds checking, carefully manage communications between independent modules of code, instantly tear-down and restart any bit of code which shows the slightest signs of an error, and also strictly ensuring real-time operation.

I'm not endorsing any product here. The fact is nothing like this exists. That is why we aren't seeing mechanical systems having components being replaced by software as quickly as they can be redesigned. Open source operating systems