Drone damage amplifier (lore)

The Drone Damage Amplifier is a passive low slot module that improves the damage output of combat drones.

A fusion of existing drone enhancement technology with structural elements common to Sleeper weapon systems, the module projects a multi-node quantum entanglement onto a drone communications net. This lossless connection bridges the drones' onboard sensor data processors and turret controls with the ship's weapons control core without consuming any drone control bandwidth or ship CPU (beyond the base requirements of the module). Bridged processors are faster and more powerful, and as such, able to make target trajectory predictions in near-real time, which results in a higher damage output rate.

History

Origin

The Drone Damage Amplifier began as an evolutionary synthesis of some of the components CreoDron and its research collaborators have designed to improve drone control, speed, optimal range, weapon tracking, and sentry drone damage. While most of these components (the sentry damage enhancement being the most notable exception) existed in prototype or conventional form prior to the capsule, none of them were compatible with capsule-equipped ships until YC107.

The oldest of these components is the Drone Link Augmentor, a module that extends the signal range of a ship's drone net. This extender, usable with combat, industrial, sentry or utility drones alike, provides no other advantages.

CreoDron's next enhancement component, the Drone Navigation Computer, was the first step taken toward improving drone performance by shifting computational load from individual drones to ship resources. A Drone Navigation Computer sits in a ship's drone net and provides high-speed back end propulsion subroutine processing to all active drones, making for more efficient navigation. Drones networked with a Drone Navigation Computer experience an improvement in their microwarpdrive thrust, which for most translates to higher velocity. Although the Drone Navigation Computer can increase drone damage output somewhat, it is solely an incidental benefit of drones' being able to attain and better maintain optimal range to a target. The module itself neither expands drone optimal range nor increases drone turret tracking speed.

Interested in developing something that could, CreoDron approached Core Complexion, developer of the Tracking Computer. Together, CreoDron and Core Complexion created the Omnidirectional Tracking Link (and provided the Federation Navy, who helped arrange the initial discussions, with an advanced version of the module). Like the Drone Navigation Computer, an Omnidirectional Tracking Link acts as a subroutine processor; it shifts some computational burden from a drone's turret control system. It also increases the proportion of drone net bandwidth allocated to the ship weapons control core/drone turret control interface, in a similar manner as a Tracking Computer -- which also crunches turret control subroutines -- boosts the link between weapons control and ship turrets.

Maturation

Although the Omnidirectional Tracking Link can increase drone damage output, it is only a fortunate side effect of improved drone optimal range and turret tracking. The first intentional damage-related drone improvement came about courtesy of shortcuts taken in order to work around CONCORD regulations.

Included with the drone improvement modules CreoDron released to capsule pilots in YC107 was a new class of combat drone: the Sentry, a stationary high-damage long range drone. CreoDron’s early discussions with CONCORD representatives suggested that if they were to develop the Sentry-class independently or solely with a Federation-based research partner, the drone would more likely be considered a “completed technology” rather than just a smaller, self-anchoring version of fixed stargate and station guns.

By CONCORD regulation, completed technologies developed by any one Yulai Accords signatory needed to be shared with the others. CreoDron did not want the Sentry's release tied up by multiple international auctions for development rights (and as speculated, it was not comfortable with the idea that any of those auctions could be won by undesirable firms). To avoid this situation, it found research partners in each of the signatory nations and with them developed national versions of Sentry-class drone.

The CreoDron-Core Complexion "Bouncer" sentry drone was co-developed by some of the same team members who designed the Omnidirectional Tracking Link, researchers who were already comfortable working with each other and mutually eager to push the edges of ship-drone interface technology. Their collaboration resulted in a prototype sentry drone that had significantly higher damage than other national versions.

CreoDron executives admired the innovative circuitry subschemas that made the higher damage output possible, but faced a release deadline that would not permit them to have the innovations incorporated throughout the drone class. Believing that an effectiveness imbalance between drone versions would jeopardize CONCORD acceptance of the drone, they chose to scrap the subschemas from the Bouncer that gave it an advantage in damage output.

This innovation did not go to waste, however. CreoDron conglomerated the subschemas into a ship hack ("rig") that enhanced the damage output of all sentry drones, regardless of version. In YC108, it made the general schematics for these and other drone-related ship hacks available to the market.

Created based on the logic that stationary drones do not require much net bandwidth devoted to navigational instructions, the Sentry Damage Augmentor rig forces a ship’s drone net to release the majority of a sentry drone’s net bandwidth allocation for navigation. It then hijacks that freed bandwidth to forge a direct connection between a sentry drone’s sensors and turret control and the ship’s weapon system.

