Embedded-AI-Harness: Skill for Claude Code

Signal Generator (/api/siggen/*)

The testbench Pi has one signal-generator service. Two RF sources sit behind it (Si5351 on I²C, BCM2835 GPCLK on GPIO 5/6) and an optional PE4302 step attenuator can sit in the RF path. The endpoint is the same regardless of which backend is active — /api/siggen/* is the only entry point you should reach for.

This skill replaces the legacy cw-beacon skill, which only knew about GPCLK and led to wrong frequencies on testbenches that have an Si5351.

---

Always check status first

Before starting a carrier or recommending a backend, GET /api/siggen/status. The response tells you which hardware is detected:

{
  "ok": true, "active": false, "backend": null,
  "freq_hz": 0.0, "channel": null, "pin": null,
  "atten_db": null, "morse": null,
  "hardware": {"si5351": true, "gpclk": true, "pe4302": true}
}

Why this matters:

• If hardware.si5351 is true, you can hit any frequency exactly (333 kHz – 112.5 MHz, fractional synthesis). Don't reach for GPCLK.
• If hardware.si5351 is false, you fall back to GPCLK, which only produces PLLD/N integer dividers — ~25–30 kHz frequency steps in the 80m band. Tell the user the actual freq_hz returned, not the requested one.
• If hardware.pe4302 is false, calls to /api/siggen/atten will 4xx. Don't promise attenuation control.
• If active is already true, starting a new carrier replaces the old one. If the user just wants to retune, use /api/siggen/freq instead so the Morse keyer (if any) keeps running.

Skipping the status check is the most common failure mode of this skill — pick the wrong backend and the carrier ends up tens of kHz off frequency, or you offer attenuation that doesn't exist.

---

API summary

Every endpoint, with its request and response shape: FSD Appendix D.11.

freq retunes an active carrier without restarting the Morse keyer — use it rather than stop/start when a test must not lose keying state.