Library Landscape

Warning

Pre-implementation. This page describes proposed contracts and selection criteria. Exact dependency versions, license review, and supported transmitter surfaces must be verified during implementation and recorded in reference docs or architecture decision records (ADRs).

Emitter correctness is hard to inspect by eye. Small mistakes in carrier-frequency offset (CFO) sign or sample-clock handling can produce plausible-looking in-phase / quadrature (IQ) samples that are still wrong. The framework therefore prefers mature libraries and reference implementations over custom waveform code whenever a suitable backend exists. Here, a backend is the library, tool, or replay source that actually synthesizes the emitter waveform; the rfgen emitter wraps that backend behind the framework contract.

This page explains how to choose those backends. The main Emitters concept page defines the emitter contract; this page explains what should sit behind that contract.

Selection Policy

Use the strongest available implementation tier:

Tier	When to use it
Linked mature library	Preferred when the dependency is compatible with distribution and exposes the waveform families rfgen needs, such as OFDM frames, GFSK packets, chirps, or radar pulses.
Runtime-isolated tool	Use when the best implementation has licensing, process, or environment constraints, such as a GPL-licensed simulator that rfgen must invoke through a subprocess and read back from an output file.
Independent implementation	Use only when no suitable backend exists or the algorithm is small, published, and testable.
Captured playback	Use for families where generation is not credible but real IQ is available.

The goal is not to avoid custom code entirely. The goal is to keep custom code near integration boundaries, validation harnesses, adapters, and small well-scoped algorithms instead of reimplementing full RF stacks.

Candidate Backend Map

Family	Preferred library	Sources	License	Tier	Specific entry point	Caveats
Generic comms modulation	TorchSig	TorchSig signals; Sig53 paper for synthetic radio-frequency machine-learning (RFML) dataset practice (arXiv:2207.09918)	MIT	linked	torchsig.signals.builders.constellation.ConstellationSignalGenerator; sibling FSKSignalGenerator, OFDMSignalGenerator, FMSignalGenerator, AMSignalGenerator, LFMSignalGenerator, ChirpSSSignalGenerator, ToneSignalGenerator	Covers common digital modulations: phase-shift keying (PSK), quadrature amplitude modulation (QAM), frequency-shift keying (FSK), Gaussian FSK (GFSK), orthogonal frequency-division multiplexing (OFDM), analog AM/FM, chirps, and synthetic benchmark families. Pulse shaping is limited to rectangular and square-root raised cosine.
5G New Radio (NR)	Sionna physical-layer (PHY) library	Sionna NR API; 3GPP TS 38.211 for NR physical channels and modulation	Apache-2.0	linked	sionna.phy.nr.PUSCHTransmitter	End-to-end transmitter support is uplink-only through PUSCH, the channel a handset uses to send user data to a base station. Downlink PDSCH, synchronization SSB, random-access PRACH, control PUCCH, and sounding SRS coverage requires the fallback (py5gphy, MIT).
Long-Term Evolution (LTE)	srsRAN 4G	srsRAN 4G docs; ZeroMQ virtual-radio note	AGPL-3.0	runtime-isolated	srsenb binary driven via the ZMQ RF frontend, IQ captured to file	LTE is distinct from 5G NR; an NR backend does not cover LTE. AGPL requires a subprocess boundary; MATLAB LTE Toolbox is the proprietary alternative if the license is acceptable.
LoRa	gr-lora_sdr (EPFL TCL)	EPFL LoRa physical layer based on GNU Radio; gr-lora_sdr	GPL-3.0	runtime-isolated	gnuradio.lora_sdr.lora_sdr_lora_tx hierarchical block	Requires a GNU Radio 3.10 system install; subprocess boundary required by GPL; no LR-FHSS support.
Wi-Fi	MATLAB WLAN Toolbox	MathWorks wlanWaveformGenerator; WLAN Waveform Generator standards coverage (app docs)	proprietary (MathWorks commercial)	runtime-isolated	wlanWaveformGenerator	Open-source gap: gr-ieee802-11 covers only 802.11a/g/p. No permissive 802.11n/ac/ax transmitter exists today.
Zigbee	gr-ieee802-15-4 (bastibl, WIME)	gr-ieee802-15-4; IEEE 802.15.4 standard family	GPL-3.0	runtime-isolated	ieee802_15_4_OQPSK_PHY hierarchical block	Subprocess boundary required by GPL; alternative is to vendor a roughly 100-line NumPy O-QPSK modulator inside rfgen and validate against gr-ieee802-15-4 reference vectors.
Automatic Dependent Surveillance-Broadcast (ADS-B)	rfgen-native PPM modulator + pyModeS	MathWorks ADS-B example for 1090 MHz PPM, 1 Mbit/s, and 8 microsecond preamble (Airplane Tracking Using ADS-B Signals); pyModeS	rfgen-internal (BSD-3 target) + pyModeS GPL-3.0	independent + runtime-isolated	Roughly 50-line NumPy pulse-position modulation (PPM) modulator at 1 Mbps with the 8 microsecond preamble per ICAO Annex 10 Vol IV; pyModeS for CPR, CRC, and altitude field codecs	ADS-B is the 1090 MHz aircraft transponder broadcast. Validate output against FlightAware dump1090; runtime-isolate pyModeS to keep the GPL boundary.
Radar	RadarSimPy (radarsimx) + scipy.signal.chirp + rfgen-native Barker and polyphase generators	RadarSimPy examples; SciPy chirp; Richards, Fundamentals of Radar Signal Processing, 2nd ed. for Barker and polyphase code families	RadarSimPy GPL-3.0; scipy + rfgen-native BSD-3	runtime-isolated + independent	RadarSimPy for FMCW; scipy.signal.chirp plus internal generators for short coded-pulse radar waveforms, including Barker, Frank, and P1-P4 polyphase phase codes	RadarSimPy is a non-PyPI download; phase-coded sequences are closed-form and can stay in-process.
Drone control links	Captured-IQ only	No cited waveform-synthesis source yet; keep this family playback-only until a credible synthesizer is identified	n/a	playback	Treat as a captured-IQ family until a credible drone-protocol synthesizer is identified	Re-run deep research to evaluate DroneRF, DroneSig, ExpressLRS captures, and equivalent datasets; existing prose recommendation stands in the meantime.
Captured playback	sigmf-python (gnuradio org)	Signal Metadata Format (SigMF) specification; SigMF Python documentation	LGPL-3.0	linked	sigmf.fromfile(path) returning a SigMFFile object	SigMF stores RF captures as IQ data plus metadata. RadioML 2018.01A and WiSig are CC-BY-NC-SA-4.0 (commercial use blocked); ORACLE RF Fingerprinting dataset license is unspecified.

