One Pi, Every Mode
A single Raspberry Pi that ties together most of the ways a ham station talks: analog and digital voice, two mesh networks, packet, and email over radio. One box, bridged, that keeps working whether the internet is up or not.
Overview
Most ham gear does one thing. A DMR radio does DMR. A packet TNC does packet. A Winlink client does email. This is an attempt to put the connective tissue in one place: a single Raspberry Pi that bridges those worlds so a message can start on one and come out another.
The plain version: one small computer that lets voice, text, and email cross between systems that normally cannot talk to each other, and that keeps working off the internet when it has to.
What is connected
VOICE DATA / MESSAGING
AllStar (VoIP) --+ Meshtastic (LoRa) --+
System Fusion --+ MeshCore (LoRa) --+
DMR --+ APRS --+
| |
v v
+-----------------------------------------------+
| one Raspberry Pi |
| MMDVM + DVSwitch voice bridges |
| mesh command gateway |
| Winlink (Pat) . APRS bridge . web console |
+-----------------------------------------------+
| |
v v
cross-mode voice commands + email,
(any mode <-> any) over RF or internet
The pieces
Voice. An AllStar node and an MMDVM digital stack share the Pi, bridged through DVSwitch so an analog AllStar user, a System Fusion handheld, and a DMR handheld can land in the same conversation. More modes can follow the same pattern.
Mesh. Two LoRa mesh networks run side by side: Meshtastic and MeshCore. A command gateway listens on both. Send a short text on a private channel and the station answers: weather, grid, a situation report, nearby repeaters, a callsign lookup, or a question routed to an assistant. The same commands work over APRS.
Email over radio. A Winlink client runs on the Pi, so mail and formal reports move with no internet at all.
The console. A web dashboard sits over all of it: a live routing map, HF propagation, config and control, radio programming. One place to see and drive the station.
Why one box
Two reasons. The first is that bridges only work when the things they bridge are in the same place at the same time. Putting them on one always-on Pi is what makes the cross-connections possible at all.
The second is resilience. The internet paths are nice when they are there. The RF paths keep working when they are not. A SITREP can go out over Winlink. A command can come back over LoRa. The station does not have a single thing that, when it fails, takes everything else with it.
Results so far
Analog to Fusion and to DMR is bridged and verified on the air. The mesh gateway answers over Meshtastic, MeshCore, and APRS, and reaches the field over the internet when direct RF is out of range. Winlink is integrated. The console runs the whole thing. Each of these has its own writeup; this is the map that holds them together.
Lessons
- Interop is a place, not a feature. The value is not any single bridge. It is that they all terminate on the same box and can be wired to each other.
- Design for the internet being gone. Every path that can have an RF fallback should have one. Treat the internet as a bonus, not a dependency.
- One box is also one failure domain. Keep the services isolated enough that a crash in one does not take the others down. That constraint shaped most of the build.