# fm-rds-tx docs

## Build & Test

### Root CLI
- `go test ./...`
- `go run ./cmd/fmrtx -print-config`
- `go run ./cmd/fmrtx -config docs/config.sample.json`
- `go run ./cmd/fmrtx --dry-run --dry-output build/dryrun/frame.json`
- `go run ./cmd/fmrtx --simulate-tx --simulate-output build/sim/simulated-soapy.iqf32 --simulate-duration 250ms`
- `go run ./cmd/offline -duration 500ms -output build/offline/composite.iqf32`

### Internal DSP module
- `cd internal`
- `go test ./...`

### Examples module
- `cd examples`
- `go test ./...`
- `go run ./soapy_simulated`

## Dry run

The dry-run mode generates a synthetic, hardware-free frame summary based on the current config.
It is intended as a no-hardware smoke path for the CLI and config/control-adjacent logic.

The HTTP control plane also exposes `GET /dry-run` for quick inspection of the currently effective no-hardware summary.

## Simulated transmit

`--simulate-tx` runs the offline generator through the Soapy-oriented simulated backend path and writes an IQ-style artifact to disk.
This is the current closest no-hardware stand-in for the future transmit pipeline in the main application path.

## Offline generation

`cmd/offline` generates a deterministic no-hardware IQ/composite-style file using the repository's output backend path.
This is still an MVP path, but it is a more realistic offline artifact than the JSON-only dry-run.