Embedded-AI-Harness: Skill for Claude Code

SDR Receiver (/api/sdr/*)

The testbench Pi has one RTL2832U dongle behind the rtl_433 toolchain. Every receive operation goes through /api/sdr/*. It is the receive-side counterpart to the transmit-only signal-generator skill — never SSH in to run rtl_433 yourself, drive the API.

One dongle, one user. Every capture (and the whole live console) holds a single-instance lock. While one is running, the others return "SDR busy — a capture is already running". Stop the live console before a one-shot, and vice-versa.

---

Always check status first

GET /api/sdr/status before anything:

{"ok": true, "active": false, "mode": null, "freq_hz": 0,
 "hardware": {"rtl_433": true, "rtl_test": true, "device": true},
 "available": true}

• hardware.device: false / available: false → the dongle isn't detected. Try POST /api/sdr/reset (USB reset); if still absent, it's unplugged or the USB controller is wedged (see Dongle recovery).
• active: true → something is already using the dongle; stop it first.

---

API summary

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

Only the choice between them is this skill's: capture decodes, analyze gives raw pulse timing when nothing decodes, power measures a level, and acquire runs all three in sequence when you do not yet know what is on the air.

Common body fields: freq_hz (default 433.92 MHz), duration_s, gain (number dB, or omit for AGC), sample_rate (default 250 kHz — keep low, it's a Pi Zero 2 W), flex (an -X spec).

A dongle plugged in after boot is picked up automatically — status re-probes while the SDR is idle, so there is no need to restart the portal. If device stays false, the dongle really is absent or not enumerating.

Pin gain on anything you will compare. On AGC the tuner rescales from whatever it saw recently, so the same quiet band reads tens of dB apart between calls and a strong carrier compresses instead of standing clear. This bites hardest on power, where the whole point is comparing numbers.