Hello all, I wanted to talk a bit about the subject of off grid networking and digital ham radio communications that leverage modern technologies that we use and rely on every day. I’ve been doing a number of experiments that leverage Raspberry Pis, phones, tablets, and laptops in the shack, in the field, and while traveling to operate one or more ham radios.
I’ll go through the ways I’ve configured my field computers to operate in: as a single device, as two or more devices, as devices connected to a $25 travel router running OpenWrt, and as equipment connected to a home network. The reality of this setup is that all my off grid computers work in one of two ways given any situation, but with some subtle differences.
The broad scenario 1 is when one of my Pis detect a wireless network they’re configured to connect to. This can mean they’re connected to a familiar Internet-connected wifi network at the QTH or elsewhere as a client, OR they’ve connected as a client to a wifi network generated in the field by another device designed to operate off grid. This means the device is acting as a standard wifi client.
The second broad scenario that one of my Pis supports is that it does not detect a recognized wireless network and generates its own. Only one device should be in this mode in any scenario. Once a single device generates a network any additional Pis, laptops, tablets, phones, etc. should connect to this Pi which will also automatically serve DHCP, DNS, NTP (in some cases), etc. This host then becomes responsible for handling basic network services as well as its ham radio related functions. There is, however, a drawback to this scenario with my current setup. For some reason my Raspberry Pi 4s and Raspberry Pi Zero W will stop passing network traffic after a few minutes. The solution to this problem is just to re-connect to the wireless network and things work again, but reliability is an issue. If you can’t simply log in and reconnect a Pi you have to reboot it. I address my solution in one of the more specific scenarios discussed later.
By supporting these two broad ways of handling connectivity we can create effective on and off grid networks. This makes sense because the first host that gets powered up has the chance of becoming the master of the wireless network. By coordinating the name of your off grid or standalone wireless network and its pre-shared keys you can create a network that can be formed on the fly, and that can have at least some self-healing properties in the event of a device failure. If all the nodes are capable of becoming an access point with all necessary network services in the absence of another we can ensure our services are available, or are as available as possible.
Let’s start with the five very specific scenarios we mentioned earlier. Notice that these five scenarios are mostly combinations of the two very broad ways our devices are configured to behave.
First let’s say that things are normal and we’re doing some digital HF or UHF/VHF work in the shack. Our local infrastructure is working fine, our Internet connectivity is fast and working well. Because all of our devices are clients on our home network we can use any device to access VNC, SSH, HTTP, or Winlink services on our Pis without issue while watching our favorite streaming service. All the Pis we have powered up are clients to an established network.
Secondly let’s talk about a scenario where we’re on battery but no configured wireless networks are available. Maybe we’re in an emergency scenario, camping, or on the road. Our Pi attached to our radio generates a new wireless network that you can connect to and starts the necessary DNS, DHCP, or even NTP service to allow wireless clients to connect and use provided services. Maybe this Pi is running JS8Call/FlDigi or Pat Winlink. You just connect your phone, tablet, or laptop to this network and access the documentation web server, Winlink web page, or use VNC/SSH to control the Pi. We’re now able to communicate using our radio via digital modes and read any documentation we stored on the Pi. It should be pointed out that none of my field-portable Pis have keyboards, displays, or monitors of any kind when in normal use. I rely on other devices for those functions to cut down on power consumption and bulk.
Our third scenario assumes one operator with no configured wireless networks, but is running two radios. Maybe we have one Raspberry Pi attached to a UHF/VHF radio that’s set up for packet Winlink, and another HF rig running JS8Call. The Raspberry Pi that booted first is serving our wireless network and basic network infrastructure services that allow subsequent devices to connect. The operator is now able to connect to to the generated wireless network and use Pat Winlink as well as JS8Call or FLDigi. One person and one device can now manage two radios set up for different purposes! The trick is that we might not have 100% due to the connection issues with Pis when they’re in access point mode.
For our fourth scenario we’ll modify the last scenario a bit. We have one operator with one device connecting to two radios over the wifi connection. This time we’ll introduce our modified $25 wireless access point. It’s now generating the wireless network, serving DHCP, DNS, and NTP if one of our Pis with GPS units is connected. All Raspberry Pis are now in wifi client mode so we no longer have the connection reliability issues in our second and third scenarios! What’s even better is that if we have a wired Internet connection we can now plug that into the travel router and have full Internet connectivity for our Pis and operator’s device. Sweet!
Our fifth scenario builds on the fourth, but we’ll introduce one or more operators using one or more devices. This could also apply to the third scenario with a Pi hosting the wireless infrastructure without an access point but we’ll ignore that. Every radio operator connected to the wireless network can now queue up e-mail on Winlink or take turns using VNC to control our HF rig. All the operators on the network now have access to the documentation server because it’s just a web page that serves files. We now have a field network that can serve more than one radio operator, and we can be more efficient sending email over Winlink by batching, and we can also decide to create an APRS server that allows multiple instances of APRSDroid or some other KISS over TCP client to connect if we’d like.
I hope you came away from this thinking about different ways we can build resilient and flexible systems even when working off grid or in emergency situations. A minimal amount of additional hardware combined with some preparation ahead of time can allow us to use more efficient or sometimes required digital technologies off grid and can even allow a group of operators to save power by sharing radios and batching messages rather than dealing with the overhead of connection setup for modes like Winlink!
