I worked on this project. It's a project filled with realizable goals and impossible mandates. SCA is the most useless thing I've ever encountered. The requirement to use CORBA is simply impossible, there is no way you can make a real-time system using CORBA.
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"
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.
That's a common problem. I griped about their mandating CORBA for use with separation kernels. I figured we could do something simpler like Sun's XDR, a stronger ASN.1, or JSON. Make a tool to autogen import or export code. Not happening. Meanwhile, Galois built a high assurance version of ASN.1 and ZeroMQ has shown CORBA for the outdated garbage it is. Had mandates not existed, the contractors would've probably been able to pick these right up to get their benefits and do certified implementations.
The technology is not there, that's the big joke on top of all the management blunder.
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.
The technology was supposed to be there. The grand vision was radios that could operate anywhere in a multi-GHz range, opportunistically use that spectrum, and be reconfigured via FPGA and pluggable wave-forms. JTRS was supposed to be the software platform gluing it all together.
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.
Analog hardware that is robust enough for military deployment is crazy expensive because it tends to require parts of very high precision in order to achieve repeatable results.
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).
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...
You can build a radio system that will do damm near DC-Daylight but that doesn't mean it will perform as well as a radio with a narrower bandpass. Usually its a pretty solid constant, the wider the bandpass of the radio, the lower performance, its sometimes a worthy tradeoff, but often not.
And, of course, battery life is a big problem for SDR. High bandwidth ADC/DAC conversion combined with FPGA is a recipe for battery sucking.
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.
You don't have to use high bandwidth ADCs, in another post Aloha brings up the XTS3000 which uses a ADC/DAC setup that only digitizes about 400KHz of bandwith and it gets along fine as far as power consumption.
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.
You can make radios that do really wide swaths with really good performance. ICOM already makes receivers that go from 50KHz to 6GHz with little performance issues other than those related to antenna interfacing. In another post you mention the Astro and Astro25 radios (XTS3000/XTS5000), if we look at a Spectra as an example, the UHF R2 units do 438-470, thats 33MHz, the XTS3000 has a 66MHz tuning range it can work with (403-470MHz for example) the XTS5000 has a range of some 90MHz (380-470MHz for example)... this is achieved through more finite control of the analog portions of the transceiver circuits and through software defined first IF. So we are already seeing the fruits of SDR in some 20 year old Motorola products.
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.
Remembering back to my training a few years ago on all these radio systems, I'm not really sure there's a replacement for gaining a deep understanding of radio wave theory and actually getting out there and building antennas and systems. In one course, we built all the antennas we needed from things like claymore wire and constructed resistors from hammering a nail into the ends of a battery. IMHO that radio hardware itself really does need to be something that "just works" and isn't weighed down by trying to do too much.
I was talking about the technology for the specific project I worked on. Not in general. The RF hardware had underwent significant development and refinement to the point that it's problems were worked out and the limitations were known.
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.
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.
Using CORBA in a system and building a system entirely using CORBA are two different things.
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.
Incompetent buyers is the best description for it, but it's not all. There are few financial incentives/penalties in government, the only real risks are political. You'll not get in big trouble for securing funding for a project that ultimately doesn't succeed, but you will end up in big trouble if you run a successful and frugal project that steps on the toes of someone higher up.
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).
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.
Flashbacks! My first job involved JTRS. We were working on an unrelated DARPA project: XG. The purpose of which was to develop the opportunistic spectrum use capability described in the article. Early on, they saddled us with the requirement of implementing our technology as an SCA component, even in simulation. I glued some open source reference implementation together with our code, but we ended up hiring a consultant to write a whole SCA implementation in house. Which we then ended up throwing away because it was pointless to do that in a technology development platform.
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.
The project might have simply been the result of the "revolving door:" military people ensuring big profits for defense contractors who pay them high salaries as "advisors" later. Most of these projects that appear to be failures are actually successes of theft from taxpayer. Article on this below with examples:
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.
> I think credit should be given for the standards-based, open architecture approach.
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.
> "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."
I've never heard of CORBA but this is how some of the demodulation options on Agilent (Keysight) spectrum analyzers are implemented. Care was taken to ensure that new measurement schemes could be loaded in tens of milliseconds, which makes it appear instantaneous to a person.
I'm not an aviation enthusiast but I heard the F35 (Joint Strike Fighter) is suffering the same problems as this radio project, and that it will probably never be usable in war conditions.
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.
It's a plane that still can't fire its gun while in flight. I'd say the F-35 is a failure. For the cost of the program, we could have just given the Marines full scale aircraft carriers.
I question why they couldn't buy COTS P25 radios for tactical communication in a hardened form factor - I'm sure Motorola (or whomever else) would have gladly whipped up a extra durable version of an XTS3000 or XTS5000 - P25 by its nature supports pluggable encryption, so you can use just about anything with it.
For Lower than 30mhz - there are many COTS solutions using well proven technology, even supporting digital encrypted audio available.
What do you do when the enemy deploys a jammer? One part of the military's broader cognitive radio strategy is/was radios that could avoid jamming by hopping to different parts of the spectrum.
Building a simple durable FHSS system isn't hard either, you could then effectively send a P25 data stream on top of it - the radio access channel and data stream are reasonably divorced in P25. Even then, its hard to build an effective broadband jammer - you simple move to another part in a say ~120MHz band.
No doubt part of it was trying to "have it all". They wanted radios that could act as VSAT terminals (for field to base comms), data terminals (for which P25 is poorly suited) and for operational voice with fallback (UHF, VHF, HF).
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 main issue with the project is more the software outside the SDR software, they wanted these radios to do everything to the point of absurdity, just look at the list:
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.
Eh, it varies. The apollo program was pretty good. There was some stuff with networking that seemed to take off a few years ago. The human genome project was pretty spiffy.
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.
The interesting part about the Manhattan Project wasn't the funding of the R&D. It was the fact that we created an entire industrial infrastructure to pull it off.
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.
If the atomic bomb had been delayed even a few more months, the war would have been over.
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.
I would start with Rhodes' The Making of the Atomic Bomb (http://www.amazon.com/The-Making-Atomic-Bomb-Anniversary/dp/...). It has something for everyone, although many want to e.g. skip the initial 300 or so pages on the relevant developments in nuclear physics. And the author will sometimes go on excessively long digressions, like all about Swedish village where Lise Meitner and her nephew Otto Hahn did their Christmas vacation when she was the first to get the news from her colleague back in (Nazi) Germany that uranium fissioned.
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.
The key is to keep the project small. Once projects reach a certain size there's a whole ecosystem of bureaucratic parasites that latch on and begin feeding. "Purple suit" projects like this one are particularly prone to this problem since they involve three or four giant bureaucracies from the get-go.
As an alternate path, forget limiting project size, find harmless places to store the bureaucrats, and decide that success is worth whatever amount of money it takes.
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.
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.