SDR Project Design

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

1. 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

1. 3. Pick the dominant upstream inspiration

Use the matching family reference first, not the whole landscape blob.

1. 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.

1. 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

1. 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

1. 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.

1. 8. Recommend one build path, not ten

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

1. 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" → INLINECODE4
• project still fuzzy / missing requirements → INLINECODE5
• scanner / dispatch / public safety → INLINECODE6
• browser receiver / remote tuning → INLINECODE7
• satellite / weather / pass-based capture → INLINECODE8
• unknown signal / reverse engineering → INLINECODE9
• desktop live exploration, ADS-B, APRS, packet, or utility modes → INLINECODE10
• architecture, system decomposition, and implementation planning → INLINECODE11
• how to actually assemble the stack → INLINECODE12
• how SDR ideas map onto OpenClaw host/node/service/dashboard structure → INLINECODE13
• cross-platform deployment choices (Linux/Windows/macOS/Pi/native vs container) → INLINECODE14
• hardware/runtime pain and common breakage → INLINECODE15
• SDR hardware/driver integration (RTL-SDR, SDRplay, HackRF, USRP, SoapySDR bindings, USB passthrough) → INLINECODE16
• worked example OpenClaw builds → INLINECODE17
• dashboard / UI design patterns for SDR observatories → INLINECODE18

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