Military's 15-year quest for the perfect radio is a blueprint for failing big.

In 1997, the Defense Department began its quest for the perfect family of radios: software-defined radios that, like computers, could be reprogrammed for different missions and could communicate with everything the US military used. Digital signal processing could adaptively use available radio spectrum based on the needs of the moment, turning soldiers, tanks, planes, and ships into nodes of a broadband radio-based network.

The goal was to solve radio problems like this one in Afghanistan, detailed by the Center for Public Integrity in January 2012. Soldiers who watched an ambush forming on a ridge nearby found themselves limited by the hugely variable needs of their many radio systems:

They had short-range models for talking with the reconstruction team; longer-range versions for reaching headquarters 25 miles away; and a backup satellite radio in case the mountains blocked the transmission. An Air Force controller carried his own radio for talking to jet fighters overhead and a separate radio for downloading streaming video from the aircraft. Some of these radios worked only while the troopers were stationary; others were simply too cumbersome to operate on the move.

But the program meant to fix the mess, called the Joint Tactical Radio System (JTRS), instead became a massive 15-year software and hardware development mess of its own, involving five sub-programs and multiple multi-billion dollar contracts. It has been a financial disaster for the DOD. Billions were thrown away on technology that will never see the light of day, despite multiple heroic efforts to pull the project back from the brink of disaster.

JTRS provides a textbook case of what not to do in a technology development program, proving that even a few great ideas can’t save a project that has been over-specified and under-tested, and that remains blinkered to what's going on in the world around it.

“This achievement enables the Department of Defense to harness years of investment and technological progress associated with the GMR development,” said a JTRS Joint Program Executive Office spokesperson in a statement at the time.

GMR formed the cornerstone of the Army's plan to build mobile ad hoc networks that connected troops in the field to each other, as well as to Army and Air Force aircraft flying in support, and to commanders back in operations centers. With WNW as the network's backbone, the Soldier Radio Waveform for communicating to handheld and other mobile radios, and waveforms for satellite and ground-to-air communications as well, the GMR would be the router on the battlefield Internet. And now it was ready to go.

Well, sort of. After burning through over $6 billion just to develop GMR, the Army had actually cancelled the project back in October 2011 after it failed the Army’s Network Integrated Environment (NIE) testing. Big, bloated, and complex, the GMR couldn’t handle the heat of White Sands, New Mexico, and it proved to be less "iPhone" than "mainframe" in complexity.

The NIE exercise highlighted the uncomfortable fact that soldiers might sometimes have to send critical messages during a fight. An impatient lot, they may not be terribly excited about waiting 10 minutes for the radio to run through a slow series of boot-up processes… If someone were to make a television commercial for the GMR, it would undoubtedly include a line about sophistication being worth the wait. Except in combat, sometimes you really can’t wait. Too bad the GMR was supposed to go to war, because it would apparently be a pretty sweet system in an environment where the temperature and operational tempo are both low.

So although GMR is "certified for use," the Army doesn't actually want to use it. And the system isn’t done costing the government money. While the Army waited years for GMR, it spent $11 billion more on “legacy” radios based on technology from the Cold War. As Ward pointed out, the Army may yet pay billions more to get the radios it actually needs—just as the war in Afghanistan is winding down.

The GMR, broken down in schematic form. Who wouldn't want to lug this around the battlefield?

Department of Defense

Open source radio

At its core, JTRS was built on what sounded like a good idea: separating radio standards from transmission hardware by creating an open “operating system” common to all military radios. If radios’ waveforms were defined in software rather than hardware, they could be moved like applications from one set of hardware to another, or upgraded with a simple software update.

Taking a page from open source licensing schemes like GNU, the core software architecture and the “waveforms”—application-specific formats for radio communication—were made available to anyone building radios for the DOD, with the provision that any implementation of the code be contributed back to the JTRS code repository. It was a success, if success can be measured by number of contributions: that repository now holds four million lines of code.

The idea behind the open architecture was to ensure that all the communications gear that each of DOD’s services bought would work together seamlessly. And since the core software and the waveforms would be freely available to anyone—even companies that didn’t get in on the main JTRS programs—the overall cost of getting new radios should fall dramatically by allowing competition between manufacturers based on a well-defined standard. In other words, JTRS was supposed to commoditize the software-defined radio market.

When I spoke with then-JTRS program executive Dennis Bauman back in 2008, he said that the open code base allowed JTRS to “enroll” new vendors on a rolling basis. While there was still an open competition for the design phase of each component radio program, manufacturing would always have more than one option. “We require that we qualify at least two sources,” Bauman said; those qualified vendors would compete annually to manufacture radios in lots.

