DigiPi Hotspot — Vol 2: Operating the Modes

2.1 About this volume

Volume 1 explained what DigiPi is. This volume is the operator’s manual: how you actually run each mode, in the browser, once the box is connected to a radio and joined to your network. The hardware that makes the audio-and-PTT connection to your radio is Vol 3’s subject — here we assume it exists and works, and focus on the software workflow you drive from http://digipi/.

DigiPi’s home page is essentially a launcher: a set of tiles or links, one per mode or service. You pick a mode, a mode-specific page or app opens, and you operate. The unifying idea is that every application below — Direwolf, Pat, WSJT-X, JS8Call, FLDigi — has been pre-configured to share the one audio device and the one PTT line your interface provides, so you do not juggle sound-card settings. You mostly just choose a mode and go.

A standing caveat for the whole volume: exact page labels, button names, and menu paths are drawn from public documentation, not from a unit on the author’s bench. Where the precise wording or on-screen flow matters, it is flagged TBD — verify so you confirm it against a real image rather than trusting a paraphrase.

2.2 Operating APRS

APRS — the Automatic Packet Reporting System — is the tactical, real-time side of packet: position beacons, short messages, weather, and telemetry, all sharing a national simplex channel (144.390 MHz in North America) and cross-linked to the internet via IGates. It is DigiPi’s flagship use case, and the 2.x images lean into it hard.

Under the hood, APRS on DigiPi runs on Direwolf, the well-known software TNC, in the current beta build bundled with the 2.x image. Direwolf demodulates the 1200-baud AFSK packets your radio hears and modulates the ones you transmit, entirely in software — no hardware TNC required. Because it is all software, the same engine that beacons your position also does the digipeating, the IGating, and the messaging; you are not adding hardware for each role, just enabling more of Direwolf’s capabilities. Everything below is Direwolf wearing different hats.

In North America, APRS lives on the national simplex channel 144.390 MHz (other regions use different frequencies), so an FM radio on that channel plus DigiPi is a complete APRS station. That single-frequency simplicity is part of why APRS is such a natural first mode for a new DigiPi owner.

2.2.1 The Direwolf dashboard

The headline 2.x feature is an animated APRS tactical map, the “Direwolf Dashboard.” Rather than reading raw packet lines, you get a live map with stations plotted and updating as beacons arrive — position, movement, and identity at a glance. For situational awareness during an event or a net, this is the difference between staring at a scrolling log and simply seeing who is where.

TBD — verify. Confirm the exact name, layout, and controls of the Direwolf Dashboard on the current image (zoom/pan behavior, what station detail a tap reveals, whether it plots your own position). Described from documentation only.

2.2.2 APRS WebChat: sending and receiving messages

APRS is not only positions — it carries short text messages between stations, acknowledged end-to-end. DigiPi 2.x exposes this through an APRS WebChat / messaging interface: a browser page where you type a message to another callsign, send it over the air (or via IGate), and see incoming messages and acknowledgements. It turns APRS messaging into something that feels like a chat app, which is exactly the friction-remover DigiPi is built to be.

TBD — verify. Confirm the WebChat page’s exact behavior: addressing by callsign-SSID, ack handling, bulletin support, and whether it sends via RF, IGate, or both. Described from documentation.

2.2.3 Digipeater and IGate

Two classic APRS infrastructure roles are built in:

Digipeater — DigiPi can repeat received APRS packets back out on RF, extending the reach of the network in your area. You configure the aliases it responds to (WIDE-style paths) and it relays qualifying packets.
IGate (Internet Gateway) — DigiPi can bridge RF APRS traffic to and from the APRS-IS internet backbone. As a receive IGate it feeds locally-heard stations up to the network (where they appear on aprs.fi and the like); with the right configuration it can also gate messages back down to RF.

Running either responsibly means understanding local band conventions — a poorly-configured digipeater or a promiscuously gating IGate is a nuisance, not a contribution. But the capability is there, one Pi and one radio, no separate hardware.

TBD — verify. Confirm exactly how digipeater aliases and IGate parameters (APRS-IS server, passcode, filter, RF-gating rules) are entered in the DigiPi web UI, and whether there are sane defaults. Described from general APRS practice plus documentation.

2.3 AX.25 packet, KISS, and Bluetooth TNC

Beneath APRS sits general AX.25 packet — the connected-mode and unconnected-mode data networking that APRS is a specialized use of. DigiPi supports classic packet networking, so you can work packet BBSes, keyboard-to-keyboard connections, and other AX.25 services where they still live on VHF/UHF.

The key to packet’s flexibility is the KISS TNC interface. KISS (“Keep It Simple, Stupid”) is the minimal framing protocol that lets external software drive a TNC. DigiPi exposes Direwolf as a KISS TNC, which means any KISS-speaking application — on the Pi or, crucially, on another device — can use DigiPi as its modem.

