TorchSig integration¶

Use this integration when you already use TorchSig in an RFML workflow and want to generate compatible waveforms, exchange supported records, or compare a classifier against the pinned TorchSig benchmark augmentation profile. rfgen remains the owner of scene composition, physical propagation, physical receiver (RX) modeling, labels, provenance, and storage contracts.

TorchSig is optional; from a source checkout, follow the authoritative installation guidance and use uv pip install -e '.[torchsig]'.

Choose your route¶

Your goal	Start here	Result
Generate comms examples with TorchSig waveform builders	Emitter API and the narrowband classifier Golden Path	An rfgen `Signal` generated through an explicitly selected emitter
Read or write data with a TorchSig workflow	TorchSig Interop	An in-memory LabeledScene ↔ TorchSig `Signal` conversion
Benchmark a single-signal classifier against TorchSig augmentation	Augmentation configuration and benchmark validation	A classification-only `BenchmarkSample`, not a stored rfgen record

Choose one route deliberately. Installing TorchSig never changes rfgen’s default emitter, propagation backend, or physical RX chain.

Generate TorchSig-backed waveforms¶

TorchSig waveform builders are behind rfgen emitter wrappers. Add a selector to a valid emitter-zoo configuration; the fragment below belongs inside a complete GenerationConfig, not in isolation:

emitter_zoo:
  families:
    - family: comms
      selector: torchsig_comms
      classes: [bpsk, qpsk, 16qam, 64qam]

The selector resolves one rfgen BaseEmitter. rfgen validates the family and class labels before generation, and the wrapper returns rfgen IQ and metadata, not a TorchSig object. See the Emitter API for the available wrappers and parameter contracts.

Exchange data deliberately¶

Use the TorchSig Interop reference when a TorchSig consumer needs compatible data. It specifies supported IQ shape, single-RX restriction, metadata mapping, known losses, and the two explicit conversion functions, to_torchsig_signal and from_torchsig_signal.

Both operate on in-memory objects. Neither reads or writes a store: rfgen’s own store is signal_dataset, and installing TorchSig does not change what it writes or add a shard format that a TorchSig loader reads directly. Converting a published dataset means reading records back and calling to_torchsig_signal yourself.

Compare a classifier with TorchSig augmentation¶

TorchSig augmentation is an opt-in classification benchmark, separate from the physical RX chain. Configure it under the top-level augmentation block of a valid GenerationConfig:

augmentation:
  selector: torchsig_classification
  params:
    profile: torchsig_rx_classification_v2_1_1
    torchsig_version: "2.1.1"
    label_contract: classification_only

GenerationConfig.build_augmentation() constructs the adapter. Its augment accepts a LabeledScene with one emitter, no bboxes or segmentation, packed (2, N) torch.float32 IQ, and N >= 3, then returns BenchmarkSample(iq, class_target, provenance). It does not mutate the scene or enter ChannelPipeline; therefore it cannot preserve detection boxes or segmentation masks. The allow-listed transform set, pinned environment, deterministic CPU boundary, and exclusions are defined in the benchmark validation report.

Boundary with rfgen physics¶

Use rfgen’s physical RX chain when modeling a receiver. Its explicit local oscillator (LO) error, mixer, filtering, resampling, low-noise amplifier (LNA) noise, analog-to-digital converter (ADC), phase noise, IQ imbalance, and digital automatic gain control (AGC) are described by the RX Frontend API. TorchSig augmentation is a benchmark comparison surface, not a physical-RX claim.

The public integration namespace owns upstream calls and conversion. rfgen core types and contracts do not expose TorchSig objects; the integration’s wrappers and converters translate at explicit boundaries.