This map is a blueprint, not a dependency lockfile. Implementation still needs dependency pinning, license review, and validation fixtures before a family is marked supported.

Wrapper Boundary

Every backend, whether linked or isolated, should still satisfy the same rfgen emitter contract:

• produce clean baseband IQ or a documented scene-relative waveform;

• report bandwidth, sample rate, duration, class taxonomy, and provenance;

• use the supplied RNG or declare where deterministic replay is impossible;

• keep emitter output separate from channel propagation and receiver noise;

• expose validation fixtures that compare output against reference examples, captures, or independent checks.

Clean baseband IQ means complex samples centered at zero frequency before the scene composer places the signal in time, carrier frequency, and receiver context. A scene-relative waveform is one that already carries an explicit time/frequency relationship to the scene and must document that relationship.

The wrapper is also where backend quirks are normalized: tensor layout, units, metadata naming, seed handling, and exception types.

License And Distribution Boundary

This page is not a legal opinion. The engineering policy is conservative:

• compatible, redistributable dependencies may be linked directly;

• restrictive or uncertain dependencies should be optional and runtime-isolated;

• generated artifacts should record the backend and version that produced them;

• license decisions should be recorded in an architecture decision record or dependency audit before release.

Keeping optional tools behind process or service boundaries also makes it easier to swap a backend later without changing the emitter contract.

Validation Expectations

A backend choice is not complete until it has a validation path. Depending on the family, useful checks include:

• comparison against known-good reference vectors;

• spectral mask and occupied-bandwidth checks, meaning the signal stays inside its allotted frequency band and does not leak excessive power into neighbors;

• demodulation or decoding by an independent receiver, such as passing ADS-B IQ through pyModeS and checking that it decodes the expected aircraft fields;

• round-trip comparison to captured data;

• classifier or detector sanity checks against established radio-frequency machine-learning benchmarks, such as RML2016 or TorchSig Sig53.

Coverage and validation methodology are tracked in Coverage and Background / Validation.

See Also

• Emitters for the contract every backend implements.

• Coverage for spectrum coverage and validation planning.

• Reference / rfgen.emitters for the proposed API surface.