That “another device” path is where the Bluetooth rfcomm TNC comes in, one of the marquee 2.x additions. DigiPi can present its TNC over a Bluetooth serial port (rfcomm), and it ships a Bluetooth pairing web interface to make the connection. The payoff: pair your phone and run a mobile app like APRSdroid using DigiPi (and thus your real radio) as the TNC — wirelessly. You get APRSdroid’s polished mobile UI driving a proper radio through DigiPi, no cable between phone and Pi.

TBD — verify. Confirm the Bluetooth pairing flow in the web UI and that APRSdroid (or a named KISS-over-Bluetooth app) connects and passes traffic on the current image. Confirm which rfcomm channel/profile is used. Described from documentation.

2.4 Winlink email with Pat

Winlink is the amateur radio email system — a global network that lets you send and receive genuine email (including to and from regular internet addresses) over RF, with no internet at the radio end. It is a cornerstone of EmComm, and it is one of the strongest reasons to own a DigiPi.

DigiPi’s Winlink client is Pat, a modern, cross-platform Winlink program with a clean web interface: an inbox and outbox that read like ordinary email. You compose a message, drop it in the outbox, connect to a Winlink gateway, and Pat exchanges your queued mail. Incoming messages land in the inbox. Because Pat’s UI is itself a web app, it slots perfectly into DigiPi’s browser-driven model.

Winlink needs a transport — a modem to carry the mail over RF — and DigiPi gives you two, matched to your radio:

ARDOP over HF. On an SSB HF rig, the ARDOP modem (Amateur Radio Digital Open Protocol) carries Winlink over the shortwave bands. This is the long-haul path — you connect to an HF Winlink RMS gateway hundreds or thousands of miles away and pass mail with no local infrastructure at all. It is the classic “email from anywhere” capability.
Packet over VHF/UHF. On an FM rig, Winlink rides ordinary AX.25 packet (via Direwolf) to a nearby VHF/UHF RMS packet gateway. Shorter range, but faster and simpler where a gateway is in reach.

So the same Pat inbox serves both: which transport you pick is a function of which radio you have connected and which gateway you can reach. For a go-kit, the HF/ARDOP path is the headline; for a metro area with a packet gateway, VHF packet is often quicker.

TBD — verify. Confirm on a real unit how you select ARDOP-HF vs packet-VHF within Pat on DigiPi, how gateways/RMS stations are chosen, and how the Winlink account/password is entered. Also confirm the bundled Pat version (fact sheet notes 1.0.0). Described from documentation and general Winlink practice.

2.5 Weak-signal HF: FT8 and JS8Call

The weak-signal digital modes are DigiPi’s HF playground, and they are why a USB-CAT HF rig pairs so naturally with the box.

2.5.1 FT8 with WSJT-X

FT8 is the mode that reshaped HF operating: extremely short, structured exchanges that decode well below the noise floor, letting you make contacts on signals you cannot even hear. It is fast, it is automated, and it works stations worldwide on modest power and antennas. DigiPi runs it through WSJT-X (version 3.0.1 in current images), the reference application for the WSJT family. You get the familiar waterfall, decode window, and the semi-automated QSO sequencing — driven, like everything here, from the browser.

Because FT8 is time-critical (its 15-second transmit cycles demand an accurate clock), the Pi’s system time needs to be correct — normally handled automatically once DigiPi is on your network with internet access.

TBD — verify. Confirm how WSJT-X’s UI is presented over the browser on DigiPi (native app streamed, VNC-style, or a web wrapper), how band/frequency is set, and that time sync is automatic on the current image. Confirm the WSJT-X version. Described from documentation.

2.5.2 JS8Call

JS8Call takes the robust, weak-signal FT8 waveform and turns it into something conversational: keyboard-to-keyboard messaging, relaying, and store-and-forward, so you can actually chat (slowly) and pass messages far below the noise floor. Where FT8 is optimized for brief structured contacts, JS8Call is optimized for content — check-ins, messages, even a form of low-bandwidth email-like relay. DigiPi bundles it as a first-class mode. It shares the same audio and CAT plumbing as WSJT-X, so switching between them is a matter of choosing the mode on the DigiPi home page.

TBD — verify. Confirm how JS8Call is launched and presented in the DigiPi browser UI, and that it shares CAT/audio configuration with WSJT-X without manual reconfiguration. Described from documentation.

2.6 FLDigi: CW, PSK31, RTTY, MFSK, SSTV

FLDigi is the venerable multimode workhorse, and DigiPi bundles it to cover the classic keyboard modes that WSJT-X does not:

PSK31 — the efficient, narrow, ragchew-friendly phase-shift-keying mode that made HF digital popular.
RTTY — radioteletype, still alive and well in contests and casual operating.
CW — Morse, sent and decoded by software (with the usual caveat that machine CW decode is only as good as conditions allow).
MFSK modes — robust multi-tone modes like MFSK16 for tougher paths.
SSTV — slow-scan television, sending and receiving still images over SSB. (The fact sheet lists SSTV among DigiPi’s services; whether SSTV lives inside FLDigi or a dedicated app on your image is worth confirming.)

FLDigi’s own interface is dense — decades of features — but for DigiPi’s purposes it means one app covers a huge swath of the digital-mode spectrum. Pick FLDigi from the home page, choose your sub-mode, and operate.

TBD — verify. Confirm how FLDigi is presented in the DigiPi browser UI, which sub-modes are enabled, and specifically whether SSTV is handled within FLDigi or a separate application on the current image. Described from documentation.

2.7 Rig control with rigctld

Everything above needs the radio to be on the right frequency and in the right mode — and for a USB-CAT rig, DigiPi can control that directly. rigctld is the Hamlib rig-control daemon: it speaks the CAT protocol of hundreds of radios and presents a common interface the mode apps use to set frequency, change mode (USB/LSB/FM), and — importantly — key PTT over the data connection rather than a separate wire.

On a USB rig (IC-7300, IC-705, FT-991, Xiegu), the single USB cable carries audio in, audio out, CAT, and often PTT all at once, and rigctld ties the mode software to that CAT channel. That is why the USB-rig path is so clean: WSJT-X can read and set your frequency, Pat can key the transmitter, and you never touch the radio’s front panel once you are running. On a non-USB rig, PTT instead comes from a GPIO/serial line on the interface board (Vol 3), and rigctld’s role is reduced or absent since there is no CAT channel.

TBD — verify. Confirm how the radio model (Hamlib rig ID) is selected for rigctld in the DigiPi UI, which serial/USB device it binds to, and how PTT method (CAT vs GPIO/RIB) is chosen per radio. Described from Hamlib/general practice plus documentation.

2.8 Putting it together: a typical session

To make the workflow concrete, here is how an ordinary session tends to go, regardless of mode:

Power the DigiPi, which is already cabled to your radio and joined to your home Wi-Fi.
Open http://digipi/ in a browser on your phone or laptop.
Pick the mode from the home page — say, APRS, or Pat/Winlink, or FT8.
The mode’s page or app opens, pre-configured to use your interface’s audio and PTT.
Operate: watch the APRS map, send a Winlink email, work FT8 — all in the browser.
Switch modes by returning to the home page and choosing another tile.

The elegance is that the radio rarely changes — it stays on the mode’s frequency in FM or SSB — while DigiPi swaps which software modem is driving it. One box, one radio, a browser, and the whole data-modes catalog.

2.9 Matching modes to your radio

A recurring theme worth stating plainly, because it governs which of the above you can actually do: the mode you can run is bounded by the radio you have connected. DigiPi is mode-agnostic in software, but the physics is not.

An FM radio — a handheld or a VHF/UHF mobile — gives you the FM data modes: APRS, AX.25 packet, the Bluetooth TNC, and VHF Winlink over packet. These live on 2 m and 70 cm, they are line-of-sight-plus, and they are cheap to get into. What an FM radio cannot do is the weak-signal HF modes, because those need single-sideband.
An HF SSB radio gives you the weak-signal and long-haul modes: FT8, JS8Call, ARDOP-Winlink, and the FLDigi modes (PSK31, RTTY, MFSK, CW, SSTV). These reach across continents on modest power, but they demand an SSB transceiver — you cannot run FT8 through a Baofeng.

So when you look at the DigiPi home page, mentally grey out the tiles your currently-connected radio cannot serve. Hook up an FM HT and the HF tiles are decorative; hook up an SSB HF rig and the APRS/packet tiles wait for a different radio. Many operators keep both radios around and simply move the DigiPi (or its interface) between them depending on the day’s operating.

2.10 A note on shared audio and one-mode-at-a-time

One practical consequence of DigiPi’s single-audio-device design is worth internalizing: the modes generally run one at a time. Because Direwolf, WSJT-X, Pat, JS8Call, and FLDigi all want the same sound device and the same PTT line, you select a mode and that mode owns the radio until you switch. You are not, in the normal case, simultaneously running FT8 and monitoring APRS on the same box and radio — you pick one. This is rarely a limitation in practice (you are on one frequency, in one mode, on one radio anyway), but it explains why the interface is a launcher rather than a dashboard of everything running at once.

TBD — verify. Confirm on a real unit whether any modes can genuinely run concurrently (e.g. a background APRS/IGate while another mode is foregrounded) or whether mode selection is strictly exclusive on the current image. Described from the shared-audio architecture; not bench-confirmed.

Which radio, and what it takes to wire it up, is Vol 3.