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

**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

**Analysis approach:** Use `ambgfun` zero-Doppler cut to study the matched filter
response (mainlobe width, sidelobe structure). Measure PSL with `sidelobelevel`
on that cut. Only construct a `phased.MatchedFilter` object when the user
explicitly needs coefficients for downstream signal processing.

### Agent Reasoning Policy

- Follow the clarification flow above — do not skip to code without sufficient context.
- 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; do not require application context.
- 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 `radarWaveformGenerator` requires R2026a.
- **No debugging loops.** If code errors or results don't match expectations, retry at most once with a targeted fix. If the second attempt fails, stop and report what went wrong, what you tried, and ask the user whether to adjust requirements, relax constraints, or provide additional information. Do not iterate beyond 2 attempts.

### Requirements to Clarify

Once the application dimensions are known, check for these specific gaps:

| If the user hasn't specified... | Ask about... | Impacts... |
|---|---|---|
| Modulation type | Pulsed vs CW; FM vs phase-coded | Object selection (decision tree) |
| Range resolution | Required resolution (m) | Bandwidth via `rangeres2bw` |
| Sidelobe requirement | Acceptable PSL (dB) | NLFM vs windowed matched filter vs phase code choice |
| Range and velocity together | Max unambiguous range AND velocity | PRF conflict check (see Parameter Derivation) |
| Doppler tolerance | Max target velocity during dwell | LFM (tolerant) vs phase-coded (sensitive) tradeoff |
| Hardware constraints | ADC bandwidth, instantaneous BW limit | Stretch processing or stepped FM instead of wideband LFM |

### Requirement-to-Recommendation Heuristics

- If the user prioritizes Doppler tolerance over perfectly decoupled range–Doppler, prefer LFM-style solutions.
- If the user prioritizes low sidelobes without receiver SNR loss, consider NLFM.
- If the user needs spectral notching (avoiding interference bands), use `shapespectrum` on an existing waveform. If they need a custom frequency profile for sidelobe control, use `nlfmspec2freq` + `CustomFMWaveform`.
- If the user's hardware cannot support large instantaneous bandwidth, consider stretch processing or stepped FM.
- If the user needs to bring external IQ data into toolbox processing, use the Custom IQ pattern (`Phas