Upcoming designs: regarding the Apollo ACM...

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)

Okay. An idea to increase the number of control links by a geometric factor, through propagation. Let's turn the Apollo system on its ear.

For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles). That is a limitation of 10 control missiles. But the 10 Apollo control missiles(that are receiving FTL input) are each in turn communicating with and controlling eight other dumb missiles.

But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board. At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer. This is where I perceive of an easily aquired measure of improvement. All launches could be staggered, whereas a single ACM, let's call it a PACM(propogation ACM) is launched very close to a our regular maximum control link salvo of 8 pods(than the normal 10). Yet this single ACM is the only ACM that communicates with the ship, and it, in turn, communicates to eight other ACMs (rather than eight dumb missiles) which then propogates the signal down to their eight dumb missiles. This increases the maximum number of control links by a factor of eight, simply by altering the paradigm. No additional tech is needed beyond reprogramming of the PACM, perhaps, and I say perhaps because an individual ACM wouldn't care if it was acting as an ACM or a PACM, therefore wouldn't care whether it was communicating with eight other ACMs or eight dumb missiles.

And real time control of all missiles would remain in effect, because the PACM(Propagation ACM) remains negligibly close to the other ACMs).

Effective control link multiplication via propagation.

A potential problem is the maximum communication range between the ACM and other dumb missiles, which would translate to ACM to ACM. If that is a weak point, then a signal boosting missile can be used in place of a an attack missile. Still a significant threat multiplier.

There may be inherent problems with this approach, but I think it sound enough to merit R&D.

Rebuttal?

Note:
This all hinges on my limited understanding of what's going on.

cthia 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)

Okay. An idea to increase the number of control links by a geometric factor, through propagation. Let's turn the Apollo system on its ear.

For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles). That is a limitation of 10 control missiles. But the 10 Apollo control missiles(that are receiving FTL input) are each in turn communicating with and controlling eight other dumb missiles.

But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board. At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer. This is where I perceive of an easily aquired measure of improvement. All launches could be staggered, whereas a single ACM, let's call it a PACM(propogation ACM) is launched very close to a our regular maximum control link salvo of 8 pods(than the normal 10). Yet this single ACM is the only ACM that communicates with the ship, and it, in turn, communicates to eight other ACMs (rather than eight dumb missiles) which then propogates the signal down to their eight dumb missiles. This increases the maximum number of control links by a factor of eight, simply by altering the paradigm. No additional tech is needed beyond reprogramming of the PACM, perhaps, and I say perhaps because an individual ACM wouldn't care if it was acting as an ACM or a PACM, therefore wouldn't care whether it was communicating with eight other ACMs or eight dumb missiles.

And real time control of all missiles would remain in effect, because the PACM(Propagation ACM) remains negligibly close to the other ACMs).

Effective control link multiplication via propagation.

A potential problem is the maximum communication range between the ACM and other dumb missiles, which would translate to ACM to ACM. If that is a weak point, then a signal boosting missile can be used in place of a an attack missile. Still a significant threat multiplier.

There may be inherent problems with this approach, but I think it sound enough to merit R&D.

Rebuttal?

Note:
This all hinges on my limited understanding of what's going on.

I think this kinda violates the Honorverse "Control Link" concept and David's anti-automation bent for the series (Because people are at the center of the story, not the systems).

However...

Any system designed today to launch a handful of missiles at the same target would probably include mesh networking concepts. The failed Netfires missile system encorporated that, and we'll see more of it in the future. Netfires wasn't supposed to mesh sensor data together, like a ACM swarm should, but individual missiles acted as data handling nodes, passing data packets through them to other missiles as needed and using any available network uplink to pass their data back.

(I even saw one discussion of using a timed Netfires barrage as a data transfer "conduit" for other network devices cut off from a network, so there was always a missile in transfer range for the 2 minutes or so before the Netfires pallet ran out.)

It's just another example of how reality has slid past sci fi.

KH2 has demonstrated the ability to control 200 pods per ship in a single mass salvo.

cthia wrote:Okay. An idea to increase the number of control links by a geometric factor, through propagation. Let's turn the Apollo system on its ear.