The Harris Falcon III handled "JTRS-compliant" radio, developed independently by Harris with access to the JTRS code repository.

Harris Corp.

That approach paid off, at least with some of the first transitional handheld radios that could interoperate with the broader JTRS program. For example, in 2007, Thales won the contract for the Consolidated Interim Single Channel Handheld Radio (CISCHR)—a project merged into JTRS from the US Special Operations Command. But Harris developed a version of its Falcon III radios on its own that was "JTRS Compliant" and could use the Soldier Radio Waveform, as well as other legacy radio formats that were ported to the architecture, by using the common JTRS repository. Harris sold over 100,000 “JTRS-compliant” radios to the Army and Marine Corps in open competition with the "official" Thales radio; the competition between the two for JTRS business saved the Army $104 million on the first batch of 39,000 radios alone.

If JTRS had just been a software standards effort focused on waveforms, this might be an article about the “genius of JTRS.” Unfortunately, it wasn’t. And this isn’t. The various services, especially the Army, weren’t content just to have companies compete on the software standard. They increasingly wanted more hardware features as well.

Some of the most fundamental problems with JTRS (and especially with the GMR sub-program) are common to any large, failing technology project—only on a more massive scale. The scope of JTRS was so huge from day one that no manipulations of the “iron triangle” of project management could keep cost and schedule under control.

Inadequate understanding

Military technology often pushes at the edge of the doable—that’s why agencies like DARPA exist. But when JTRS was originally conceived in 1997, the Army's most significant previous work on software-defined radio was an Army project called SpeakEasy—the first version of which took up the entire back of a military truck. Clearly, an ambitious project like JTRS had plenty of basic research to chew through before it could produce anything useful. In hindsight, the military badly underestimated the challenges before it.

"In the end, building a radio that worked with all the different waveforms envisioned by the project required bending some fundamental rules of physics."

In a letter sent to the chairman of the House Armed Service Committee in October 2011 explaining the cancellation of the GMR program, acting Undersecretary of Defense for Acquisition, Technology, and Logistics Frank Kendall wrote that “the technical challenges of mobile ad hoc networks and scalability were not well understood due to the immaturity of the technology” when the program began.

First and foremost was the software development problem. When JTRS started, software-defined radio (SDR) was still in its infancy. The project's SCA architecture allowed software to manipulate field-programmable gate arrays (FPGAs) in the radio hardware to reconfigure how its electronics functioned, exposing those FPGAs as CORBA objects. But when development began, hardware implementations of CORBA for FPGAs didn’t really exist in any standard form.

Moving code for a waveform from one set of radio hardware to another didn’t just mean a recompile—it often meant significant rewrites to make it compatible with whatever FPGAs were used in the target radio, then further tweaking to produce an acceptable level of performance. The result: the challenge of core development tasks for each of the initial designs was often grossly underestimated. Some of those issues have been addressed by specialized CORBA middleware, such as PrismTech’s OpenFusion, but the software tools have been long in coming.

Then there was the range of requirements demanded by the waveforms themselves. Each waveform called for different frequencies; while the radio’s electronics could be software-configured for those, significantly different frequencies required divergent antenna properties and modifications to the radio hardware itself. In the end, building a radio that worked with all the different waveforms envisioned by the project required bending some fundamental rules of physics.

Having an undefined technical problem is bad enough, but it gets even worse when serious "scope creep" sets in during a 15-year project.

Having worked on JTRS-capable or JTRS-compliant systems, I can attest to how cumbersome the whole architecture was. As the SCA/JTRS was being defined, key pieces of the system were missing like how to actually move audio/data through the system. This meant that "off-the-shelf" waveforms were not plug-and-play and would need adaption to meet the system they were meant to run on.

I have no idea if they ever figured those pieces out, because I transferred out of that development not too long after learning how far down the rabbit hole went.

I think it's fairly important to understand how painful development gets the instant you have to contract. Federal Acquisition Regulations (and the subset DoD Directive / service regulations) cause some serious problems in terms of even giving the developing company enough time to develop a technology. Contracts get awarded at most for five year cycles, but quite often go up for bidding every year. Many military systems can blame their shortcomings on the colossal bureaucracy they must pass through prior to approval, mass production, and subsequent fielding to the troops, opposed to the systems themselves. (Partly to do with why the M16/M4 still hasn't been replaced, despite numerous superior options including one upper receiver replacement which would upgrade all the weapons for a ridiculously low price)

