A complete appliance build

Key takeaways This is the whole module as one recipe: a hardware list with reasons, then seven build phases — flash → harden → prove the dongle → daemon foreground → service → tune → monitor & back up — each ending in an acceptance test that must pass before the next phase starts. The finished state: a Pi in a closet decoding trunked radio 24/7, console on every device in the house, invisible to the internet, self-healing, monitored, and restorable in ten minutes. Build it in order; the order is the method.

Thirty lessons of ideas become one afternoon of build. Nothing here is new — that’s the point: every step links back to the lesson that taught it, and each phase ends with a test that proves the layer before you stack the next. Follow it as a checklist the first time; after that, it’s simply how you build appliances.

What goes in the box?

The shopping list, each line carrying its unit’s reasoning:

Part	Spec	Why (lesson)
Board	Current full-size Pi, 4 GB+	CPU + USB headroom (Picking a board)
Storage	High-endurance SD 64 GB+, or SSD	Continuous writes (Storage)
Power	Official/name-brand supply	Undervoltage is the classic gremlin (Power)
Case	Vented or thermal metal, mountable	Sustained load, closet ambient (Cooling)
SDR	Name-brand RTL-SDR (TCXO)	The radio (Connecting an SDR, hardware guide)
Network	Ethernet cable to the router	Reliability + RF silence (Networking)
Antenna	Suited to your band, metres of coax	Distance from the board’s hash (Gotchas, antennas)

Phases 1–2: a hardened headless base

Flash (lesson): Raspberry Pi OS Lite 64-bit via Imager — hostname scanner, your user, SSH on. Boot on Ethernet. Find and enter (lesson): ssh matt@scanner.local, health tour, note the IP. Harden (lesson): full upgrade, unattended-upgrades on. Pin a DHCP reservation (lesson). Push SSH keys, disable password login — new-door-before-old-door (Remote administration). Arm the hardware watchdog (RuntimeWatchdogSec=15 — Watchdogs) and cap the journal (SystemMaxUse=64M — SD-card wear).

Acceptance test: reboot; the board returns on the same address, key-only SSH, vcgencmd get_throttled reads 0x0.

Phase 3: a proven radio

Blacklist the DVB module, apt install rtl-sdr, dongle straight into the board (Connecting an SDR). Antenna on its coax, metres from the board (Gotchas).

Acceptance test: two minutes of rtl_test with zero lost-sample lines, and get_throttled still clean under the dongle’s load.

Phases 4–5: the daemon, foreground then service

Install the arm64 binary, write the minimal one-system config, and run foreground in tmux until the control channel locks and a call records (Install GopherTrunk on a Pi). Open http://scanner.local:8080 from the sofa. Then promote: dedicated user, the unit file with Restart=on-failure, enable --now, retention policy set in config.

Acceptance test: the power-cycle test — pull the plug, wait two minutes, console up, lock reacquired, calls flowing, nobody logged in.

Phase 6: tuned to its budget

During the busy hour: htop, load average, journal grep for can’t keep up (Tuning for small CPUs). Trim captured bandwidth and concurrency until sustained CPU sits ≤50% with throttling flags clean.

Acceptance test: a full busy hour with no overrun warnings, no dropped samples, temperature equilibrium under ~70 °C.

Phase 7: watched and recoverable

The health-check script on a timer — vitals logged, thresholds alerting, weekly heartbeat. Golden image of the finished card, config/data rsync on schedule to another machine, and the restore rehearsed once on a spare card (Backups & images). Access stays LAN-only; remote listening via VPN or tunnel (Appliance networking).

Acceptance test: kill the daemon (sudo systemctl kill gophertrunk) — it self-restarts and the alert arrives. Boot the spare card — the clone decodes. Now, and only now, put it in the closet.

Where do you go from here?

You’ve built the thing this module exists to teach — and picked up the whole embedded discipline on the way: headless Linux, services, buses, reliability engineering, and a working scanner as proof. Three roads onward:

Become a better operator of what you built: the Scanning & Monitoring module — finding systems, scan lists, feeds, and the craft of listening.
Understand the signal path beneath the daemon: the RF & SDR module from antenna to decoded bits.
Scale the ops skills up: the Deployment module — containers, CI, and fleet-grade monitoring; your appliance habits transfer directly.

And the build itself keeps evolving — the SBC build guide tracks hardware and config as boards change. Keep the glossary handy as a reference.

Quick check: why does the recipe demand an acceptance test at the end of every phase?

Recap

The build is seven phases — flash, harden, prove the dongle, foreground, service, tune, monitor & back up — each gated by an acceptance test.
The hardware list is the module’s units made shoppable: headroom, endurance, clean power, cooling, antenna distance.
The two decisive gates: rtl_test clean before any decoder, and the power-cycle test before calling it an appliance.
Finished state: 24/7 decoding, LAN-only console, self-healing, monitored, ten-minute restore — an embedded system in the full sense of lesson 1.
The path continues in Scanning & Monitoring, RF & SDR, and Deployment.

Next up: you’ve completed the module — take the operator’s road with Scanning & Monitoring, or level up your ops with Deployment.