For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles). That is a limitation of 10 control missiles. But the 10 Apollo control missiles(that are receiving FTL input) are each in turn communicating with and controlling eight other dumb missiles.

But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board. At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer. This is where I perceive of an easily aquired measure of improvement. All launches could be staggered, whereas a single ACM, let's call it a PACM(propogation ACM) is launched very close to a our regular maximum control link salvo of 8 pods(than the normal 10). Yet this single ACM is the only ACM that communicates with the ship, and it, in turn, communicates to eight other ACMs (rather than eight dumb missiles) which then propogates the signal down to their eight dumb missiles. This increases the maximum number of control links by a factor of eight, simply by altering the paradigm. No additional tech is needed beyond reprogramming of the PACM, perhaps, and I say perhaps because an individual ACM wouldn't care if it was acting as an ACM or a PACM, therefore wouldn't care whether it was communicating with eight other ACMs or eight dumb missiles.

And real time control of all missiles would remain in effect, because the PACM(Propagation ACM) remains negligibly close to the other ACMs).

Effective control link multiplication via propagation.

A potential problem is the maximum communication range between the ACM and other dumb missiles, which would translate to ACM to ACM. If that is a weak point, then a signal boosting missile can be used in place of a an attack missile. Still a significant threat multiplier.

There may be inherent problems with this approach, but I think it sound enough to merit R&D.

Rebuttal?

Note:
This all hinges on my limited understanding of what's going on.

I remember reading about the "recon drone" use of the ACM and I believe it was only done in simulation by Admiral Henke's officers as they traveled to Spindle.

IIRC when ACM's were first introduced one of the concerns was over how the effective the "dumb" missiles would be if the ACM was destroyed. But it turned out that this ended up not being a big concern. I believe that's because the missile pod group would have to be in counter missile range before the ACM cold be destroyed and by that time the dumb missiles could have already received their final attack commands. This situation would also be helped by the fact that the ACM actually follows/trails it's "dumb" missiles to protect it from detection and destruction before it's job is done.

In your idea the "PACM" would lead all the other missiles that it was controlling and being out in front would allow it to be detected and destroyed much more easily. And say that it did talk to 8 other ACM's which each in tern controlled 8 "dumb" missiles I would now loose control of 64 missiles and most likely before they had received their final attack commands. Which in my mind would greatly reduce their effectiveness in attack.

Also, I would want to keep the granularity of control to smaller groups of missiles for the reason of dividing up which or how many targets were engaged with those 64 missiles. I don't necessarily want to send all 64 after a single ship. And if I sent those 64 missiles after several ships and your "PACM" control missile is reacting to the ECM of one particular ship of which it is trying to attack that one ship may not be using the same exact mode of ECM, or ship roll position as the other ships. This could again have an impact on how effectively the missiles will attack those other ships.

I suppose you could claim that the other missile pod groups could each be controlled separately but just through the link of your one "PACM". But I am not sure that would work real well either, just how much communication bandwidth does one FTL communication link have? In the current configuration of 8 "dumb" missiles to one ACM there is enough bandwidth for those 8 "dumb" missiles to send back their sensor data to the ship. Can that same FTL link carry 8 times that amount of data? Currently an ACM had one light speed link that talks to it's 8 "dumb" missiles and one FTL link that talks to the controlling ship. On your "PACM" would you have 2 FTL links, one talking to the ship and another talking to the 8 other ACM's or would you split the use of the one FTL link so it talked to both the other ACM's and the ship. This would double the bandwidth required to 16 times the original FTL link.

Any way you slice it I think your PACM would require a massive alteration to the current very successful configuration with out much improvement.

But I do like the idea of having an "Recon Missile" (RM) that could be launched by itself with out any other missiles going with it. It could be fired in between missile salvos to first get a close up recon view of the enemy's ships and then to assess the damage done before committing the next salvo of missiles to particular targets. I could also then fire just the RM as a high speed recon drone with out the expense of sending 8 missiles with it. If I came into a system and really needed to rapidly know what was out there I could launch several RM's in to a volume of space and get that information. The RM could quickly burn through 2 of it's 3 engine stages and then coast, dark and undetectable, and very fast!. It wold be a neat trick, but then again, ghost rider drones are fairly fast themselves, how often would you need to recon a volume of space at the speed of an RM missile? I suppose it's possible that I would want to recon and area with out spending time to recover the ghost rider drones... The RM's would just destroy themselves at the end of their run.