And this approval system bloat wasn't simply a product of military imagination, it was sadly the only way for the military to be "fair" according to the FAR...

I did university research with SDR and used it with the AFRL. The tech is awesome, though the DoD mismanagement (the short time I was there) was astonishing. I still believe SDR has a bright future, it just needs private commercialization efforts to make that happen.

I did university research with SDR and used it with the AFRL. The tech is awesome, though the DoD mismanagement (the short time I was there) was astonishing. I still believe SDR has a bright future, it just needs private commercialization efforts to make that happen.

Maybe, but as pointed out in the article, the present way, with lots of cheap, single-purpose radios, plugged together, worked better than some all-in-one solution.

Again, you have to remember that the DoD has to comply with the Federal standards unless they make specific exceptions for the DoD, and each of the services have their OWN requirements on joint projects. It's not that the military WANTS such a huge pain, it's that they're forced into it otherwise they're not "being fair" or "testing enough".

I worked on one of the WNW waveforms for HMS. I can't overstate how far this architecture is from being plug-and-play with waveforms. Any change in model of FPGA or DSP blows an entire design out of the water. At the time I believe about three fourths of our FPGA group (so about 10-12 people) was working on WNW waveform porting. Those four million lines of code in the JTRS repo cannot be dropped into future devices.

I did university research with SDR and used it with the AFRL. The tech is awesome, though the DoD mismanagement (the short time I was there) was astonishing. I still believe SDR has a bright future, it just needs private commercialization efforts to make that happen.

Maybe, but as pointed out in the article, the present way, with lots of cheap, single-purpose radios, plugged together, worked better than some all-in-one solution.

Commericial radios are moving to SDR. With the multitudes of frequencies next generation phones has to support, it sounds like a great idea if it can prove itself.

