Zero Retries 0187
2025-01-31 — Roadmap for the IP400 Network Project, Techsplaining About Innovating Mostly In Software, Trends I Hope to See in 2025 (and Beyond) - Part 1, DigiPi Compatibility with the AIOC
Zero Retries is an independent newsletter promoting technological innovation that is occurring in Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its fourth year of publication, with 2400+ subscribers.
About Zero Retries
Steve Stroh N8GNJ, Editor
Jack Stroh, Late Night Assistant Editor Emeritus
Web version of this issue - https://www.zeroretries.org/p/zero-retries-0187
In this issue:
Roadmap for the IP400 Network Project
Martin Alcock VE6VHThe Necessity of Techsplaining About Innovating Mostly In Software
Steve Stroh N8GNJTrends I Hope to See in 2025 (and Beyond) - Part 1
Steve Stroh N8GNJProgress on M17 Project with the backing of the new M17 Foundation
Progress on new initiatives for APRS with the backing of the APRS Foundation
Increased recognition and use of ka9q-radio as an all channel receiver
zBitx - More Casual HF Operation Outdoors… and more General Operators
Progress on a Amateur Radio GEO payload for the Western Hemisphere
Comments for This Issue (redirect to Comments page)
Request To Send
Commentary by Editor Steve Stroh N8GNJ
Paid Subscribers Update
My thanks to Newton White N4EWT for becoming a new Founding Member Subscriber to Zero Retries this past week!
Founding Member Subscribers are listed in every issue of Zero Retries!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
There’s No One Best Amateur Radio Data Technology
What is the best Amateur Radio data (or other) technology depends on the user’s needs, preferences, requirements, applications, etc.
As you’ll see, very prominently in this issue, in Zero Retries, I promote and explain and follow several types of data communications systems used within Amateur Radio. In my big picture perspective, all of these systems have their niches and use cases to recommend them. I’m sure there are some Zero Retries readers that feel whipsawed in such coverage and think “Pick one technology and focus on that”! But Zero Retries isn’t the AREDN newsletter, or the M17 Project newsletter, or even the IP400 Network Project newsletter.
My goal with Zero Retries is to report out into Amateur Radio about the incredible technological innovation that is occurring, that most Amateur Radio Operators aren’t hearing about in their Amateur Radio news, and thus just don’t know about.
These multiple, and often overlapping capabilities, can be confusing, especially now that I’ve begun to evangelize the emergence of the IP400 Network Project (which I’ve had some influence on). In a lot of ways, if my vision for IP400 is completely realized, IP400 will be a superset of all of it - capable enough to be interoperable with almost all existing modes in use in Amateur Radio. This, while (explained in this issue) I’m simultaneously hoping for the emergence of a new type of minimalist data radio from Chinese manufacturers, and hoping that someone will develop a mobile radio that integrates M17 and especially the M17 data mode.
For someone starting out in Amateur Radio or in data communications on Amateur Radio, choosing a system to begin using data communications in Amateur Radio can be a bit dizzying. This issue of Zero Retries is already overflowing, but an article in a future issue of Zero Retries will attempt to contrast and compare various systems.
Thought Experiment on Citizen Science - Monitor GNSS “Wobble”
This is a followup on Zero Retries 0186 - Thought Experiment - Integrating Personal Radio Science Projects. I recently read about a new Global Navigation Satellite System (GNSS) receiver that integrates a number of GNSS signals for improved accuracy. While it wasn’t “consumer” inexpensive, the cost was reasonable for an experimenter. Apologies - I didn’t record the details as I had not made the mental connection (that I’m about to explain) at that time.
The US Wide Area Augmentation System (WAAS) adds additional precision to US Global Positioning System signals. My inexpert understanding of how WAAS works is:
A very high precision GPS receiver is established at a very precisely surveyed location, including its altitude.
Each of these receiving stations knows where it is located, and continually receives the signals from the GPS constellation to compute its location.
The difference between the known location and the computed location is (aggregated? and) uplinked to a geostationary satellite which has a specialized transmitter.
WAAS-equipped GPS receivers receive both the GPS signals and the WAAS correction signals (from the nearest WAAS surveyed location) and output a higher accuracy location and altitude than was possible with just GPS signals.
When last I looked at WAAS, I think it was originally intended to correct for atmospheric effects that would interact with the precise timing of GPS signals. If memory serves, when it was designed, it wasn’t (then) intended to detect deliberate jamming or spoofing of GNSS signals. But jamming and spoofing of GNSS signals is now a routine capability that’s commonly experienced in some parts of the world. And the equipment to do so is no longer expensive; I can imagine that it could be done with a Software Defined Transmitter1.
Thus… what if in addition to all of the various citizen science capabilities that one can contribute to, we in Amateur Radio / citizen science created a network of GNSS “Wobble” monitoring stations? It’s not difficult or expensive to do reasonable surveying of a precisely known location, and the receivers (and as I keep noting, inexpensive dedicated computing power) are readily available.
One reason to do so is the increasing (unfortunate… illegal…) use of “GPS jammers”. With a big enough network of GNSS “Wobble” monitoring stations, even GNSS jamming as localized as the use of a “GPS jammer” at a local truck stop would quickly be known.
As for who to report this data to, especially if a potential jammer is detected? No idea… post it to a web page? I think this would be a cool project for a student thesis.
See also the followup on this general subject by Bill Echols NI5F in the ZR > BEACON section later in this issue.
…
As for the N8GNJ / KD7WSF / Fiona and Shreky kittencats household this weekend, we’ll be stocked up, with backup batteries charged up, streaming media downloaded for the first snowmageddon of 2025. And it will be my first real test of the “snow melt mode” of the Starlink antenna (mine is on a small pole, comfortably out of the range of outdoor cats). As I write this, the weather forecast says “85% for up to 10 inches of snow”. Fortunately, no mention of the gale force winds that can come blasting down from the Yukon through British Columbia’s Frasier River Valley, targeted straight at Bellingham. I cannot complain - we recently enjoyed a rare six-day streak of 100% sunny weather which I enjoyed immensely.
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities! Stay warm and dry!
Steve N8GNJ
Roadmap for the IP400 Network Project
By Martin Alcock VE6VH
This project, like all others, started to be something completely different. Through a mutual acquaintance I connected with Steve N8GNJ, and we started discussing my project, and through the course of our discussions the concept for a 400 MHz network was born.
The initial concept was to explore the capabilities of high speed data in the band using off the shelf components. We discussed the merits of other networks such as HamWAN and New Packet Radio, but the conclusion was that what we really wanted was an ‘ad hoc’ mesh network, where any node can join in without complex setup procedures.
The first baby steps were taken using an off the shelf evaluation board for a microcontroller from ST microelectronics called a Nucleo, which features an ARM microcontroller and an integrated 100mW radio, capable of transmitting up to 600Kb/s using 4FSK modulation. There are amplifiers available that will increase the power out to 25W or more, making this a viable way to get a data radio on the air.
I set to writing some basic code to get the ball rolling, which can send and receive data frames, repeat them, build a mesh table, send a beacon frame periodically, and I also provided a simple menu application complete with a chat facility. The board can also accommodate a GPS receiver, which can be used for mobile applications. This code is now reasonably complete, and others have successfully downloaded the code and installed it, and the chatting has begun.
But what is next?
First, the Nucleo hardware is a good proof of concept and development platform but is limited to a single serial port for data. The next step is to include a Raspberry Pi, and, using the Serial Peripheral Interface (SPI), to send data at higher speeds to the radio, which will send them as frames This planning is still in the early stages. Those with the Nucleo boards will be able to take advantage of the enhancements implemented on the Raspberry Pi with a couple of jumper cables to connect to the SPI.
Two hardware modules are in the final stages of construction. The first is a Pi HAT with the radio module on it, which will soon be available as a kit for a full-sized Raspberry Pi. The second is a completed radio with a Raspberry Pi Zero included, is in the works for the end of March of this year. Applications that can be developed could include file transfers, bulletin board systems such as JNOS, IP encapsulation, even an AX.25 replacement, or anything that can be dreamed up. In addition, capturing the beacon frame data and passing it on could be used to build a user database, with location and signal strength information. A central server application could repeat these frames between nodes, enabling a wider reach similar to the AREDN network.
Beyond that, plans are being made to develop a new Pi HAT with higher data rate capabilities and be able to send full motion video using H.264 compression, which is standard on the Pi 4 and 5. Of course backward compatibility will be preserved and speed negotiation will be included.
But it does not end there. So far, I have only discussed the radio node, the next is what we can do at a repeater, which is where I came into this originally. I designed and published a repeater controller based on an FPGA and Pi HAT, which we have running at several repeater sites already. The limitation of current repeater controllers is their inability to deal with digital data streams, which is where the world is currently headed.
Modern day repeaters use a plethora of different digital data formats, brought about by the introduction of C4FM modulation, which has spawned several new standards from different manufacturers, none of which are compatible with each other, and to add more complexity a new one invented by amateurs - M17, has also entered the scene. Some use a common speech coding technique called advanced multiband encoding (AMBE), but latter has one all of its own - Codec 2, which also sounds better. The multi-mode digital voice modem project (MMDVM) brings all these together with ability to transcode between them.
The most common repeater control system that runs on a Raspberry Pi is known as AllStar, which is based on the popular Asterisk Private Branch Exchange (PBX) platform, and currently has a large user base. Apart from its ability to do basic repeater control, it can connect to other systems by making use of the PBX trunking facility, which was design to place calls between systems. However, it has no ability to deal with MMDVM digital modes, and to add to the data stream requirement, let us not forget simple applications like messaging, chat, telemetry and position reporting.
Adding all these together determines that the next generation repeater controllers need to encompass all of these paradigms, starting with the lowest common denominator and moving up from there to MMDVM modes. To preserve the AllStar capability the final piece of the puzzle is to add an IP400 Supernode to the controller, which can provide a path to local nodes, other repeaters, and other devices with an Ethernet connection. This will build on the radio node development. As it evolves, so can the controller evolve to include higher speeds as they become available. The anticipated completion of the controller is the latter part of this year.
The sum total of all of this will be an ad-hoc network that includes radio nodes and repeaters, which can exchange a plethora of different digital formats, and be compatible and interchangeable and have infinite reach.
Now we have the next generation of amateur radio.
The Necessity of Techsplaining About Innovating Mostly In Software
By Steve Stroh N8GNJ
In an earlier era, we used to make nails one at a time, by hand in a forge. In this era, we focus on building things with cheap, factory made nails.
This article isn’t an oblique commentary / critique on any specific Amateur Radio project. Rather I’m addressing a trend I’ve been seeing by folks that are comfortable “soldering things up” assuming that everyone else is also, or wants to be. I posit that such an assumption isn’t necessarily the case.
As I write this the week of 2025-01-24, the biggest news in technology is the emergence of DeepSeek R1 that (seemingly) delivers cutting edge General AI technology… on trailing edge AI hardware. Significantly, it was released as open source, and at least one YouTube creator claims to have run it on a desktop computer with a “commodity” Graphics Processing Unit (GPU). We’ll see… but at minimum this is yet another demonstration that in this era, software is the primary technology. If you want to see the DeepSeek R1 on a Raspberry Pi perspective, see Jeff Geerling’s OpenAI's nightmare: Deepseek R1 on a Raspberry Pi. (TL:DR - Not really practical yet; the currently big and expensive GPU “tail” wags the Raspberry Pi “dog”. But wait a year or so for a future Raspberry Pi (or just a board with a Raspberry Pi Compute Module 5 mated with a “cheap, but good” GPU).
The 2020s have seen multiple, simultaneous, rapidly increasing capabilities in radio technology, including:
Field Programmable Gate Arrays (FPGAs) simultaneously becoming more sophisticated, but less expensive. The tools to use FPGAs are getting steadily more accessible to more developers.
Rapid increases in cost effectiveness of computing that can be dedicated to a task (embedded). The prime example of this trend is the Raspberry Pi 5 - 2.4 GHz quad core, 64-bit CPU with 16 GB RAM for $120. Spend just a bit more for a Solid State Drive connected via fast PCIe bus.
Small machine learning / artificial intelligence models that are suitable for embedded use, especially if they can be domain restricted to an assigned task. I remarked recently that it should be possible for an IP400 voice contact to just say “N8GNJ calling VE6VH” and the SuperPeater would parse my words (locally), query “the network” to find out which repeater VE6VH was last heard from, and connect me there and perhaps regenerate my voice on that repeater.
Radio hardware is increasingly becoming integrated into “radio on a chip” with only power, digital I/O, and an antenna connection required to implement a fully functional radio. And of course, software. My thanks to my co-conspirator in the IP400 Network Project, Martin Alcock VE6VH for demonstrating to me just how capable, and inexpensive, certain radio chipsets had become.
Increasingly sophisticated and general open source software technology of which GNU Radio is the best-known, but there are other open source software suites for implementing entire radio systems on off the shelf software defined radios / transceivers.
Inexpensive software defined transceivers that can operate in the VHF / UHF bands such as Caribou Lite ($140), ADALM-PLUTO ($235), HackRF One ($375), and LimeSDR Mini 2.0 ($400) make “software radios” more approachable than ever before. It was only a few years ago that the only option for a VHF / UHF software defined transceiver was from Ettus Research for $thousands.
Not to detract from the incredible innovation in the development of radio technology hardware, especially the trend towards “radio on chip” that is so beneficial to Amateur Radio development such as the IP400 Network Project, but all of these trends increasingly enable Software Defined Radio technology. Simply put, Amateur Radio (potentially) has a lot more radio experimenters / developers that prefer / are capable of experimenting / developing / innovating in the software domain rather than in the hardware domain.
Thus, in my highlighting / promotion of technological innovation in Amateur Radio, I’ve found it necessary to continually mention / techsplain2 in Zero Retries and my presentations that many of the current generation of hackers / experimenters / developers / innovators are comfortable experimenting and innovating in software but much less in hardware.
I think the famous quote from hockey legend Wayne Gretzky applies:
I skate to where the puck is going to be, not where it has been.
In Amateur Radio, “where the puck is going to be” are plug and play radio units with a rich software environment (that can control as many parameters of the radio signal as possible). “Where the puck has been” is the previous practice of building up a radio from discrete components or even microcontrollers with tightly crafted firmware.3 We used to build radios that way because that’s what the technology of previous eras supported (accessible to amateur experimenters). Before that, we also used to build radios from vacuum tubes, and before that, spark gap generators… also because that’s what the technology of those eras supported.
So the old ham ethos of “just solder…” is, for many, a showstopper. Not that “software first” folks are incapable or forever unwilling to tinker with hardware… they just prefer not to. And given that Amateur Radio is, for all of us, a “time available” activity, it’s important to internalize that difference in perspective for a new Amateur Radio project to succeed.
Many, perhaps the majority of Amateur Radio Operators bemoan that “no one builds any more”, that Amateur Radio isn’t a technical hobby any more, and other such complaints.
I disagree with those perspectives, and every week here in Zero Retries I document powerful counter arguments to those “no one… not technical any more…” perspectives.
In those perspectives, the mistake most are making is overlooking the “state of the current art” software dimension of experimentation in Amateur Radio. By that metric, we’re more innovative than ever!
I could spend hours listing various examples of my email tagline:
Radios are Computers - With Antennas!
But here are just a few of examples software creating new capabilities from existing, commodity hardware:
The various modes of WSJT-X, implemented solely in software, made new radio capabilities possible, that weren’t even dreamed about in the era of hardware / firmware radios. My favorite example is that a WSPR transmitter can be as simple and pico power as modulating one of the GPIO pins on a Raspberry Pi and attaching a wire (as an antenna) to that pin.
Just one innovation (of many) in Dire Wolf Software TNC - correct a failed Cyclical Redundancy Check (CRC) by “test flipping bits one by one to correct single bit errors” (elegantly explained in this presentation) increased reliability of packet radio communications enormously.
VARA FM combined numerous techniques to make enable up to 13 kbps highly reliable data communications on a standard VHF / UHF voice channel and any audio interface connected to the speaker and microphone connections on any FM transceiver.
The new zBitx is an almost entirely a “all software defined” portable HF radio with most of its capabilities (modes) are software modules running on (64-bit!) Linux on a Raspberry Pi Zero.
… all of which that weren’t feasible4 to implement in hardware (modems, radios, protocol engines, etc.).
Thus I think it’s important to guard against assumptions that the user base of any given Amateur Radio will inherently be comfortable with soldering, or more than basic assembly, or fabricating custom cables, or other such “pleasurable building experiences”. Many may be comfortable with those things… but some others… perhaps the most talented (in software) others, may not be.
Put another way, while many might feel that soldering electronics is an inherent part of Amateur Radio… it isn’t. Amateur Radio is, at its basics… about… radio. And in experimenting with radio in the 2020s, “… where the puck is going to be” is experimenting with radios in software5.
If we really want to maximize the potential for a new era of technological innovation in Amateur Radio and take maximum advantage of the vast amount of software capability that is (I think) “waiting around for something interesting to do in Amateur Radio”… we need to accommodate those that may not be comfortable “tinkering” with hardware. Such folks want ready-to-use hardware that enable their experimentation of their ideas in software.
If we do so, it’s my guess that such folks, with their powerful software skills, can take Amateur Radio projects in entirely new directions, that project creators never would have imagined.
Trends I Hope to See in 2025 (and Beyond) - Part 1
By Steve Stroh N8GNJ
These are some trends, technologies, projects, organizations, etc. that I expect… hope to see in 2025 and beyond. As usual, my perspective for these is mostly US-centric. I started with an incomplete list of such trends, thus there will be a Part 2 within a few issues when I compile a more comprehensive list. It will be interesting to look back at these articles in January, 2026.
Completion of FCC Docket 16-239
Every new presidential administration reorients the FCC to its priorities. Thus I hope that the momentum begun in 2024 in FCC Docket 16-239 regarding removing symbol rate limits and bandwidth limits from the Amateur Radio VHF / UHF bands will result in doing as the vast majority of commenters recommended - remove symbol rate limits and bandwidth limits. If the FCC agrees with the commenters, such a change requires no additional regulation, “merely” a deletion of the mentions of symbol rate limits and bandwidth limits. I’m hopeful this will happen in 2025 and thus enable new modes of data communications on Amateur Radio VHF / UHF bands - like the second and third generation of IP400 radios that VE6VH has envisioned in his roadmap (see related article) - and finally, legal use of the 1 Mbps mode of New Packet Radio (which exceeds the current 56,000 symbols per second, and the maximum bandwidth for data modes of 100 kHz in the 420-450 MHz band).
44Net VPN Becomes Widely Available
In 2024, ARDC quietly began beta testing a Virtual Private Network (VPN) service for Amateur Radio Operators and selected experimenters to access and use 44Net address space from any other Internet connection. This is an invaluable capability for Amateur Radio Operators that wish to host experimental services directly without the requirement of a static IPv4 address (often expensive or unavailable) to allow incoming connections. I hope that the beta testing has gone well, and in 2025, this service will be available to Amateur Radio Operators. I’m certainly hoping it will be as I have ideas to make various radio systems in my N8GNJ Labs (shop) available for remote access for testing various modems and radios that software developers might not have physical access to.
Basic Mobile Data Radio from China
I posit that the radios being developed within the IP400 Network Project will be complementary to a Basic Mobile Data Radio. IP400 is targeted at fast data and advanced capabilities. A basic mobile data radio is targeted more modest data communications, such as VARA FM.
I currently recommend the Yaesu FTM-6000R as the most cost-effective radio for data use. It currently costs $299 at Ham Radio Outlet. I recommend this radio solely because it’s in production and includes a flat audio (“data”, “9600”) connection that enables plug and play data and the maximum audio frequency bandwidth for high performance modems and applications such as VARA FM.
But for data applications, beyond the flat audio interface, that radio’s features are overkill.
Here’s what we really need, and don’t need, in a basic data radio:
FM radio (no DMR) with a selection of channel sizes.
Flat audio interface - the standard 6-pin MiniDIN “data”, “9600” connector is acceptable.
No, or optional front panel.
No, or optional microphone and speaker. A connection for an external speaker is useful for troubleshooting so you can hear other traffic on the channel.
Optional Bluetooth module capable of voice and data.
All radio functions - frequency, transmit offset, etc. settable from a serial over USB link. Ideally from an internal web server and serial console (for automated scripting).
Max power of 25 watts is acceptable.
Ideally, a big heatsink and fan for high duty cycle operation (long transmit cycles - this is a data radio).
Even if it complicates the design a bit, for the US market, such a radio with 144-148, 222-225 MHz, and 440-450 MHz capability would be ideal. I’d buy several just for the 222-225 MHz capability.
The Chinese Amateur Radio vendors are trying to outdo each other with numerous variations on features most of which are “fufu” or irrelevant features adding complication to the point of not wanting to buy it.
One of the most unfortunate trends is to include an underpowered TNC (patterned after the embedded, underpowered TNC in the Kenwood TM-D710 series radios). In this era, there’s nothing an embedded TNC can do better than can be accomplished with a flat audio connection with all modem and protocol functions moved to a host computer - smartphone, tablet, laptop, desktop, etc.
Some Chinese radio manufacturer is going to figure out this trend, make a radio as above, price them below the “full featured” radios by not including a front panel, speaker, or microphone, and sell a lot of them.
Progress on M17 Project with the backing of the new M17 Foundation
2024 was a transition year for the M17 Project. The most notable development in M17 was the release of the Connect Systems CS7000 M17 portable radio. A radio featuring “M17 out of the box” was a significant milestone. Until then, many considered M17 to be a “science project” - feasible, interesting, open source, and cool that a digital voice system for VHF / UHF had been developed by Amateur Radio, for Amateur Radio. Now, with the CS7000 M17, and the CS7000 M17 PLUS, many consider that “M17 is real”.
But the M17 Project team went through a lot of turmoil and had to reorganize due to changing dynamics within the former team. The new M17 Foundation, based in Poland, is now the sole, official “voice” of the M17 Project. Being an open source project, that doesn’t impede independent development relating to M17.
Within Amateur Radio VHF / UHF, especially among repeater owners, M17 hasn’t made much of an impact. While there are some M17 (capable) repeaters on the air, there aren’t many.
I think that two developments need to occur, hopefully within 2025, to continue and accelerate M17 forward into more mainstream awareness and usage:
We need a mobile radio equivalent to the CS7000 M17; that is a mobile radio (of course, usable as a base radio), with power output of at least 25 watts, with “M17 out of the box”. This radio should also include…
M17 has a data capability that hasn’t been given the same attention, development, and documentation as the digital voice capability of M17. If / when data can become as easy to use as voice within M17, that will put M17 significantly ahead of the partially realized data capabilities of other digital voice systems such as DMR, D-Star, System Fusion, P25, etc. Note that because of the requirement to be able to do “voice one moment, data the next moment” within an M17 radio, this is an exception to my “don’t embed a TNC in a radio” observation in my suggestions for a basic data radio.
My activities in support of the M17 Project in 2025 include:
Contribute to the M17 Project website to provide better, current documentation of most things related to M17.
Maintain the M17-Users email list and promote a reasonable level of activity and interesting information exchange there.
Participate in bringing M17’s data capability to equivalence with its voice capability, especially documentation of how to use the data capability. For more details on this, see the discussion thread on this topic on the M17-Users email list that I started.
Set up my own M17 systems within N8GNJ Labs, an MMDVM hotspot for connecting with other M17 users via Internet, and equipping at least one of my test repeaters with an MMDVM (which supports M17) to develop hands-on experience with M17.
Write a small book about M17 discussing all the various “pieces” of M17, such as (the very basics of) building a repeater with an MMDVM unit configured for M17 as just another digital voice mode, and all the other “M17 capable” units such as the Mobilinkd TNC4.
Progress on new initiatives for APRS with the backing of the APRS Foundation
In December 2024, APRS Foundation lost one of its founding board members - Lynn Deffenbaugh KJ4ERJ. That has handicapped APRS Foundation for a while as it recovers from KJ4ERJ’s passing, which was also a significant loss to the entire APRS community.
The only new initiative for APRS in 2025 under the APRS Foundation that I’m aware of is that I hope that the APRS Foundation can convene a new committee to update the APRS Protocol Specification to represent the “APRS state of the present” in 2025. There were many changes proposed, implemented, and generally widely accepted that were never formally implemented updated in the original formal APRS Protocol Specification. APRS Foundation board member John Langner WB2OSZ has begun such a project, but it has not been adopted as a formal activity of the APRS Foundation (that I can find any public mention of).
In my opinion, that update is the foundation of any future progress on APRS. Without it, APRS will remain a loose confederation of apps and other implementations of APRS technology… which admittedly has worked to date.
APRS Foundation is building up a new website - how.aprs.works (How APRS Works) with foundational articles reflecting modern technologies and usage of APRS. Articles there counteract some of the dated… or just blatantly incorrect… articles that can be found when searching for information on APRS.
In addition to the How APRS Works website, another ongoing project of the APRS Foundation is “rationalizing” the impressive amount of material on http://aprs.org. That website was actively maintained and grown by the late Bob Bruninga WB4APR, the creator of APRS, until his terminal illness and death. Thus the information about APRS there has “accreted” and needs a thorough overhaul. APRS Foundation hasn’t posted any updates on how that effort is going.
Lastly, I hope to see TAPR formally transfer the APRS trademark to APRS Foundation. Doing so would be a significant goodwill gesture by TAPR in active support of APRS Foundation’s role in promoting APRS. TAPR was foundational in the creation and popularization of APRS in its newsletter, conferences, booth at Hamvention, developing unique APRS hardware, and hosting an APRS email list (which continues). But in this era, TAPR does not seem to have any interest in promoting APRS, thus the transfer of the APRS trademark to APRS Foundation would be in the best interest of the APRS community as APRS Foundation is the only entity focused on promoting APRS.
New variants of New Packet Radio and expanded usage of NPR
New Packet Radio was developed as an open source project several years ago, and has been used and tested and found to work as promoted in providing 56 kbps - 1 Mbps raw data rate on 430 MHz using 100 kHz - 1 MHz channels. But the assembled and tested unit offered by ELEKITSORPARTS (like the original units by the developer) transmit at relatively low power levels, requiring a hard-to-find power amplifier designed for DMR portable radios to achieve reasonable transmit power.
Use of New Packet Radio in the US has been somewhat hampered because current US Amateur Radio regulations for the 420-450 MHz band specify a maximum “symbol rate” of 56,000 symbols per second with a maximum bandwidth for data modes of 100 kHz. While NPR has a mode that is compliant with those current US Amateur Radio regulations… such use falls far short of the maximum capability of NPR of 1 Mbps (in a 1 MHz channel).
I haven’t seen any reports about how widely NPR has been used in Europe given that its fastest speed requires a 1 MHz channel, and in Europe the band is 10 MHz - 430-440 MHz.
There’s hope that US Amateur Radio regulations will be modernized to allow NPR’s full data rate. That “full rate” 1 MHz channel won’t be an issue given that in the majority of the US, the band is 420-450 MHz.
Localino offers an improved New Packet Radio unit with an integrated power amplifier with a 7 watt power output.
The SCOMS TACNPR Project in Finland is working to create a version of NPR with an integrated power amplifier with a 20 watt power output.
A 2024-02 ARDC grant to a group in the UK:
… seeks to develop an NPR with both upgraded 70cm capabilities and the ability operate on 2m and 23cm.
That variant will be developed by Localino, who previously developed the 7 watt unit.
Thus with these potential (improved) variants of NPR hardware (higher power radios, additional bands) there might be enough critical mass of NPR usage to drive additional protocol development in NPR, such as increasing the number of users that can use a relay node.
Increased recognition and use of ka9q-radio as an all channel receiver
ka9q-radio is, in my opinion, a technological breakthrough. Connect an inexpensive software defined receiver, to an inexpensive dedicated computer such as a Raspberry Pi 4 or now Raspberry Pi 5, add the ka9q-radio software, and one can monitor all repeater channels in 50-54, 144-148 MHz, 222-225 MHz, and (I think) 440-450 MHz, and a selected portion of 902-928 and 1240-1300 MHz. (I think this requires one SD receiver per band).
Simultaneously! Not scanned sequentially… not just displayed in a waterfall where you “click to listen / decode”… ka9q-radio is the equivalent of a series of independent receivers all operating simultaneously. KA9Q says that he routinely records all the repeater channels that are in use in his area (San Diego, California). ka9q-radio is open source, and the code he’s written receives FM and a few other modes, and it’s up to “the community” to write other receivers such as digital voice modes like DMR and other modes of interest.
ka9q-radio is a major part of what I think will enable my SuperPeater concept. When you don’t need to monitor a specific channel when you want to communicate with another person or station, and you can monitor all repeaters, simplex channels, packet nodes, etc. in your area, the concept of a repeater can be very flexible.
The debut of the Kenwood “TM-D720GA”
This one is hardly a skilled or bold prediction as Kenwood displayed a mock up / concept unit under glass at (Tokyo, Japan) Ham Fair 2024. The product name TM-D720GA is purely my speculation. Kenwood also said “2025” so it’s a tossup if it will debut at Hamvention or Ham Fair.
While I’m hoping for the best…
A flexible architecture that can incorporate new modes such as M17,
Inclusion of a high performance audio interface rather than a TNC with fixed modes, with external access to be able to use it with external modem software (such as VARA FM),
An internal processor that can emulate 1200 bps AFSK and 9600 FSK through the audio interface for backwards compatibility with the TM-D710GA,
Bonus points if they’re able to incorporate at least FX.25, if not IL2P Forward Error Correction.
Higher speed mode like 19200 bps or (dare we hope?) 38400 bps,
Use Ethernet to connect the front panel to the radio unit so that the front panel can be remoted much further away from the radio unit with long cables,
A “de-featured” companion unit radio such as the TM-V71A was to the TM-D710.
A method to connect a keyboard, either USB or Bluetooth,
and the same great, rugged, big microphone as the TM-D710GA and the TM-V71A.
I’m bracing for the worst…
High price - I’m guessing at least $800; I wouldn’t be surprised if it costs over $1000,
The packet radio capability - 1200 bps AFSK and 9600 FSK is fixed like the TM-D710GA,
Feature set basically the same as the TM-D710GA - pretty (color) display optimized for APRS,
Uses the same (underpowered) internal TNC as the TM-D710GA,
1200 bps AFSK and 9600 bps FSK like the TM-D710GA,
Removes the flat audio (“data”, “9600”) connection making it largely unusable for VARA FM. Admittedly this isn’t a big deal as much lesser radios can be used for VARA FM… but it would be nice to have the option to use VARA FM,
No keyboard capability,
Basically the same cable distance limitations between the front panel and the radio unit due to using the same proprietary interface,
Lightweight, lesser quality microphone,
No “de-featured” companion unit radio such as the TM-V71A.
We’ll see it when Kenwood wants us to see it. Whatever the features, and whatever the price, the Kenwood APRS fans are eager for a TM-D710GA replacement, and will buy this new unit.
It will be interesting to see if the Kenwood documentation for this radio says that APRS is a trademark of… TAPR, who is now the owner of the APRS trademark. It’s muscle memory for the APRS community to state that APRS is a trademark of Bob Bruninga, when that has not been the case for several years now.
VARA FM continues to be the most robust, fastest data mode…
For standard VHF / UHF FM voice channels…
Using standard VHF / UHF FM voice radios (including those with a flat audio connection)…
Using standard or high performance audio interfaces.
As I’ve documented in Zero Retries, VARA FM has a lot to recommend it. One key aspect is the amazing performance of 13 kbps using nearly any radio, connecting to the microphone / speaker connections. Previously, the best data speed that could be achieved with those connections was 2400, perhaps 3600 bps (with a NinoTNC or Dire Wolf Software TNC). And the very best feature of VARA FM is that it can auto negotiate between VARA FM stations for “best common speed”, so that high performance stations (that can do up to 25 kbps) can communicate with lower performance stations (that can do up to 13 kbps) on the same channel.
One under-appreciated aspect is that VARA (FM and HF) includes a KISS interface, so any packet radio software that can “speak KISS” can use a VARA connection.
Another stellar aspect of VARA (FM and HF) is the independently developed VarAC companion program which features great user interface design, email, messaging, and many other features beyond the basic VARA features and the VARA Chat and VARA Terminal utilities offered by VARA’s author.
We’re edging closer to VARA’s capabilities with open source systems and software, but to date, no one has combined the same set of capabilities of VARA FM.
zBitx - More Casual HF Operation Outdoors… and more General Operators
More people than ever (including me) will embrace outdoor, casual HF operating thanks to the new highly portable zBitx HF radio. It costs < $200 and includes data modes natively (yay!) - including FreeDV digital voice. It can easily be connected to an external display and keyboard (if desired). In 2025, I predict that HF Signals will sell all the zBitx units they can manufacture… and still be waitlisted by the end of the year.
zBitx is finally the flexible, software defined, low cost, easy to use HF radio suitable for portable operation that will motivate many Technician class operators to upgrade to General so they can operate on HF with a zBitx.
Potentially (admittedly this is a stretch, with no hint of such a thing from HF signals, which hasn’t yet shipped production units), zBitx will be so popular, that we may see a zBitx 2 designed for fixed operation with a bit more transmit power.
Amateur Digital Television Receiving Increases
Equipment to participate in Amateur Radio Television repeaters is expensive and it’s a rite of passage to get working (often on 902-928 MHz or 1240-1300 MHz). But new capabilities to receive Amateur Radio Digital Television on inexpensive Software Defined Receivers coupled with a dedicated computer (typically a Raspberry Pi) allow viewing of ATV Digital Repeaters.
It will be very cool for the current video-first generation (think TikTok and YouTube) to be able to see live video via an Amateur Radio repeater in major cities that have an active group that provide a (Digital) Amateur Television Repeater.
Raspberry Pi 5 Family Makes a Difference
It seems to me that with the Raspberry Pi 5, 16 GB RAM version, for $120, a significant threshold in embedded price / performance has been crossed.
The Raspberry Pi 5 family now includes the classic form factor Raspberry Pi, with variants from 1 GB RAM to 16 GB RAM, but also the Raspberry Pi 500 “built into a keyboard” and the Raspberry Pi 5 Compute Module.
Beyond the usual speed increase in a new Raspberry Pi product line (2-3x faster than a RPi 4), the Raspberry Pi 5 introduced the ability to cleanly integrate an SSD via a native PCIe interface, a real time clock, native H.264 video decoding, and numerous other improvements.
Sadly, one “step backward” of the Raspberry Pi 5 is that this performance improvement now requires active cooling (a fan).
With the performance improvement, greater RAM, fast storage with integrated SSD, perhaps AI / machine learning applications will improve or perhaps “now made practical” with the RPi 5 family. For one, I’d love to see an “Interactive Voice Response” capability created for monitoring repeaters. Something like if someone calls “N8GNJ - you around?” on one of my favorite repeaters, I get a popup on my computers that someone is calling me.
Progress on a Amateur Radio GEO payload for the Western Hemisphere
Approximately… none… in 2025. This is my sole pessimistic prediction for Zero Retries Interesting projects in 2025. While I’ve observed some activity on this subject in 2024, and some studies are underway… I don’t detect any sense of urgency. No one is talking… at least in public venues. There may be something going on in the pages of AMSAT Journal or AMSAT-DL Journal, but that’s paywalled.
It says a lot that the web page of AMSAT-CA, an organization formed specifically for such a possibility, is now offline, viewable only via the Internet Archive, and that page never progressed beyond a placeholder web page.
And last but not least, the IP400 Network Project
I’ve written extensively about the IP400 Network Project in recent issues of Zero Retries, and I’ll have much more to say in near future issues, so there’s little need to rehash all of that info in this mention. This issue includes an article by Martin Alcock VE6VH about the near future of IP400.
Suffice it to say I fully expect to see several generations of IP400 Network Project hardware, and some amazing software / firmware / protocol capabilities to emerge in 2025, all operating at data rates we wouldn’t previously have imagined.
…
I hope that Zero Retries Readers will share their Zero Retries Interesting predictions / hopes for 2025 in the comments section of this issue.
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
Upcoming Events Countdown
Utah Digital Communications Conference, 2025-02-22 in Sandy, Utah, USA in 3 weeks.
HamSCI 2025, 2025-03-14 and 15 in Newark, New Jersey, USA in 7 weeks. Tina KD7WSF and I will attend this event. I hope to meet up with any Zero Retries readers that are also attending HamSCI 2025 to talk about all things Zero Retries Interesting.
Southeastern VHF Conference 2025, 2025-04 and 05 in Clarksville, Tennessee, USA in 9 weeks. More details in an email list message.
LinuxFest Northwest 2025, 2025-04-25 thru 27 in Bellingham, Washington, USA in 12 weeks. No direct involvement with Amateur Radio, but I’ll be attending and learning.
Four Days In May 2025 - 2025-05-15 in Fairborn, Ohio USA (in conjunction with Hamvention 2025).
Nice Mention of IP400 Network Project in Amateur Radio Newsline
Amateur Radio Newsline Report 2466 for Friday, January 31st 2025 (script text):
Mesh Network For 70Cm A Project In Canada
PAUL/ANCHOR: An ambitious project in Canada hopes to develop a mesh network to link repeaters and accommodate several digital modes. Hoping to combine the best features of such digital networks as HamWAN, AREDN and New Packet Radio, developers in Canada are starting development of a mesh network that will operate on the 70cm band.
Writing in the newsletter, Zero Retries, Martin Alcock, VE6VH, said the project is being designed to link repeaters using RF and will include digital voice modes, data transfers, messaging and a data networking layer. The project is called IP400, short for Intelligent Protocol 400. It has the support of the Alberta Digital Radio Communications Society and is looking for contributors familiar with the C and C++ languages. Free open source code is being used for the development. IP400 is intended to operate on amateur frequencies between 420 and 450 MHz. Martin said that unlike conventional analogue links, a digital mesh platform will be capable of carrying compressed digital video as well as compressed audio and telemetry.
He writes: [quote] "The first step is to get a simple chat and beaconing application running to experiment with the technology. From there we can layer on other features and frame types, and then consider moving into the repeater world." [endquote]
A link to his contact page can be found in the text version of this week's newscast at arnewsline.org
[DO NOT READ: https://ve6vh.mapledsp.com/home-page/contact/ ]
(ZERO RETRIES, AMATEUR NEWS WEEKLY)
That’s a really nice writeup of IP400 Network Project for a general (and very wide) audience of Amateur Radio Newsline. I’ve been a fan since they were known as Westlink Amateur Radio news back in the 1980s. And the mention of Zero Retries in the script (to be read) is always appreciated.
Also thanks again to Cale Mooth K4HCK for the original mention of the IP400 Network Project in Amateur Radio Daily, January 19, 2025. K4HCK is the most SEO-savvy person I know of in Amateur Radio, and stories in Zero Retries that get coverage in Amateur Radio Daily and Amateur Radio Weekly become much more widely noticed than what I’m able to achieve in Zero Retries.
Forgotten Internet: Giving (Or Getting) The Finger
Finger was a common service provided by computer services at the time. It was like a LinkedIn profile page for the 1970s.
Based on RFC 742, Finger was the brainchild for [Les Earnest]. From a user’s point of view, you put a few files in your home directory (usually .project and .plan; both hidden files), and when someone “fingered” you, they’d see some human-friendly output about your account like your name and office location, if you were logged in or not, and the contents of your project and plan files.
Modern versions may also show your public PGP key and other data. You could usually put a file in your home directory called .nofinger if you wanted to stop people from fingering you.
Finger was a feature of the TCP/IP software we used back in the days of the Puget Sound Amateur Radio TCP/IP Network, and referring to it was even cringier than this article suggests… the common usage was “finger someone”.
But seriously, finger was one of my favorite minor features of operating Amateur Radio TCP/IP. We regularly had new users come online, and everyone was curious what the “new user” would say in their finger file. One person’s finger file memorably had many, many quotes that went on for several screenfuls. Fortunately, this was all being done at 9600 bps.
I’d certainly like to see something like a finger feature in the IP400 Network Project software. I’ve also suggested it for inclusion into the excellent VarAC app.
DigiPi Compatibility with the All In One Cable (AIOC) Interface
Jeff Marden N1JCM on the DigiPi email list:
I looked at the script provided by G1LRO and it appears he adds a "PTT /dev/DEVICEFILE -RTS DTR" to the DIrewolf.xxx conf files to get the AIOC working. For me "DEVICEFILE" is ttyACM0. Not sure what "-RTS DTR means; Serial Request to Send and Data Terminal Ready signals, or something else.
Anyway, when I added this text to the "direwolf.tnc.conf" and "direwolf.digipeater.conf files, DigiPi for these selections appeared to work including PTT.
More testing to do.
This minor configuration change allows any Raspberry Pi to use an inexpensive AIOC device to easily connect to a portable radio that adheres to Kenwood’s external speaker / microphone spacing and signals (such as Baofeng radios). In using AIOC, dedicated DigiPi hardware isn’t needed, and there’s no need to buy or build custom cables from your DigiPi interface to your radio.
(This change also enables a pretty painless computer-to-portable connection if, for example, you’re running Dire Wolf on your laptop. USB-C from your laptop to USB-C on the AIOC. Just add that critical new line in the Dire Wolf configuration on the laptop.)
This makes Amateur Radio data communications, at least the modes supported in the DigiPi software, even more accessible. DigiPi was already one of the easiest entries into Amateur Radio data communications, and this development makes for an even more plug and play starter package.
Put another way, DigiPi plus an AIOC is a great entry into data modes for those new hams with a Baofeng that wonder “Hmmm, what else can I do with this thing?”
In an email exchange, N1JCM recommended that the USB-A (Raspberry Pi) to USB-C (AIOC) cable include ferrite chokes, since the USB cable is so close to a source of radio energy (when you use an antenna directly connected to the portable radio).
I bought good quality hi-speed, shielded USB cables, along with some type 43 Ferrites and put two loops of cable thru a Ferrite at each end of the cable about 5 inches from the connector. This kept RF out of the DigiPi and the Laptop.
N1JCM also wanted to provide credit due to Mark Herbert G1LRO:
Please note in your article that my work with the AIOC and DigiPi resulted directly from the earlier work G1LRO did in creating a web page and script for updating the DigiPi-specific config files for direwolf to work with the AIOC, and another similar product from the same vendor. I looked at his shell script to see what he was changing and made those changes manually in my DigiPi/direwolf config files to get TNC/igate and digipeating going.
My ongoing kudos to Craig Lamparter KM6LYW for creating the DigiPi project.
Followup on Zero Retries 0186 - Thought Experiment - Integrating Personal Radio Science Projects
Bill Echols NI5F, via email:
Many are already doing some to most of these things.
I already have HF WSPR beacons on all bands including 22-meters and have had for years. I have four receiver banks of SDRs monitoring all HF bands and several VHF bands for WSPR, packet, etc.; eight of these are available online for users at my IP address of
72.170.239.252
on an assortment of ports (see QRZ.com/NI5F for port numbers). The KiwiSDR is quite busy most of the day; the SDRPlays are not as busy. The best of them, 2 Perseus, are rarely accessed. I run all of them with openwebrx or openwebrxplus so that no drivers or other software is needed to use them. In addition to the receivers…
I have multiple APRS gateways.
I have airplane data exported to FlightAware, FlightRadar24, and ADSB-Exchange for both Mode-S and UAT.
I collect earth movement with infrasonic detector and seismometer.
I have a GQ Geiger counter that continuously sends data to online map.
I have two complete weather stations online: KFLGRACE11 and KFLGRACE12.
I have HamSCSI Grape 2 with magnetometer collecting data from WWV on multiple frequencies.
I collect Jupiter noise and sun noise measurements for NASA's Juno project.
I collect solar power in visible light and UV during sunlight times.
I have a tracking camera that records the skies above, in particular, the airplanes leaving persistent contrails. No one wants this data, by the way.
I have an IQAir Nano-particulate counter; that data goes to a server in Switzerland.
All are above equipment runs off DC with multiple solar chargers and battery banks. I have learned the hard way that the AC power system is not reliable.
The biggest issue is that the data are sent to various servers all over the world. I don't want to stop that; I instead want a piece of software for my Ubuntu server that will collate the data and display it all realtime. That way you can have a picture of what is going on at EM70FU. That software doesn't exist yet although I am learning C++ and how to program a useful GUI for my Apache server instance.
It takes a lot of time and money buying or building all the equipment, configuring, installing, and then maintaining it. Just keeping all the 30 or so Raspberry Pi's running on static IPs and keeping track of all the passwords, hostnames, NTP connections, etc. is necessary and time-consuming.
Ideas in my head:
What I would like to see is an organization that would set up a server perhaps with VLANs to separate, for example, ADSB from particulate count, or separate servers on different IP ports, to take all the data, mostly UDP, I am forwarding all over the world to disparate servers and save this TCP-IP data tagged with my Maiden Head coordinates. When those locations are selected by observers or analysts on an online GIS, such as Google Maps, a selection window would open and you could view any or all the saved categories real time. If you wanted a 1-day, 10-day, or 1-year history, selection is made and the tabbed .csv is stored on an TFTP server for their download.
This in-place storage might encourage others to contribute whatever data they collect. Furthermore, it might encourage others to contribute. I can see getting local junior high and high school students to participate.
First technical steps for this new organization will be to determine what you want to store AND the transmission format and daily payload for each of the pushes AND the way to bridge the current contributor's payload to the respective archive IP address and port in the proper format. Second step would be to size the servers and the incoming Internet port and ensure redundancy to deliver 5 nine's availability. Third step is to define security parameters internally and with the contributors, observers, and analysts.
This is a large undertaking and I would probably need either a technical corporate sponsor (no, I don't mean the ARRL :) ) or university sponsorship. Some of the data has financial implications; for example, the lightning data could be used by insurance companies to detect fraud or validate claims for lightning damage.
I do like the way ADSBExchange has a Raspberry Pi Python script you can download from their website to add feeding to them from your existing data feed to FlightAware or FlightRadar24. You just download from a command line in the FlightAware (or FlightRadar24) Pi and it installs and almost configures itself; you do have to tell it your coordinates.
When I wrote that thought experiment, I imagined that some were actually doing such things, but it often surprises me that “I don’t imagine big enough” when someone like NI5F replies with such an impressive “Oh, is that all you want to do? How about…”
My thanks to NI5F for this excellent description of what’s possible, but also for his impressive ongoing contribution to citizen science.
WiFi Retromodem for USRobotics Sportster
Introducing the WiFi Retromodem, an innovative solution that seamlessly replaces the PCB in your existing external USRobotics Sportster modem. With our latest Version, experience a nostalgic journey with added simulated audio featuring dial tone, DTMF dialed digits, ringing and the 1200 baud connect cadence. Based on GitHub ZiModem V4.0 sources, its supports baud rates up to 115,200.
I mentioned this vendor’s previous product for Hayes Smartmodems in a previous issue of Zero Retries. But this time I was more curious about the vendor, Tattler Solutions. There were some potential fateful words there…
Custom Work Available.
So maybe my fantasy of retrofitting vintage AEA PK-232MBX units that I’ve been stockpiling for cheap, with a new circuit board that makes use of all the indicators, switches, knobs, etc. for modern usage, such as embedding an audio interface and a Raspberry Pi…
Sigh. No. Not today. Way too many other projects ahead of that fantasy. Gotta… get… back… to… editing.
5 GHz from Espressif: The ESP32-C5
Andreas Spiess HB9BLA:
The ESP32-C5 is the first dual-band chip with 2.4 and 5 GHz WiFi. I got one of the first engineering samples to show to you.
This is a bit of a coup for HB9BLA as this was the very first mention I’ve seen of this new ESP32 version. It’s a logical development; being able to get an embedded device onto 5 GHz Wi-Fi solves a few problems such as having dedicated Wi-Fi access points for specific projects can more easily be accommodated on 5 GHz than the three non-overlapping channels available on 2.4 GHz. We’ll see a lot of usage for this device in the near future.
Bouncing Signals Off Of Satellites Other Than The Moon
Bryan Cockfield in Hackaday:
The moon is a popular target for ham radio operators to bounce signals since it’s fairly large and follows a predictable path. There are some downsides, though; it’s not always visible from the same point on Earth and is a relatively long way away. Thinking they could trade some distance for size, an amateur radio group from the Netherlands was recently able to use a radio telescope pointed at a geostationary satellite to reflect a signal back down to Earth, using this man-made satellite to complete the path instead of the more common natural one.
While I understand (really, I do) understand the Amateur Radio übertechie cred appeal of this… project…, and I offer (kind of) kudos for its success. But, um, did no one consider the satellite owner’s perspective about having unwanted radio energy focused on their (private property) satellite (Inmarsat GX-5), which has sensitive radio receivers? The reason that doing Earth Moon Earth (EME; Moonbounce) is of no concern to anyone is that there isn’t any one / any thing on Luna that could be harmed from focused radio energy targeted at Luna. Not to mention that without a government level budget (like the RADAR ranging that was part of Project Diana), it’s tough to deliver meaningful levels of radio energy to Luna.
I think it’s telling that the article linked in the Hackaday article is “404”, but Internet Archive preserved it, and in that article there’s no mention of them obtaining permission to “target” Inmarsat GX-5. Geosynchronous orbit slots are of high value, so there are few if any satellites there that aren’t functional and in revenue use, and thus the owners of those satellites have reason to be protective of them.
How To Install The Software-Defined Radio (SDR) Inspired Linux Lubuntu Distro Called “DragonOS_Focal” Onto An Old Windows 10 Laptop
Mindy Hull KM1NDY on her KM1NDY blog:
I have an old HP ProBook that is not qualified for an upgrade to Windows 11. Some readers may remember I have been dabbling in Linux over the years. And by dabbling, I mostly mean clenching my jaw, hands, and toes, waiting for something to install, and fretting over how badly I broke my computer this time. An attempt to figure out how to use VIM / GCC instead of the Arduino IDE destroyed the Linux Mint OS I had installed on my cheapo computer. I have yet to reinstall.
…
The bottom line? Like all things Linux, the installation process is finicky. But once it is working, the software (including GNU Radio) seems to work flawlessly with my SDRplay RSP2. I have had some pain points with the installation, including losing wireless connectivity and problems with the system starting on a reboot. But overall it works.
Though I’ve never actually used or installed DragonOS, I’ve known of it for years, and see it frequently referenced and well respected by others I follow. You have to love the simplicity of its raison d’être:
Out of the box OS for SDRs
with a selector for Raspberry Pi or X86-64.
I love “recipes” like KM1MDY’s in this article. That’s the reason I snagged a small stack of lightly used surplus Lenovo laptops when I saw them for a good price at a computer recycling store. I also have a larger cache of surplus desktop Lenovo’s from the Windows 7 era. They’ll be used as dedicated “appliances” for various Amateur Radio projects. I’m not concerned (too much) about maintaining them to current Windows or Linux standards as when I do use them on a network, it will be partitioned off from my Internet and household networks.
Zero Retries Boilerplate
See the Zero Retries Boilerplate page for significant acknowledgements and other information relevant to Zero Retries. For new readers of Zero Retries, that page, and the About Zero Retries page has useful information to check out.
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Annual Founding Members who generously support Zero Retries financially:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2024)Founding Member 0001 - Randy Smith WU2S (Renewed 2024)
Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2024)
Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2024)
Founding Member 0004 - William Arcand W1WRA (Renewed 2024)
Founding Member 0006 - Todd Willey KQ4FID (Renewed 2024)
Founding Member 0007 - Merik Karman VK1DF / VK2MKZ (Renewed 2024 with two Founding Member subscriptions!)
Founding Member 0008 - Prefers to Remain Anonymous 14 (Renewed 2024)
Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025)
Founding Member 0011 - Rick Prelinger W6XBE (New 2024)
Founding Member 0012 - Ryan Tolboom N2BP (New 2024)
Founding Member 0013 - Newton White N4EWT (New 2025)Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
Thanks for reading!
Steve Stroh N8GNJ / WRPS598 (He / Him / His)
These bits were handcrafted (by a mere human, not an Artificial Intelligence bot) in beautiful Bellingham (The City of Subdued Excitement), Washington, USA, and linked to the Internet via Starlink Satellite Internet Access.
2025-01-31
Blanket permission is granted for Amateur Radio use of any Steve Stroh content in Zero Retries for Amateur Radio newsletters and distribution via Amateur Radio such as (but not limited to) Packet Radio Networks, Packet Radio Bulletin Board Systems, Repeater Nets, etc. Specific blanket permission is granted to TAPR to use any Steve Stroh content in Zero Retries for the TAPR Packet Status Register (PSR) newsletter (I owe them from way back).
In such usage, please provide appropriate authorship credit for the content (especially for guest authors) and mention that it was first published in Zero Retries newsletter, preferably in this format:
This article is reprinted with permission. It was first published in Zero Retries newsletter, issue Zero Retries (number), (date) - (include full web link of the specific issue).
It’s appreciated (a courtesy, but not required) to notify Zero Retries Editor Steve Stroh N8GNJ of any reuse of Zero Retries content - stevestroh@gmail.com
If you’d like to republish an article in this issue for other uses, just ask.
All excerpts from other authors or organizations, including images, are intended to be fair use. Unless otherwise noted in the article, there are no paid promotional items in any Zero Retries articles.
Portions Copyright © 2021, 2022, 2023, 2024, 2025 by Steven K. Stroh.
Footnotes for this Issue
To see the relevant sentence for the footnote, just click the footnote number.
In mentioning this, I’m not condoning, or suggesting, or encouraging such activity or development of such a capability. I’m merely pointing out the reality that new technologies such as SDRs create new capabilities which can (and are) used for good, or for ill.
I made that term up… or so I thought, until I thought to check and sure enough, it’s already in use.
I think that “where the puck has been” is going to increasingly apply to “Software Defined Radios” that are “locked down” and the user cannot change them. FlexRadio is one of the few that straddles this trend between their “locked down” SmartSDR radio operating system… which also has Application Programming Interfaces (APIs) that allow user software to be loaded into the radio (as of the FlexRadio 8000 series which has enough processing power to spare for user software).
Possible, perhaps, but not (reasonably) feasible in Amateur Radio, especially at Amateur Radio prices.
A memorable quote at a conference I attended went something like “I needed a radio that did X… so I took a little bit of time and wrote one”.
That software was becoming a key component of communications occurred to me back in the late 1980s whe were playing with old packet radio networks. Soon we had TCP/IP over packet through our TNCs. In the '90s we began talking about software defined radios - which are now mainstream. And now we have "radios" that aren't exactly radios either! As I write this, I'm on 7.074 Mhz FT8 - where to a large extent, much of the the "radio" is my PC! There is much innovation yet to come - and we will see it across the board, in analog and digital radio - and much more.
Steve wrote, "zBitx will be so popular, that we may see a zBitx 2 designed for fixed operation with a bit more transmit power".
HFSignals also offers the sBitx, which is a 25 watt radio that offers similar capabilities as the zBitx in a larger and more expensive package. In many ways the zBitx is a miniaturized version of the sBitx. https://www.hfsignals.com/index.php/sbitx-v3/
I am also someone that is interested in picking up a zBitx when they become available! :-)