StealthSeeker wrote:

cthia wrote:
Okay. An idea to increase the number of control links by a geometric factor, through propagation. Let's turn the Apollo system on its ear.

For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles). That is a limitation of 10 control missiles. But the 10 Apollo control missiles(that are receiving FTL input) are each in turn communicating with and controlling eight other dumb missiles.

But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board. At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer. This is where I perceive of an easily aquired measure of improvement. All launches could be staggered, whereas a single ACM, let's call it a PACM(propogation ACM) is launched very close to a our regular maximum control link salvo of 8 pods(than the normal 10). Yet this single ACM is the only ACM that communicates with the ship, and it, in turn, communicates to eight other ACMs (rather than eight dumb missiles) which then propogates the signal down to their eight dumb missiles. This increases the maximum number of control links by a factor of eight, simply by altering the paradigm. No additional tech is needed beyond reprogramming of the PACM, perhaps, and I say perhaps because an individual ACM wouldn't care if it was acting as an ACM or a PACM, therefore wouldn't care whether it was communicating with eight other ACMs or eight dumb missiles.

And real time control of all missiles would remain in effect, because the PACM(Propagation ACM) remains negligibly close to the other ACMs).

Effective control link multiplication via propagation.

A potential problem is the maximum communication range between the ACM and other dumb missiles, which would translate to ACM to ACM. If that is a weak point, then a signal boosting missile can be used in place of a an attack missile. Still a significant threat multiplier.

There may be inherent problems with this approach, but I think it sound enough to merit R&D.

Rebuttal?

Note:
This all hinges on my limited understanding of what's going on.

I remember reading about the "recon drone" use of the ACM and I believe it was only done in simulation by Admiral Henke's officers as they traveled to Spindle.

IIRC when ACM's were first introduced one of the concerns was over how the effective the "dumb" missiles would be if the ACM was destroyed. But it turned out that this ended up not being a big concern. I believe that's because the missile pod group would have to be in counter missile range before the ACM cold be destroyed and by that time the dumb missiles could have already received their final attack commands. This situation would also be helped by the fact that the ACM actually follows/trails it's "dumb" missiles to protect it from detection and destruction before it's job is done.

In your idea the "PACM" would lead all the other missiles that it was controlling and being out in front would allow it to be detected and destroyed much more easily. And say that it did talk to 8 other ACM's which each in tern controlled 8 "dumb" missiles I would now loose control of 64 missiles and most likely before they had received their final attack commands. Which in my mind would greatly reduce their effectiveness in attack.

Also, I would want to keep the granularity of control to smaller groups of missiles for the reason of dividing up which or how many targets were engaged with those 64 missiles. I don't necessarily want to send all 64 after a single ship. And if I sent those 64 missiles after several ships and your "PACM" control missile is reacting to the ECM of one particular ship of which it is trying to attack that one ship may not be using the same exact mode of ECM, or ship roll position as the other ships. This could again have an impact on how effectively the missiles will attack those other ships.

I suppose you could claim that the other missile pod groups could each be controlled separately but just through the link of your one "PACM". But I am not sure that would work real well either, just how much communication bandwidth does one FTL communication link have? In the current configuration of 8 "dumb" missiles to one ACM there is enough bandwidth for those 8 "dumb" missiles to send back their sensor data to the ship. Can that same FTL link carry 8 times that amount of data? Currently an ACM had one light speed link that talks to it's 8 "dumb" missiles and one FTL link that talks to the controlling ship. On your "PACM" would you have 2 FTL links, one talking to the ship and another talking to the 8 other ACM's or would you split the use of the one FTL link so it talked to both the other ACM's and the ship. This would double the bandwidth required to 16 times the original FTL link.

Any way you slice it I think your PACM would require a massive alteration to the current very successful configuration with out much improvement.

