The Strategy of Technology

tlb wrote:

Joat42 wrote:Not really. Considering that encoding algorithms today can manage a pretty good 2 way video communication at a couple of 100's of kilobit/s I would say that with 2000 years further refinement we would end up with a bandwidth less than 50 kbit/s.

Weird Harold wrote: Everyone keeps assuming that a functional FTL fire-control system requires two-way video. In HotQ, Honor did just fine with a RD that transmitted information in two and four character codes -- essentially early 20th century 300 bps TTY speeds. iow, teletype, not television.

Yes, but that was nothing compared to whatever Apollo does. HOTQ reported recon drones informing of enemy presence, not the fire control that you call it. Honor only needed enough information to interpose her ship between the enemy and the planet: just the message "here he is" from one of the array of drones was sufficient.

From Storm from the Shadows:

"Essentially, Admiral Gold Peak," he began, "Apollo is a new step in missile command and control. It's a logical extension of other things we've already been doing, which marries the existing Ghost Rider technology with the Keyhole platforms and the MDM by using the newest generation of grav-pulse transceivers. What it does is to establish near-real-time control linkages for MDMs at extended ranges. At three light-minutes, the command and control transmission delay for Apollo is only three seconds, one-way, and it's turned out that we've been able to provide significantly more bandwidth than we'd projected as little as seven months ago. In fact, we have enough that we can actually reprogram electronic warfare birds and input new attack profiles on the fly. In effect, we have a reactive EW and target selection capability, managed by the full capability of a ship of the wall's computational capacity, with a shorter control loop than the shipboard systems trying to defeat it."

That can be ready as saying that Apollo did not need the highest bandwidth, but used it to make the system much more capable.

runsforcelery wrote:It can be read that way because that's precisely what it's saying. The point she's making is that the bandwidth is now sufficient to reprogram, if needed, rather than simply controlling which of the preloaded programs is in use. It's also true that the control ship is in a position to combine the data feeds from all the Mark 23-Es in any salvo to create a much more detailed map of the battlefield than any single Echo can do on its own, which means that as long as they can maintain a real time telemetry link, the ship can provide better targeting information to the salvo as a whole. It's not so much that the computers aboard ship are enormously larger or more capable. In the early stages of the war they were more capable (a bunch) than those in the individual missiles as part of the whole "build 'em cheap" philosophy where SDMs were concerned. Now, it's far more a matter of the amount and the nature of the data available to all of them. Echoes can talk to their own missiles and to at least some of the other Echoes in their salvo (wedge interference restricts lateral datasharing), but they can't talk to all of them. Effectively, the control ship can, so it "sees" farther and more clearly than any individual Echo can.

Note that I'm not saying that the Echo is just as capable as an all up starship. I'm saying that within its designed role, it is extremely effective and that at extended ranges, off the apron strings of its launching ship, it's probably as capable of managing its missiles as, say, a OBS-era Manty DD.

Vince wrote:..snip..
It should be noted that the ability to "reprogram electronic warfare birds and input new attack profiles on the fly" absolutely requires lossless compression (where no data is discarded during compression), not lossy compression (where data is discarded prior to or during the compression processing and cannot be recovered during decompression).

Some background information on compressibility:

Text can be extremely compressible (the compression ratio goes up to ridiculous levels as the text you are compressing gets longer).

Video is highly compressible, but most video compression codecs used today achieve high compression ratios by using lossy compression.

Similarly, pictures are highly compressible, but most picture compression codecs used today achieve high compression ratios by using lossy compression.

Audio is compressible, but most of the audio compression codecs used today achieve high compression ratios by using lossy compression.

Binary program or data files cannot be compressed using lossy compression, and the best lossless compression software can only achieve a 2:1 compression ratio, at best (which requires a much longer time spent compressing the files).

Why is compression used? Because both data storage and transmission bandwidth are limited and the cost (can be money, materials, mass & volume, time, or all of the preceding) go up as more of each are needed.

tlb wrote:Yes, but that was nothing compared to whatever Apollo does. ...

