SDR Project Design

Design, compare, research, and plan SDR projects for OpenClaw. Use when the user wants broad SDR research, beginner orientation, hardware/software selection,...

Security Scan

This is an instruction-only SDR project design skill whose requested resources, instructions, and references are consistent with its stated purpose and it does not request credentials or install arbitrary code.

Purpose & Capability

The name/description (SDR project design for OpenClaw) matches the content: all required references, heuristics, and runbooks relate to SDR stacks, hardware, deployment choices, and OpenClaw mapping. There are no unrelated environment variables, binaries, or permissions requested that would be inconsistent with the stated purpose.

Instruction Scope

SKILL.md and the included references stay on-topic (intake, architecture, hardware-driver notes, container/native deployment, example builds). The text includes operational commands and host-level suggestions (e.g., starting sdrplay_apiService, apt installs, Docker-bindmount examples, use of SoapySDR Python bindings) that are normal for SDR ops but would require the user/administrator to perform privileged host actions. The skill does not itself instruct the agent to read unrelated system files or exfiltrate data; it only directs the agent to read internal reference files included in the skill.

Install Mechanism

No install spec and no code files that would be written to disk — the skill is instruction-only. The references suggest typical package and container steps as guidance, but the skill does not attempt to download or install code itself.

Credentials

The skill requires no environment variables, credentials, or config paths. References mention env vars like SOAPY_SDR_PLUGIN_PATH as configuration guidance for SDR runtimes, which is proportionate to the domain and clearly explained.

Persistence & Privilege

always is false (not forced into every agent run) and the skill does not request persistent system-wide changes or modify other skills. The default ability for the model to invoke the skill autonomously is allowed by platform defaults; there are no other privileged flags or behaviors requested.

Assessment

This skill is a documentation-driven, design-focused tool and is internally coherent with its SDR design purpose. It does not request secrets or perform installs by itself. However, many of its recommendations are operational (starting daemons, installing packages, bind-mounting host libraries, running container commands) and therefore require administrator privileges and careful review before you run them on any host. Before acting on implementation instructions: (1) review any suggested shell commands and Docker mounts to avoid unintended changes to your system, (2) run them on a test host or in a controlled environment where you can recover if something breaks, (3) ensure you comply with local laws and rules around radio reception/transmission and public-safety data, and (4) if you want stricter control, disable autonomous skill invocation or only call this skill interactively so it cannot be used without your explicit action.

Use this skill when the user wants to get an SDR project built in OpenClaw.

Treat this as an OpenClaw builder skill first and an SDR comparison skill second. That means your job is not only to know the SDR ecosystem, but to turn that ecosystem into an OpenClaw-friendly plan:

• what upstream project(s) to borrow from
• what should run as mode-specific services
• what should live in a dashboard or web UI
• what should store files/events/metrics
• what to build first so the user gets working value quickly

What this skill is for

This skill helps with:

• comparing SDR projects and picking the right stack
• designing end-to-end SDR architectures
• deciding between desktop, headless, web, and ingest-first designs
• choosing where decoding should happen
• structuring storage, APIs, event streams, maps, dashboards, and playback
• avoiding common SDR project mistakes like coupling hardware, DSP, and UI too tightly

Workflow

1. Run intake quickly If the user’s requirements are fuzzy, read references/project-intake.md and fill in the missing shape of the project.

2. Classify the project Put the request into one or more buckets:

   • scanner / dispatch / public safety
   • web receiver / remote tuning
   • satellite / weather / pass-based capture
   • unknown signal / reverse engineering
   • general desktop receiver / live exploration
   • data collection / observability / RF lakehouse

3. Pick the dominant upstream inspiration Use the matching family reference first, not the whole landscape blob.

4. Translate it into OpenClaw shape Default to these OpenClaw-native layers:

   • SDR-attached host or node that owns hardware
   • mode-specific ingest/decoder services
   • shared files/events/status outputs
   • dashboard / browser UI / automations above that

   Do not assume Docker, Unraid, or Linux unless the user does. If platform/runtime choice matters, read references/platform-deployment.md.

5. Separate the stack into layers Always reason in layers:

   • hardware + driver layer
   • source / ingest layer
   • decoder / classifier layer
   • event / storage layer
   • API / stream layer
   • UI / workflow layer

6. Prefer loose coupling Recommend architectures where the SDR hardware can be swapped, the decoder can be changed, and the UI can keep working. Favor:

   • SoapySDR or clean source abstraction
   • filesystem or queue-based handoff where practical
   • simple HTTP/JSON APIs for dashboards
   • containers for services, native install only where hardware bindings are fragile