But I do like the idea of having an "Recon Missile" (RM) that could be launched by itself with out any other missiles going with it. It could be fired in between missile salvos to first get a close up recon view of the enemy's ships and then to assess the damage done before committing the next salvo of missiles to particular targets. I could also then fire just the RM as a high speed recon drone with out the expense of sending 8 missiles with it. If I came into a system and really needed to rapidly know what was out there I could launch several RM's in to a volume of space and get that information. The RM could quickly burn through 2 of it's 3 engine stages and then coast, dark and undetectable, and very fast!. It wold be a neat trick, but then again, ghost rider drones are fairly fast themselves, how often would you need to recon a volume of space at the speed of an RM missile? I suppose it's possible that I would want to recon and area with out spending time to recover the ghost rider drones... The RM's would just destroy themselves at the end of their run.

The PACM would not lead, but follow. The ACM follows the clump. The PACM follows the ACM. The other problems will have to be worked out by the S&S team. I'm just a tinkerer with a suggestion. But I'll chew on it.

There could be a "normal" salvo, followed by a PACM salvo, after refined targeting data.

All missiles do not have to be spent on a single target.

cthia wrote:The PACM would not lead, but follow. The ACM follows the clump. The PACM follows the ACM. The other problems will have to be worked out by the S&S team. I'm just a tinkerer with a suggestion. But I'll chew on it.

There could be a "normal" salvo, followed by a PACM salvo, after refined targeting data.

All missiles do not have to be spent on a single target.

Perhaps I, at least in part, misunderstood what you are proposing.

IIRC in the simulation that was run they launched a single pod of 8 "dumb" missiles and one ACM. That missile pod group burned through it's first 2 engine stages and then coasted on a ballistic course for a period of time. Then that missile pod group ignited it's 3rd stage as it approached the target and as it did so the 8 "dumb" missiles collected target data that was sent back to the ship. This data was then used by the ship to update the full salvo of missiles that followed 30 seconds behind that first single pod launch.

Then several seconds behind that full salvo of missiles was another single pod launch that was used to access the damage done so that the full salvo of missiles that followed 30 seconds behind it could get appropriate target update information. No use wasting missiles on a ship that the first salvo already destroyed. They would continue this alternate launch of single pod then full salvo through out the attack.

It was my understanding that, as you referenced this simulation, you wanted a single missile that would take the place of the single pod launch missiles. That was what I was proposing with my concept of the Recon Missile (RM) which would have it's own sensors, rather than relying on the 8 "dumb" missiles, and it would coast on a ballistic path as it passes though the enemy ship formation and collects data to be sent back to the ship. That data would then be given to the full missile salvo that followed behind.

But what you apparently are wanting is a relay/signal repeater missile, more or less a small adaptation of a Keyhole-Two platform with 8 links to 8 ACM missiles. This "Keyhole-missile" would then connect to a single missile control link on the launching ship. Thereby giving a single control link on the ship control of 64 missiles rather than just 8 missiles. Thus giving a ship the ability to launch and control, yet again, 8 times more missiles than it can now. So if this would work, and as someone else pointed out, there are 200 control links on a (SD)P, then one ship could control twelve thousand eight hundred missiles. Hmmm... a bit of an overkill isn't it? And you would still have the missile control link bandwidth problem to deal with, and the computing power. But wow, 12.8K missiles controlled by a single ship. You might be able to empty a whole (SD)P in a couple of salvos. Overkill

StealthSeeker wrote:But I do like the idea of having an "Recon Missile" (RM) that could be launched by itself with out any other missiles going with it. It could be fired in between missile salvos to first get a close up recon view of the enemy's ships and then to assess the damage done before committing the next salvo of missiles to particular targets.

A recon drone down range should be able to provide this more or less continuously, insofar as it can remain undetected and maintain a similar vector to the target.

Granted, when you don't have buckets of RD's and you can't count on those assumptions, the much small, far more expendable RM would be nice.

I could also then fire just the RM as a high speed recon drone with out the expense of sending 8 missiles with it. If I came into a system and really needed to rapidly know what was out there I could launch several RM's in to a volume of space and get that information. The RM could quickly burn through 2 of it's 3 engine stages and then coast, dark and undetectable, and very fast!. It wold be a neat trick, but then again, ghost rider drones are fairly fast themselves, how often would you need to recon a volume of space at the speed of an RM missile? I suppose it's possible that I would want to recon and area with out spending time to recover the ghost rider drones... The RM's would just destroy themselves at the end of their run.