Unlike earlier drone enhancement modules that included separate load balancing subroutine processors, the Sentry Damage Augmentor shifts much of a sentry drone's computational burden onto a ship’s weapons system core, gaining faster and more accurate target tracking (and the accompanying improved damage output) for the drones at the expense of ship CPU.

Evolution

For some time, CreoDron combat drone efficiency researchers struggled to create a version of the Sentry Damage Augmentor rig that could be used with all combat drones without requiring any sacrifice of navigational functionality. They eventually abandoned this effort in favor of a module-based approach.

Their first step in this direction was revisiting the Drone Navigation Computer in the belief that they could modify the module to provide processing support for drone turret controls as well as navigation. This premise showed some early promise: drones networked with the modified module not only maneuvered with the same degree of efficiency as they did connected with a regular Drone Navigation Computer but also more effectively calculated and executed auto-targeting solutions.

However, testing soon revealed that the dual-function module was not without problems. Its presence in the drone network caused frequent communications interrupts that prevented drones from responding to pilot commands. Networked drones ignored a pilot's target selection and continued to cycle through their own auto-targeting solutions, completed their target list and simply drifted in space, or, as reputedly happened in one testing session, selected their pilot's ship as a target and attacked it.

The project team initially believed that the communications failures were a result of the module's increased computational burden. They attempted to salvage the project by gutting the modified module's navigation-related functions.

The new "Drone Damage Computer" worked flawlessly in simulation, but the drone network communication delays seen with its first incarnation returned during live testing. Researchers ultimately isolated the problem to co-channel interference inside the drones' native communications clusters; the drone-Drone Damage Computer dialog was at times crowding out other network traffic. Placing an unmodified Drone Navigation Computer in the same drone network muted the interference, but at the cost of sharply reduced effectiveness for both modules.

Since this module pair provided very little benefit for its cost in ship resources, the research team decided to try another tactic. It was impractical to redesign the communications cluster for every CreoDron drone model (and expensive to recall all of the ones already on the market), but it seemed reasonable to try to harden the Drone Damage Computer's network channel so that its chatter did not bleed into others.

For some help with this task, CreoDron called upon one of their other research collaborators: Hyasyoda.

Before the Caldari-Gallente War, Hyasyoda was one of the Federation's leading developers of agricultural mechanization technology. Hyasyoda autocombines, robotillers and sower-weeder crawlers, originally designed for the rugged terrain and harsh climate of Caldari Prime, were the mechanical workhorses that helped support both Gallente and Caldari colonization efforts.

Hyasyoda is less well known for its work in wireless communications. One of the keys to its success in automating agricultural machinery was a once-proprietary resilient communications network that functioned in the most adverse conditions. Wartime researchers working for the Caldari Navy used (or stole: Hyasyoda has been historically reticent on the subject) this technology as the backbone of the first Ballistic Control System, a computer system that enhances missile damage in a manner similar to what CreoDron was attempting to do for combat drones.

The CreoDron-Hyasyoda team's first prototype was a straightforward hybrid of the Drone Damage Computer and a Ballistic Control System stripped of all missile-related hardcode. The hybrid performed exceptionally well in both simulated and live testing, although in the latter, it demonstrated that it could sustain communications (and provide damage enhancement) with only one combat drone in the network at a time. This focus shifted from drone to drone based on time of last drone action.

Removing all other drone-related modules from the network did nothing to improve or degrade performance: the prototype simply continued to boost a single drone at a time. The team isolated the boost focus impedance to a network quality assurance traffic gate inside the hybrid module. It did not take long to determine that the gate was performing as designed, and the real culprit was the drone network's own data flow constraints.

In order to work around this problem, the team revisited the Drone Link Augmentor, believing that they could modify the simple signal range extender to permit more robust data flow between components linked to the drone net.

They were successful in doing so, but the success came at the cost of drastically increasing the CPU needs of the adapted Drone Link Augmentor while negating its range boost benefit: in order to maintain data integrity and transmission speed, the size of the net needed to shrink. Redesigning the Drone Link Augmentor to draw upon more ship power resources did mitigate the range shrink, but with another undesirable effect -- the powergrid required for a single modified module to sustain a net range comparable to that afforded by an unmodified one was unworkable for smaller vessels.

Before CreoDron's first encounter with Sleeper technology, the researchers were experimenting with pairs of modified and unmodified Drone Link Augmentors, attempting to use the latter as an amplifier for the enhanced drone net created by the former, and required by the hybrid Drone Damage Computer/Ballistic Control System.

Revolution

Although the corporation has not made public the minutiae of its research into Sleeper technology, anecdotal evidence suggests CreoDron scans and loads all of the artifacts it has collected from Anoikis or purchased from the capsule pilot market into a virtual test bed. This test bed is available to corporate scientists and engineers working in all disciplines. Many routinely pursue it in search of elements that can inform or be integrated with their current research (particularly after the test bed is updated with novel or relatively whole examples of Sleeper technology).

Shortly before the anniversary of the Seyllin Incident, an Aydoteaux-based wormhole exploration crew was fortunate enough to retrieve and succeed in cracking open the metallofullerene container that held an extremely rare set of intact Sleeper weapon subroutines.

The resulting scans were swarmed by CreoDron researchers from all disciplines. During the ensuing corporate-wide discussion, some observed that the calibration and tracking devices inside the containerized Sleeper devices did not have any obvious wired or wireless network connectors. Speculation suggested that signal may have been conducted between the devices inside the container via surface-to-surface contact, and possibly to the container itself in the same manner, but it was unknown how the devices may have communicated with anything outside the container, or indeed if they had passed anything between themselves and the container but an electrical or acoustic signal.

Spurred by emerging external hypotheses that the fullerene alloys of Sleeper technology were possibly conceived more for computing purposes than structural engineering, some within CreoDron began to speculate that the metallofullerene container which stored the weapon subroutine devices might have acted like a novel type of fluid router, possibly one dedicated to internal ship communications.

While the Aydoteaux exploration crew had managed to retrieve the weapon subroutines, they were forced to flee the wormhole before they had been unable to salvage more of the subroutines' associated Sleeper structure. Not having the other potential member of the router pair complicated testing of the container-as-fluid router hypothesis. It was ultimately decided to take two fragments of the collected container, put them in separate labs and apply an electrical signal to one to see if the other fragment detected the signal.

The experiment was more successful than anticipated. Not only did the other fragment detect the signal, but also so did the remaining pieces of container and every electronic device between the three pieces of metallofullerene.

[All future experiments were confined to remotely piloted test ships in remote space so as to minimize potential damage to laboratory equipment, infrastructure and personnel.]

Some of the CreoDron scientists participating in the Sleeper weapons systems communications discussion were also members of the CreoDron-Hyasyoda combat drone damage research team. Reasoning that a fluid-router like entanglement might reduce the power draw required by their Drone Damage Computer/Ballistic Control System hybrid and its paired modified/unmodified Drone Link Augmentors, they severed the wired connections between all of them, bolted fragments of the metallofullerene sample onto each, then put them all online.

The researchers hoped that the configuration would simply pass drone turret control data through the data booster and range booster on a quantum bridge, eliminating the powergrid resources that were required for conventional module-to-module communication.

Instead, once the hybrid Drone Damage Computer/Ballistic Control System was online, it seemed to ignore both of the Drone Link Augmentors. No traffic from or to it hit either member of the pair, but all of the drones within the network continued to benefit from a boost to their damage output.

The team shut the data booster down, killing with that the test platform's excessive consumption of ship powergrid and CPU. The range of the network also returned to that achievable by a normal drone net equipped with an unmodified Drone Link Augmentor (offlining that module saw the net range return to the test ship's base value).

Further investigation revealed the source of the sustained damage output: a projected quantum entanglement between the drones' onboard sensor data processors and the ship's weapons control core. This lossless connection required no drone net bandwidth -- though shutting off the drone net or offlining the hybrid Drone Damage Computer/Ballistic Control System did terminate the connection -- and consumed very little ship CPU. It was soon proved out that swapping in any fragment of Sleeper metallofullerene derived from a weapons system caused the prototype to perform in the same manner.

The module that ultimately resulted from these experiments was called the Drone Damage Amplifier. It was released to the capsule pilot market in 05-114, through a distribution deal with FedMart.

Uses

As the communications mechanism incorporated in the Drone Damage Amplifier is still not fully understood, it has yet to see considerable use in other applications.

Manufacturers of personal security drones are reportedly petitioning CreoDron, Core Complexion, and Hyasyoda (and also possibly Viziam) to produce or license a miniaturized version of the Drone Damage Amplifier. While one tailored to operator-controlled miniature drones seems likely, it is doubtful that one may be produced for automated or "smart" ones, from concern that exposing near-AI to Sleeper technology might have detrimental effects.

See Also

• Ship technology
• Drones
• Fluid Routers
• FTL Communications
• Seyllin
• Anoikis (Chronicle)
• Old Man Star (Chronicle)
• The Vitrauze Project (Chronicle)
• The War Drones On (Chronicle)
• World on Fire (Chronicle)