Print 61 comment(s) - last by rcc.. on Apr 1 at 4:26 PM

The B2 Bomber's radar frequency was recently sold to a Russian entrepeneur on accident. The incident emphasized the military's increasing spectrum woes.  (Source: U.S. Air Force)

The F22 Raptor's AWACS targeting probably won't work outside the U.S. This is just one of the many costly spectrum issues the Air Force and armed forces are having in the U.S. as civilian spectrum use increases.  (Source: Wikimedia)
Costly blunders and redesigns all part of military networking growth pains

The U.S. military originally had a virtual monopoly of certain communications channels.  It was one of the few entities to be using internet, and it used many areas of the spectrum untouched by civilian communications.  However, with the digital revolution and the expansion of civilians onto the internet and increasing using of the digital spectrum, the military is finding adapting to the deprivation of these bands difficult.

Last year during the bandwidth auction, the portion of the spectrum used by the B-2 bomber's Raytheon APQ-181 radar was accidentally sold to an obscure multinational organization according to  As a result, U.S. taxpayers will be footing the over $1B USD bill to replace the radar in the 20 remaining jets.

With users demanding video-ready smartphones, high-speed mobile internet, and other emerging applications, the military is finding that the spectrum is quickly disappearing, and it’s having trouble finding areas for its own sensitive technologies.

Other expensive losses abound.  The Joint Tactical Information Distribution System, a costly system used to get AWACS targeting data to F-22 fighter jets has "limited supportability outside the continental U.S."

Another key issue is the steady creep of civilian communications into the spectrum used for flight-test telemetry.  While there are workarounds to gather some additional information, telemetry data remains essential to testing both manned and unmanned aircraft and protecting pilots from failures.

Ultimately, more data takes more bandwidth -- an unalterable fact -- and to achieve higher frequencies more power is required.  This places inherent limitations to the amount of data capable of being communicated over the spectrum.

Military designers are in a sticky situation as they can't compress their data, in many cases, like civilian applications.  "This is not a cell phone,” said Darrell Ernst. "You can't ask the pilot to wait while you redial."

Ernst works for the Mitre Corp., a member of a U.S.-European delegation trying to raise international awareness of bandwidth issues, and estimates that by 2020 the Air Force will need 600 MHz of spectrum for telemetry data.  Currently the only vacant spot suggested to them is the 5091 and 5150 MHz band.  The Air Force is eager to occupy even this meager 59 MHz offer.  States Mr. Ernst, "If [the flight-test community] can get in there and start using it, we can be established as the primary user and it will be hard for them to throw us out."

When it comes to the spectrum issues, there are few good answers, just more fears and doubts.  As a final example of the industry problems, when the Joint Strike Fighter (JSF) test program is flying two missions no other combat aircraft will be able to fly in the Western U.S.  States Mr. Ernst, "They're the 600-lb. gorilla. They don't see that they have any reason to move, and they don't have the radios to do it."

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: Why can't they compress data??
By hyperbolicparody on 3/23/2009 2:42:25 PM , Rating: 4
Ada is still used extensively for aircraft and DoD applications. OFPs are still often written in Ada83, as are a lot of the military flight and ground simulations (both for testing and training purposes) out there, and I think it's a total shame that it wasn't until recently there was a free compiler (GNAT has come a long way in the past few years).

I actually wouldn't be surprised if the data coming off of the OFPs would be remarkably hard to compress. Working on them... hooks for simulation, test and debug are such an afterthought... the engineers are primarily focused on the insane flaming hoops they must jump through to get everything written, verified and approved.

There's rarely ANY overhead written into the hardware specs, and the components are horrifically sensitive to timing requirements. It makes non-normal operation rough... you might find your component locked out of the MS1553 bus (or even worse designed to self-destruct) if it's cycle count is out-of-whack with other components. But that's all done to make components pulled from crashed aircraft useless.

Also, it's tough to compress data fast enough on the hardware available. It's not the size, it's the volume, and it's the hardware on the aircraft. Gathering and packaging all your data at deterministic rates higher than 200Hz is harder than you think... and need all that data transmitted to the ground station with as little transport delay as possible. Also, imagine trying to do all of that on the embedded hardware available to you 10 years ago.

...oh, and some of it is written in FORTRAN. FORTRAN!

By lotharamious on 3/23/2009 3:25:40 PM , Rating: 4
...oh, and some of it is written in FORTRAN. FORTRAN!

What's wrong with Fortran? It's a powerful computation language. Unless you're talking about something prehistoric like Fortran 4.

"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." -- Bill Gates
Related Articles

Most Popular ArticlesSmartphone Screen Protectors – What To Look For
September 21, 2016, 9:33 AM
UN Meeting to Tackle Antimicrobial Resistance
September 21, 2016, 9:52 AM
Walmart may get "Robot Shopping Carts?"
September 17, 2016, 6:01 AM
5 Cases for iPhone 7 and 7 iPhone Plus
September 18, 2016, 10:08 AM
Update: Problem-Free Galaxy Note7s CPSC Approved
September 22, 2016, 5:30 AM

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki