Missile Telemetry

cthia wrote:If I may be granted a wish used in the form of a question, why is this method employed by keyhole? Is it to address an inherent limitation or to sharpen resolution, i.e., the rotation is to ensure the KH platforms closest to the action has control, or is it a matter of rotating links to avoid localization, or a combo of both? Of course it makes sense, in case a particular platform is destroyed.

RFC said the KH IIs alter which one is transmitting in order to avoid the enemy localizing and effectively targeting the platforms.

Though I do wonder if there's a limit to how many FTL control channels can be "talking" in a given area of space without interference. If a 6 ship squardon's fire is normally controlled (at any given instance) by 1 of their 12 KH IIs, how many more missiles can they control if they decide not to care about platform survivability and let as many broadcast as can without interference? I have to believe it's far less than 12x, but how much less?

cthia wrote:

Weird Harold wrote:Apollo and KHII actually depend on rotating links. Not the single control link hopping between several missiles, but several control links (KHIIs) swapping control of the same missiles.

Ah, that makes sense. Thanks for clearing up my confusion.

If I may be granted a wish used in the form of a question, why is this method employed by keyhole? Is it to address an inherent limitation or to sharpen resolution, i.e., the rotation is to ensure the KH platforms closest to the action has control, or is it a matter of rotating links to avoid localization, or a combo of both? Of course it makes sense, in case a particular platform is destroyed.

Not too sure on the specifics, but I think there's a quote somewhere which indicates avoidance of localisation. A single KH2 platform can control an entire squadron's salvo or something like that.

The distance between individual KH2 platforms of a formation in relation to a missile salvo is negligible. Most fleets stay within a 50,000km sphere in order to provide mutual coverage with PDLCs.

Such large redundancy makes sense as each keyhole is also a massive defensive asset - and squawking lots of FTL signals turns them into giant beacons on the gravitic sensors. Upon which attack missiles rely, at least for initial acquisition.

Eighth Fleet almost certainly used all of their keyholes at maximum when they fired upon Fifth Fleet during First Manticore. It did have the slight downside of consuming around 50% of their entire pod loadout in one shot.

cthia wrote:

Weird Harold wrote:Apollo and KHII actually depend on rotating links. Not the single control link hopping between several missiles, but several control links (KHIIs) swapping control of the same missiles.

Ah, that makes sense. Thanks for clearing up my confusion.

If I may be granted a wish used in the form of a question, why is this method employed by keyhole? Is it to address an inherent limitation or to sharpen resolution, i.e., the rotation is to ensure the KH platforms closest to the action has control, or is it a matter of rotating links to avoid localization, or a combo of both? Of course it makes sense, in case a particular platform is destroyed.

munroburton wrote:Not too sure on the specifics, but I think there's a quote somewhere which indicates avoidance of localisation. A single KH2 platform can control an entire squadron's salvo or something like that.

The distance between individual KH2 platforms of a formation in relation to a missile salvo is negligible. Most fleets stay within a 50,000km sphere in order to provide mutual coverage with PDLCs.

Such large redundancy makes sense as each keyhole is also a massive defensive asset - and squawking lots of FTL signals turns them into giant beacons on the gravitic sensors. Upon which attack missiles rely, at least for initial acquisition.

Eighth Fleet almost certainly used all of their keyholes at maximum when they fired upon Fifth Fleet during First Manticore. It did have the slight downside of consuming around 50% of their entire pod loadout in one shot.

Thanks.

I don't think I made my point quite clear with this one though. My apology if so...

i.e., the rotation is to ensure the KH platforms closest to the action has control,

Which I think prompted this?...

The distance between individual KH2 platforms of a formation in relation to a missile salvo is negligible. Most fleets stay within a 50,000km sphere in order to provide mutual coverage with PDLCs.

It's nice to know that. But I was referring to the fact that any given platform may be in a better position to call the ball from missile to target. For instance, one particular KH may be able to calculate vectors for an upcoming up the kilt shot that a KH out of position cannot. (A fact which I always thought accounted for those rare but spectacular golden BBs.) KH's obviously have to work on a line of sight function as far as efficient targeting. So, I thought it'd be conceivable that a particular KH would be better deployed and positioned to analyze attack vectors, sweet spots.

cthia wrote:I don't think I made my point quite clear with this one though. My apology if so...

i.e., the rotation is to ensure the KH platforms closest to the action has control,

Which I think prompted this?...

The distance between individual KH2 platforms of a formation in relation to a missile salvo is negligible. Most fleets stay within a 50,000km sphere in order to provide mutual coverage with PDLCs.

It's nice to know that. But I was referring to the fact that any given platform may be in a better position to call the ball from missile to target. For instance, one particular KH may be able to calculate vectors for an upcoming up the kilt shot that a KH out of position cannot. (A fact which I always thought accounted for those rare but spectacular golden BBs.) KH's obviously have to work on a line of sight function as far as efficient targeting. So, I thought it'd be conceivable that a particular KH would be better deployed and positioned to analyze attack vectors, sweet spots.

Keyhole IIs are well clear of the ship's wedge, but they still seem to be close enough to have neglicable lightspeed lag to their parent ship. Even if you called it a 1/4 lightsecond away that's 1/850th as far away as the missile's max powered range; which works out to a 0.066 degree different in angle.
That's just not a big enough baseline for 2 different Keyhole IIs in the same formation to have noticeably different views of the targets.

The infodump on Keyhole platform survivability makes it sound like the jumping is only to keep people from homing in on the keyhole IIs from their FTL signatures; and not to pick specific ones for some infinitesimally better angle or range.

Moreover, whenever more than one podlayer with the system are involved, they share command channels and the "active" platform jumps frequently and randomly. That is, Ship A may transmit the commands to all Apollo drones in one "active" window, while Ship H will transmit the next series of commands, Ship E transmits the third, etc.

cthia wrote:It's nice to know that. But I was referring to the fact that any given platform may be in a better position to call the ball from missile to target. For instance, one particular KH may be able to calculate vectors for an upcoming up the kilt shot that a KH out of position cannot. (A fact which I always thought accounted for those rare but spectacular golden BBs.) KH's obviously have to work on a line of sight function as far as efficient targeting. So, I thought it'd be conceivable that a particular KH would be better deployed and positioned to analyze attack vectors, sweet spots.

Keyhole platforms don't do these calculations - their motherships and the missiles themselves, during their final attack phase, handle that.

I imagine most of a Keyboard's onboard computing power would be allocated to its PDLC suite - they definitely don't want hundredth-second delays in targeting those.