Weird Harold wrote:You're missing the point that what Apollo, in its final form, can do is more than is necessary to implement FTL fire control. Data rates comparable to the RD in HotQ put more emphasis on the capability of the ACM's AI and on the prescience of the pre-programmed options.

Such a low bandwidth system would NOT be the equal of the Apollo + KHII system, but it would be far better than no FTL control at all.

tlb wrote:That can be read as saying that Apollo did not need the highest bandwidth, but used it to make the system much more capable.

Weird Harold wrote:This is what I've been trying to get people to realize: Apollo + KHII is far better than a first-iteration FTL fire control needs to be--in the same way a modern smart-phone is better than 1950's vintage car-phones or early 1980's vintage analog cell phones (Which weighed about ten pounds and were about the size of a five-pound bag of flour.)

What you want is not necessarily what you need. Since Manticore has the bandwidth needed for other applications -- ie FTL comm -- they'd be negligent not to put as much as they could into Apollo. But Apollo could be usefully built around first generation FTL RD speeds and codes. WWII television guidance systems aren't even close to modern optical/laser guidance systems, but they did work better than unguided ordinance, and ANY FTL guidance is better than no FTL guidance at all.

tlb wrote:Compare the line in bold in this statement with the one in bold from your more recent post. I agree with the current you and disagree with the past you; as I read these two statements, you also disagree with your former self. Yes, an FTL fire control system could be built with the first generation transmitter; but it would not be Apollo.

tlb wrote:One thing that I wonder is when the ship receives signals from several Apollo missiles at the same time, how can the mixed signals be separated into the threads. With radio you can assign different base frequencies. Do we know anything about that physical aspect of TFL communication? If each bit is just a pulse propagating on the hyperwave boundary, then how can you separate them by source?

Jonathan_S wrote:

tlb wrote:Compare the line in bold in this statement with the one in bold from your more recent post. I agree with the current you and disagree with the past you; as I read these two statements, you also disagree with your former self. Yes, an FTL fire control system could be built with the first generation transmitter; but it would not be Apollo.

I'd quibble slightly and say that a minimal FTL fire control could have been built around a transmitter with the bandwidth of the first generation transmitter.

The actual 1st gen transmitters in those recon drones was likely much too large and power hungry to squeeze into any practically sized missile (even once you dialed down the necessary transmit range).


Now one thing we've speculated about (or at least I have) but not seen is a missile or CM that can only receive FTL updates; but is unable to respond in kind. Theoretically that receiver should be smaller and more straightforward to design than the transmitter since pretty much any grav sensor can read FTL broadcasts.

The Honor of the Queen, Chapter 22 wrote:“It certainly is,” McKeon said feelingly. “The power requirement is enormous—our people had to develop an entire new generation of fusion plants to pull it off—and that’s only the first problem. Designing a pulse grav generator and packing it into the drone body came next. As you can probably imagine, it uses up a lot more mass than a drive unit, and it was a monster to engineer. And there are certain fundamental limitations on the system. Most importantly, it takes time for the generator to produce each pulse without burning itself out, which places an insurmountable limit on the data transmission speed. At present, we can only manage a pulse repetition rate of about nine-point-five seconds. Obviously, it’s going to take us a while to transmit any complex messages at that rate.”

The Honor of the Queen, Chapter 32 wrote:“Besides,” McKeon went on, “the pulses are directional, and the repetition rate is so slow it’s unlikely they’ll get more than a few pulses off any one RD before they’re out of the transmission path. Without more than that, even the best analysis won’t recognize what they’re actually hearing.”

tlb wrote:One thing that I wonder is when the ship receives signals from several Apollo missiles at the same time, how can the mixed signals be separated into the threads. With radio you can assign different base frequencies. Do we know anything about that physical aspect of TFL communication? If each bit is just a pulse propagating on the hyperwave boundary, then how can you separate them by source?

Joat42 wrote:It's a problem that has already been solved. Everyone transmits on the same frequency bands but multiplexed (it's actually a bit more convoluted than that but it's good enough description). It's how modern cell phones and digital TV transmissions works.

kzt wrote:Each device has a time slot and transmits during that slot. All the weapons listen to all all the commands and execute the ones that apply to them.

Same way it works on a wireless access point.