Every satellite that leaves the ground carries a radio. It has to. Radio waves are, still today, the only practical way to communicate between a spacecraft and Earth, or between spacecraft in orbit. But for most of the history of space systems, a satellite’s radio was a fixed piece of hardware: designed for one mission, one frequency, one set of protocols. Once launched, it couldn’t be changed.
That constraint shaped the entire economics and risk profile of space missions. If communication requirements evolved, whether due to changes in spectrum allocation, new interoperability needs, or evolving ground infrastructure, adaptations were limited to what the original hardware could support. If a new communication standard emerged mid-mission, you had to adapt within rigid hardware limits. If spectrum conditions shifted, there wasn’t much you could do. The radio was, in effect, frozen in time from the moment it was integrated onto the spacecraft.
Software-defined radio, or SDR, was born from the desire to break that constraint. And over the past decade, it has quietly become one of the foundational technologies of modern satellite systems, from large geostationary telecommunications platforms down to small CubeSats in low Earth orbit. Understanding what an SDR is, and what it actually changes, and what it does not, is increasingly essential for anyone working in the space sector.
What Is a Software-Defined Radio?
At its core, the idea behind software-defined radio is straightforward: shift as many radio functions as possible from fixed hardware into software-controlled processing.
In a traditional radio, the functions that define its operation, such as modulation, demodulation, filtering, frequency selection, and encoding, are implemented in dedicated analog or digital circuits. Changing any of these requires physically changing the hardware. An SDR replaces most of these fixed circuits with a general-purpose digital processing platform, on which the radio’s behaviour is defined by programmable software called a waveform.
The antenna still captures or emits electromagnetic waves. The analog front-end is tunable to the application’s signal characteristics, a key distinction from traditional radios, where this stage was fixed. The signals are converted to the digital domain as early as possible through high-speed data converters (ADC/DAC). Once digitised, the signals are processed by a digital processing unit. This processing is driven by software, allowing the system to be updated, reconfigured, or extended throughout its lifetime, including after launch.
Did you know? The concept of software-defined radio was first formally articulated by Joe Mitola III in a 1991 paper for the U.S. Department of Defense. His vision was a single reconfigurable hardware platform capable of implementing any radio standard in software. More than three decades later, that vision is a commercial reality aboard satellites in orbit.
Inside an SDR: the key components
It’s worth taking a moment to understand what an SDR is actually made of, because the architecture is what makes reconfigurability possible in the first place.
The RF Front-End
The RF front-end is the analog entry point. It receives the incoming signal, performs initial conditioning such as filtering, amplification, and frequency selection, and prepares it for digitisation. In modern SDR architectures, this stage is not fixed but designed to be tunable and configurable, adapting to the frequency band, bandwidth, and dynamic range of the application. This tunability can be achieved in different ways: through a software-defined mixer that shifts the signal from a varying frequency to a reference band, or through a wideband analog front-end that digitises a broad spectrum and lets software select the desired frequency range. On the transmit side, the RF front-end performs the inverse function, converting digital signals back to the required RF frequency. While it remains an analog subsystem, its behaviour is largely controlled and configured through software, enabling a high degree of flexibility within the limits of the hardware design.
It is also worth noting that additional analog components, such as a low-noise amplifier (LNA), a power amplifier, or bandpass filters, can be placed upstream or downstream of the SDR’s front-end to improve signal quality or reject unwanted interference. These components complement the SDR but are distinct from it.
ADC & DAC
The analog-to-digital converter (ADC) and digital-to-analog converter (DAC) are where the analog world hands off to the digital. On the receive path, the ADC samples the incoming analog signal and converts it into a stream of digital data. On the transmit path, the DAC performs the reverse. The performance of these converters, particularly their sampling rate, resolution, and dynamic range, directly impacts the achievable bandwidth, sensitivity, and overall signal fidelity of the SDR. As a result, they are key architectural elements that strongly influence the system’s capabilities in any SDR design.
The Digital Processing Core
This is where the core radio functionality happens. Depending on the platform, this is typically performed using an FPGA (Field-Programmable Gate Array), a DSP (Digital Signal Processor), a general-purpose processor, or increasingly a System-on-Chip (SoC) that integrates several of these elements. Our VILSA SDR uses such a SoC, integrating FPGA fabric with embedded ARM processors on a single device.
Within this digital domain, functions such as digital filtering, frequency translation, demodulation, decoding, and higher-layer protocol processing are implemented. While the most time-critical operations are executed in programmable logic (FPGA), higher-level processing and control are handled by embedded software. This architecture enables the signal processing chain to be reconfigured and updated throughout the mission, including after launch, allowing the system to adapt to evolving requirements or operational conditions.
The Waveform — the Software Layer
The waveform is the radio’s identity in software. It encompasses all the key functions that determine how signals are transmitted and received: the modulation scheme, channel coding, frequency plan, timing, error correction, and many other parameters. On a conventional radio, these functions are implemented in fixed hardware. On an SDR, the waveform is a software module that can be loaded, swapped, and updated. Different waveforms can coexist on the same hardware platform, and new ones can be uploaded in orbit.
A note on terminology: in everyday RF engineering, the word “waveform” often refers to the shape of a radio signal. In the SDR context, it has taken on a second, specific meaning: the software implementation of a complete radio protocol. Both usages are technically valid; the SDR sense is the one used throughout this article.
Together, these components define the SDR’s operational envelope. The hardware sets the physical limits, frequency range, processing capacity, bandwidth; the software determines, within those limits, what the radio does.
Hardware vs. Software: What Actually Changes?
To appreciate what SDR enables, it helps to contrast it with what came before.
A conventional satellite transponder is purpose-built. It operates at defined frequencies, with a fixed modulation scheme, a fixed channel bandwidth, and fixed protocols. This specificity isn’t a flaw. It reflects the realities of space qualification, where hardware must be tested exhaustively to withstand radiation, vacuum, and thermal cycling. Custom hardware can be optimised for exactly one, well-defined job, and for many missions, that remains an effective approach.
That optimisation comes at a cost: inflexibility. If a mission’s communication requirements evolve, for instance if a different modulation or coding scheme is required to match new link conditions, or if interoperability with another system becomes necessary, the hardware cannot adapt. The system remains constrained by the design choices made before launch.
An SDR changes that dynamic. The same physical platform can support different communication modes, operate across multiple frequency bands within its hardware range, change modulation schemes, and implement new protocols, all through software updates uploaded from the ground. The hardware provides the physical capabilities; the software defines the radio’s behaviour. This distinction has profound implications in space, where modifying hardware after launch is not an option. SDRs introduce a level of adaptability that was previously unattainable in satellite communications.
Why SDRs Matter Specifically in Space
Reconfigurability in orbit
The most cited advantage of SDRs in space is the ability to update a payload after launch. Missions routinely span five to fifteen years. Over that time, communication standards evolve, spectrum allocations shift, new ground infrastructure becomes available, and mission objectives sometimes change.
NASA’s SCaN Testbed, operated aboard the International Space Station from 2012, provides a concrete demonstration of this capability. Over seven years of operation, it logged more than 4,000 hours of space-based SDR experiments and successfully completed 888 in-orbit reconfiguration routines, each representing a modification to the radio’s software behaviour with no physical access to the hardware (NASA Technical Reports Server, 2019). In a traditional space programme, each of those routines would have required either a redesign of the hardware prior to launch or would not have been possible at all once the satellite was in orbit.
Multi-mission flexibility from a single platform
Modern SDR platforms can support multiple concurrent signal processing chains operating at different frequencies. Some commercial SDR architectures support as many as 16 independent chains at once (Military Embedded Systems, 2021). Each chain can be assigned to a different application: TT&C (telemetry, tracking and command), payload data downlink, inter-satellite links, navigation signal reception, or Earth observation, all from the same unit.
This consolidation is particularly valuable for small satellites, where size, weight, and power constraints are tight. Instead of deploying multiple dedicated radios, each optimised for a specific function, a single SDR platform can allocate its resources dynamically across different communication tasks. The result is not only a reduction in mass and volume, but also a more flexible system architecture. Communication resources can be reconfigured during the mission, for example by prioritising data downlink over housekeeping telemetry during high-throughput phases. In many small satellite programmes, this level of integration is not simply advantageous; it is a key enabler of mission feasibility.
Cost efficiency across a satellite programme
Satellite development programmes benefit from SDR in ways that extend beyond an individual spacecraft. When the same SDR hardware platform can be reused across multiple missions with different software configurations, non-recurring engineering costs, the expensive work of designing and qualifying new hardware from scratch, are spread across a larger fleet. That efficiency is a key factor behind the growing adoption of software-defined payload architectures. The market for software-defined satellites was valued at roughly $3.1 billion in 2024 and is projected to reach nearly $5.9 billion by 2029 (Research and Markets, 2025), reflecting sustained investment in the flexible payload architectures that SDRs enable.
Did you know? Harris Corporation (now L3Harris) developed a commercial SDR platform from technology originally demonstrated on the NASA SCaN Testbed. That platform, branded AppSTAR, has since been deployed on more than 250 space radios, including hosted payloads on the Iridium NEXT constellation, where it simultaneously supports aircraft tracking and maritime ship-monitoring services from the same radio hardware. (Space Foundation)
Where SDRs Are Used in Space Missions
Software-defined radios appear across a wide range of space applications. While their exact role depends on the mission, several recurring use cases illustrate how SDR platforms enable flexible and multi-functional payload architectures.
Telemetry, Tracking and Command (TT&C): The baseline function of any satellite radio. SDR-based TT&C subsystems can be updated to support new ground station protocols or frequency plans without a hardware change. This proves particularly useful as ground infrastructure evolves over a mission’s lifetime.
Payload data downlink: Earth observation, remote sensing, and science missions generate large volumes of data that must reach the ground efficiently. SDRs enable the implementation of higher-order modulation schemes and adaptive coding, allowing the link to be optimised based on channel conditions.
Navigation signal reception: GNSS receivers are increasingly implemented as SDR-based functions, allowing satellites to process GPS, Galileo, GLONASS, or BeiDou signals, or combinations of them, on a shared platform. The first in-orbit use of the Galileo E5A navigation signal was, in fact, demonstrated by NASA’s SCaN Testbed SDR in 2018 (Microwaves & RF, 2021). This illustrates the flexibility of SDRs to support signals and applications that were not part of the original mission design.
Inter-satellite links: As low Earth orbit constellations grow, satellites increasingly need to communicate directly with each other rather than routing all data through ground stations. SDRs provide the flexibility to implement and evolve inter-satellite link protocols as constellation architectures change over time.
IoT and narrowband connectivity: Satellites supporting Internet of Things connectivity must interface with a fragmented landscape of standards. Protocols such as LoRa, NB-IoT, LTE-M, and others all coexist in the terrestrial IoT ecosystem. SDR platforms allow operators to support multiple protocols simultaneously and to add or update support as standards evolve.
Did you know? In 2018, the NASA SCaN Testbed became the first device in orbit to receive and process the Galileo E5A signal, a navigation signal that hadn’t even been included in its original mission design. That was only possible because the radio’s behaviour was defined in software, not fixed in hardware.
These five use cases are also among the earliest to be implemented in SDR, in part because they impose comparatively modest demands on processing power and RF front-end performance, which explains why they remain the most widespread today. As SDR processing capacity and RF performance continue to improve, a new generation of more demanding applications is coming within reach. Spectrum monitoring payloads, for instance, require wideband RF channels capable of observing large swaths of spectrum at once. Defence-related applications such as jamming or spoofing detection demand both high-performance processing platforms and highly capable RF front-ends. Radar applications, for Earth observation or for mapping other celestial bodies, rely on synchronised RF transmit and receive channels. These represent just a few examples among a growing range of existing and emerging use cases.
This is precisely the segment where high-performance SDR platforms such as Anywaves’ VILSA SDR are designed to operate, where the combination of a wideband, tunable RF front-end and a high-performance processing core enables capabilities that lower-end SDRs are not built to support.
A Quick Note on What an SDR Is Not
It’s worth briefly clarifying a common point of confusion. An SDR is not, by itself, a complete communications payload. An SDR encompasses the radio chain: a tunable analog RF front-end combined with a programmable digital processing architecture. It works together with an antenna system, potentially additional RF conditioning components (LNA, power amplifier, filters), power management electronics, and thermal management hardware, all of which are equally critical to a functioning payload.
Moreover, the performance of an SDR is bounded by its physical hardware: the frequency range of its analog front-end, the processing capacity of its FPGA or SoC, its ADC/DAC performance, and its power envelope. Software defines the radio’s behaviour within those bounds; it doesn’t transcend them. This is an important nuance when evaluating SDR platforms for specific missions, and one we’ll explore in more depth in upcoming articles.
The Bigger Picture: Toward Software-Defined Satellites
SDRs are part of a broader trend in the space industry toward more flexible and reconfigurable payload architectures, and, ultimately, toward software-defined satellites, where not just the radio but the entire payload can be reconfigured in orbit to serve new functions. This shift is reshaping how missions are designed, how constellations are managed, and how the economics of satellite manufacturing work. Greater emphasis is placed on platform reuse, functional flexibility, and the ability to adapt to uncertainties over long mission lifetimes.
For payload engineers and mission architects, understanding SDR technology, its genuine capabilities, its constraints, and its interaction with the rest of the RF chain, is becoming a core competency rather than a specialist niche. This is not because SDR technology is new, but because it is becoming a baseline assumption in modern payload design, where differences in implementation significantly impact performance, integration effort, and operational flexibility.
Conclusion
Software-defined radio represents one of the more significant architectural shifts in satellite payload design of the past two decades. By moving key radio functions from fixed hardware into programmable architectures, SDRs introduce a level of adaptability that was previously unattainable in space systems.
In an environment where communication standards evolve, spectrum usage changes, and mission requirements can shift over time, the ability to adapt after launch provides a clear operational advantage. However, as SDRs become a baseline in modern payload design, the focus is increasingly shifting from the concept itself to how effectively it is implemented, particularly in terms of RF performance, system integration, and operational complexity.
In future articles, we will explore these aspects in more detail, including the interaction between SDRs and antenna systems, the challenges of space qualification, and the design trade-offs that shape next-generation RF payloads.
Anywaves designs and manufactures space-grade RF payload subsystems, including flight-proven software-defined radio platforms. Our new VILSA SDR combines a high-performance processing unit with a wideband, tunable RF front-end covering VHF to X-band. It is built on a previous generation SDR with flight heritage on ESA missions including HERA/Juventas.
