Hacker News Reader

Comment by rayiner | Hacker News Reader

I worked on a DARPA contract on military radio technology. I’m not surprised at all why these things go over budget.

Imagine awarding a contract to build a self-driving car. Do you think that contract could be delivered on budget and on time? That’s like every military contract. They’re for bespoke stuff that doesn’t exist in the market. The military looks at what’s out there, adds a bunch of wishlist items, and then puts out a contract for that.

Think about how the private sector develops new products. They don’t award a fixed price contract. They throw a bunch of money at startups. Most of those efforts fail. What is the development cost of every successful product, accounting for those failures? In the military, all the hiccups and restarts and course corrections and dead ends that would kill a startup, and be written off by investors, instead get accounted for in the final cost of the contract.

View on HN

Unlike self-driving car, radio is a solved problem. Marine and commercial transceivers from Icom and Yaesu are cheap and rugged. Ham radio operators sometimes even use transceivers build from kits, e.g. Elecraft. Adding encryption should be trivial.

> Adding encryption should be trivial.

Encryption is by no means the only additional feature, at least frequency hopping is crucial to avoiding jamming. I can imagine there are other requirements I can't immediately think of.

Modern radios are software-defined, or at least controlled by a microprocessor, so frequency hopping or even spread spectrum shouldn't be much of a problem.

That's like me going up to a Netflix engineer and saying "why do you get paid so much? You've got the video already, just send it to the device; shouldn't be much of a problem."

Well, the difference would be that I actually built radios, and at least some of them worked. It's really that simple, even without SDR. You already have a microcontroller that reads rotary encoder attached to the tuning knob and changes voltage that goes to the VCO (or divisor in PLL). All you need is to control it from CSPRNG.

You will need to spend some effort on getting synchronization right, but it's a lot less complicated than, say, building a CRUD app.

What do you think these radios are doing? They aren't just voice radios, you do realize that right?

I was talking about the tactical radios discussed in the article (2km range).

If you want the radio to let you watch video feed from a drone above, show a map with locations of other soldiers, or update Facebook status via satellite link, that may be a bit more work.

Imagery and location data with others are among the feature set of JTRS. So yeah. A bit more work.

Congratulations, you made a few working radios with the most basic feature set.

Now make a radio that works in sub-zero and 100+ degree temperatures, survives water, dust, and firearm exposure, being dropped dozens of feet, is resistant to broad-spectrum jamming, can handle secure encrypted communications with a large set of ever-changing participants, has a range of dozens of miles and days of battery life, is of a size and weight portable enough to be carried by a soldier for hours or days alongside their normal gear, and which can be field-repaired by a soldier with a few days of training.

And those are just the high-level requirements. It's a lot more complicated than a CRUD app, which even a non-programmer can do in an hour.

What is firearm exposure? Working next to a firearm? Working after being shot with a firearm?

Any cell phone seems to do the former just fine, and I don't know of any radio, military or not, that can do the latter.

Link to CELab post on Mil Std 810 - Gunfire shock.https://celab.com/en/laboratory/environmental-tests/mil-std-...

The application portion has a nice explanation on the effects of gun fire on systems. Keep in mind that "gunfire" covers everything from a 9mm handgun to a 30mm Gatling gun.

Doing secure encryption of multicast radio is anything but trivial. You have packet loss, the group is constantly changing and for narrowband technologies you typicaly have small enough MTU that normal cryptographic constructions have larger per-packet overhead than what is left for the useful payload (this is also issue for many long-range IoT radio layers)

Partially solved. Most Ham operators don't have to deal with adversaries. These radios need to stand up to jamming and eavesdropping. They also need to handle a (fairly complex) protocol automatically and in a dynamic configuration. Imagine a cell network with no tower, each phone is capable of becoming the leader. And multiple networks can exist in the same physical space. All traffic has to be encrypted to protect against eavesdropping, and frequency hopping and other techniques have to be incorporated to become jamming resistant.

APRS and packet radio existed since the '90s. They handle routing and multiple participants, and are rather resilient to interference.

There is no encryption and no frequency hopping not because it's difficult to do, but because the goal is to be heard and understood by anyone who listens.

APRS does not have the reliability necessary for commercial use, let alone military use. Packet radio is pretty trivially jammed, handles routing poorly and interference almost not at all.

You can't say that "radio is a solved problem" without knowing the military's requirements for these radios.

For example, we were working on radios that could self-organize into networks on frequencies they picked dynamically and keep on the same frequencies while facing a changing RF environment because they were in a convoy driving through the desert with a high powered jammer randomly stomping on everything.

And these aren't fanciful requirements. You're in a country whose government you just toppled--you can't count on the civilian frequency allocations. The military really doesn't want to keep track of every squad's frequency assignment manually. The radios are always on the move, in often challenging terrain (mountains, etc.). The enemy has jammers and countermeasures. Even if not every radio needs every one of these capabilities, the military needs an overall communications architecture that accommodates all of these functions.

Guess how we know you've never designed or used a military-grade radio.

Try the following experiment. Take the best 2meter hand held radio to the Dayton hamvention. Pick a simples frequency, talk to your buddies on this frequency. You will hear crosstalk, imd, phantom signals, dropouts. Now take that situation and put it in a hostile, battle situation. Not at all solved.

Reply on news.ycombinator.com