Mynaric: Laser Communication Terminals and the Systems Engineering of Space Optical Links

The Hardware That Only Works Twice

A laser communication terminal is not a standalone product. Every specification it carries — pointing accuracy, acquisition time, link margin, bit error rate — is only meaningful relative to another terminal, a platform, and an orbital geometry that changes by the second. Mynaric builds these terminals for satellite constellations, aerial platforms, and defense applications, which means the company is in the business of engineering hardware whose performance is inherently co-defined by systems it does not control.

That is an unusual position in the hardware industry, and it shapes everything about how Mynaric approaches requirements, product architecture, and test.

What Mynaric Actually Builds

Mynaric’s product line centers on free-space optical (FSO) communication terminals — devices that establish laser links between platforms in motion, at distances ranging from tens of kilometers for air-to-ground links to thousands of kilometers for satellite-to-satellite (inter-satellite link, or ISL) applications.

Their current products include the CONDOR Mk3, targeted at space applications and designed for constellation-scale volume production, and the HAWK terminal family for airborne use. The CONDOR line is positioned explicitly as a product rather than a custom deliverable — a critical architectural decision that separates Mynaric’s business model from legacy defense suppliers who built bespoke optical terminals on program-specific contracts.

The core engineering problem these products must solve is deceptively simple to state: aim a narrow laser beam at a moving target, acquire the return beam from that target, lock onto it, and hold that lock through vibration, thermal distortion, attitude perturbations, and orbital dynamics — while consuming as little power, mass, and volume as possible.

In practice, that problem touches every major discipline in systems engineering.

The PAT Problem: Where Physics Meets Systems Engineering

Pointing, acquisition, and tracking (PAT) is the central technical challenge for any FSO terminal. Understanding why requires a brief look at the numbers.

A well-designed space optical terminal operates with a beam divergence on the order of tens of microradians. At 1,000 km, a 50-microradian half-angle beam subtends a footprint of about 50 meters. The terminal must hold its pointing within a fraction of that divergence to maintain link margin — meaning pointing stability requirements are typically expressed in single-digit microradians for high-performance systems.

For comparison, a high-quality spacecraft attitude control system might hold platform attitude to tens of arcseconds, which is roughly 50–200 microradians. The platform is not stable enough to point the beam passively. The terminal must include its own fine-pointing mechanism — typically a fast-steering mirror (FSM) driven by a closed-loop control system using the received beacon as its error signal.

This creates a cascade of derived requirements:

Vibration isolation. The FSM’s bandwidth is finite. Disturbances above the control loop’s bandwidth reach the beam line of sight directly. The terminal must either reject these disturbances mechanically (vibration isolation mount), or the FSM bandwidth must be specified to encompass the disturbance spectrum of the host platform. Neither is free in terms of mass or complexity.

Acquisition field of regard. Before the fine-pointing loop can close, the two terminals must find each other. Acquisition requires a wider field of regard and a separate (or repurposed) coarse-pointing stage — often a gimbal or a steerable telescope assembly. The acquisition field of regard must be sized to encompass the pointing uncertainty from the host platform’s attitude knowledge, orbital position uncertainty, and any latency in the inter-platform communication used to coordinate acquisition.

Link-closure timing. Acquisition is not instantaneous. For a constellation operating at orbital velocities, the geometry changes continuously. Acquisition time — from initial search to locked fine-pointing loop — must be short enough that a useful portion of the contact window remains after lock is achieved. This is a system-level constraint that flows down to component-level requirements on detector sensitivity, beacon power, search strategy, and control loop settling time.

Thermal distortion. A terminal transitioning from eclipse to sunlight undergoes structural thermal gradients that can shift the boresight of the optical assembly. For a system with microradian-level pointing requirements, even small structural distortions matter. This drives requirements on material selection, structural design, and potentially active thermal compensation.

Each of these cascades further. The vibration isolation mount requires interface loads characterization from the host platform. The gimbal or coarse-pointing stage requires a power budget. The detector sensitivity requirement interacts with received signal power, which depends on the transmit power of the other terminal and the link distance — parameters Mynaric does not own.

SWaP Constraints and the Constellation Business Case

Volume-production satellite constellations impose SWaP (size, weight, and power) constraints that are fundamentally different from those in traditional defense or research programs. A constellation operator deploying hundreds or thousands of satellites cannot absorb a terminal that requires custom integration on each spacecraft. The terminal must be a catalog item: defined dimensions, defined mass, defined power draw, defined interfaces, repeatable performance.

Mynaric’s CONDOR Mk3 reportedly targets a mass envelope consistent with integration on small to medium constellation satellites — roughly in the range of 5–15 kg depending on configuration, with power consumption in the tens of watts during operation. These are not trivial constraints when the optical assembly, fine-pointing mechanism, acquisition stage, modem, and thermal management all have to coexist in a package that fits on a spacecraft already crowded with other payloads.

The tension between SWaP and PAT performance is real and does not resolve cleanly. Higher-bandwidth fine-pointing loops require faster, more powerful actuators. Better vibration isolation requires larger, heavier mounts. More sensitive detectors can compensate for lower transmit power but often require cooling. Every trade has a mass, power, or cost penalty.

What Mynaric’s product strategy does is fix the outcome of those trades for a defined performance envelope, rather than reopening them on every program. The CONDOR Mk3 is a point in the trade space, not a customizable solution. Customers who need different trades — higher margin, different link distances, different platform dynamics — are pointed to different products or, in some cases, declined.

This is a requirements management philosophy embedded in a business model. By defining the product envelope firmly, Mynaric converts a continuous requirements negotiation problem into a compatibility verification problem: does the customer’s platform and link scenario fall within the CONDOR’s performance envelope? If yes, integration proceeds. If no, a different solution is needed.

The External Interface Problem: Requirements You Do Not Own

The most distinctive systems engineering challenge in Mynaric’s position is the bilateral nature of the link. A terminal’s link margin depends on the transmit power, beam quality, and pointing performance of the terminal at the other end. If a customer deploys CONDOR Mk3 terminals in a mesh constellation where all nodes are the same product, that bilateral dependency is contained within Mynaric’s performance envelope. But many deployment scenarios are not symmetric.

Defense programs, in particular, may require interoperability with government-furnished terminals from other vendors, legacy systems, or terminals built to evolving standards such as those emerging from programs like the Space Development Agency’s Transport Layer or NATO optical communications initiatives. In these cases, Mynaric must allocate link margin based on assumptions about the other terminal’s performance — assumptions that may be encoded in interface control documents (ICDs) that are themselves subject to change.

This is a textbook external interface management problem, and it is where requirements traceability becomes operationally important rather than bureaucratically important. If the assumed receive sensitivity of the partner terminal changes between ICD revision 2 and revision 4, that change propagates through link budget calculations to potentially affect transmit power requirements, which may affect power draw, thermal dissipation, and ultimately the SWaP envelope that was frozen for production planning.

Managing that propagation manually — through documents and spreadsheets — is tractable on a program with one or two terminal designs and a stable interface. It becomes fragile on programs where multiple terminal types, multiple link geometries, and multiple ICD revision streams interact. The requirement change that seemed local turns out to have touched seven derived requirements, two of which were allocated to subsystems with long-lead procurement items.

The programs that handle this well tend to maintain live traceability models — graph-based representations of requirements and their dependencies — rather than document-based hierarchies where propagation has to be traced manually. Whether that model lives in a formal tool or in engineers’ heads varies considerably by program maturity and organizational culture.

For FSO systems, the link budget is the analytical artifact that makes all the above concrete. Link-closure analysis — calculating whether a given terminal configuration, at a given range, with a given platform pointing error, under a given atmospheric or space environment condition, achieves the required received power to close the link at the target data rate and error performance — is the systems engineering calculation that ties terminal specifications to mission outcomes.

A well-maintained link budget is a living document in the sense that it encodes the current best estimate of every parameter that affects link performance, with uncertainty bounds, and it is updated as those parameters are refined through test, analysis, and ICD negotiation. When a subsystem engineer changes a beam divergence estimate because a new lens prescription came back from the optical fabricator, the link budget tells you immediately whether that change is absorbed by margin or whether it cascades to a performance shortfall that must be resolved.

Link-closure analysis is also the forum where the bilateral dependency becomes numerically explicit. The received power at one terminal is a function of the transmitted power at the other terminal, multiplied through a chain of loss terms — pointing loss, atmospheric loss, diffraction, optical efficiency. If the partner terminal’s transmit power is uncertain by 1 dB, that uncertainty appears directly as link margin uncertainty at your terminal. Requirements allocated to your hardware must absorb that uncertainty or the interface must be tightened.

Mynaric, operating as a terminal manufacturer rather than a prime integrator on most programs, must deliver hardware whose link budget contribution — transmit power, beam quality, receive sensitivity, pointing loss — meets the allocation it has been given, or negotiate a change to that allocation. That negotiation is technical requirements management conducted across organizational boundaries.

Volume Production and the Stability of Requirements

One underappreciated consequence of Mynaric’s volume-production strategy is the requirement for requirements stability. Custom programs can absorb late requirements changes by adjusting the design. A production terminal, manufactured in units of dozens to hundreds, cannot. Once tooling is cut, processes are qualified, and supply chains are established, a fundamental performance requirement change is extraordinarily expensive to accommodate.

This creates a strong organizational incentive to front-load requirements validation — to verify, before production begins, that the stated performance envelope will actually satisfy the customer’s link scenario and platform interface. Test and verification at the terminal level must demonstrate compliance with the production specification; verification that the production specification is the right specification is a systems engineering activity that happens earlier, during the requirements definition and product definition phases, and it requires engagement with customers who may themselves be in early phases of their own system definition.

The difficulty is that constellation programs and defense acquisition programs often have their own requirements still in flux when they are seeking terminal suppliers. Mynaric is defining a product to a performance envelope while its customers are still refining what performance envelope they need. Managing that mismatch — staying close enough to customer requirements to be design-compatible at production time, without reopening the product definition every time a customer updates their link scenario — is one of the more subtle systems engineering challenges in the commercial space supply chain.

Honest Assessment

Mynaric has made a clear strategic bet: that the commercial and defense satellite communication market will mature to the point where a standardized, catalog-producible optical terminal is what most customers want, and that getting to volume production capability before competitors is the durable competitive advantage. The engineering decisions that follow from that bet — fixed performance envelopes, defined interfaces, SWaP optimization for constellation-class hosts — are internally consistent with it.

The challenge is that the bet depends on a level of requirements stability in the customer base that does not yet fully exist. Government programs continue to evolve their interface standards. Constellation operators continue to adjust their link architectures. The bilateral dependency inherent in optical links means that Mynaric’s product is only as interoperable as the ecosystem around it.

What Mynaric is building is, in the end, a node in a system that is still being defined. The systems engineering competence that matters most in that position is not the ability to optimize a single terminal in isolation — it is the ability to manage requirements across organizational and system boundaries, maintain coherent traceability from mission objectives to hardware specifications, and recognize early when an external interface change has invalidated an internal allocation. That is less glamorous than laser physics, but it is where production programs succeed or fail.