SDR equipment and software is widely available to civilians - ham operators certainly know about Flex Radio Systems which makes SDR - both receivers AND transmitters. And their latest model coming out is doing something only dreamt about 10 years ago - direct conversion (instead of taking the signal, bringing it down to baseband and extracting the I/Q signals, direct conversion receivers stick a fast ADC right at the antenna terminal (well, first an amp - ADCs are notknown for their sensitivity) then do the baseband conversion down in discrete time (digital down conversion).

Then there are things like the RTL SDR, Funcube dongle and software like WinRad, HD-SDR, PowerSDR, GNU Radio, USRP...

Really makes you wonder where all the money went, especially since basic non-direct conversion SDRs are basically a glorified sound card when they hook to the PC (one channel carries I, the other Q)

But direct conversion is the way to go - the number of bands you can simultaneously receive is only limited by your processing hardware.

could someone please give a brief, very brief, explanation of the difference between analog and dsp when it comes to radio. not what it is so much as i know the differences when it comes to cd and vinyl, but what is the advantage for radio? what is the difference when a signal fails? does analog get weaker and digital just drop off? wouldn't digital have a shorter broadcast distance? I'm guessing dsp capable radios can receive data as well but analog processors cannot (at least not nearly as simply), is this correct?

SDR equipment and software is widely available to civilians - ham operators certainly know about Flex Radio Systems which makes SDR - both receivers AND transmitters. And their latest model coming out is doing something only dreamt about 10 years ago - direct conversion (instead of taking the signal, bringing it down to baseband and extracting the I/Q signals, direct conversion receivers stick a fast ADC right at the antenna terminal (well, first an amp - ADCs are notknown for their sensitivity) then do the baseband conversion down in discrete time (digital down conversion).

Then there are things like the RTL SDR, Funcube dongle and software like WinRad, HD-SDR, PowerSDR, GNU Radio, USRP...

Really makes you wonder where all the money went, especially since basic non-direct conversion SDRs are basically a glorified sound card when they hook to the PC (one channel carries I, the other Q)

But direct conversion is the way to go - the number of bands you can simultaneously receive is only limited by your processing hardware.

+1

I've just started reading up on FLEX's latest design, and it seems to completely change the game for amateur transceivers. One feature amateurs and the military have in common is the desire to have one radio send and receive in multiple bands, sometimes at the same time. Mind, there may be any number of other reasons why FLEX's radios aren't a good choice in the field, but they seem to be pretty cool, and very capable.

could someone please give a brief, very brief, explanation of the difference between analog and dsp when it comes to radio. not what it is so much as i know the differences when it comes to cd and vinyl, but what is the advantage for radio? what is the difference when a signal fails? does analog get weaker and digital just drop off? wouldn't digital have a shorter broadcast distance? I'm guessing dsp capable radios can receive data as well but analog processors cannot (at least not nearly as simply), is this correct?

Analog radios cannot deal with different modulations and protocols because they're based entirely in hardware that is not easily modifiable. Although they're functional for specific types of voice and video communications, e.g. FM radio and NTSC video, they aren't designed for communication of digital data (anything you might see on a computer) which is much more flexible.

In digital communications, the signal is discretized and parceled into a finite set of symbols (e.g. if using 8 symbols, you would be communicating 3 bits at a time) that are known to the receiver. There are numerous advantages over analog:(1) Error correction - you can reliably communicate a message across a link under poor conditions (low SNR or high interference) by coding the message with redundant data.(2) Spectral efficiency - more data (bps) per unit of frequency spectrum (Hz) consumed.(3) Security - Digitial data lends itself to encryption.(4) Networking - Multiple users can share a swath of radio spectrum more efficiently with digital communications techniques.(5) DSP - Digital signal processing is superior for many of the tasks inside a radio such as filtering, synchronization, coding / decoding.

The drive behind software defined radio is that you can support many different communications formats (current and future) without changing or replacing the radio hardware. A small portion of the radio at the front-end it still analog, but once the signal is digitized at intermediate frequency then you have a very flexible processor than can handle the demodulation and decoding for pretty much any type of signal. The concept it sound, there just needs to be some more advancement with standards.

could someone please give a brief, very brief, explanation of the difference between analog and dsp when it comes to radio. not what it is so much as i know the differences when it comes to cd and vinyl, but what is the advantage for radio? what is the difference when a signal fails? does analog get weaker and digital just drop off? wouldn't digital have a shorter broadcast distance? I'm guessing dsp capable radios can receive data as well but analog processors cannot (at least not nearly as simply), is this correct?

Analog radios cannot deal with different modulations and protocols because they're based entirely in hardware that is not easily modifiable. Although they're functional for specific types of voice and video communications, e.g. FM radio and NTSC video, they aren't designed for communication of digital data (anything you might see on a computer) which is much more flexible.

Digital communications also holds numerous advantages over analog:(1) Error correction - you can reliably communicate a message across a link under poor conditions (low SNR or high interference) by coding the message with redundant data.(2) Spectral efficiency - more data (bps) per unit of frequency spectrum (Hz) consumed.(3) Security - Digitial data lends itself to encryption.(4) Networking - Multiple users can share a swath of radio spectrum more efficiently with digital communications techniques.(5) DSP - Digital signal processing is superior for many of the tasks inside a radio such as filtering, synchronization, coding / decoding.

The drive behind software defined radio is that you can support many different communications formats (current and future) without changing or replacing the radio hardware. A small portion of the radio at the front-end it still analog, but once the signal is digitized at intermediate frequency then you have a very flexible processor than can handle the demodulation and decoding for pretty much any type of signal. The concept it sound, there just needs to be some more advancement with standards.

very comprehensive explanation. thank you. on topic: why is this equipment so large and heavy? and are you saying the pay off for this system will just take time for standards to be set so a broader range of equipment and services work seamlessly, rather than the fragmentation that has happened in the past ? so eventually this will save money in upgrade costs?

I did university research with SDR and used it with the AFRL. The tech is awesome, though the DoD mismanagement (the short time I was there) was astonishing. I still believe SDR has a bright future, it just needs private commercialization efforts to make that happen.

A great example of how flexible and resonably cheap sdr can be is the fun cube dongle.Its was designed to receive a cube sat signal but also works as a 60MHz to 1.7GHz receiverhttp://www.funcubedongle.com/

You can't blame not properly tying down/finalising requirements as a problem with the technology, its a lack of proper project management and looks like they fell into typical software project problems .

I used to work in the defense business a few decades ago. What I have seen is the same thing grow at a geometric rate: the increasing time and cost to create a new system versus the decreasing time it takes for technology to obsolete it. Just imagine the North American Aviation NA-73 being developed in today's world. This aircraft, which arguably at least shortened WWII by making daylight precision bombing possible without crippling losses, went from request to flying prototype in less than a year and was developed less than two years later into the P-51 Mustang with the addition of the Packard-built, Rolls Royce Merlin engine.

I lived through the DivAD fiasco. We even inherited one of their computers after the system was finally canned. As a country in league with NATO and commonality needs, we need to put hard and short time frames on products. If we continue on our present course no new system will be affordable or fielded.

The only real loss if we make the changes will be the loss of journalism stories like this one.

All communications are analog once they hit the RF. In this context, 'digital' just means that the data you are transmitting (over an RF carrier) is 1's and 0's.

perfect. thank you.

I have other questions (like why they didn't merge all the systems onto a cellular based network), but I am going to reread the article first.

Best i can tell, because modern civilian wireless tech came about after this project got started and all eyes were firmly on the SDR target. Now they are going after creating mesh networks (the word escaped me earlier when i talked about self-repairing networks) and such apparently, and often seems to adapt civilian gear for military use (latest i read was them grabbing Android devices and slapping on security hardening and custom apps).

What's most interesting is the differences between services and their preferred waveforms/radios. The Army has a love affair with SINCGARS and the Air Force shuns it. We still maintain radios that are only in use by a single airframe. It's an absolute mess. I say that military should all migrate to the Harris line of radios (Falcon III)--they are by far the most capable and most durable radio systems that I have had the pleasure to use in all types of situations.

could someone please give a brief, very brief, explanation of the difference between analog and dsp when it comes to radio. not what it is so much as i know the differences when it comes to cd and vinyl, but what is the advantage for radio? what is the difference when a signal fails? does analog get weaker and digital just drop off? wouldn't digital have a shorter broadcast distance? I'm guessing dsp capable radios can receive data as well but analog processors cannot (at least not nearly as simply), is this correct?

Software Defined Radio is a bit like the difference between an audio record and a CD.

In an audio record, the sound waveform is recorded in an analog way - almost like drawing waveform onto the record.

Now, for radio, it gets a bit more complicated. Radio waves are much higher frequency that sound waves, and so there are different ways to encode that lower frequency sound wave onto a higher frequency radio wave.

Once you have the digitised radio wave, you can use your computer to process the recorded wave, performing the modulation/demodulation in software instead of using specialised hardware.

The advantage of this technique is that one piece of hardware can theoretically handle a wide range of frequencies and a wide range of modulation techniques.

Here is an example of such a piece of hardware: http://www.funcubedongle.com/ These were originally designed to pick up digital TV broadcasts for viewing on a PC, but they can be reprogrammed to pick up cellphones, police radios, analog TV, and, well, just about anything from 64MHz to 1700Mhz.

The problems arise because the devil is in the details. I am not well versed enough in these details to tell you all about it, but below iis my understanding of some of the issues.

One such detail is that radio waves are often too high a frequency to digitise and process directly, and so there are various tricks used to manage that, for example, converting a radio wave down to a lower frequency, i.e. grabbing snippets of the wave and slowing them down before digitising. Of course, by only grabbing snippets of the wave, information is lost.

Another detail is that for transmitting digital data, the modulation techniques get more and more sophisticated, https://en.wikipedia.org/wiki/Quadratur ... modulation , requiring more and more precise and high frequency digitisation of the radio wave. A single bit might be represented by some very minor change in the shape of a sine curve from one peak to another. In fact, multiple bits might be represented by the shape of a single sine curve. It gets messy very quickly.

Well software defined radio is one of those ideas that sounds good, but the devil is in the details. Technology is going to have to do some progression to cover the wide range with the needed resolution. As the article pointed out, sometimes the solution isn't an all-in-one, but smaller,cheaper, mass produced. Kind of like microprocessors.

I think it's fairly important to understand how painful development gets the instant you have to contract. Federal Acquisition Regulations (and the subset DoD Directive / service regulations) cause some serious problems in terms of even giving the developing company enough time to develop a technology. Contracts get awarded at most for five year cycles, but quite often go up for bidding every year. Many military systems can blame their shortcomings on the colossal bureaucracy they must pass through prior to approval, mass production, and subsequent fielding to the troops, opposed to the systems themselves. (Partly to do with why the M16/M4 still hasn't been replaced, despite numerous superior options including one upper receiver replacement which would upgrade all the weapons for a ridiculously low price)

And this approval system bloat wasn't simply a product of military imagination, it was sadly the only way for the military to be "fair" according to the FAR...

Keep in mind a lot of this regulation and bureaucracy came into being in the first place as an attempt to reign in rampant abuse and cronyism by defense contractors. As long as the big defense primes, who have been gaming the system for decades, are involved, it's hard to imagine this changing any time soon.

P.S. I had the "opportunity" to work with some code from the JTRS repository several years ago. Ye gods, what a mess.

Sean Gallagher / Sean is Ars Technica's IT Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland.