It’s been a while since we’ve posted regularly, but we are back with a new ungoing project – a portable server for EmComm use.
Why a Server?
To understand my rationale behind building a server rather than just using a field computer or tablet, we first need to understand what a server is and does.
Essentially, a server is simply a computer used to perform a dedicated function on behalf of “client” devices. You could for example upload your files to the cloud where a data server stores and indexes them rather than your personal device. This doesn’t just free up your devices resources but also allows those files to be accessed from your other devices as well rather than just the device they are stored on. This can be useful for all sorts of things, but how does it fit into my emergency communications plan?
Field computers have been becoming increasingly common for coordinating emergency response efforts using programs such as WinLink and certainly have a place in the ham shack. There are countless tools that a radio operator might find useful for both day to day operations and emergency use. But as we’ve already mentioned a server not only allows you to run these programs, but access them from multiple devices.
What I Wanted It To Do
Originally, my interest in building this server was from looking into FreeTAKServer. I wanted a compact portable server that could be set up either in a TOC or field environment without relying on outside infrastructure.
This TAK in a Box solution from Guerilla Dynamics was pretty close to fitting my needs. In fact, my original intent was to mimic their design with a Raspberry Pi as I preferred a smaller form factor and they have a wide consumer support base.
But as single board computers were hard to find at the time, I kept looking around and thinking of other use cases for the project – after all, who wants a one trick pony. I looked into various amateur radio applications such as bulletin board systems, SDR integrations, etc.
I also wanted to be able to use FTS over LoRa through the Meshtatic app or similar. This led me down the rabbit hole both in terms of hardware and software that in short led me to a 4 Pi cluster setup rather than a single SBC system, but we will get back to the hardware side in a minute.
Eventually this is how I decided to configure the Raspberry Pis in my cluster:
Since we will be booting our cluster over the network, I decided one of the Pi’s would be best used as a boot server. This ensures that our cluster can always boot over the local network, even if external networks are down (like when a natural disaster impacts internet availability). After booting the other Pi’s, its role becomes more administrative, routing traffic and issuing automated commands to the other nodes.
Software
- Preboot Execution Environment – Serve Boot Images Across the Network
- Network File System – Share the File System Across the Network
- DHCP Server – Assign IP’s to other Nodes, Clients and Route Traffic
- LogWatch – System Logs with Daily Summary
- Parallel SSH – Run SSH over any number of nodes asynchronously
- x11vnc – Broadcasts a View Only Session of the Monitoring Node
- NoVNC – A Web Based VNC Client That Acts as a Bridge Between the Cluster and Client
- Flask Access Control Script – Will Allow Switching To A Control Node IP Address for X11
- Flask HTTP Endpoint – Near Real Time Centralized Node and Network Status
Connected Hardware
- 2x 2TB Solid State Drives
- GPS Dongle
With the primary use case for the server being emergency communications, this Raspberry Pi is for amateur radio integration. Through the use of a handheld transceiver digital modes can be sent, recieved, and decoded via UHF/VHF and even HF radios connected directly to the server via the proper soundcard and adapter cables. A mobile QRP radio could also be adapted for this set up or it could be plugged into an existing radio system via different cables.
Software
- Pat WinLink – Email Over RF
- Direwolf – Software TNC for APRS and Packet
- CQRLog – Ham Radio Logging Tool
- JS8 Call Server Client – JS8 Call Integration with MQTT
- FLDigi – Encode and Decode Digital Modes
- XLM-RPC (Pre-Installed) – Can be Used to Control FLDigi from a Web Dashboard
- Flask HTTP Endpoint – Near Real Time Centralized Node and Network Status
Connected Hardware
- Dual Band Transceiver
Beyond traditional radio communications, I wanted to implement LoRa and mesh networking technology into the system. This not only gives us another tool at our disposal but also provides redundancy should traditional radio communications go down or encounter interference. The LoRa network is primarily decentralized in nature meaning clients nodes can still communicate without the server, but the server adds additional managing and routing capabilities.
Software
- FreeTAKServer – Serve and Manage TAK Clients
- Mosquito MQTT Broker – Relay Messages over LoRa from Different Network Types
- PHP Bulletin Board – Bulletin Board System Served over Reticulum and ATAK
- Reticulum – Local Decentralzed LoRa Network
- Flask HTTP Endpoint – Near Real Time Centralized Node and Network Status
Connected Hardware
- LoRa Hat & Dongle
–or–
- 2x LoRa Dongles
Lastly, I wanted to integrate various RF monitoring tools through the use of software defined radios. By being able to monitor aircraft and trunked systems as well as scan using a waterfall, we can maintain a high level of situational awareness during emergencies.
Software
- CubicSDR – Scan RF Band with Waterfall
- SDRTrunk – Decode and Monitor, Trunked Radio Protocols, ADS-B, and UAT
- xdotool – Controls What Window To Share Via X11 On the Boot Node and Thus Client Devices
- FLDigi – Decode Digital Modes
- XLM-RPC (Pre-Installed) – Can be Used to Control FLDigi from a Web Dashboard
- Flask HTTP Endpoint – Near Real Time Centralized Node and Network Status
Connected Hardware
- 2x General Purpose Software Defined Radios
- ADS-B / UAT Software Defined Radios
As you can see, the use case for my system has really evolved from just FTS to several other programs and hardware working in concert to provide better situational awareness and enhance the communication capabilities of those connected to its network. We will take a deep dive into each of these in later segments along with how it all works and how to set it up. I will also be posting videos to our YouTube channel going over the build process in a more concise manner, but this is intended to be a comprehensive resource for anyone trying to replicate my build.
Choosing the Right Hardware
With the software requirements and performance goals in mind, I had to figure out how it would all go together. As a layman, this wasn’t as easy as I thought it would be. I guess you could say I have a high aptitude for mechanical and engineering topics, and I have on and off studied IT related stuff over the years.
However, lacking formal education on the subject, I could envision what actions each component needed to do and what they should connect, but I didn’t know what things were called or the best practices for tethering them together.
After months of research (and plenty of updates) I came up with something like this:
Basically, I wanted the two Raspberry Pi’s linked together via Ethernet, each with a couple SDRs and the primary also having a sound card interface and SSD. Then of course they would share a battery as this is meant for portable use.
This design wasn’t ideal, but filled the base requirements without much complexity. However there were a couple tweaks I would end up making, namely in how it was all hooked up.
Now I wanted a 4 Pi cluster controlled by a single master node connected to a POE switch and a subsequent router. This alleviates a lot of cables as you start adding more Raspberry Pi’s to a system like this and gives greater control over the entire thing, all while vastly increasing it’s capabilities in all respects – except for size.While extreme portability was still a priority of mine, I started to question how portable it really needed to be.
The original design was meant to be slightly larger than a tissue box, but it would also have a more limited scope of use, meant to be used with only very small teams. But it could in theory be manpack-able if needed. But there are better ways of connecting small teams (whether through a centralized network or not) that I will be experimenting with alongside this server project.
The reality is, you may not need to carry a server on your back, but for use in tactical or emergency operations centers could well benefit from something the size of medium desktop computer that is fully self contained and can connect a moderate number of responders with a wide array of capabilities.
Components
As with the rest of this project, the list of parts for this server build has only grown since I began. Luckily, I have yet to make an expensive mistake but some of the components I ended up going with were vastly different from those I originally envisioned. For example, I wasn’t planning on using POE (or a network switch at all for that matter) at first. But between the need for better cable management as the cluster grows and enabling network booting, POE quickly became mandatory.
I’ll try to remember to update this list should I make any more hardware selection changes, but it should give you a good idea of where I’m going with this project.
Computing and Storage
4x Raspberry Pi 5 4GB & 8GB
2x Crucial X9 Pro 2TB SSD
The heart of any server is of course it’s computing components and mine is based around the Raspberry Pi 5. The RPi 5 has faster processing speeds than previous models and the 8GB version is ideal for memory intensive operations. The 4GB model is still quite capable despite the difference in RAM but comes at a much lower cost.By clustering multiple of these together, we can build a pretty powerful computing platform.
To compliment the Pi’s, I decided to add external SSDs as well. I narrowed down my options to either the 2TB Samsung T7 Shield for its rugged design and reliability, or the Crucial X9 Pro (which is also rugged) is typically a bit cheaper. However as I already had SD cards I could use for testing and setup, the SSDs aren’t something I need right away and will hold off until one goes on sale before adding one to my setup.
Networking
48v Managed Gigabit POE Switch
4x Waveshare POE HAT F
EAP225 POE Access Point
As simple as the concept seemed, sourcing the right networking gear proved to be the most challenging part of the selection process. Even after a week of scouring the web for the ideal setup, I had to make some compromises.
First of all, I needed a managed POE switch for powering and linking the Raspberry Pi’s together. Since I needed to link 4 Pi’s and an access point, I needed a minimum of 5 POE ports, potentially a 6th for future expansion. It should also have gigabit speeds as I wanted to reduce latency between the Pi’s in the cluster when communicating to each other. I also wanted the smallest possible form factor, meaning too many extra ports, or “dead space” wouldn’t be ideal. I also needed some level of management capability. VLANs, port mirroring/isolation, QoS, and security management at a minimum would greatly benefit my set up and are pretty common among managed switches. Inter-VLAN Routing, ACL control, and other advanced settings would also be beneficial, but for those I would have to go with a L2+ managed switch instead of an L2. Lastly, since the entire setup will be wired to a battery instead of plugged in, I was only looking at industrial models that had a 4 pin phoenix connector.
As it turned out, finding a switch that checked all the boxed would be next to impossible, especially given my budget. Long story short, I eventually narrowed down my choices to one that was a quite compact 8 port L2, and another that was a slightly larger 10 port L2+. As of the time of writing this, I’m still on the fence between the two as I have to decide whether to prioritize management capabilities or form factor and still hope to find the Goldilocks switch out there that does everything I want. If anyone knows of one, let me know in the comments below.
To compliment the POE switch, we need to add a POE HAT to each Raspberry Pi, allowing them to not only establish a network connection to the switch, but also draw power from it. The Waveshare POE HAT F is a great candidate for this and includes a fan which will be helpful for keeping our cluster cool. Note that the Waveshare POE HATs are model specific, so be sure to pick one that is compatible with the model of Raspberry Pi you chose.
Next I had to source an access point for the system. I wanted it to be POE powered, gigabit speed, compact, and dual band. Since I’ll be using the managed switch, SDN integration was optional, but additional management options are almost always beneficial. Again, I had to search around a little to find one that met my needs, but it was nowhere near as difficult to find as the switch. Eventually I came across the EAP225 AC1200 Outdoor Access Point from TP-Link which seemed to check all the boxes.
Power Management
12v LiFePO4 30Ah Battery w/ Integrated BMS
Drok Battery Monitor
12v to 48v Boost Converter
MeanWell Power Supply
Fuse Block
Luckily, the power management was much easier to work out. Since this will be a portable setup, everything will run off a battery. For this I’ll be using 12v 30Ah LiFePO4 battery with an integrated battery management system. These batteries are stable, reliable and fairly lightweight at only 6lbs. You could of course go with a bigger battery if you need a longer runtime, but as this will be a portable system, the 30Ah was a good middle ground for me and could always be upgraded later if needed. Just as important as the type of battery is its BMS which prevents damage to the battery from overcharging, over-discharging, and temperature related issues.
Next up is the battery monitor. This is pretty self explanatory, but the Drok monitor shows the remaining battery percentage, voltage, and temperature of the battery on a color LCD screen. It even has an alarm feature that will flash and buzz if the voltage drops too low.
As nearly all of the server components will be powered via the POE switch (which requires 48v) we will have to step up the voltage from the battery. For this we will need a 12v to 48v boost converter. When selecting your boost converter ensure it is rated for the appropriate wattage and amperage to power all the downstream devices and peripheries.
If you want to be able to plug the server into an AC power source when available while maintaining the battery backup, you’ll need an appropriately sized power supply. You’ll want the power supply to be capable of delivering more power than the draw on the battery from the downstream devices so that it can not only power your equipment while plugged in, but also charge a depleted battery.
Integrations
2x NooElec NESDR v3 Nano
2x NooElec Smart NESDR v5
Antenna Relocation Cables
ADS-B / UAT Antennas
Nagoya NA-F30G
Dual Band Radio
USB to 2 Pin Soundcard Adapter
LoRa HAT & Dongle
APRS-K1 Interface
With the main components of the server sourced, we can now take a look at expanding our capabilities to better serve our emergency communication goals. A software defined radio is probably the easiest to add to our setup and are quite popular for scanning purposes. While some SDRs have transmit capabilities (like the HackRF One), these are typically much more expensive than receive only models. For this build, we will be using the NooElec NESDR Nano v3 for its extremely small form factor. along with the Smart NESDR v5 from the same company.
The Nano v3 is better suited for use with ADS-B / UAT use cases due to its internal filtering while the Smart NESDR v5 is a better general purpose SDR. The difference in length also means when I mount my antennas vertically, they will be offset from one another with all 4 in one PI. They also both have a metal housing which offers better shielding from interference from our other components and heat dissipation.
I already own a nano v2 and have been quite happy with it during my limited testing, but this project gave me a good excuse to upgrade. That being said, I will likely use my v2 with the server in the short term to put my budget towards other components.
Next up, lets connect a more traditional radio that we can transmit with. For this, we could use something like the Digirig or SignalLink as an interface between our Raspberry Pi and our radio, but I wanted to give the APRS-K1 interface a shot. With this, we should be able to use our K1 style handheld radio to transmit digital signals generated by the server. This should take minimal effort to set up and will be a great addition to our build.
Lastly, I wanted to add a LoRa for use with Meshtastic and other LoRa based communication protocols. I decided to go with the Waveshare LoRa HAT for a clean installation and seamless integration, though I want to also experiment with some concurrent USB devices as well to reduce the load on the hat and conserve bandwidth by operating them on different channels or using time division. That being said, the LoRa HAT will likely offer better reliability, performance, and ease of installation in most cases.
Optional Accessories
7″ Micro HDMI Touchscreen
Micro HDMI Cable
4x I2C OLED Displays
M2.5 Spacer Kit
0.125″ ABS Sheets
Medium Pelican Case
While we will go over how to remotely access and administer the cluster in our next post, it may be useful at times to have an integrated screen. Since our GPIO pins will be taken up by other accessories, I would opt for a screen that interfaced through the micro-HDMI port instead. Some even have a backlight switch allowing you to save power when you don’t need to use the screen.
I may or may not get a touchscreen, I am certainly going to connect a 0.91″ I2C OLED display to each Pi in the cluster. I plan on using these as status indicators for the Raspberry Pi’s, showing my information like the IP address, status, and name of each device.
Lastly, I’ll be making a simple stackable case for my cluster using some 1/8th inch ABS plastic sheets and some M2.5 spacers and mounting the entire system inside a Pelican case.
My Process
Due to time and financial constraints, I decided to tackle this project over a couple months, starting with a single Raspberry Pi 5 and Nano SDR. Next I would add the router and WisBlock, giving me both WiFi and LoRa capabilities. The SSD will be the last component I purchase, mainly due to its price (which costs nearly as much as the rest of the server put together). There will also be various low cost additions such as OLED displays, jumper wires, connectors, etc, that will be picked up in no particular order. For the most part, I expect these to all integrate in a pretty straight forward way, but I will post periodic updates on the build, especially when things aren’t so straight forward.
Here’s the basic process I intend to follow:
- Initial Install and Setup
First up, we need to flash our operating system to our first Raspberry Pi and do some basic configuration like setting up our user accounts, network and SSH.
- Firewall Configuration
From there we will want to set up our firewall and other security settings. This is a crucial first step as we want to reduce the chance of malicious actors from accessing our server going forward.
- Network Booting with PXE
Next we want to set up our first Raspberry Pi as a boot server for the rest of the cluster. This will make managing the server easier and optimize our resource management.
- Adding Additional Hardware
Once we have network booting configured, we can start adding additional Raspberry Pi nodes to the cluster and their respective hardware components. To ensure we get everything set up correctly, we will be adding one component at a time.
- Installing and Configuring Software
With the hardware in place, we can start adding software to the Pi’s to start utilizing them. Again, we will be doing this one program at a time to ensure everything runs as intended.
- Create Web Interface
Rather than having our clients use SSH or VNC to access our server, we’ll want to set up a web interface for them to connect to and interact with. This will make it easier to scale our network and make it easier for our clients to utilize the server resources.
- Optimization
With everything installed and configured, we can start optimizing our set up and removing some software that is only needed during the setup process.
- Testing
Finally, we will conduct thorough testing on our server, not just to ensure everything works properly, but also to gauge the limitations of our system. This will include its ability to support multiple clients simultaneously, battery life, heat mitigation, network speed and more.
A Living Project
Keep in mind that this is an ongoing, living project and as such some features may be added or removed as I go through the build and configuration process. However, I will add information to these articles detailing any changes as we go forward.
As we dive into this project, we hope you follow along with our build, and encourage any discussion or feedback on the topic. We will be regularly posting both videos to our YouTube as well as written instructions here at ModernWarriorSchool.com to document each step along the way.