Single drive missiles would do for a lot of RM usage, apart from tracking targets you're engaging in MDM duels. That may be very handy for older ships still doing recon/picket duty with single drive missile tubes and boat bays that won't hold many RD's.

I don't think it's something with so much use that it would drive RD's out of business, but as a niche occupant of a small portion of a ship's missile magazines (or boat bay, for that matter), it's likely as useful as old nuclear warhead missiles.

cthia wrote:Okay. An idea to increase the number of control links by a geometric factor, through propagation. Let's turn the Apollo system on its ear.

For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles). That is a limitation of 10 control missiles. But the 10 Apollo control missiles(that are receiving FTL input) are each in turn communicating with and controlling eight other dumb missiles.

But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board. At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer.

Let's stop this here--you need to completely rewrite your proposal because you are mistaken. The text says that the ACMs do communicate with each other. Each ACM collects observation data from the attack missiles it controls, and shares that data with the controlling ship and with all the other ACMs nearby. Every ACM gets all the data from all the missiles, which vastly enhances the targeting solution of each ACM.

Your proposal is misguided. What you are suggesting is to have clumps of 73 missiles rather than clumps of 9 missiles. All those missiles would stay clumped together, all the way to the target. So all 64 attack missiles would attack a single ship from a single vector, instead of from 8 vectors. The defensive options would be greatly simplified. Rather than needing to defend against 8 different vectors, it only needs to defend against 1 vector.

cthia wrote:For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles).

Flawed premise #1: Each keyhole II equipped ship can control 200 Apollo pods. That's about 80 times as much capability as you posit.

cthia wrote:But after the ACM receives FTL updated info from a Keyhole II ship, it is relegated to a dumb conversation across the board.

Flawed premise #2: The ACM maintains a constant, two-way, communications with the controlling ship and with its brood of eight missiles.

cthia wrote:At no point does an ACM get to communicate with another ACM. It never gets a chance to communicate with a peer.

Possible flawed premise: IIRC, the ACMs also "crosstalk" with each other to share data and avoid conflicts.

cthia wrote:This is where I perceive of an easily aquired measure of improvement. All launches could be staggered, whereas a single ACM, let's call it a PACM(propogation ACM) is launched very close to a our regular maximum control link salvo of 8 pods(than the normal 10). Yet this single ACM is the only ACM that communicates with the ship, ...

In theory, your suggestion could work, but is it really necessary? Does it add tactical flexibility or lock an entire PACM's brood into a single target?

cthia wrote:No additional tech is needed ...

No additional tech is needed, but your proposal burns-up eight ACMs with FTL capability where a simpler (cheaper) pre-processing node would suffice.

cthia wrote:Rebuttal?

This sounds like another "solution in search of a problem."

SWM wrote:Let's stop this here--you need to

Your proposal is misguided. What you are suggesting is to have clumps of 73 missiles rather than clumps of 9 missiles. All those missiles would stay clumped together, all the way to the target. So all 64 attack missiles would attack a single ship from a single vector, instead of from 8 vectors. The defensive options would be greatly simplified. Rather than needing to defend against 8 different vectors, it only needs to defend against 1 vector.

Epic logic fail.

Defensive options are simplified, because they are curtailed!

Attacking from one vector is optimal.
Limits defender ability to defend itself
--> Fewer Broadside control links in use
~ Therefore fewer CM's attacking your missiles.
--> Fewer PDLC defending the ship.
= concentrated damage able to penetrate further and cause truly crippling damage instead of only surface damage.

Weird Harold wrote:

cthia wrote:For sake of argument, let's say that our Keyhole II equipped ship only has control links to manage 10 pods of launched missiles. (10x9 = 90 missiles).

Flawed premise #1: Each keyhole II equipped ship can control 200 Apollo pods. That's about 80 times as much capability as you posit.

We have no idea how many pods a Keyhole can control. We have a lower limit set by BOMA1, but otherwise we have no upper limit.