matlab-design-radar-waveform

# Radar Waveform Design

Design and select radar waveforms using the Phased Array System Toolbox. Use
the decision tree to select the correct waveform object based on requirements,
follow correct function-to-object pairings, and avoid common mistakes.

## When to Use

**Primary keywords** (any of these alone can trigger the skill):
waveform, signal, chirp, LFM, NLFM, FMCW, PMCW, pulse compression,
transmit signal, M-sequence, MLS, PN code, spread spectrum, phase code,
joint radar-communication, dual-function waveform

**Sensing-context words** (confirm sensing domain when paired with primary keywords):
target, jammer, jamming, pulse, pulses, spectrum, sidelobe, Doppler, range resolution, detection, clutter, matched filter, ambiguity, sweep, PRF, PRI

**Trigger logic:**
- Primary keyword + sensing-context word → use this skill directly
- Primary keyword alone → ask: sensing or communications? (communications → skill does not apply)
- Sensing-context words + vague language ("a signal that changes each time") → use this skill

**After triggering, clarify purpose and scope:**

1. **Purpose** — application-driven or exploration/learning?
   - Exploration/learning (student, paper reproduction, comparing properties): proceed with given parameters, suggest `radarWaveformGenerator`. Do not push for application context.
   - Application-driven → clarify dimensions below.

2. **Application dimensions** (ask what's unknown — applies to any sensing application):
   Range scale | Target motion and velocity | Resolution need | Environment (clutter, jamming, interference) | Hardware limits (ADC, duty cycle) | Primary metric (detection, resolution, accuracy, or ambiguity-free)

3. **Requirements** — Derive waveform parameters from the answers above (see table below)

## When NOT to Use

- Full radar system simulation (transmitter → channel → receiver chain)
- Beamforming or array design (use phased array skills)
- Target detection / CFAR processing
- Simulink waveform generation blocks
- Communications waveforms (OFDM, QAM, etc.)

### Escalation / Boundary Conditions

Do not answer as if waveform choice alone solves:

- Range/velocity ambiguity resolution strategy (staggered PRF scheduling, medium-PRF processing)
- Tracker-level Doppler/range association
- Detailed receiver chain design (noise figure, dynamic range budgets)
- Clutter suppression design (MTI, STAP)
- Antenna/array pattern issues
- CFAR or detector performance questions

Instead, explain that the issue is system-level and identify what waveform-related
part can still be addressed.

## Workflow

1. **Clarify requirements** — Gather what the user hasn't specified (see table below)
2. **Select waveform object** — Use the decision tree below
3. **Configure the waveform** — Set properties based on requirements
4. **Analyze** — Use appropriate analysis function (ambgfun, pambgfun, sidelobelevel)
5. **Suggest interactive exploration** — Recommend `radarWaveformGenerator` app

### Construction Rule (non-negotiable)

Always generate signals using toolbox System objects and functions — never
manually construct `exp(1j*...)` or write custom LFSR/sequence generators.
If `mlseq`, `legendreseq`, `phased.LinearFMWaveform`, or another toolbox
function can produce what you need, use it. Manual construction is only
acceptable when no toolbox equivalent exists for the specific operation
(e.g., applying element-wise phase modulation to an existing waveform vector).
For hybrid waveforms (e.g., LFM + communication encoding), generate the base
with the appropriate object, apply the modification, then wrap the result with
`PhaseCodedWaveform` using `Code='Custom'`. If no built-in object fits (e.g.,
exact DFT-bin nulls, non-contiguous bands), escalate to custom IQ synthesis but
keep toolbox functions for parameter derivation, wrapping, and analysis. Always
state which parts are toolbox-based and which are custom.

### Analysis Rule (non-negotiable)

Never use `xcorr` for radar waveform autocorrelation or matched filter
response visualization. Instead:

- **Matched filter response / autocorrelation:** Use `ambgfun` with
  `'Cut','Doppler'` (zero-Doppler cut = response vs delay).
- **PSL measurement:** Use `sidelobelevel` on the dB-converted cut.
- **Doppler tolerance:** Use `ambgfun` with `'Cut','Delay'` (zero-delay
  cut = response vs Doppler).
- **Downstream signal processing:** Use `phased.MatchedFilter` when you
  need the actual filtered signal (range processing, bit recovery, etc.).

### Agent Reasoning Policy

- Follow the clarification flow above — do not skip to code without sufficient context.
- **User names a waveform family** → treat as a constraint; configure and analyze it. Only override if requirements are impossible with that family.
- **User gives only performance constraints** → choose the simplest family that satisfies them and explain why.
- Performance requirements given → derive parameters before selecting objects.
- Waveform family given (e.g., "NLFM") → ask about the goal (sidelobes, spectral shaping, Doppler tolerance, hardware).
- Exploration/learning → help directly with given parameters. **Still use toolbox objects** — generate base waveforms via System objects, use `mlseq`/`legendreseq`/`apaseq` for sequences, wrap custom results in `PhaseCodedWaveform` with Custom code. Do not write manual signal construction. Suggest `radarWaveformGenerator` for interactive exploration.
- Application context only (no numeric requirements) → recommend the waveform family/object and explain why. If the domain has well-known defaults (e.g., automotive radar at 77 GHz), state assumptions and proceed. Otherwise ask the application dimensions. Do NOT silently invent parameters without stating them.
- Conflicting requirements → surface the conflict before proposing a waveform.
- "Best waveform" → explain it depends on resolution, ambiguity, sidelobes, Doppler, hardware, and processing.
- User states MATLAB release → check function availability; note `radarW