A portable communications server built around a Raspberry Pi 4 with dedicated routing, integrated cellular internet, GPS-disciplined NTP, LAN file sharing, web monitoring, and multi-protocol radio interface/hotspot.
What started as an annoyance caused by Windows networking has evolved into my first end-to-end hardware and software project.
With that said, all code will be reviewed by me (not just hey it works, let's keep going) and all ideas / designs will be 100% human generated.
This GitHub will also use a mix of my own writing and AI-generated text. All text was generated by using a source file I wrote myself or prompts that I heavily refined. I am learning how to use GitHub, and I'd rather have a nice AI-generated page than a gross-looking human-generated one because I don't know what I'm doing.
- Simple and straightforward software setup with a single script
- Reliable LAN communication between connected clients
- Samba file share reachable by connected clients
- NMEA GPS-disciplined / internet NTP reference for connected clients
- Optional cellular internet connectivity for connected clients
- Multi-Protocol radio interface (APRS, Meshtastic, Pi-Star)
- Rugged and durable enclosure for field deployment
- Emergency/grid power capable
- Easy operation by non-technical users
For more detail, see Project Overview.
PCS software is currently beta-quality but working. Pi-side installs are repeatable, and the base installer configures the core network, storage, time, monitoring, WWAN/GNSS, and optional APRS, Pi-Star, and Meshtastic support. Modem firmware or USB-composition changes, credentials, unavailable external appliances, radio identity, and RF activation remain deliberate operator-supervised steps.
The PCS hardware is an operational v1 prototype. The AC/DC source selector, cooling fans, Pi-Star hotspot, cellular/GNSS path, external SMA antennas, HD44780 LCD, MAX7219 matrix, WS2812 indicators, and APRS subsystem are installed.
The SA818S, stock Easy Digi, GPIO6 PTT, USB audio, 144.5500 MHz RF path, GNSS beaconing, two-way APRS-IS, messaging, and WIDE1-1 fill-in operation have been validated. The RAK4631 persistent USB/MQTT gateway and GPSD position delivery are live-validated, including successful encrypted proxy publishes to the NeoMesh broker, opted-in hourly map reporting, public-map appearance for IJC1, and RF-to-public-map forwarding of an opted-in IJC2 position heard over LoRa. PCS sends its GPSD-backed Meshtastic position every 30 minutes with 15-bit channel/map precision. Broader RF coverage and the case-sensor baseline remain operator checkpoints. The exact as-built electrical and mechanical record is also unfinished.
- Raspberry Pi 4 8GB service host and network gateway
- Linksys EA4500 running OpenWrt as the AP and Ethernet switch
- Sierra Wireless EM7565 connected through a USB WWAN adapter
- LTE and active GNSS antennas with validated cellular registration and 3D GNSS fixes
- DS1307 I2C RTC for a sane boot-time reference
- Removable USB primary storage with an SD-card backup mirror
- Optional Pi-Star hotspot integrated at
10.42.0.3 - Operational AC/DC power system with source selector switch; as-built electrical measurements and wiring records remain pending
- HD44780 16x2 LCD, MAX7219 8x8 annunciator, and six-pixel WS2812 status chain
- GPIO18 hardware-PWM fan control; commanded duty is validated but RPM is not measured
- SA818S/Easy Digi APRS subsystem with Sabrent USB audio, GPIO6 PTT, direct UART control, and validated bidirectional RF/APRS-IS operation
- RAK4631 Meshtastic expansion connected over USB with validated persistent NeoMesh MQTT proxy, 30-minute GPSD position delivery, hourly map reporting, demonstrated remote RF reception/map forwarding, and an uplink-only mirror for the MQTT map embedded on the NeoMesh Meshtastic page; the mirror carries public LongFast traffic and explicit opt-in map reports; sensor placement and accuracy remain operator checkpoints
- Reliable unattended startup after power-on or reboot, with bounded GPIO boot indicators before live health alerts
- Public PCS status homepage and password-protected administration at
10.42.0.1 - Pi-side self-test and status scripts
- USB primary Samba share with SD-card backup mirror
- GPS NMEA from
/dev/ttyUSB1through gpsd and Chrony to LAN clients - Installer-selectable manual cellular control or automatic Wi-Fi-to-cellular fallback; the commissioned PCS uses automatic mode, with live failover, cellular-only Internet, Wi-Fi recovery, and boot persistence validated
- LAN GPSD, NTP, and installer-assisted coordinated Pi-Star shutdown integration
- Managed Dire Wolf 1.8.1 startup with SA818S programming, ALSA level restoration, LAN-only AGW/KISS access, and guarded activation/rollback
- Repeatable Meshtastic USB/BLE MQTT gateway with privacy-safe public/admin dashboard status, guarded restart, broker/proxy policy validation, GPSD position delivery, public-map forwarding status, and local environment telemetry
- PCS Pi SD-card wipe/rebuild most recently verified on August 18, 2026; the
current
mainstack was synchronized and passed 137 live self-tests with no warnings or failures on August 24, 2026; credentials, external-device recovery, and RF checks remain manual
- Capture final enclosure dimensions, mounting details, photos, and CAD references
- Reconcile the power and wiring documents with the physical as-built system
- Record measured rail voltages, current draw, fuse values, and thermal behavior
- Characterize Meshtastic range beyond the commissioned RF-to-map test and establish a referenced case temperature/humidity baseline
- Continue expanding automated and operator-supervised field validation
The outbound WireGuard remote-management plane was commissioned on PCS on
2026-08-26. It is an explicit, default-off base-installer choice using an
ignored private profile and individually authorized management-peer /32s.
The PCS API and Android companion remain paused local roadmap work and are not
deployed. See WireGuard Remote Management
and the Remote Management/API/Android Roadmap.
Before running setup, connect the hardware you want the installer to configure:
- Raspberry Pi booted from the target SD card. Tested with Raspberry Pi OS 64-bit Desktop; Lite has not yet been validated.
- Ethernet from the Pi to the PCS router/AP through a LAN port, not the WAN/Internet port.
- The PCS router/AP powered on.
- The RTC module installed, if this build includes the RTC.
- The WWAN modem installed and connected over USB, if this build includes cellular/GPS.
- The GPS/GNSS antenna connected to the WWAN modem, if configuring WWAN GPS/NMEA.
- The intended USB storage device connected, if using USB primary file storage.
- The 16x2 HD44780 LCD, six-pixel WS2812 indicator chain, and MAX7219 matrix connected to their documented GPIO lines, when fitted.
- The GPIO18 PWM fan connected, when using the Armor Lite cooler.
- The APRS USB sound card and radio interface, only when moving beyond software staging.
Clone the repository:
mkdir -p ~/Projects
cd ~/Projects
git clone https://github.com/Saberhawk09/PCS-Portable-Comm-Server.git
cd PCS-Portable-Comm-ServerRun the base setup:
./scripts/setup-pcs-base.shThe setup script installs the PCS software baseline, configures the Pi client network, and sets up Samba, Chrony, RTC support, Cockpit, the public PCS homepage, and the authenticated administrative control panel. When selected, it also configures Pi-Star monitoring and coordinated-shutdown pairing, can stage Dire Wolf without activating an RF path, can stage the persistent Meshtastic USB/Bluetooth MQTT gateway without connecting to a radio, and can install the 16x2 HD44780 status display, six-pixel WS2812 indicators, MAX7219 annunciator, and GPIO18 hardware-PWM thermal fan controller.
For more detail, see Raspberry Pi Setup and Script Reference.
Dire Wolf can be installed, rendered, policy-validated, and synthetically tested without attached APRS hardware or an enabled RF path. The documented workflow provides separate guarded RX/TX activation, managed SA818S and ALSA startup, LAN-only AGW/KISS, logs/dashboard telemetry, and transactional rollback. See Dire Wolf / APRS Integration.
After setup completes, reboot:
sudo rebootAfter the Pi comes back up:
cd /home/pi/Projects/PCS-Portable-Comm-Server
git status
./scripts/pcs-self-test.sh
./scripts/pcs-status.shExpected result:
nothing to commit, working tree clean
PCS Pi-side self-test PASSED.
An intentionally disconnected cellular profile is informational when manual mode is selected or Wi-Fi is active in automatic-fallback mode. Investigate every reported warning or failure before field use.
For more detail, see Testing Checklist.
Fresh installs ask whether cellular should remain manual or automatically serve
as a fallback when Wi-Fi is unavailable; the conservative default is manual.
The selected policy is saved in config/pcs-install.conf.
In wifi-fallback mode, PCS waits 30 seconds after active Wi-Fi is lost before
starting cellular. After Wi-Fi has been restored for 30 seconds, it disconnects
only a cellular session that the fallback service started itself. The
NetworkManager profile remains non-autoconnecting in both modes, and manually
started cellular sessions remain under operator control.
Change the installed policy at any time:
./scripts/setup-cellular-profile.sh --fallback wifi-fallback
./scripts/setup-cellular-profile.sh --fallback manualOpen the PCS homepage and select Admin Login:
http://10.42.0.1/
Authenticated operators can change the admin password from the administration page. If it is forgotten, rerun ./scripts/setup-pcs-control-panel.sh --reset-admin-password from an interactive Pi terminal.
For additional documentation, start here:
- Project Overview
- Bill of Materials
- Power System
- Network Topology
- Network Design
- WireGuard Remote Management - commissioned outbound management tunnel
- Remote Management, PCS API, and Android Companion Roadmap
- Raspberry Pi Setup
- Full-Stack Reinstall Runbook
- WWAN Card Setup
- GPS Network Sharing
- GPS, Internet NTP, and RTC Time Sources
- Pi-Star Integration
- Meshtastic USB/Bluetooth MQTT Gateway
- Samba File Share
- PCS Control Panel
- PCS GPIO Allocation
- Testing Checklist
- Release Checklist
- Script Reference
- Changelog
From a Windows client connected to the PCS access point, run:
ipconfigExpected:
IPv4 Address: 10.42.0.x
Subnet Mask: 255.255.255.0
Default Gateway: 10.42.0.1
Then test network access:
ping 10.42.0.1
ping 8.8.8.8
ping google.comExpected:
10.42.0.1replies from the Pi8.8.8.8confirms internet routing when an uplink is intentionally activegoogle.comconfirms DNS when an uplink is intentionally active
For more detail, see Testing Checklist.
From a device connected to the PCS network:
PCS Homepage: http://10.42.0.1/
PCS Admin Login: http://10.42.0.1/admin/
Cockpit: https://10.42.0.1:9090
Primary Share: \\10.42.0.1\PCS-Share
Backup Share: \\10.42.0.1\PCS-Backup
LAN NTP Server: 10.42.0.1
LAN GPSD Server: 10.42.0.1:2947 (optional)
Pi-Star Dashboard: http://10.42.0.3 (when selected during setup)
Windows NTP test:
w32tm /stripchart /computer:10.42.0.1 /samples:5 /dataonlyWindows File Explorer tests:
\\10.42.0.1\PCS-Share
\\10.42.0.1\PCS-Backup
For more detail, see PCS Control Panel and Samba File Share.
\\10.42.0.1\PCS-Share -> /mnt/pcs-usb/PCS-Share
\\10.42.0.1\PCS-Backup -> /srv/pcs-share-backup
PCS-Share is the primary field share on removable USB storage.
PCS-Backup is the SD-card backup mirror.
Manual sync:
./scripts/sync-pcs-share-to-backup.shFor more detail, see Samba File Share.
scripts/setup-pcs-base.sh- Main baseline setup workflowscripts/pcs-self-test.sh- Quick Pi-side validation testscripts/pcs-status.sh- Detailed system status outputscripts/setup-usb-primary-share.sh- Configure USB storage asPCS-Sharescripts/sync-pcs-share-to-backup.sh- Mirror USB primary share to SD backupscripts/setup-pcs-control-panel.sh- Install the public homepage and authenticated control panelscripts/setup-dashboard-redirect.sh- Install the legacy port 8080 redirect to/admin/scripts/setup-gpsd-lan-proxy.sh- Publish GPSD only on the trusted PCS LANscripts/setup-chrony-lan-ntp.sh- Configure GPS-first, Internet-second LAN NTP with RTC holdoverscripts/setup-rtc.sh- Configure the DS1307 and guarded boot-time RTC seedscripts/setup-pistar-pcs.sh- Apply or verify the Pi-Star PCS integrationscripts/setup-pistar-shutdown.sh- Pair the PCS shutdown button with Pi-Starscripts/setup-direwolf-aprs.sh- Stage, validate, activate, or recover the managed APRS subsystemscripts/setup-meshtastic-bluetooth.sh- Stage or configure the persistent Meshtastic USB/BLE MQTT gatewayscripts/setup-wireguard-management.sh- Opt-in WireGuard profile import and commissioned management workflowscripts/pcs_gpio.py- Inspect, simulate, and deliberately test PCS GPIO status hardware
See Script Reference for the full script list.
Installed and tested hardware:
- Raspberry Pi 4
- RTC module
- USB flash drive
- Linksys EA4500 running OpenWrt used as AP/switch
- Sierra Wireless EM7565 WWAN modem with external LTE and active GNSS antennas
- Pi-Star hotspot
- AC/DC source-selector power system and two 120 mm cooling fans
- HD44780 16x2 LCD status display
- MAX7219 8x8 health-annunciator matrix
- Six-pixel WS2812 status-indicator chain
- Armor Lite cooler with GPIO18 hardware-PWM fan control
- SA818S V1.2, stock Easy Digi, C-Media USB audio, GPIO6 PTT, and managed Dire Wolf APRS
- RAK4631 Meshtastic node over USB with NeoMesh MQTT, GPSD position, and public-map forwarding
Installed with as-built records or measurements pending:
- RAK4631 sensor model/mounting record and referenced environment baseline
Remaining documentation and validation:
- Record the exact as-built power components, fuses, wiring, grounding, rail measurements, and thermal results
- Capture final enclosure dimensions, mounting details, photographs, and CAD/export references
- Characterize Meshtastic range beyond the completed IJC2 RF-to-map test and establish a referenced case-sensor baseline
For more detail, see Bill of Materials and Power System.
As usual, when multi-billion dollar companies fail to understand how to code their software properly, open source comes to the rescue yet again.
During ARRL Field Day 2026 me and my amateur radio club ran into some networking issues. We had 3 Windows laptops running radio contact logging software for the event, and wanted all 3 to use the same log file for accurate tracking of stats.
The problem was simple:
Windows update.
During the Winter Field Day prior, we had used my Dell Latitude 7212 Toughbook for networking. All logging machines connected to my machine through the Wi-Fi hotspot function, and it worked well enough. The only problem was Windows not allowing me to turn the hotspot on without an internet connection. My Toughbook had a DW5821e cellular modem, but the signal was very marginal, so I had to make sure that once the hotspot was on, it never turned off.
Nerve wracking and annoying, but we made it work.
However.
With Windows being Windows, this suboptimal but functional solution never worked again.
It was an hour before start time, while everyone was setting up antennas I was configuring the network share. Only trouble was, Windows had other ideas. Devices couldn't connect to my hotspot, once connected my Toughbook never showed they were, they didn't have internet access, and I could never see my Toughbook share over the local network. It was a massive headache that was thankfully solved by a club member who let us use his portable cellular router while we sourced a replacement dedicated club router.
Once we had everything hooked up via Ethernet, all the file sharing worked and we never had a single issue with networking or the rest of the event. Needless to say I was annoyed. Not just at Windows, but at myself for assuming it would work properly and not planning ahead. Well the lessons from that mistake have evolved into this project.
The goal of this project isn't to replace commercial networking equipment or build a portable homelab grade server, it's to build a communications appliance specifically tailored to emergency communications exercises and other portable operations.