Survival Radio with a Raspberry Pi is a technical endeavor. The emcomm tools we use will always require parallel operator skills. There is no getting around that!
There isn’t a day going by where a comment is left on the channel saying our comms tools should be easier to use, or concepts should be less complex. Although I can agree, we should try to remember communications for emcomm or preparedness will always require a certain amount of investment in skills and field experience by the operator. There is no other way!
As a young ham radio operator, I went out with the university ham radio club, who taught me about setting up a field station. Because of the extreme conditions (extreme cold or killer mosquitos), we have here in Finland, keeping and eye on pragmatic-deployment was essential. Any amount of fiddling was too much. It was essential to get your station up and running, as quickly as possible.
A few years ago I started publishing videos and blogs promoting the Raspberry Pi as an emcomm tool for communications preparedness. The Raspberry Pi had huge potential as a cheap, easy to use, and accessible platform anyone could deploy. The problems with the Raspberry Pi were many, but one of the biggest issues was poor software support from the ham radio community.
The best example of ham radio software on the Raspberry Pi was JS8Call. JS8Call has a nice install shield, making it easy to install. The install shield could be downloaded from a normal website using a shared link. There was no need to compile anything, or enter any complex string of commands to get it on a Raspberry Pi (or any other platform). The executable could be zipped and sent over the air to a remote station if needed. It is so easy to set up, all a radio operator had to do was focus on the radio communications. That’s actually the point, but let’s get back to this later.
The Raspberry Pi
Often after publishing a video or blog with something new on the Raspberry Pi, the support questions started coming in like there was no tomorrow. This took my attention away from making YouTube videos and blogs, instead wasting my time on supporting the installation and configuration of hobby grade ham radio or Linux software packages. This wasn’t true for all packages, but for most it was a nightmare.
The thing about the Raspberry Pi is the tinkering! The Raspberry Pi is an excellent tool for those who like to tinker! I would argue that those of us who are using radio as a preparedness toolset, are not interested in tinkering. We need systems as streamlined as possible, and as easy to deploy as possible. We should be focused on reliability, and able to leave out the majority of “tinkering”. Bottom line, we should almost solely be focused on communications! This forces us to ask “why is the tinkering necessary?”. A couple of reasons really.
- The Raspberry Pi is designed for tinkering, hacking and learning to code.
- There are few if any “standards” for quality of deployment.
- It is designed to be bare bones, budget-friendly, and a learn as you go platform.
In my Ultimate Raspberry Pi video, I introduced clever tools from groups in Germany and North America, designed to make deployment easier. These were huge steps forward! Automated software downloads and install using a guided GUI. Definitely getting better! Although these tools bridged the gap, they also added new problems to the list. After 4 years working with the Raspberry Pi on the channel, I gave up on it as a critical communications solution! That was a sad day! I also knew I would take a hit from the community.
The video below illustrates the issues with using the Raspberry Pi as our primary set of emcomm tools for emergency communications and preparedness. It is the video outlining my shift away from a Raspberry Pi platform, to a Windows based solution, despite my disdain for Windows!
What we fail to consider
The Raspberry Pi is not the perfect computer! It can get close to being as functional and reliable as higher end machines, but not without spending significantly more money than a base RPi. Here are just a few of the areas where upgrades were required to bring the Raspi up to a reasonable level of reliability.
- The best emcomm tools eg Winlink, Vara HF, Vara FM, VarAC, … are currently only available on Windows!
- Get rid of the SDCard for OS and memory storage. Replace with SSD.
- Add buck converter to drop 12 volts from my station power, to 5 volts for the Pi.
- Smart power button for soft shutdown.
- Find a portable power supply to keep the Pi up and running when out in the field.
- Integrate a GPS for time sync.
- Build a custom enclosure to house all the components.
- Setup VNC on the Pi and an Android smartphone or tablet to interact with the raspberry pi.
- Add the cost of an Android tablet or smartphone
- …
Ultimately, all of the required packages and hardware customizations became individual potential points of failure. Memory card corruption, reconfiguring or reinstallation of tools after updates, package incompatibility after updates, VNC server connectivity issues, lost connection between tablet or smartphone and Rpi, … What started as an effort to simplify our emcomm tools, became a tail-chasing race to keep the darn thing up and running.
The Raspberry Pi was great doing one thing! JS8Call ran absolutely wonderfully on the RPi. WSJT-X was also OK. FLDigi was a nightmare to configure. PAT Winlink was unnecessarily difficult to install and configure. Winlink Express has not been ported to Linux and it doesn’t seem it ever will be. It is the same story for Vara HF. If all ham radio-focused applications were implemented and deployed like JS8Call (eg download link, install shield, executable, setup GUI, desktop shortcut), there would be no need for such complex deployment tools. I digress!
The point is reducing complexity! As radio operators, we are primarily focused on our emergency communications skillsets. Moreover, some computing skills are required and absolutely necessary BUT, the required computing skills (whatever the platform) and complexity should not become an obstable to getting on the air. This is why I ultimately decided to dump the Raspberry Pi for critical communications. Take a look at the video below to see the journey from start to end.
Migrating to the Microsoft Surface
Ultimately I moved over from a Raspberry Pi to a Microsoft Surface. I have mentioned before my disdain for Microsoft, so there is no need to rehash that point. It didn’t have to be a Microsoft Surface though. It could have been a Dell Latitide, Panasonic Toughbook, or whatever low power field computer the operator was comfortable with using. I chose the Microsoft Surface Go 2. At the time it was the budget Surface model but had enough memory and CPU for ham radio data mode communications. There are also several other “field computers” in my arsenal.
- Dell Latitude 7280 laptop
- Microsoft Surface 3 Pro
- Lenovo Yoga C920 with touchscreen
- RasPad Tablet (Raspberry Pi 4B)
- Raspberry Pi 4 NTP server
I understand many of the followers of this blog and channel, felt I abandoned the Raspberry Pi, but let me explain a few things we may not have considered.
- The cost of the RPi and Android smartphone plus all the hardware add-ons was more costly than the Microsoft Surface Go 2. This is without adding the same reliability and ease of use as the Surface tablet provides.
- The weight of the RPi, Smartphone, power bank for the RPi, SSD, GPS, cabling, and enclosure, … became heavier on the Raspberry Pi, than the Microsoft Surface Go 2.
- With a built-in SSD, the MS Surface has not experienced any memory/write failures, corrupted SDCards, … vs the Rpi failure rate of several times per year, when using it daily.
- “Time to get on-air” with the Raspberry Pi from start up to ready to transmit was 7-10 minutes. Time from start up to ready to transmit with the MS Surface was 2-3 minutes.
- Rather than having multiple components cobbled together with the RPi, I now have one computer, and one radio! Some consider this a single point of failure. Perhaps it is! However, the MS Surface after nearly two years of operation (since February 2021) has not experienced a single failure of any type, either at home, or in the field! Moreover, I will soon add the Surface Go 3 LTE to my kit.
- There were no significant power savings using the Raspberry Pi!
The Raspberry Pi certainly was fun to tinker with. It was even nice to use as a home desktop machine for FT8, JS8Call, … When it is in use every day, one begins to understand how fragile the Raspberry Pi really is. It was not designed to be a desktop or laptop replacement running 24/7. It was adopted by the ham radio and preparedness communities as a low-cost alternative to more expensive computers. I get it, but it will never be a one to one replacement!
The video below explains the benefits of the Microsoft Surface Go 2 over the Raspberry Pi/Android smartphone solution. Keep in mind my focus is on critical communications, and not just casual ham radio. Reliability is critical, Ham Radio is not my “hobby”. Ham Radio is a tool for emergency communications and preparedness.
Getting to the point
As I mentioned earlier in this post, off-grid radio operators for emergency communications and preparedness must have a deep skillset. We must understand many things like:
- Propagation
- NVIS vs DX
- Antenna configurations
- What band to use at specific times of day
- Bandwidth and filters
- Efficiency vs throughput
- What modes to use when propagation isn’t cooperating
- Powering our stations while off-grid
- Minimising our current consumption, while remaining effective.
The emcomm tools we use are complex. In fact, they are never going to be easier than they are now. The best we can hope for is simplifying the deployment of our tools, creating better user interfaces for the tools, and making it as easy as possible to set things up. We already have an incomprehensible amount of knowledge required to carry out reliable HF communications. So we should not be making our emcomm tools and the hardware systems they run on, unnecessarily complex. Keep It Simple Stupid! Even if that means using a Windows machine. Until the ham radio community reaches a reliable, cross-platform level of development, we need to reduce multiple failure points, in our off-grid comms configurations. We should never embrace unnecessary complexity.
73
Julian oh8stn
YouTube http://www.youtube.com/c/oh8stn
Buy me a rootbeer: https://paypal.me/oh8stn/2usd
Follow my backup channel on Rumble: http://oh8stn.net/rumble
No comments:
Post a Comment