The server bundle — overview
The server bundle is what you install on the machine that sits near your radio (a Raspberry Pi, a shack PC, a Mac — anything that’s on the same LAN as the radio). It contains two programs:
-
podsdr-proxy— the server. It does up to three jobs at once, all in one process:- Serves the web client over HTTP(S) from the bundled
web/directory. - Bridges radio traffic between browsers/Android (WebRTC data channels) and the radio (UDP on the LAN). It discovers OpenHPSDR radios itself and offers them to clients in a device list.
- Optionally uplinks to the cloud broker, so clients outside your network can reach the radio with no port forwarding.
Beyond OpenHPSDR hardware, the proxy can also host traditional CAT transceivers (Xiegu, QRP Labs QMX, Icom — including network-connected Icoms — Yaesu, BG2FX; see the supported list) and composite radios that combine two devices into one (e.g. RX on one radio, TX on another). Those appear in the same device list as the SDRs.
- Serves the web client over HTTP(S) from the bundled
-
podsdr-emu— a Protocol-1 radio emulator. Started manually when you want a virtual radio on the LAN; see Using the emulator.
The bundle also carries the web/ directory with the browser client the
proxy serves — see
what’s inside a server bundle.
The two launchers
| Launcher | What it starts |
|---|---|
run.sh / run.bat | LAN web server only: HTTPS on port 8080 (pass a port number to change it, or --no-tls as the first argument for plain HTTP). |
run-cloud.sh / run-cloud.bat | Cloud-broker uplink plus the same LAN web server. Set NO_LOCAL_WEB=1 to run a pure uplink with no local web server. |
Both are thin wrappers over podsdr-proxy command-line flags — see the
command-line reference if you want to compose your own invocation.
Where to go next
- Serving the web client on your LAN
- Remote access through the cloud broker
- Running as a system service
- Configuration file — CAT radios, RTL-SDR, composite radios, receive-only bands, audio gain