Military's 15-year quest for perfect radio is a blueprint for failing big (2012)
arstechnica.com
arstechnica.com
The project I worked on recently changed its goal from being the high bandwidth backbone of the Army to
>"The program will demonstrate the HNW version 3.0 waveform (supports the JC4ISR radio) and then store the waveform in the DOD Waveform Repository"
From: http://www.dote.osd.mil/pub/reports/FY2014/pdf/army/2014win-...
The technology is there, the need is there, the funding has been there, but the overall management of it by the military is awful. You can't really fault the contractors either, they are just doing what they are told.
And ultimately those political forces are what drive these projects. You do some work for a client in the army, and then Mr. Army gets on a bus with a guy in the air force. Mr. Army sings your praises to a big-shot from the Air Force and just like that you've got another $5M contract (to make Drupal websites).
It seems the military uses CORBA frequently for such systems.
"the Navy has specified the use of the Common Object Request Broker Architecture (CORBA)—the military's favorite mission-critical middleware model." http://arstechnica.com/information-technology/2013/10/the-na...
and
http://www.ois.com/Markets/military-and-aerospace.html
The military has control of the allowed CORBA implementations so they don't suffer from different runtimes that plauged it's usage in Internet scenarios, and get all the typed benefits and speed benefits.
Not that I think CORBA is necessarily a great protocol in general, but then again I don't have any idea what tradeoffs are appropriate for the military either.
All of the branches wind up granting individual projects some degree of leeway over these types of mandates. Mostly because the military needs the products to actually work.
But it's the military...
There are multiple radios used in the field for different distances and bandwidths: VLF, LF/MF/HF, V/UHF, SAT, and ultra high frequency SAT. There is very little in common between those radios in terms of total equipment mass, space and cost. The "waveform" is an insignificant part.
The significant mass, space and cost is on band-specific power amplifiers (PAs), antennas and front-end filters, and those 3 elements are not interchangeable nor can they be software-defined.
What they have done after >15 years is to ignore all the frequency bands except V/UHF, and call the result a success.
http://rf.harris.com/capabilities/tactical-radios-networking... http://harrisradio.com/products/unity-xg-100p/
The tech is there. Also, as for front ends and PAs, you can make wideband transciever frontends, the PAs in JTRS appear to be specific to bands, so it does not appear that they are trying to do the impossible. Tho they do appear to be trying to make it compatable with every thing under the sun: https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System#Wa...
A radio with single-purpose chips and multiple antennas is always going to be more power efficient.
The other problem is that the military often wants HUGE power outputs. It's non-trivial to get good sensitivity on receive when your radio antenna wants to transmit watts of output power.
My main point is that we already do this sort of thing in the radio industry and the RF requirements of the JTRS are not at all far fetched. The issue with the project is the software outside of the actual SDR code.
Also, as a little bit of extra trivia, antennas designed for higher transmit power don't have any less performance than equivalent antennas for lower transmit powers. Infact the opposite may be true on HF as you will be more likely to tune (both actively and passively) the antenna you have connected to an HF transceiver than connected to just a receiver.
We can go in the opposite direction and look at how older radios like the Syntor had tunable working bands of 12 or less MHz, and theres always the MX300 series, with its crystals and tuning needed after that.
As the quality and bandwidth of RF parts gets better year over year we will be seeing more improvements like this. So, in conclusion, I do not see how making one common base transceiver of about 5W output and using separate external power amplifiers per-band is not an achievable goal, considering this is already a product that is currently being manufactured by Harris for both the military and public safety markets.
The vision was possible.[1] You can have multiple PAs, wide-bandwidth omnidirectional antennas, replicate front-end filters, etc. As part of the XG project, the company I used to work for actually developed a very wide-bandwidth front-end that implemented WiMax in FPGA. The trouble is that analog doesn't scale like digital. The tuner alone was $5,000, and that doesn't decrease every 18 months like digital.
[1] In fact, to really take full advantage of opportunistic spectrum usage, it's necessary to have a radio that can operate over a very wide frequency range.
I don't know much about radio hardware. What is it that makes this so expensive, and (it sounds like) resistant to economies of scale?
It's one thing to build an analog circuit in the lab that performs a certain function, another to make this as a consumer grade device and a completely different kettle of fish to build it in such a way that the military will accept it as a part of their command-and-control infrastructure.
Military comms gear is overdesigned to a degree that is hard to imagine if all you've seen is consumer stuff.
By comparison, making a digital circuit with very high reproducibility of features is childs play.
Digital, by its very nature is a lot easier to get right because every state-transition is 'hard' whereas with analogue parts variability and noise are much harder to control and will lead to circuitry becoming un-usable (especially over time, in the presence of vibration or over a large temperature and humidity range).
There is of course no magic wand (yet) that gives you a broadband transceiver with good performance over 1 mhz - 100 ghz. The WIN-T program always aimed to deliver a variety of different radios into the hands of the soldier so they'll have some degree of comms in all opertional scenarios. They just don't want to have soldiers dealing with 10 different radios when 3 or 4 will work.
https://en.wikipedia.org/wiki/Joint_Strike_Fighter_program#C...
https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System#Pr...
Any others?
https://en.wikipedia.org/wiki/AGM-169_Joint_Common_Missile - cancelled
https://en.wikipedia.org/wiki/Joint_Air-to-Ground_Missile - follow on to the JCM (not sure about it's status - they may have gotten the planning right by putting in for a long dev period up front)
Really though it's a tongue-in-cheek observation with a basis in the reality that a 'Joint' program implies multiple service branches sourcing requirements. In turn, that increases requirements count and complexity, which in turn has a non-linear and negative effect of program efficiency.
It also often moves program decisions from technical tradeoffs made by engineers into political space between branches.
That said, I don't think CORBA is the worst thing ever. It was slow as shit back for the day, but in this age of HTTP based RPC services it seems lightweight and efficient. Memory management in the C++ binding was broken by design, however.
http://www.counterpunch.org/2014/02/11/the-best-government-m...
On the technology front, I was about to suggest they use Field Programmable RF to help solve this and then look what I find:
http://finance.yahoo.com/news/altera-lime-microsystems-demon...
I think credit should be given for the standards-based, open architecture approach. I believe that is the right approach for a procurement project like this. The problem appears to be with the manner in which the requirements and delivery were managed.
It's easy to scoff at such failures but three-person startups and MVPs are a world apart in terms of the scale, time horizons and practical challenges faced by military hardware.
It's a pity the armed forces don't make better use of commercial talent when they're undertaking this kind of procurement project. They may be at the cutting edge when it comes to the technology they're looking to reply but the management techniques they're using are about 60 years out of date.
True, but then the decision to expose FPGAs as part of the programming interface was absolutely wacky. FPGAs are some of the most proprietary devices on the market, usually requiring a vendor toolchain to even produce working bitstreams for the devices.
They defined the interface at the wrong level. They should have developed something like an MII interface and focused on open framing and message protocol formats rather than on open source waveform generators.
That sounds like a recipe for slow torture.
http://jpeojtrs.mil/sca/Documents/SCAv4_1_DRAFT/SCA_4.1_DRAF...
And by that I mean theres nothing in there that gets you any closer to, you know, actual communication hardware.
> Could everyone on the call turn to section 3.1.3.4.1.7.5.1.1 titled "Brief Rationale"
$6 billion and counting in the hands of government contractors, lobbyists and freshly minted industry experts retired out of the service.
Sounds like mission accomplished to me.
It seems to me that we are reaching the limits of what can be done in big technological projects if we don't get rid of greed and internal politics.
At the top you have big corpos that want to milk the government and at the bottom you have people that will make decisions that will advance their careers whatever the consequences for the project.
For Lower than 30mhz - there are many COTS solutions using well proven technology, even supporting digital encrypted audio available.
Otherwise yes, you can buy (today) hardened P25 handsets with IP66+ rated fist microphones and all that.
(my opinion is that the project was madness on a hardware level: all of those filters and FPGAs were competing with size, battery life, cost and complexity)
I think the P25 datastream however is a useful construct to build a larger radio system around however.
They wanted it all, and got nothing, the usual ending when you try to build something around a "grand unified model" there is always an edge case.
https://en.wikipedia.org/wiki/Joint_Tactical_Radio_System#Wa...
This requires a significant amount of software outside of decoding a radio signal from a bitstream into another bitstream. You have tons of software to interface to all the little dingus and do-dads you want to plug in. Some of this is standardized.
Remember, the military connector category on Mouser is 500,000 parts large.
The win rate isn't real good though.
On the other hand, the Manhattan Project beats all of these aside from that obscure networking stuff, Apollo and the HGP were more taking existing working stuff and doing it on a more ambitious scale. I've been studying the Manhattan Project as of late, and it's for example amazing how much the plutonium path was pushed before they understood really important details about it, like fast neutron cross section, average number of neutrons from fast neutron fission (needs to be > 1), how to chemically isolate it after transmutation in a natural uranium reactor, and how to do that with that fantastically radioactive irradiated stuff.
Or the faith that they'd be able to develop a good enough membrane for the Oak Ridge gaseous diffusion plant (high pressure + fiercely corrosive UF6). Or how they got all this in motion before having good bomb designs, and how the Pu240 contamination of reactor brewed vs. cyclotron created plutonium required getting the most difficult bomb design to work ... and it worked the first time! Or how they set to making multiple reactors before they really knew they'd work, and if the size they'd chosen would work in the face of the neutron poisons it would likely generate.
And in such short time; study of the people and their methods of management (e.g. Groves and Oppenheimer) is very worthwhile for many HN readers.
Almost 84% of the Manhattan Project funding went to the industrial production at Oak Ridge and Hanford--more than 80% of all funding went just to producing fissionable material.
Almost 1 in every 250 Americans worked on the Manhattan Project.
This wasn't just big. It was unprecedented. And it almost didn't work. If the atomic bomb had been delayed even a few more months, the war would have been over.
http://blog.nuclearsecrecy.com/2012/04/02/do-we-want-another...
http://blog.nuclearsecrecy.com/2013/05/17/the-price-of-the-m...
http://blog.nuclearsecrecy.com/2013/11/01/many-people-worked...
Very possibly not; Operation Olympic, the invasion of the smaller main island of Kyushu, was in every mind but McCarther's on hold due to massive reinforcements and an (underestimated) huge number of kamikazes available. Those who knew about the bomb were planning on using a number of them for that invasion if the initial 2-3 demonstrations of it failed, those who didn't were planning on using chemical weapons (I think in general, but maybe for or also for Olympic). So what would have happened if the war dragged on to it's scheduled October 1945 date? We can't know.
But the rest that you say, yeah. Bohr didn't think the project was feasible without turning a nation into a factory, and upon coming here, noted that was indeed what we did.
More later, or email me (check my HN profile).
Next book for the management of the project, although there's a lot more, e.g. Groves was responsible for US intelligence actions WRT to Germany and Japan's nuclear projects, one of the last chapters it titled something like "Destruction of the Japanese Cyclotron", is his Now It Can Be Told: The Story Of The Manhattan Project (http://www.amazon.com/Now-It-Can-Told-Manhattan/dp/030680189...).
Earlier publication date, so less could "be told", but lots of good stuff. E.g. when he first got an estimate of something major from the Chicago "Metallurgical Lab", he asked for the uncertainty factor, expecting something like 25%, and got a factor of 10. After explaining that in a neat "to feed somewhere between 10 and 1,000 people" metaphor, he then relates how they discussed it for a while, he realized there would be no firmer figure for some time, and then they all forged ahead. A truly remarkable man.
There's also a lot that's been published on Oppenheimer, but I'm not studying Los Alamos too much now, and e.g. the above book is very interesting for lots more details in how Groves picked him, and reexamined it in late 1944 or so because of Oppenheimer's relatively poor health and still couldn't find a replacement (as noted by Rhodes, if Oppenheimer had lived just a bit longer he ought to have gotten a Nobel for his earlier and way ahead of it's times late '30s theoretical astronomy on topics like neutron stars and black holes).
I'm in the middle of the Manhattan Project section in this much more specialized book, which has a political science analysis focus that's not going to be of interest to most of us, but it's quite promising, the railway story is neat and feeds right into Germany's physics establishment story; check back with me in a few weeks to see if it's worth your while: Technology and International Transformation: The Railroad, the Atom Bomb, and the Politics of Technological Change (http://www.amazon.com/gp/product/0791468682) the cheapest copy is now $19 (plus shipping), vs. the $3 I got it for, so it's very possibly not worth it.
I've also got these books on order: The General and the Bomb: A Biography of General Leslie R. Groves, Director of the Manhattan Project (http://www.amazon.com/gp/product/0396087612) and suggested from the previous book The Atomic Scientists: A Biographical History (http://www.amazon.com/gp/product/0471504556) which might be interesting if you really like the first 300 pages of Rhodes' book.
I think that last element helps explain the Manhattan Project's success, rightly brought up by a poster above. They simply had to succeed and they were potentially able to tap the wealth of the entire United States to make it happen. Smart, motivated people + quasi-infinite resources: things can happen.