backtop


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 Military.com.  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
quote:
...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.


“Then they pop up and say ‘Hello, surprise! Give us your money or we will shut you down!' Screw them. Seriously, screw them. You can quote me on that.” -- Newegg Chief Legal Officer Lee Cheng referencing patent trolls

Related Articles













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