A Raspberry Pi Software-Defined Radio That Boots Straight into a Touch Dashboard

The client had a Raspberry Pi 4, a mini HDMI display and an ADI PlutoSDR+, and wanted the combination to behave like an appliance rather than a computer: power it on, and it is a radio. No login, no terminal, no remembering which command starts which stack.

What we built

• Kiosk boot — auto-login into a session that loads the desktop and the SDR stack on power-on, scaled correctly for the small display, identically every time. No keystrokes required to reach a working state.
• Touch dashboard — a Python front end wrapping the SDR stack so receive, decode and PlutoSDR transmit/receive functions are one-touch controls rather than command lines.
• Wi-Fi hotspot — hostapd, dnsmasq and NAT configured so the Pi rebroadcasts whatever real internet path is fed into it (satellite modem, LTE stick or ethernet) to any device that joins.
• Licence gate — server-authoritative activation with a two-day evaluation licence, so an image can be handed out for trial without handing out the product.
• Remote diagnostics — a log agent shipping Pi logs to a collector, so a field unit that misbehaves can be investigated without physically retrieving it.
• Repeatability — an install.sh, image build notes and a step-by-step rebuild guide, so the build is reproducible rather than a one-off hand-tuned card.

Scoping out what could not be done

The headline request in the original brief was free two-way internet pulled off open satellites. That is not achievable on a PlutoSDR — a receive/transmit radio is not an authorised satellite-internet terminal, and open downlinks are almost entirely one-way broadcasts. We said so before starting, wrote it into the project's scope-and-risk document, and excluded it from the agreed build, replacing it with the hotspot that rebroadcasts a real internet path the Pi is actually given.

It is a small thing to record and an important one. The alternative — accepting the brief as written and discovering the physics later — costs the client the whole budget and the schedule.

Status

The full deliverable tree was built: boot configuration, dashboard, hotspot, licensing, logging, installer and rebuild documentation. We hold no record confirming the build was shipped to and accepted by the client, so we present it as work completed on our side rather than a closed engagement.