7. Check failure modes before sounding confident If the plan touches vendor drivers, SoapySDR, USB passthrough, or hardware sharing, read references/common-failure-modes.md.

8. Recommend one build path, not ten Give one primary OpenClaw build path, then brief alternates only if they materially matter.

9. Use an example build when it helps If the request matches a common shape, read references/example-builds.md and borrow the closest pattern.

What to read

Read only the most relevant reference(s):

• broad SDR research, beginner orientation, or "help me understand the SDR landscape" → references/sdr-research-deep-dive.md
• project still fuzzy / missing requirements → references/project-intake.md
• scanner / dispatch / public safety → references/scanner-public-safety.md
• browser receiver / remote tuning → references/browser-receiver.md
• satellite / weather / pass-based capture → references/satellite-weather.md
• unknown signal / reverse engineering → references/reverse-engineering.md
• desktop live exploration, ADS-B, APRS, packet, or utility modes → references/general-desktop-and-utility.md
• architecture, system decomposition, and implementation planning → references/architecture-patterns.md
• how to actually assemble the stack → references/implementation-recipes.md
• how SDR ideas map onto OpenClaw host/node/service/dashboard structure → references/openclaw-build-patterns.md
• cross-platform deployment choices (Linux/Windows/macOS/Pi/native vs container) → references/platform-deployment.md
• hardware/runtime pain and common breakage → references/common-failure-modes.md
• SDR hardware/driver integration (RTL-SDR, SDRplay, HackRF, USRP, SoapySDR bindings, USB passthrough) → references/hardware-driver-integration.md
• worked example OpenClaw builds → references/example-builds.md
• dashboard / UI design patterns for SDR observatories → references/dashboard-ui-patterns.md

Heuristics

• Trunked/public-safety ingest: start with trunk-recorder or sdrtrunk; add rdio-scanner or scanner-map above them.
• Call mapping / AI summaries / geocoding / dispatcher UX: scanner-map is the strongest inspiration.
• Browser-based tuning and multi-user receiving: prefer openwebrx+; treat vanilla OpenWebRX mainly as lineage/background unless there is a specific compatibility reason not to.
• Desktop live tuning and general exploration: SDR++, GQRX, CubicSDR.
• Satellite capture/processing: SatDump first.
• ADS-B / aircraft observability: readsb / dump1090 class decoders plus tar1090 for map/UI are the default reference stack unless the user wants something stranger.
• APRS / packet / igate ideas: Dire Wolf is the default practical reference. Note: SDRplay/RSP1B requires SoapySDR + FM demod → FIFO pipeline, not rtl_fm directly.
• Unknown 315/433/868/915 protocol work: rtl_433 for known devices, URH + inspectrum + SigDigger for discovery/reverse-engineering.
• Deep custom DSP: GNU Radio.
• Hardware abstraction / avoiding vendor lock-in: SoapySDR, but be wary of plugin/runtime/version mismatch.

Output shape

When helping the user, usually give:

• best-fit stack
• why this stack
• OpenClaw layout (what runs where)
• what each layer does
• implementation order
• likely pain points

OpenClaw defaults

Unless the user asks otherwise, prefer:

• SDR hardware owned by the host or paired node physically attached to it
• one mode-specific runtime per mode instead of one giant SDR app
• one shared dashboard/UI that reads files, JSON, metrics, and status from those mode services
• lightweight automation around outputs, not around raw DSP internals
• browser control or dashboard UI for operators, with a separate debug/maintenance path

A mode-specific runtime can be:

• a container
• a native service
• a pinned app/runtime on Windows or macOS
• a dedicated SBC/node process

If a project looks like a polished web product, borrow the upstream UX ideas but keep the OpenClaw build split into:

1. hardware/driver ownership
2. decoder/ingest services
3. storage/event outputs
4. web/dashboard layer

Important SDR reality checks

• Driver stacks matter as much as app choice.
• SoapySDR is great, but version mismatches and vendor plugin/runtime issues are common.
• Satellite, trunking, and ISM projects often want different sample-rate, storage, and scheduling assumptions.
• A good SDR project usually has two UIs:
  • an operator UI
  • a maintenance/debug path

Good default design style

For a home-lab “radio observatory” style project, prefer:

• headless ingest services on the machine with the SDR attached
• web UI separate from the hardware-specific code
• append-only event storage for decoded things
• saved IQ/baseband only when needed, not for everything
• mode-specific services rather than one giant app trying to do all DSP paths at once