One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Scott – N8SY and articles are submitted by cabinet members.
Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.
You can receive the Journal and other Ohio Section news by joining the mailing list Scott has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!
If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.
Now without further ado…
Read the full edition at:
THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net
Hey gang,
On this month’s edition of “Pi Talk” – just when you thought I couldn’t talk about Pi anymore! I received a question from Chet – K8KIZ who has a laptop used for station operation. He wanted to replace it with a Raspberry Pi. In searching, he found way too many choices and wanted help to set him on the right path. This might be a question that others have or one they are considering. He soon found out it was a lot more complicated than originally thought.
Over the past number of years, I’ve done a lot of integration work which involves making one system or application talk to or replace another. It frequently involves bridging communications with other services such as databases or API’s (application programming interface) and facilitating data flow between them. Sales, Account Managers, and System Engineers for the new vendor will always throw around buzzwords and catch phrases – “setup and integration are easy and seamless,” “automated,” “zero configuration,” “drop-in replacement,” “pays for itself in three days” (not really), “reduce costs.” List goes on and on. It is never any of those things.
They have absolutely no idea about your environment, how involved, and how costly it will be to utilize their services. They just want you to buy them. Soon after comes the nickel-and-dimming: “you want to process how much data? That’s an extra couple thousand dollars” or “that doesn’t come with the license you purchased, that will cost you an extra-large-number with many 0’s!” Internal business units do this too. They weren’t prepared or made it seem like they are in position to handle a situation and were not. Feature requests take an extraordinarily long time to implement or claims of not having enough man-power soon follow.
The FCC is in a situation similar to this or they’re making it seem like they are: ‘oh, our licensing process is all digital and we can eliminate that pesky licensing fee!’ And the peasants rejoice. Reading the latest news about the FCC wanting to reinstate license service fees, “…we propose a nominal application fee of $50 due to automating the processes, routine ULS maintenance, and limited instances where staff input is required.” Wait, isn’t that why they went digital to reduce these costs? Someone sold them a bill-of-goods that didn’t actually reduce their costs or they’re looking to recoup costs elsewhere.
Not wanting the same thing to happen to Chet, where the alternative didn’t actually improve his situation, I took the approach of having him think about his station. What does he use his station for and what he would consider “a success” of replacing his laptop with a Raspberry Pi? Anytime anyone is looking to replace X with Y, an evaluation of this nature. What is X used for and are the pros/cons of Y sustainable?
In Chet’s case, replacing a laptop used for ham radio with a Raspberry Pi, he would need to consider things such as:
- Is the current laptop setup Windows or Linux?
- If it’s Windows, would he want to climb the Linux learning curve?
- Is he using any software apps that are Windows only? Examples would be: RT Systems programmers, Ham Radio Deluxe, N3FJP logging, SmartSDR, N1MM, Wires-X, etc., etc.
- Can those Windows only apps be replaced by Linux apps – and are those Linux apps equally as good?
- Does he have any hardware requirements (like multiple serial or parallel ports)? The Pi has UART via GPIO pins but two or more serial ports require USB-to-Serial converters.
- How many USB ports are required? Pi’s only have 4. 2 ports would be taken up by using a wired keyboard and mouse.
- Do all of his hardware devices and interfaces work in Linux? These would be things like radio programming, control (CI-V) or firmware flashing, audio mixers and audio interfaces.
This is not an all-inclusive list especially since I didn’t know anything about his station – though I seem to remember he was into Vibroplex CW key tuning and repair from a local hamfest. I thought through scenarios that might apply to the majority of HF operators and came up with that list.
Some Windows programs can be run under Linux using a compatibility layer program such as WINE or run virtual machines (VMs). That would contribute to the Linux learning curve. Raspberry Pi isn’t powerful enough today to run VMs. VMs or hypervisors maybe an option for some Linux desktop/laptop situations.
Instead of wired keyboards and mice, Bluetooth devices could be a replacement option but are more costly. Wired is preferred to wireless for reducing interference problems. Built-in antennas for Bluetooth or Wi-Fi aren’t going to be as good as laptop antennas. Additionally, monitors without HDMI or mini-HDMI connectors will need adapters, cables, or outright replaced if it doesn’t have compatible connectors. USB hubs are an option for expanding the number of USB ports. I have yet to find a USB hub that is problem free. They don’t work well with some operating systems, attached devices do not fare well with temporary connection interruptions, and they tend to break down after a short time.
Best way to track these considerations and more is to make a list. Start by looking at all connections to the existing laptop, both physical and virtual (like with an SDR). Include any software used during operating (radio control, prediction modeling, packet, digital, etc.). Programming radios? Those tend to be Windows (or DOS) programs along with firmware updaters. If using a Raspberry Pi is still desired, another Windows machine will be needed for programming and firmware updates. Include all of these in the list and evaluate solutions on the Raspberry Pi or Linux platform for alternatives that meet the requirements. Consider splitting non-supported, but essential, functionality to another Windows machine.
Another way to approach evaluation would be to operate with a new “Pi” system, hands-on, but keeping the old system up-and-running nearby. The old system would be used as a reference for program settings, coping or migrating data files (such as export from one and import to the other), and a comparison point when evaluating Linux programs.
Lastly, completely ditching the previous system and entirely starting from scratch is an option. This type of evaluation style is more draconian by ripping and replacing. Most people have their own operating style and rarely want to deviate from their ritual. Rip-and-replace might be needed if they’re fed up with a current setup and want to start over with something else. The operator, in this case, would not care about migrating previous data, starting out anew, and take whatever options are offered by a different platform.
To future proof, I’d recommend going with the latest version of the Pi. Currently, that would be a Raspberry Pi 4 Model B with at least 4GB RAM ($60), 8GB ($90) if able to spring for the extra RAM. Quality of the power supply and SD card plays a role in stability as I talked about in July. Data corruption possibility is still not zero. Even on a desktop PC. Corruption seems to be more prevalent on Pi’s, likely because of cheap components chosen by the user.
I strongly recommend making frequent data backups. This applies to any system. There should be 3 copies of data: the local copy (on the Pi), another copy on a storage device like a USB Hard Drive or Network Attached Storage (NAS). A third copy, off-site, located at a friend’s house, relative’s house, or a work location. Another off-site storage location would be cloud storage or backup service provider. Think about where you would be if you lost those LOTW logs, FT8 contacts, SSTV images, or Winlink messages. This strategy is known as the 3-2-1 backup strategy and should be used for ANY important data. 3 copies of data, 2 on different medium, and 1 copy off-site.
Starting out, I would consider the “Ham Pi” or “Build a Pi” projects I discussed in August initially. “Ham Pi” has just about every Linux ham radio application pre-installed. That would allow an operator to try different programs, find one that suits their needs or one they prefer. “Build a Pi” can be a little more tailored to operating style. You can also get down and dirty by compiling programs from source, depending on Linux experience or desire to tinker with Linux.
That just about covers broad considerations. Chet realized this was a larger undertaking than finding a plug-and-play option. He appreciated the analysis of the issues at hand. I hope he is able to find a working solution to replace his station laptop. When considering major overhauls such as this, know that for most people, it’s a little more complex and involved than most realize.
A quick note about Winlink. The WINMOR protocol has been deprecated systemwide and will soon be removed from the client software application. First introduced by Rick – KN6KB in 2008, it was the first ‘sound card’ mode offered by Winlink as an alternative to modem hardware needed at the time. Rick and the Winlink Team have moved on to developing robust and speedier protocols such as Amateur Radio Digital Open Protocol (ARDOP) and VERA HF. RMS gateways will only support ARDOP, VARA HF, and Pactor 3 or 4 (where applicable) near term. If you are still using WINMOR, it’s likely been hard to find gateways that support the protocol because sysops have been asked to remove in favor of the other modes. WINMOR had a great run and was the mode I used when I first got on Winlink.
Thanks for reading and 73… de Jeff – K8JTK