Apollo's design is perplexing to me. Apollo can read the sensors on its clutch of missiles and get this info to the other control missiles that is trailing it. But it doesn't handle that directly. It does this by sending it round trip - back upstream to the KH (the signal inefficiently passing above the heads of the trailing control missiles) then it propogates back downstream to the control missiles (One which already knows - 'cause it was the leading one that sent it) then finally to the brood.

At this point, because the ship is too far out of position to make any calculations, it isn't needed. The control missiles are now making the calculations. The KH platform therefore, is no longer needed because the ship's info is outdated and the KH is only a final-leg relay at this point. Yet, why is the KH platform at this stage needed? It seems the lead "recon" clutch of missiles should be able to directly talk to the other control missiles now. They all have the same FTL send/receive capability. Disconnect the KH channel and the bandwidth/channel immediately becomes available to each control missile. What's the KH needed for at this point, it doesn't perform any calculations, I'm told?


Included simply as a convenient HUD.

wiki wrote:Apollo was an advanced missile system developed by the Star Kingdom of Manticore in the early 20th Century PD.
In this revolutionary system, the salvo from a single missile pod contained two types of missiles; eight of the missiles were standard Mark 23 three-stage MDMs with a variety of warheads and ECM. The second type was a single larger Mark 23-E missile fitted with a faster-than-light telemetry link instead of a warhead; this missile acted as a control node for the other eight missiles in the pod and allowed a Keyhole II equipped ship to provide effectively real-time control to the missiles across their range envelope, resulting in exceptional accuracy and ECM resistance. If the Apollo missile were destroyed, the rest of the cluster could continue on with whatever their last telemetry had given them.

The Apollo control missile could also analyze the readings from the sensors on its clutch of missiles, and report back via FTL to the Keyhole II platforms, essentially allowing it to act as a high-speed recon platform as well. A tactic developed by Battlecruiser Squadron 106 was to fire two extra pods, one ahead of the salvo, and one behind the salvo. The initial clutch would act as the recon platform, allowing them to both confirm their targets, and refine targeting data (since most ship-based sensors would be far out of range for precise targeting), while the follow-up clutch would be in position to observe the actions of the main salvo, allowing a ship commander real-time analysis of the enemy's battle-damage.

A system-defense Apollo variant, the Mark 23-F, was developed for the new four-stage Mark 25. (HH11, SI2)

There's a screw loose in my head somewhere - I just know it. Banging on the side of it doesn't seem to help. Pulling my hair isn't resetting the screw either.

cthia wrote:Apollo's design is perplexing to me. Apollo can read the sensors on its clutch of missiles and get this info to the other control missiles that is trailing it. But it doesn't handle that directly. It does this by sending it round trip - back upstream to the KH (the signal inefficiently passing above the heads of the trailing control missiles) then it propogates back downstream to the control missiles (One which already knows - 'cause it was the leading one that sent it) then finally to the brood.

At this point, because the ship is too far out of position to make any calculations, it isn't needed. The control missiles are now making the calculations. The KH platform therefore, is no longer needed because the ship's info is outdated and the KH is only a final-leg relay at this point. Yet, why is the KH platform at this stage needed? It seems the lead "recon" clutch of missiles should be able to directly talk to the other control missiles now. They all have the same FTL send/receive capability. Disconnect the KH channel and the bandwidth/channel immediately becomes available to each control missile. What's the KH needed for at this point, it doesn't perform any calculations, I'm told?

Hmm.
First the total round-trip FTL transmission lag from a ACM to the controlling Keyhole II and back to a ACM in the next salvo is only about 0.16 of a second; being 62 times faster than light is amazing. It appears from the few engagements we've seen that a keyhole II can only reach about 5 lightseconds - beyond that you need relays of some sort to talk to the missile.
So adding the ability to to peer-to-peer FTL doesn't save much time.

Second, the only part of ship's position that matters for calculations is whether or not it's still within range to talk to the ACM (Well, I guess theoretically a large wedge interposed near the missile or the keyhole II might mask the FTL signals...). The ship doesn't need the same line of sight to the target as the missiles have - because the Apollo control missile is sending all the consolidated sensor information to the ship for the massive tactical computers to crunch through. The ship gets their senor info < 0.08 of a second after they send it, sets its tactical computers to determine if there's any new info the missiles need to know from that, and tightbeams updates to any relivant ACMs (again reaching them in less that 0.08 of a second)

Third I tend to imagine that the sensors for the FTL tranceiver are bolted onto the back of the missile, where they've got a view back to the launch platform. So they'd be pointing entirely the wrong way to pulse grav ripples sideways or forewards.
The normal attack sensors on the missiles nose, might, be able to be used to receive FTL transmissions from ahead of it, but the grav pulse transmitter is fairly directional and you'd have to add extra (bulky) transmitters to broadcast in other directions.


So I don't see where it's a big limitation that the ACM has to talk to the ship. It adds very little lag disseminating the information to other ACMs and the ship has both more comprehensive information and more capable computers to evaluate that information.
More comprehensive because it's getting the sensor data from every missile it launched, and all its recon drones, plus whatever its onboard sensors can add.

cthia wrote:Apollo's design is perplexing to me. Apollo can read the sensors on its clutch of missiles and get this info to the other control missiles that is trailing it. But it doesn't handle that directly. It does this by sending it round trip - back upstream to the KH (the signal inefficiently passing above the heads of the trailing control missiles) then it propagates back downstream to the control missiles (One which already knows - 'cause it was the leading one that sent it) then finally to the brood.

At this point, because the ship is too far out of position to make any calculations, it isn't needed. The control missiles are now making the calculations. ...

You're cherry-picking a single simulation of a very long range "scout and intercept" tactic. That is NOT a normal use of Apollo; it is a fringe tactic that really falls under the "Stupid Apollo Tricks" heading.

Honor's long range bluff of Tourville in the BoMA is another "Stupid Apollo Trick" which she later admitted was as much as she could do at that range.

In normal use, the ACMs don't need to cross-talk because the time lag for communicating with the KHII array is no more than the time lag for SDMs and light-speed control links.

"Stupid Apollo Tricks" are uses that fall outside the design parameters and aren't useful often enough to add additional features (and mass) (and cost) to the system. Features that would only be used every thousand battles or so just aren't cost/mass effective.

Jonathan_S wrote:

cthia wrote:If I may be granted a wish used in the form of a question, why is this method employed by keyhole? Is it to address an inherent limitation or to sharpen resolution, i.e., the rotation is to ensure the KH platforms closest to the action has control, or is it a matter of rotating links to avoid localization, or a combo of both? Of course it makes sense, in case a particular platform is destroyed.

RFC said the KH IIs alter which one is transmitting in order to avoid the enemy localizing and effectively targeting the platforms.

Though I do wonder if there's a limit to how many FTL control channels can be "talking" in a given area of space without interference. If a 6 ship squardon's fire is normally controlled (at any given instance) by 1 of their 12 KH IIs, how many more missiles can they control if they decide not to care about platform survivability and let as many broadcast as can without interference? I have to believe it's far less than 12x, but how much less?

Jonathan, this post intrigues me greatly because of the keyword: interference.

I always thought that someone was going to counter Apollo by disrupting/interfering with its transmissions. Of course, I thought it'd be Foraker. Perhaps in the upcoming book with the MAlign.

cthia wrote:

cthia wrote:And in the midst of that chaos, you don't want to be cutting communications channels to rotate, even temporarily - which effectively that's what it amounts to - regardless of the gigasecond response time of the rotating connections/computers.

Weird Harold wrote:I think you mean Pico-second or nano-second. A billion seconds response time is pretty slow.

No. I meant gigasecond. It was just a poor editing error on too ambitious of a bloated post. My first drafts can be a doozie. Most of it never makes it to the cutting room floor.

My first draft was something like "No matter what insane response times Honorverse computers can attain, if cutting control links are employed, it may as well be rated in gigaseconds - as in the situation that a missile faced prior to reestablishing links couldn't change any more drastically in a gigasecond. Or something like that. I even had something about the execution time of the software routine, yatta yatta yatta, as I said, bloated post. Sometimes I need to send my posts to an editor before sending.

I've got gigsecs on the brain. There's a Rubik's cube contest presently going on in the family. Anything more than 45 seconds is too slow. Over a minute is a gigsec of laughs. (A kids play on words. Meaning how much you can giggle/sec in 31 years, at your opponent.)

It takes me, at least, 45 seconds. I'm the slowest in the pack. But their kindness allowed my record to be acceptable - they're so kind. And I can't beat my own time (set in junior high) often. Sometimes it takes me over a minute depending on how that damn cube is spinning. Sometimes it gets stuck. Kids are constantly pulling off sub 20's with a much faster (and complicated) algorithm in their heads. There's talk of a kid somewhere pulling in five secs???

The algorithm that I use requires you to be able to get at least one face beforehand. But after that, you can literally close your eyes or amaze the masses by solving the cube behind your back. At that point you are only counting the amount of turns on a particular axis - an algorithm. There are other, harder to memorize, algorithms that are much faster and don't require an initial face first.

Once you learn to solve a cube in this manner, it becomes a bit boring. But enough of how my wife and I are wasting our vacation.

cthia wrote:Is that true? My apology if I'm that far off. I thought that Apollo communicated with its brood of missiles simultaneously? The control missile maintains communication. And that the control missiles do not enjoy links to each other.

Weird Harold wrote:Apollo and KHII actually depend on rotating links. Not the single control link hopping between several missiles, but several control links (KHIIs) swapping control of the same missiles.

Ah, that makes sense. Thanks for clearing up my confusion.

If I may be granted a wish used in the form of a question, why is this method employed by keyhole? Is it to address an inherent limitation or to sharpen resolution, i.e., the rotation is to ensure the KH platforms closest to the action has control, or is it a matter of rotating links to avoid localization, or a combo of both? Of course it makes sense, in case a particular platform is destroyed.

Some people are mailing me enquiring about the 5 sec Rubik's cube time. Yes, that is true. One of my nieces supplied the link.

https://youtu.be/huh4GEPKYt4

I'd sure like to know that algorithm.

Of course he's using an algorithm, and you see evidence of it. He rolls the cube in his hand beforehand, before the clock starts. He's orienting his mind with a particular color on a particular axis on a particular side. One color will be better positioned in these type algorithms.

Actually, all colors will be better positioned somewhere. It's usually a matter of finding what side your favorite color is optimally placed. Mostly. Some people have favorite colors to work with. I like picking out an optimum yellow color. They're easier to track, visually. IMO.