http://localhost:4503/content/mae/en/blogs/aerospace-defense-blog.html2014-04-25T08:02:20.976ZCan commercial software-defined radio replace JTRS? One reader points out why notJohn KellerAdobe CQGeraldThe General has a great idea. Offer the radios for free. Of course, they would require a service contract for, say, a minimum of ten years, or else you pay a hefty penalty, and you have to turn in your free radios and find a new one. Service fee would cover the costs of infrastructure, security, maintenance. Why buy an expensive radio when DOD will just give you JTRS radios free? Why, it could come in appropriate colors for each of the Services.<br>Even purple for Joint commands./content/mae/en/blogs/aerospace-defense-blog/2009/09/can-commercial-software-defined-radio-replace-jtrs-one-reader-points-out-why-not.html#comments-the-general-has-a-great-idea-offer-the-radios-for2011-12-08T22:32:27.618Z2011-12-08T22:32:27.618ZBobsommThe predecessor of JTRS was the Multi Mode-Multi Band Transceivers under development by CECOM at Ft. Monmouth NJ ending about 1994. The were 17 inches high in a RETMA Rack config and weighed about 105 pounds. I was instrumental in killing that program with cooperation from US Army TRADOC Battle Labs. CECOM wanted me fired but I had protection from a very great hero. CECOM then tried several other approaches that failed and finally got JTRS lined up and took over 12 years and hundreds of millions of dollars to get finalized and into initial production. In the meantime, commercial radios surpassed JTRS for most purposes and the unique features of JTRS could have been retrofitted but no, the Army had spent hundreds of millions and COULD NOT adjust for fear of looking like fools. About 1994 Andy Viterbi and I discussed a wider CDMA that should have resolved the issues. But no one would fund him for this military application. <br>Back in the 1980s CECOM realized that the Cell Phone approach was viable and instead of capitalizing on commercial approaches, developed a cell phone look alike system from scratch that could not follow a phone as it went from cell to cell. I was in SIGINT and saw flaws in CECOM systems but management would not let me address the issues because they followed the 11th commandment, ALWAYS PROTECT THE PROGRAM. The same scenario happened with the CECOM TACJAM-A. Most of these folks are retired now and thank heaven for that. The Army started FCS because they could not get the programs to function internally because of all of the bullshit. FCS was awarded and immediately the Army told the contractors what was needed. These are the same Army folks that could not get it done right in 30 years of trying in house. And so, the Army insisted that one of the requirements was to implement the JTRS instead of considering alternative approaches to supplant this JTRS approach with systems based on commercial items. <br>Off the Topic, we have items in the inventory that can do a lot of good against IEDs, short range missiles and intelligent mortars and find infiltration areas in most circumstances with remoted platforms. Also, we can put up high flying drones with bent pipe repeaters to give ubiquitous coverage for Comms and provide Bi-Static radar sources etc. I am impressed with the Air Force and Navy but the Army&#39;s agility to do the right thing has left me saddened and disappointed. <br>Good luck to our troops. Your training is the best and although we spend 30 times more than necessary to improve your tools, you are still the best armed troops in the world. HUA, Bob/content/mae/en/blogs/aerospace-defense-blog/2009/09/can-commercial-software-defined-radio-replace-jtrs-one-reader-points-out-why-not.html#comments-the-predecessor-of-jtrs-was-the-multi-mode-multi-b2011-12-08T22:31:41.612Z2011-12-08T22:31:41.612Z 500

Cannot serve request to /content/mae/en/blogs/aerospace-defense-blog/2009/09/can-commercial-software-defined-radio-replace-jtrs-one-reader-points-out-why-not/_jcr_content.feed on this server


ApacheSling/2.2 (Day-Servlet-Engine/4.1.32, Java HotSpot(TM) 64-Bit Server VM 1.6.0_34, Windows NT (unknown) 6.2 amd64)