Category: Blog

Your blog category

  • Tom Salzer KJ7TRandom Wire 203: An Allmon3 password leak, and locking down AllStar logins​Random Wire℠

    Tom Salzer KJ7TRandom Wire 203: An Allmon3 password leak, and locking down AllStar logins​Random Wire℠

    Issue 203 of the Random Wire newsletter brings you AllStar, WiRES-X, and networking topics. A new Notices section near the top has announcements of interest. I highlight three new articles on EtherHam.com, plus bring you the weekly report. Closing out issue 203 is a real story of a maintenance worker, a circuit breaker, and a broken network.

    1. QRV: Are You Ready

    It’s been a full week. Last Friday, issue 202 published. That same day I dove into using fail2ban to help block login attempts to my Allmon3 dashboard and the AllScan favorites management tool. Along the way, I discovered a bug in Allmon3 that had been fixed and then resurfaced in a later change. That bug is fixed now.

    Sunday, I made a long day of it with an early morning drive to Portland. Driving Interstate 5 is not nearly as bad at 5 am on a Sunday morning, compared to the rest of the week. It felt relatively peaceful. While there, I packed up my old WiRES-X station and brought the bits to the lake house. That resulted in a write-up about getting my WiRES-X station back online. I chose to stay on version 1.57 for compatibility with legacy rooms and nodes, and to avoid some known operational issues with version 2.x.

    One of the issues I ran into in Portland was bringing my network back online. That story is in this newsletter. It revealed to me that my documentation of my own network was so poor that it took longer than it should have to get things running right again. So on Monday and Tuesday, I built a simple wiki system for tracking my gear and connections. It runs off a USB device for portability. I wrote that up in case you want to try something similar.

    When Wednesday dawned, I could feel my newsletter deadline looming, so it was time to stop playing with tech and finish writing issue 203 of the Random Wire! While I did that, I had my WiRES-X node running right beside me, catching some traffic from the Kansas City Wide network and the local Yaesu System Fusion repeater.

    Next week, I have two all-day meetings. One is in Silverdale, Washington and the other is in Vancouver, Washington. Add in a day trip to Portland and it means I’ll get no writing done on Sunday, Tuesday and Wednesday, so expect a lighter Random Wire newsletter in issue 204.

    2. Notices

    2.1 It’s World Space Week!

    World Space Week ends tomorrow. I missed alerting you to it last week, and it seems silly to bring it up now. But for those of us interested in space topics, it’s good to be aware of this. Mark your calendar for next year!


    2.2 RadioID to Begin Verifying Numbers

    Find the full notice at https://radioid.net/

    ID numbers used for DMR and other amateur radio digital networks are a finite resource. Due to the growing popularity of these modes, along with some users requiring multiple IDs, certain regions are expected to face ID shortages in the near future.  Beginning July 1, 2026, RadioID.net will implement an annual verification process. On the anniversary of each account's creation, RadioID.net will send an email to the account holder requesting confirmation that the assigned ID(s) are still needed and that the account information remains accurate and up to date.

    Annual ID verification notice from RadioID.net

    I recommend everyone log onto RadioID and see if your account is now “due for annual review.” Mine was. It was a multi-step process to verify information, and the prompts are a little confusing. Even though I wasn’t deleting anything, I had to check the box that said I understood what it meant if I was deleting something. On the plus side, it was all self-certification, so it only took a few minutes.

    Thank you to Jeff for sharing this.


    2.3 Search for Random Wire Content

    Reminder: you can search the Random Wire newsletter history on EtherHam at https://etherham.com/rw_search/. This is a custom archival system that takes my exported data from Substack (the entity that hosts the Random Wire) and pushes it to a database on EtherHam. Someday, I’ll find time to properly index my content. For now, at least there is search.


    2.4 Zero Retries Conference is October 16

    Live Attendance via Zoom: Price $45.00

    The ZR team writes:

    We have hired an AV team to provide a live feed into the conference so that people can be part of the live conference without being there. The URL will be sent a few days prior to the conference and a link to download the materials.

    Click here to register.


    2.5 AllScan Web App Updates

    The release notes tell the tale: version 1.02 added a touchscreen option and 1.03 fixed one issue with it. The touchscreen is a pretty big deal, in my opinion. If you run AllScan on a tablet or phone, it makes a real difference in usability.

    v1.03 2026-10-07
    Fix issue in TouchGUI where it would not use the favorites file selected in the main GUI. Add check to ignore duplicate node entries in favorites files.

    v1.02 2026-10-03
    Added a new touchscreen / small screen optimized GUI that can be accessed by clicking/touching the “TouchGUI” link in the header links at the top of the page. To then exit the TouchGUI just click/touch the AllScan link at the top left. Thanks to Ben WY2K for this contribution.

    AllScan header after updating

    AllScan header after updating

    Once updated, you’ll see version 1.03 on the left side of the top bar, and over to the right, you’ll find the new TouchGUI option.

    Standard AllScan (left) and the new TouchGUI (right) on my phone

    Standard AllScan (left) and the new TouchGUI (right) on my phone

    In the side-by-side view above are two views of my phone screen. The left view is the standard AllScan interface. The right panel is the new TouchGUI. Now imagine you are walking or driving. Which interface seems easier to use? For me, the big touch buttons are far easier on a small device.

    3. Thank You

    Jonathan and Marty, thank you for the coffee! It seems as if my world runs on caffeine, so this is much appreciated.

    4. New on EtherHam

    4.1 Getting My WiRES-X Node Back Online

    Months ago, the computer that ran my WiRES-X system in Portland died. This week, I finally got around to replacing it. As part of that process, I moved it to the lake house and got it set up there. I’ll add a bit more below, but if you want to jump straight to the full story, visit Getting My WiRES-X Node Back Online, on EtherHam.com.

    When looking for a new computer, I knew I wanted small, inexpensive, and capable enough to run the WiRES-X application. I read several reviews before I ordered a GMKtec NucBox G10, and I think the tradeoffs are reasonable for a WiRES-X platform. Here is one of those reviews: GMKtec NucBox G10 mini PC review.

    This budget model PC uses DDR4 memory, not the more modern and faster DDR5 RAM. What this means is the available bandwidth for the CPU is effectively reduced. And since the GPU shares main memory, video performance is also impacted by the use of DDR4. But none of that matters much for WiRES-X on Windows 11.

    I do have to say that when I went shopping, I quickly discovered there are no good deals anymore on new computers. A few years ago, you could score a solid little computer like this for a few hundred bucks. Not today, it seems!

    Margarine container to redirect sound from radio speaker

    Margarine container to redirect sound from radio speaker

    To redirect the audio from the radio speaker more toward me, I made a temporary shroud from a margarine container. It looks odd but works fine, pushing the audio toward my ears instead of to the entire room. Read the story in Getting My WiRES-X Node Back Online, on EtherHam.com.


    4.2 Putting fail2ban on Allmon3 and AllScan, and the Bug That Bit Back

    I started working on hardening a few of my AllStar nodes, and one of the first things I did was to implement fail2ban for Allmon3 and AllScan logins. Usually, you see fail2ban used to jail unruly folks trying to break into your SSH port. But it can do more, and I was eager to try this.

    What I thought would be a simple fail2ban setup for node logins revealed an unexpected surprise: a password leak. I privately reported the issue, which was resolved the very same day. If you saw a version change in your Allmon3 package to 1.11, that’s the fix.

    Read all about it in Putting fail2ban on Allmon3 and AllScan, and the Bug That Bit Back, on EtherHam.com.


    4.3 Documenting My Networks with a Wiki

    I wanted a way to document my network topology, equipment, and all the other details one must remember — including why I picked certain things and what they were expected to do. The system had to be simple. I’ve tried network scanners and complicated, SQL-based systems. No thank you. My solution needed to be a flat-file system I could take with me, something I could read even if the software died.

    I settled on DokuWiki on a Stick, installed on a Lexar external device. The wiki is beginning to take shape.

    The KJ7T Networks wiki start page, running from the NETDOCS drive

    The KJ7T Networks wiki start page, running from the NETDOCS drive

    The catalyst for this was a power loss at the Portland QTH. As I worked on recovering my network, I discovered that my records were not complete. I had to dig more than expected to find information, and that cost me a few extra hours of work. I realized that centralizing much of this information in one place would be helpful, so I started thinking about how to do that.

    And I’m starting to put how-tos into the wiki because frankly, I’ve got so many different devices and ways of doing things, I’m forgetting important steps.

    Read the write-up in A Wiki That Lives on the Rack.


    4.4 The Weekly Report

    Jump to your favorite section:

    Or click through for the full report: Weekly Report: October 8, 2026

    5. In The Lab

    5.1 Recipes at EtherHam.com?

    A reader suggested taking some of the content on EtherHam and making it more succinct. I have to admit I do get wrapped up in the storytelling sometimes, so I can certainly understand the desire for more concise, step-by-step instructions.

    I’m testing that idea with information about the 44Net allowlist I added to my MikroTik router, and I’m calling it a recipe. Personally, I like the recipe idea. We can all relate to it, and it sounds a lot less daunting than “installation procedures” and similar descriptors.

    Find the first recipe at: https://etherham.com/recipes/mikrotik-44net-allowlist/

    Take a look and let me know how this lands with you. Thumbs up? Thumbs down? Let me know with a comment or email me at etherham@pm.me.

    Leave a comment


    5.2 Changed at EtherHam.com

    I run a bot blocker at EtherHam.com because I don’t want the overhead of bots constantly crawling the site. This week I made one exception: ChatGPT-User. Unlike a crawler, it only visits a page when a person asks ChatGPT to read it. So now people can have ChatGPT read and cite EtherHam articles, while OpenAI’s training crawler stays locked out. That seems like a reasonable balance to me.


    5.3 AllScan Fix: Favorites Files Now Work Across Nodes

    I have more than one AllStarLink node, and I wanted them to share the same list of AllScan favorites. AllScan stores favorites in a file called favorites.ini, so I copied that file from one node to another. That’s when I hit a problem.

    The favorites.ini file can group favorites under a heading for a specific node number. My copied file had a heading for the node it came from. When I used Add Favorite on the new node, AllScan added the new favorite to the end of the file, which put it under the other node’s heading. AllScan only displayed favorites for the node it was running on, so the favorite I had just added never appeared.

    I shared this with David Gleason NR9V, the author of AllScan. He fixed it within days. AllScan now reads the favorites under every node heading in the file and merges them into one list. As David put it, favorites files “ideally should be interchangeable between various nodes.” If you want different favorites on different nodes, he suggests keeping a separate favorites file for each node instead.

    If you upgrade AllScan (the latest version is 1.03), it should bring in that fix.

    Thanks, David, for the quick turnaround.


    5.4 WA7ABU Tech Net (Tuesday)

    I listened to the WA7ABU tech net at 10 am Pacific last Tuesday, October 7th. This net has a regular group of participants who have technical proficiency in many aspects of amateur radio. I learn something new every time I tune in. Here’s a glimpse of some of the content discussed in just this one net.

    Net Schedule & Repeater Info

    Meets weekdays from 10:00 AM to 11:00 AM PDT on 145.290 MHz (Alternate: 145.190 MHz, CTCSS 100.0 Hz) via the WA7ABU repeater in Oregon’s Mid-Willamette Valley. Linked via AllStar (Node 543260) and EchoLink (WA7ABU-R).

    Technical Discussion Highlights

    • Digital Voice Modes & Vocoders:

      • The group discussed the differences between hardware vocoders (such as the AMBE-3000 chip used in DMR, D-STAR, and System Fusion) and software codecs.

      • Brett (KG7GDB) and John (K7JCD) noted that AMBE chips analyze speech and model a simulated vocal tract on the receiving end, which often yields a distinct “robotic” voice quality and discards original audio data.

    • FreeDV & The RADE Codec:

      • Discussion centered on recent ARRL/QST coverage of FreeDV and the new RADE (Romeo Alpha Delta Echo) auto-encoder. RADE uses machine learning/AI techniques to train an encoder/decoder pair over Orthogonal Frequency Division Multiplexing (OFDM) parallel carriers. [KJ7T comment: RADE stands for Radio Autoencoder. Like AMBE, it is a vocoder system. It sends a compact set of speech features (pitch, spectrum, voicing) rather than the original audio, and the receiver synthesizes the voice from them. RADE’s advantage is better speech quality and robustness on HF, not lossless audio.]

      • Unlike AMBE, software codecs like RADE compress audio without discarding voice information, delivering clearer, more natural SSB-width voice without squelch crashes or background hiss. [KJ7T comment: not quite. As noted above, RADE is lossy, like AMBE.]

    • Web Apps & M17 Project:

      • Rogene (K7OLI) shared information about K1FM’s web application that integrates Icom CAT control with browser-based digital voice streaming.

      • Dan (W3HDB) brought up M17, an open-source digital protocol using Codec 2. Nate (N8NAT) mentioned recent community discussions regarding hotspot support and open-source emulation efforts.

    • AllStar & Hotspot Bridging:

      • Nate (N8NAT) detailed his homemade dual-antenna MMDVM setup on a Raspberry Pi 4, bridging digital modes to AllStar using CPU emulation rather than a physical AMBE chip.

    This content was captured on my AllStar node 588416 using an AI-assisted net logging system. The transcript was then processed through Gemini AI to help summarize and improve readability. The Gemini output is what you see in the bullet points above.

    6. QRT

    Throw a Breaker, Break the LAN

    One breaker in Portland, everything shows as offline from the lake house

    One breaker in Portland, everything shows as offline from the lake house

    Last Saturday afternoon, a maintenance worker was in my Portland apartment to repair some plumbing and “heard a tone,” said his report. I was 150 miles away at the lake house. He didn’t know where the sound was coming from, so he did the sensible thing from his point of view: he switched off the circuit breaker for that part of the apartment. The tone stopped. So did my entire home network, once the battery in my uninterruptible power supply (the battery box that keeps equipment running through short outages) ran out.

    Watching from the lake house, everything went dark at once. My security cameras were not on the UPS, so they went dark instantly. As soon as the UPS battery bank died, AllStar node 588416 dropped off the network, and so did the MikroTik router that connects it to 44Net, as well as the GL.iNet router that serves my home LAN. Every remote path I have into that rack runs through those routers, so from where I sat, it looked like one of them had died.

    When I got to the apartment Sunday morning and switched the breaker back on, the routers came right back up. The GL.iNet Flint 2 connected to Xfinity and the MikroTik router reconnected to the 44Net server in Dallas. The Synology storage box, the Mac Mini running my packet BBS, and the Wyse thin client running node 578493 all restarted on their own too.

    However, node 588416 didn’t come back up. It sat there dark, because I had never set the computer’s firmware (the BIOS) to power on automatically after a power loss. I figured the UPS had the loss-of-power situation covered. But the UPS covers short outages, not long ones, and this one lasted longer than the battery. One press of the power button and the node booted up and registered with AllStarLink. It became reachable from the internet about 18 hours after it went down.

    During the several hours I was at the apartment, I did not hear the sound the maintenance person heard. It’s possible it was a warning chirp from the UPS, which could occur if the load on the system was too high. Then again, a UPS on battery usually beeps more, not less, so that theory has a hole in it.

    I’ve temporarily removed a couple of devices from the UPS. The old UPS has remained silent. The one sound my security camera caught afterward turned out to be a wall being bumped next door, not a beep. The camera now records audio, so if it happens again, I’ll have data instead of an “I heard something” report.

    Two changes come out of this:

    • First, every machine in that rack now gets checked for the power-on-after-outage setting. Node 588416 gets it on my next visit, once I bring an adapter for its DisplayPort-only video output.

    • Second, I’m replacing the small APC Back-UPS 450 with a CyberPower CP1000AVRLCD (this is an affiliate link), the same model I use at the lake house. It has more than twice the capacity, and its display shows the load and estimated runtime at a glance. I’ll configure it to cleanly shut down node 588416 if the power is lost for more than ten minutes.

    The lesson for me: the UPS was the safety net I thought was rock solid, and the BIOS setting was one thing I forgot. An outage can come from a neighborhood power failure as easily as from a maintenance worker, and each device has to be able to come back on its own when the power does. Otherwise, the safety net has a big hole in the bottom of it.

    73, and remember to touch a radio every day!

    Notice: As an Amazon Associate, I earn from qualifying purchases.

  • Tom Salzer KJ7TRandom Wire 202: Breaking news about AllStar​Random Wire℠

    Tom Salzer KJ7TRandom Wire 202: Breaking news about AllStar​Random Wire℠

    ★ Ch-Ch-Ch-Changes Coming to AllStar ★

    This is breaking news…but let’s hope it won’t break AllStar!

    If you use an app to connect to an AllStar node from your phone or computer, without a radio or a node of your own, the way that connection gets approved is about to change. On September 25, the AllStarLink team announced that it will retire WebTransceiver authentication. A new App Authentication standard, called ASL002, will replace it.

    What WebTransceiver Is (and Isn’t)

    The name comes from a Java applet that once let a web browser talk to AllStar nodes. The applet was retired long ago, but its login method survived. It became the standard way apps such as DVSwitch Mobile, Repeater Phone, Transceive and QSOone get onto the network. The ASL team calls this “nodeless” access: you connect as a user with an AllStarLink account, not as a node.

    WebTransceiver isn’t a separate mode. It uses IAX2, just like every AllStar connection. IAX2 is the voice-over-IP protocol that AllStar nodes use to talk to each other. What’s changing is how a node decides whether to let an app user in.

    Why Change It

    The ASL002 document is blunt about it: the old method has “no session security of any form.” Its login tokens also weren’t built to be unique, so in principle two different logins could look the same to the network.

    How the New System Works

    Under ASL002, your app will send your AllStarLink username and password to an ASL server once. The server sends back a token that works like a single-use ticket, good for 24 hours. When the app connects, it gives the node that token along with your call sign. The node checks the ticket with the ASL server, and the server cancels it so it can’t be used again. Your password never goes to the node itself.

    The server will also limit how fast any one app or address can request tokens, which makes password-guessing attacks harder. Each app install can hold at most three unused tokens at a time.

    For app users, the change should be mostly invisible. You’ll still log in with a username and password. You’ll need an updated version of your app once its developer adopts the new standard.

    What Node Owners Need to Know

    If you run a node that accepts app connections, this part applies to you.

    ASL3 nodes (the current AllStarLink release): a package update is expected to make a one-time automatic change to /etc/asterisk/extensions.conf, the file that tells Asterisk how to handle incoming calls. However, if you’ve customized the [allstar-public] section of that file, you’ll want to check it after the update instead of assuming the automatic fix worked. I’ll be checking my nodes after the update.

    Pre-ASL3 nodes: operators will need to edit extensions.conf themselves before the transition period ends if they want to keep accepting app connections. The ASL002 document includes the new configuration lines.

    Unknown at this time is how HamVOIP nodes may be affected. That was not part of the announcement.

    My thoughts: ASL writes standards for software it maintains. It can’t say how HamVOIP will behave because it doesn’t control HamVOIP’s code or release schedule. Like pre-ASL3 AllStarLink nodes, HamVOIP runs a much older version of Asterisk (1.4-era). The new configuration lines ask Asterisk to check each app user’s token with an ASL server over the web, then read the first few characters of the server’s reply. There’s no word yet on whether those lines have been tested on older installations, whether HamVOIP or pre-ASL3 AllStarLink.

    The Timeline

    • Now through October 2 (yes, one day after this newsletter is published): the “fatal flaw” review period (the announcement doesn’t specify a time or time zone). Questions and concerns go in the forum thread.

    • Mid-to-late October: the new login service is expected to be available for testing.

    • First or second week of November: expected to go live. ASL says a formal announcement will follow.

    • About six months after go-live: the old WebTransceiver login is scheduled to retire, along with most of the older compatibility options.

    • About a year after go-live: the last compatibility option, which lets older nodes accept connections from updated apps, is scheduled to end.

    The standard is still a draft, and some of the server addresses in the document are placeholders. Details could change before November.

    I expect to write more about this change as the important dates get closer.

    Read more: the announcement on the ASL Community forum and the ASL002 App Authentication standard on GitHub.

    1. QRV: Are You Ready?

    I put the AllStar story ahead of QRV because it’s breaking news that matters to a lot of AllStar users.

    There is a lot of computing content in Random Wire issue 202. That tracks with the nature of digital radio. I finish up the four-part series on 44Net by adding a second firewall to my system (The Third Tent Stake: A Router That Says No First).

    I also recap last weekend’s M17 net because it was packed with great information (M17 Next: A $60 Radio, a Linux HT, and Data on the Way). There is a lot happening behind the curtain, and it’s all positive. I also started working on the CC1200 HAT for M17, with a note below (Working on CC1200 HAT for M17). Expect a thorough article soon.

    Then I moved my Proxmox server containers from a small i7-powered PC to my large Lenovo P510 ThinkStation machine with a 14-core Xeon processor (A Bigger House for the Homelab). It’s not the cheapest computer to run, but I keep it around because it is such an incredible workhorse.

    Finally, the Weekly Report captures a lot of information in one place.

    2. Thank You

    Thank you to Brian, who wrote: “A few coffees to help you write Part 4 on 44 Net/Mikrotik.” The coffee helped, article is done (see 3.1 below)!

    3. New on EtherHam & Random Wire

    3.1 The Third Tent Stake: A Router That Says No First

    This is the fourth article about putting AllStar node 588416 on 44Net. Part 1 raised the tent. Part 2 and Part 3 drove the first two stakes. This one drives the third: an allowlist on the MikroTik router, so that new connections arriving over the 44Net tunnel are filtered, reaching my machines only on the ports they actually serve. Everything else is dropped at the router, before a machine’s own firewall ever sees it.

    The router’s log turned up two surprises. About 980 connection attempts arrived in the first eleven minutes, most of them aimed at addresses in my block that I assumed were empty. And one of those addresses wasn’t empty: it was my packet BBS, which the new rule had just cut off from the internet. The article covers how I found it, how I fixed it, and why the identical spare router I keep on the shelf turned out to be out of date, too.

    The big takeaway: before you build a firewall allowlist, ask the router what’s connected. It already knows, and asking takes two easy commands. Read about it at: The Third Tent Stake: A Router That Says No First.


    3.2 M17 Next: A $60 Radio, a Linux HT, and Data on the Way

    M17’s hardware has lagged behind its protocol. That’s starting to change. The Retevis C62, an inexpensive FM handheld, is on the way to running M17 with a firmware update and no hardware mods. It’s early days: transmit works, but receive and saved settings are still being finished, and the firmware is waiting for review in OpenRTX pull request #510. Close behind is the LinHT, which uses the same C62 case but puts a full Linux computer and a software-defined radio inside. That means it can learn new modes after you’ve bought it.

    There’s more. OpenRTX 0.5 is expected before the holidays and will bring text messaging and APRS to M17 radios people already own. Codec 2 got a big speed boost, old DVMega hotspots can move to M17, and an Oklahoma club has converted a multimode MMDVM repeater to carry M17 alongside its other modes. And because every piece of this is open (the protocol, the codec, and the firmware), no single vendor gets to decide where it goes next. Read the full article on EtherHam →


    3.3 A Bigger House: Proxmox Server Moved to a ThinkStation

    My Proxmox server has been living on an old i7 desktop with a single drive and a UPS it had never been configured to talk to. When I looked at the logs, I found it had been through 127 unsafe shutdowns!

    This week I moved everything to a refurbished Lenovo ThinkStation P510 that had been sitting under my desk. This platform was made and marketed as a workstation but it serves quite well in the role of a home server.

    My objective was to make each container’s move completely transparent: it would retain its number, network address, and data, so everything else on the home network would continue working as if nothing had changed. Before I could start, though, I had to break into my own computer. I’d installed Ubuntu on it at some point and written down nothing about it. That lesson made it into the article, along with a Tailscale subnet router that lets me reach the whole lake house network from 150 miles away without installing Tailscale on every box.

    There was one surprise after the move. My local AI models slowed to under a word per second, and I nearly went shopping for a pricey graphics card. The real cause was a mismatch between the processor cores the container was allowed and the number the AI software assumed it had. Changing one setting made it about 80 times faster. If you run a homelab, or are thinking about moving one to bigger hardware, the full write-up is on EtherHam: A Bigger House: Proxmox Server Moved to a ThinkStation.


    3.4 The Weekly Report

    There is a ton of information in the Weekly Report this week. Included are these topic areas:


    3.5 New on Random Wire: Reply Rules

    I want the Random Wire to be a place where people can disagree freely, treat each other with respect, and come away with better ideas. Substack, which hosts the Random Wire newsletter, lets authors set “reply rules” for commenters. I’ve written mine, squeezing them into the 500 characters allowed:

    • Stay on topic: the post or amateur radio.

    • No politics.

    • Welcome every ham; no gatekeeping by license class, mode, or experience.

    • Argue with ideas, not people.

    • Share firsthand experience and sources.

    • Selling used gear you own is fine; promoting a product you make or sell is not.

    • Makers may join discussions if they disclose, and can email me about reviews.

    • For the benefit of this community, I remove comments that break these rules.

    • Judgment calls are mine.

    • 73, Tom KJ7T

    I’d love to hear your feedback. Please leave a comment or email me at tsalzer@pm.me.

    Leave a comment

    4. In The Lab

    4.1 Working on CC1200 HAT for M17

    One year ago, I placed the minimum order with PCBWay for five CC1200 HATs for M17. This week, I pulled one out of the box and prepared to install it. The HAT is designed to fit on a Raspberry Pi Zero 2 W.

    The first dilemma I faced was finding the right standoffs to separate the HAT from the RPi. If the standoffs are too tall, the RPi’s GPIO pins don’t reach through the holes in the HAT. If they are too short, the soldered legs of the SMA connector come into contact with the mini-HDMI port shell.

    Eventually, I decided to use some side snips and trim the SMA legs shorter. That allowed me to use some standoffs I had in the lab. The GPIO pins barely extend past the top of the holes in the HAT. They are ready to be soldered.

    CC1200 HAT - pins not soldered yet

    CC1200 HAT – pins not soldered yet

    That’s where I stopped this week. I need to get my soldering station space cleared for the next step. I did ask Claude for soldering advice, and I appreciate the “tiny volcano” description. Maybe Claude said this because I’m a geologist. Whatever it was, it made me smile:

    …heat the pad and pin together, feed solder where they meet, and stop when a small shiny cone forms around the tip. A good joint looks like a tiny volcano hugging the pin. If you see a ball sitting on top, the pad didn’t get hot enough.

    Once I get it soldered, configured, and tested, I’ll write it up properly with an in-depth article on EtherHam.com.

    4.2 Audio Upgrade for Lake House

    At the Portland QTH, I have an inexpensive-but-adequate audio setup, with an Audio-Technica AT2005USB dynamic microphone (affiliate link). Audio from the mic travels via XLR cable to a Behringer MIC500USB preamp. The preamp’s USB output goes directly into Audacity on my computer. I do my trimming and some sound leveling in Audacity, then push the audio file through Auphonic for final cleanup and leveling.

    At the lake house, I’ve been using a Maono PD200W dynamic microphone (affiliate link) plugged straight into my laptop over USB, with no preamp. It sounds fine that way, but I like what the Behringer does for my voice in Portland, so a second MIC500USB is on its way. UPDATE: It arrived last night:

    Behringer MIC500USB preamp

    Behringer MIC500USB preamp

    The PD200W will run over XLR into the Behringer, and the preamp’s USB output will go into Audacity on the laptop. The rest of the workflow stays the same: trimming and leveling in Audacity, then final cleanup in Auphonic. With the same preamp at both stations, episodes recorded in either place should sound more alike.

    I have used both microphones for video calls over Zoom and Microsoft Teams, but most of the time I use a Poly Blackwire 5220 Wired Headset (affiliate link) for those. My voice comes through fine, and incoming audio is clear. The Poly headset is not a candidate for piping audio through the preamp.

    5. APRS

    5.1 My APRS Stations Are Working

    My mobile station is KJ7T-9, running on a Yaesu FTM-300DR transceiver.

    In the lake house garage, I have a one-watt iGate/digipeater on 144.390 MHz operating as KJ7T:

    LightAPRS Gateway dashboard

    LightAPRS Gateway dashboard

    I’m also running a roughly 120-milliwatt iGate/digipeater on LoRa on 433 MHz as KJ7T-2:

    LoRa APRS is online

    LoRa APRS is online

    5.2 APRS Messaging

    I’ve mentioned before how much the Zero Retries team covers. It’s simply amazing, and the depth and breadth of the Zero Retries newsletter is so good I read every issue. I recently found this gem in ZR 0263 that looks well worth digging into: Introducing APRS-WebMesg: A Modern, Free Web Front-End for APRS Messaging. The direct link to APRS-WebMesg is https://aprsmsg.app/.

    I was curious, so I tested by sending a message from APRS-WebMesg to my APRSdroid app (KJ7T-5), and then replied from APRSdroid back to the sender (me as KJ7T-7). Here is what that exchange looks like in WebMesg:

    APRS-WebMesg interface

    APRS-WebMesg interface

    That was nearly instantaneous. Pretty cool. In APRSdroid:

    Screenshot from APRSdroid on phone

    Screenshot from APRSdroid on phone

    You might wonder if APRS will store-and-forward messages. I asked myself that and then heard from a highly trusted source that it does not work that way. I verified that: messages sent via the APRS-WebMesg service are carried by APRS-IS, and APRS-IS does not store-and-forward messages. It only delivers a message to a station that’s connected at that moment. Winlink will do store-and-forward, but not APRS.

    There is, however, one “kinda sorta” fallback: aprs.fi logs APRS-IS messages. If your message was carried at some point by APRS-IS, it will show up on your station’s messages page. In this screenshot from that page, you can see how my exchange was captured in the aprs.fi log for KJ7T-5:

    Screen capture from aprs.fi messages page

    Screen capture from aprs.fi messages page

    6. QRT: End Transmission

    6.1 HamClock Update Available

    For those of us using the traditional HamClock connected to the Open Hamclock Backend, version 4.32 is now available. In the HamClock display, look to the right of the big current time in the upper left part of the screen to find the current version number. If an update is available, that version number will be shown in bold red letters (I’ve already clicked mine, so v4.32 is no longer red).

    HamClock running on current OHB release

    HamClock running on current OHB release

    When you click that version number, you’ll get a popup in the middle of the screen:

    Popup when you click the version number

    Popup when you click the version number

    6.2 WordPress Alternative?

    I’ve known WordPress since the early days when it was, quite frankly, horrible to use. It was so bad when I first tried it, I moved to Joomla and Drupal for a few years. Then I rolled my own for a couple of years before recognizing that I couldn’t keep up on the security side and continue developing, at least as a one-person shop. That’s when I took another look at WordPress and found it much easier to understand and use.

    But WordPress — the engine behind EtherHam.com — remains problematic. That’s why I continue to keep my eyes open for alternatives. Now comes a new CMS (content management system) from Cloudflare called EmDash that looks attractive. I may try a local install on my Proxmox server and see how it actually functions. It sounds like EmDash is still early days, but I’m hopeful something more secure will come along to replace WordPress. Fingers crossed.

    6.3 Busy Season for Me

    My busy season has officially started. I have six regional meetings in October, plus the usual committee and board meetings. My team is simultaneously putting the final touches on our statewide annual conference, coming up right after Thanksgiving. We get a slight break for the Christmas holiday and then the Legislature convenes a long session where we are proposing some special legislation. In the middle of all this, I’m working with attorneys and partners on an amicus brief for a case that will affect my state association members.

    Thank goodness I have amateur radio to lean on when paid work gets overwhelming!

    6.4 TriCorder?

    Something for those of us who grew up with Star Trek: Open Source Tricorder Is In It For The Science.

    You won’t be scanning for veteron radiation with this, but you do get a scintillation crystal to get a spectroscopic analysis of beta- or gamma-ray sources; there’s also a visible light spectrometer, thermal camera, and magnetic field camera along with a standard magnetometer and the usual environmental sensors to give you temperature, pressure, and humidity, plus particulate, VOC and CO2 concentration.

    That’s a lot packed into one handheld device. Trekkies will find one of the comments humorous: “Ah! A keyboard! How quaint.”

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 201: More AllStar​Random Wire℠

    Tom Salzer KJ7TRandom Wire 201: More AllStar​Random Wire℠

    1. QRV: Are You Ready?

    I had no idea AllStar was going to figure so prominently in my radio week. The firewall for my node 588416 on 44Net was important to get done. Building an AllStar node and adding DVSwitch Server and an AMBE stick was on my long-standing to-do list, and I’m pretty pleased with the result.

    Then I enabled audio prompts on my AllStar node 578494…but they didn’t work. When I investigated, I found a few gotchas you should be aware of if you’re going to do this. The audio prompts and DTMF commands add usability to an AllStar node.

    AllStar node 578494 with DVSwitch Server and AMBE stick

    AllStar node 578494 with DVSwitch Server and AMBE stick

    While working with node 578494, the node authentication check threw scary-looking errors at me, so I wrote up what they all mean.

    While I was fiddling with the audio prompts, I thought I might as well install my click-three-times shutdown script on the node. But I found that my published directions were not as clear as they could be, so I updated that information on GitHub.

    I modified my node information page on GitHub that I described last week three times. I added a status indicator, made the starter pages easier to implement, and then made a front door for the pages. All of this is free to do on GitHub.

    2. Thank You

    I’m sending a big Random Wire/EtherHam thank you to Brian and Mike for their support. It helps a great deal and I appreciate it.

    Random Wire and EtherHam.com will stay free for readers, but running them still costs money. The Random Wire newsletter now reaches more than 2,400 subscribers, up about a third in the past year, and drew 161,000 views over that time. These subscribers are engaged, technically minded amateur radio operators who build, test, and buy gear. If you’d like to support this work, email me at tsalzer@pm.me or visit the Support page.

    Contact KJ7T

    3. New on EtherHam

    3.1 Your Firewall Reflects the Moment You Built Your System

    This is the third article about putting AllStar node 588416 on 44Net, and it may not be the last. If the series is a tent, Part 1 put it up: the hardware, the tunnel, the certificate, and the remote administration. Part 2 was the first anchor, two one-line router fixes. This article is the second anchor: the firewall, and the logging that shows you what it’s doing.

    The big takeaway: if your system has changed since you set up its firewall, the firewall probably hasn’t kept up, and it’s time to review it.

    I proved that to myself again last night. While preparing for the next step, I found two leftover rules for a SIP phone that is no longer connected. The rules didn’t do what I thought they did, so I deleted them.

    Today, I’m adding a second protective layer in front of the node’s own Uncomplicated Firewall (UFW). The MikroTik router will get an allowlist, so new connections arriving over the 44Net tunnel reach node 588416 only on the ports it actually serves. Everything else gets dropped at the router, before UFW ever sees it. If I write that up, it will become Part 4.

    3.2 Reviving an Evolve III as an AllStarLink/DVSwitch Hub

    I went looking for my old Winlink-in-a-box station, contained in a heavy-duty Pelican briefcase. When I opened the case, I found an old Evolve III laptop hiding in a document slot. This was a hot item several years ago and I remember picking one up to experiment with. What I didn’t remember was where I had stashed it. And then I recalled something from my ham radio to-do list: install DVSwitch Server and document not only how to install and configure it, but how to control it. I did that on the Evolve laptop. This is that story.

    3.3 Don’t Panic: Reading The AllStarLink Node Authentication Check

    Ever have that feeling like the bottom is falling out of your stomach when you see an AllStar error message? If so, this article is for you. AllStarLink 3 includes a handy tool, asl-node-auth-check, that tells you whether your node is registered and whether other nodes can reach it. It’s genuinely useful, but its report is full of “Error” and “Warning” lines, and many of those scary messages aren’t problems at all. On my own node, it flagged five errors in one afternoon, even though the node was working. Some of those pointed to things worth fixing. Others were false alarms, and one was AllStarLink’s own server telling me to slow down.

    This new EtherHam article sorts every message the tool can print into three groups: normal, “the check couldn’t run,” and real problems worth fixing, with what to do about each. It also shows the three lines to look for first, and how to see exactly what address and port AllStarLink gives other nodes when they look you up. It starts at 10,000 feet over Indonesia, with a warning light and a pilot who wasn’t worried. Read it here: Don’t Panic: Reading The AllStarLink Node Authentication Check.

    3.4 Teaching My AllStar Node to Say Its Own IP Address

    I have written a lot about AllStarLink over the past year, and it turns out I can lose track of my own work. I went looking on EtherHam for the post where I explained how to make a node announce its IP address at boot. It isn’t there. It was a single sentence in Random Wire 145, back in August 2025, and the DTMF commands behind it were in Random Wire 142. Both track back to a post David Gleason NR9V wrote in April 2025 in his AllScan AllStar App & Nodes group on Facebook.

    But information on Facebook can be hard to find, so I documented all of the steps in this article, personally tested on my own AllStar node 578494. This content is based on David’s great work and his AllScan app. Read it at Teaching My AllStar Node to Say Its Own IP Address.

    3.5 Weekly Report

    Another jam-packed weekly report for your consumption. What a wonderful time to be involved in amateur radio. There is activity in all aspects of our great hobby. The weekly report captures some of the items, but there is far more activity than I can possibly report here.

    4. Shutdown Script: Tested Again, Instructions Updated

    I installed my three-key-up shutdown script on another AllStar node this week: node 578494, the Evolve III laptop from the article above.

    Three key-ups, a “goodbye,” and a clean power-down. The script worked as written, but the install instructions on GitHub had a few rough spots, including a reboot step buried mid-sentence where it was easy to miss. I’ve rewritten the install section as explicit, numbered steps with the commands spelled out, added a hand test you can run before turning on the service, and expanded the troubleshooting notes. The updated instructions are at github.com/EtherHamRadio/asl-shutdown-monitor.

    5. A Free Front Door for KJ7T Nodes

    I have to laugh at myself, because after I published AllStar Node Info Pages: A Step-by-Step Guide, I added a postscript. Then I added a second postscript. And finally, an update. Technically, that’s a postscript, a postscript to the postscript, and a postscript to the postscript to the postscript. Whew!

    Here’s the shorthand version: I posted the article, then added a live status indicator for a node, then realized I could make the starter script easier to implement. Finally, I saw I needed a front door for my individual node pages so I built that, too.

    Let me start with the latest postscript, the one I called an update. In that addition, I finally gave my AllStar node pages a home page. Up until now, kj7t.github.io/588416, /578494, /578493, and /588418 each stood alone. I had built some documentation but provided no top-level home for the information. This week I built a proper landing page at the root (https://kj7t.github.io/), with a personal introduction and a directory tying all four nodes together, plus some information about my HF, mobile, and APRS setups. This is a small project, but it’s the kind of thing that turns a pile of pages into an actual site. It was also rather enjoyable to put this information into one space.

    The first postscript

    Next is the very first postscript. After publishing AllStar Node Info Pages: A Step-by-Step Guide, I wondered if there was a way to show a live status indicator for the node on the node’s GitHub page. Why yes, yes there was. Details are at the end of the Guide and the download has been updated to include this information.

    It looks good — simple, but informative:

    The second postscript

    I used my “starter kit” template for a new page for node 578494…and found using it to be painful. Entering the same information, over and over, is a process that guarantees errors, and I made plenty. I decided right then: I need to find a better way.

    So I rebuilt it. Now, you enter some key information in only two places: the .yaml file and in the index.md file. Those entries are carried into all the other pages. Much simpler. A new and improved starter kit (version 1.2) with updated instructions is now uploaded to the AllStar Node Info Pages: A Step-by-Step Guide article.

    GitHub is free, and I find that free is often pretty attractive to radio amateurs. It’s not fancy, but it works. My new content hasn’t been “up” long enough to get indexed by search engines, but it’s on GitHub, so I know it will.

    So that is the story of having an idea, improving it, improving it again, and finally giving all the individual node pages a single front door to this house of information.

    6. AllScan Favorites Fix

    I ran into something unexpected this week while copying an AllScan favorites file from one AllStar node to another. AllScan (from AllScan.info) makes it easy to build and manage a list of favorite nodes, and I’d built up a good list on my node 588418 that I wanted to put on node 578494. Simple enough: download the favorites file from 588418, upload it to 578494.

    That worked fine, right up until I tried to add a new favorite on 578494. Nothing happened. The entry never showed up in the list.

    AllScan really was saving my change. I could see it in the file on disk. What I hadn’t understood is how a favorites file is organized. It has a [general] stanza, whose entries appear on every node, and it can also have a stanza named for a specific node number, whose entries appear only on that node. My file had [general] plus a [588418] stanza, and [588418] held most of the favorites I actually cared about. On node 578494, AllScan looks for [general] and [578494]. It has no reason to show a stanza named for some other node, so while those favorites were present, they were effectively invisible. On top of that, AllScan adds a new favorite right after the last entry in the file, which dropped everything I added into the very stanza 578494 wouldn’t display. Saved, but hidden. From the browser it looks exactly like a file permissions or ownership problem, and that’s where I spent a good while looking.

    The actual fix was one line: rename the [588418] stanza to [578494]. Everything appeared at once, and adding favorites has worked normally since.

    So that I don’t have to think about it again, I wrote a small Python script that takes a downloaded favorites file and folds any node-specific stanza into [general], skipping entries that are already there. The result works on any node with no editing. It can also rename the stanza to a different node number, or strip it out entirely, depending on what you want. Eventually I’d like to extend it to merge favorites files from several nodes into one master list I can import everywhere.

    This isn’t a flaw in AllScan. What I was doing is probably an edge case that the vast majority of AllScan users won’t do. Those per-node stanzas exist so one favorites file can serve several nodes, which is a sensible design. It’s the download-from-one-node, upload-to-another path that didn’t go quite right for me. I’ve passed the details along to David Gleason NR9V, AllScan’s author. AllScan is a great bit of helpful software and I install it — and will continue to install it — on my AllStar nodes.

    7. 44Net Getting Some Press

    • John Burwell KI5QKX was on the Late Shift on September 18th talking about 44Net Connect. You can catch the show at https://www.youtube.com/live/qKnC682SJuw or view it below:

    • 44Net was featured in Japan’s FB News! The first part of this three-part series describes 44Net’s history and how to get started using the network. You can read the article here: https://www.fbnews.jp/202608/special/.

    • ARDC showed off 44Net Connect at JARL Ham Fair 2026 in Tokyo. In its September 4 recap of JARL’s centennial Ham Fair, ARDC says visitors at its booth saw 44Net Connect running live. Tom Mabuchi JF3LGC, ARDC’s 44Net Regional Coordinator for Japan, translated and helped run the demos. The recap is at https://www.ardc.net/highlights-from-jarl-ham-fair-2026/.

    • Software updates this month. 44Net Connect also got a few maintenance updates this month (September 6, 8, and 18), mostly behind-the-scenes fixes. The last big release was 1.1.0 in July. The changelog has the details.

    8. Radios and Gadgets

    Icom IC-7110 radio

    Need and want are interesting things: while I don’t need a full-duplex, all-band, all-mode radio, I want one. And Icom is set to deliver it:

    IC-7110, an HF/VHF/UHF all mode transceiver featuring a 4.3-inch color touchscreen, real-time spectrum scope, and comprehensive D-STAR functionality.

    That comes straight from the Icom website (hit the link to see a promotional photo of the radio), except the full-duplex behavior was surfaced by the Ham Radio Workbench crew in HRWB 271. No word on cost, but my observation has been that prices from all major suppliers have been rising, so we can expect some sticker shock when the IC-7110 price is announced.

    No matter the price, it looks like a great radio. Having full duplex available makes this a natural for working satellites.

    FX-4CR Transceiver

    FX-4CR is currently SOLD OUT! proclaims the headline at https://bg2fx.com/fx-4cr-transceiver-so. I don’t see a provision for a waiting list. If you are thinking about this great little radio, you’ll need to monitor the website, or consider joining the FX-4CR HF SDR Transceiver User Group on Facebook to catch informational updates. This is another radio on my want (not need) list.

    9. Net Transcription

    As I continue to experiment with net logging, I captured the weekly M17 net on Saturday, September 19. I thought it would not be a successful test because the M17 audio I was hearing sounded choppy when I monitored the signal. I was surprised that the transcription actually turned out well.

    I pasted the full transcript into ChatGPT and asked for a summary. I find that it accurately reflects what I heard during the net:

    The weekly M17 Net covered recent developments in the M17 open-source digital voice and data project. Major news included experimental M17 transmission on an unmodified Retevis C62 using OpenRTX, progress on the LinuxHT board, and upcoming firmware releases 0.4.5 and 0.5. Discussion also covered hardware versus software vocoders, DVSwitch, CC1200 Raspberry Pi boards, and National Traffic System training. No formal NTS traffic was passed.

    The paragraph was derived from this pathway:

    1. M17 over the M17-KCW reflector, which also carries the net onto the Kansas City Wide system;

    2. my USRP2M17 implementation, connected to my AllStar node 588416;

    3. on 588416, the transcription system captured audio files in .wav format;

    4. the .wav files were then transcribed on the node itself by OpenAI’s open-source Whisper speech-recognition model (via faster-whisper, running locally on the node’s CPU — no cloud service, no per-minute fees);

    5. then call sign matching was done using regular expressions (no AI);

    6. production of the transcript;

    7. final summary produced by feeding the transcript to ChatGPT.

    Here are the first few minutes of the net, as created by the transcription system:

    Notice there are some errors in the transcription (for example, “Kansas City Wide” was transcribed as “Kansas Citywide”, NXDN captured as NXTN, and “Neck Control” instead of “Net Control”), but all of these are decipherable without additional AI help.

    Then I took one more step, which is optional and not automatic: I pasted the text transcript of the entire net into ChatGPT and asked for a summary. That summary is what’s quoted above.

    What pleases me most is the balance between AI use and accuracy. The only AI in the automated pipeline is Whisper, running locally on the node. As you can see in the raw text above, the transcript is usable on its own, without the extra processing performed by ChatGPT.

    I have to say that Jeff AE5ME runs a fabulous net: clear, clean, well structured, plenty of pauses for other stations, and something I rarely encounter: room allowed for emergency traffic. Kudos to Jeff!

    10. Driving with Claude

    Last Sunday, I made a day trip to Portland, about a three-hour drive on state and federal highways. On the way, I did something I thought I would never do: I talked with Claude (hands-free, voice mode) through the app on my phone while I drove.

    I left the lake house at 5:00 am Pacific time — still dark, with little traffic and only a few deer wandering about. This is the time of day when I like to think. It’s a creative period of the day for me, and it’s often when I do my best thinking about writing.

    10.1 Packet radio: AX.25 vs. FX.25

    I started the conversation wanting to learn more about the differences between AX.25 and FX.25. Before the conversation, I knew a little bit about AX.25, but I knew next to nothing about FX.25.

    AX.25 packets are validated by CRC (Cyclic Redundancy Check) and simply discarded on error, with no retransmission request on one-way links. FX.25, on the other hand, wraps AX.25 packets in a forward error correction layer. FX.25 works alongside existing AX.25 gear since a standard AX.25 receiver can still decode an FX.25 signal. Direwolf natively supports FX.25. It particularly helps satellite links at low elevations where signal quality suffers.

    FX.25 is really an RF error rate solution. For an internet-based packet system running over TCP, TCP already handles error correction and retransmission, so you wouldn’t gain anything by trying to use FX.25 in that path. It would only earn its keep if the packets ever moved over-the-air.

    10.2 M17 packet mode and the data channel angle

    Then I pivoted the FX.25 discussion to M17. M17 has two modes: stream mode, which offers one continuous 3200 bits-per-second channel of encoded speech or data, or two 1600 bits-per-second channels carrying speech and data simultaneously; and packet mode, for discrete data transfer.

    M17 packet mode is interesting to me. It already supports text messaging, APRS, AX.25, 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks), Winlink, and raw data. The M17 spec defines all of these, and pyM17 looks like a possible starting point, so I parked this as a future Python exploration idea.

    10.3 Winlink’s threading gap

    Then I jumped from M17 to Winlink, where I think there is also some potential for two-way packet communications. Winlink has a store-and-forward bulletin system that functions as a one-way broadcast…a one-to-many system. If there was a way to intake replies to bulletins and show them in context — threaded — you would have a two-way Winlink-based BBS.

    What I really like about this idea is Winlink is well established within the amateur radio community, both as a system and by reputation. That provides the potential for better adoption if a positive change could be implemented. Layering a many-to-many system on top of the existing one-to-many broadcast capability might add value. I’m thinking of this as a modernized BBS system built on the Winlink framework.

    To be clear, this is just me thinking about possibilities. These aren’t proposals, just ideas.

    10.4 APRS Chat, ANSRVR, and “next generation packet BBS”

    As the Winlink thread was percolating in my mind, it triggered some thoughts about APRS Chat, APRS Connect, and the ANSRVR group-messaging server that powers #APRSThursday via CQ and join commands. As I talked with Claude, I recognized that the command style used by ANSRVR actually resembles classic BBS commands. That took me to the idea of an APRS-based (which is packet radio, after all) BBS. ANSRVR seems slightly more modern than old-school packet, and as #APRSThursday has shown, can be robust for wide-area communications.

    10.5 Debian on phone for portable node?

    And then I went to a new place, at least for me: the idea of installing Debian, AllStar, and DVSwitch on a phone to create a truly compact multi-mode node.

    A phone-based build would need root access, an unlocked bootloader, and either a proper chroot or a full Linux install, none of which is guaranteed across phone models. It would also still need external USB audio hardware (the UCI90, the hub, the DV stick) riding alongside the phone, so the actual size and weight savings over using a small laptop becomes insignificant.

    However, with the advent of all-in-one apps like QSO One that handle all of these modes in software, a compact hardware solution is probably a moot point.

    10.6 Wrap-up

    Well there you have it. That represents about an hour of talking with Claude while I was driving. That was an enjoyable way to burn up about 60 miles of highway, thinking about amateur radio and conceptually exploring some of the little sparks flitting around in my mind. I think this time was well spent, so I plan to do it again.

    How about you? Do you ever go driving with Claude?

    11. QRT: End Transmission

    11.1 Net news

    Heard on September 23rd on the morning Coffee Break Net on the W6EK repeater (AllStar node 51018): a schedule change. If I caught it correctly, the Coffee Break Net will move to 9:00 am Pacific time beginning October 1. This net is sponsored by the Sierra Foothills Amateur Radio Club.

    11.2 Radio in the garage

    I have a VHF APRS iGate/digipeater in the garage, along with a LoRa APRS iGate/digi. But what about FM broadcast radio? At the lake house, Dad used to have a small AM/FM receiver out in the garage, along with a few beat up speakers. I’m pretty sure he sourced those items a long time ago at a local Radio Shack store. His old twin-lead FM antenna is still tacked to the wall, but the rest of that setup is long gone.

    In his memory, I purchased a low-cost FM receiver/amplifier and a pair of speakers to mount in the garage. The cheap radio only has a small telescoping aerial, so I attached about five feet of insulated wire to it to make a more-or-less half-wave FM antenna. It works fine. Dad would be happy about it, and it will remind my family members of him. It’s also a reminder to me that radio, in some form, touches all of us, in some way.

    11.3 Notation Polish Reverse used you have?

    I have a calculator nobody around me wants to touch, because it is a complete mystery to them. It’s a Hewlett Packard HP-15C, still going strong, built like a tank, and utterly indecipherable to the uninitiated. You see, it uses RPN logic: reverse polish notation. The best explanation might not be from XKCD but it’s my favorite, where RPN is presented in the guise of RPS: Reverse Polish Sausage. (I’m a big fan of the ultra-nerdy XKCD humor.)

    I love that calculator. I love it so much, in fact, that I also have the financial version, the 12C. Both are still going strong after all these years. More importantly, each one brings a smile to my face when I pick it up. I can’t explain why. It’s like a favorite radio, I guess. I just like how it feels and functions.

    11.4 Update on the book manuscript

    My conservation book manuscript is at the publishing house. They tell me it will be about 330 pages in paperback. That’s a bit more than I expected. The manuscript still needs professional editing. We’ve finalized the title and settled on a conceptual cover design. I’m expecting publication by spring 2027, but my fingers and toes are also crossed for luck! I’ll share more as publication gets closer.

    11.5 More Likely Than Lightning: What My Bitaxe’s Best Share Really Means

    My Bitaxe’s best-ever share looked impressive until I did the math. It’s still 4,400 times short of a block, but a block win is more likely than getting struck by lightning. Read: More Likely Than Lightning on EtherHam.

    With that, I’ll say 73. My best wishes to all. Remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 200: M17 Without the Hardware​Random Wire℠

    Tom Salzer KJ7TRandom Wire 200: M17 Without the Hardware​Random Wire℠

    1. QRV: Are You Ready?

    Welcome to issue 200! Remarkable! Without you (as of Wednesday: 2,400 subscribers!) this would not have been possible. Thank you to every person who subscribes.

    A thank you banner

    Thank You

    It’s been a pretty steady march forward over 4+ years for the Random Wire newsletter, with a few bumps along the way from mentions in the Zero Retries newsletter and on the Ham Radio Workbench podcast.

    A line graph showing the growth in subscribers since August, 2022

    Line graph of subscriber growth since August 2022

    Simply amazing. I continue to learn so much from so many, it makes this effort well worth it. I hope you find value, too.

    Issue 200 has been a challenge because I’ve been dwelling in the land of computer code and remote machines. Last week was all kinds of AllStar goodness. This week I’m cleaning up a bit of that work from last week and diving into more. For example, I bridged M17 to a private AllStar node, giving me a bidirectional path: M17-to-AllStar and AllStar-to-M17. Along the way I learned I don’t need to have a costly M17 radio or an M17 hotspot to get on M17 — I can do this with an AllStar node and some software. It’s not perfect, but if you have an AllStar node and wanted to dabble in M17 without spending money, you can!

    This is also a big work week for me. We’re putting together an amicus brief (technically, an amicus curiae brief) for a case before a higher court in Washington State. My team is fully consumed with preparing for multiple regional meetings next month, plus putting the finishing touches on our annual statewide conference. We are also preparing for what promises to be a very challenging legislative session that launches in January. And this week has many meetings, including a meeting of the primary state agency we work with, plus a meeting on Friday with our nonprofit association members. All of these things have pulled me away from radio this week. The flipside of this is returning to radio will taste sweeter when I get more time.

    With that, let’s dive and see what happened in my radio week.

    2. New on EtherHam

    Bridging M17 Into AllStarLink

    This item is, to me, pretty cool, and has a great takeaway.

    I spent a chunk of this week connecting my M17 reflector (M17-PNW) to an AllStarLink node. These two systems have been running as two separate worlds since they were launched. The mechanism is USRP2M17 talking to a private AllStar node over the loopback interface.

    I am certainly not the first person to do this. In fact, I recall a 2024 article in Zero Retries was where I first heard about it. I am standing on the good work of others.

    The most interesting part turned out not to be building it — that went about as expected — but something I did not see until later. I had been testing the whole chain through my M17 hotspot, because that is how I built it. I never questioned my assumption that this was the correct configuration.

    Then it landed: USRP2M17 is itself an M17 client. It connects to the reflector on its own, appears in the client list like any other station, and receives the module’s stream directly. The hotspot was never required. I do not need an M17 radio, or a hotspot, or any M17 hardware at all to put a reflector’s audio into AllStarLink.

    That is a huge takeaway for me. Until that moment, I really did not recognize that the software I was fiddling with functioned as an M17 client, negating the need for a hotspot. That reframes what the bridge is. It is not an accessory to a hotspot; it is an independent gateway, and it can be pointed at any reflector I choose. I proved it by accident, monitoring a net on an ordinary analog handheld several links downstream and noticing the audio was markedly cleaner than anything I had managed in a morning of test transmissions. Of course it was. My transmissions had been going out through a radio whose microphone I cannot adjust, which is its own story and cost me most of a morning to pin down.

    One of the very best takeaways, though, is this: you don’t need a special M17 radio or hotspot to use M17 if you have an AllStar node. Install and configure USRP2M17 and use your existing analog radio to get started with M17.

    The full account is on EtherHam, including the gain setting that is not really decibels, and the very first test that failed for a reason I had deliberately built into the node myself.


    Automatic Net Logging, Part 3: The Bug That Ate 16 Percent

    This is Part 3 of a series about building an automatic net logger on an AllStarLink hub node. Part 1 covered who it’s for and how to get audio out of a node with no radio. Part 2 covered the bugs that live traffic exposed in the detection logic. In Part 3, I describe the bug I nearly missed entirely and what it taught me about trusting my own tools. It closes with where the whole project ended up:

    But overall, it works. A net happens, and twenty minutes later there’s a record of it — searchable, exportable, and reasonably accurate about everything except the call signs. That last one turned out to be more tractable than I expected, but that’s a story for another day. Radio traffic is gone the moment it ends. It doesn’t have to be.


    The Router Rule That Sent My Replies to Dallas

    This is the second of three articles about putting AllStar node 588416 on 44Net. Part 1 is the tent: the hardware, the tunnel, the certificate, the remote administration. This one is an anchor that keeps the tent secured.

    I found two bugs in my MikroTik hAP ax2 router configuration. Each was fixed by a single line. Both took hours to find. In both cases, the configuration that caused the problem looked entirely reasonable on the screen — plausible values, in the right fields, doing something close enough to the right thing that reading it told you nothing.

    The takeaways, summarized:

    • When symptoms contradict your theory, go find a counter.

    • Check what you’re measuring before you trust what you measured.

    • A vendor configuration is correct for the traffic its author anticipated.

    • Redundancy that shares a dependency is not redundancy.

    I did share my notes with the 44Net folks who acknowledged my concern. It felt good to try to help make the campsite better for all of us.


    Weekly Reports

    Perhaps the most interesting item in the Weekly Report this week, for me, is: Successful M17 transmission using an unmodified Retevis C62 running OpenRTX. I say that because of the preliminary work I explored in Flashing OpenRTX for M17 on the Retevis C62: Almost There. It’s really great to see this project moving forward.


    Postscript to The Anatomy of Remote Assistance over SSH

    I found a simpler solution for the one-on-one help session in my SSH reverse-tunnel article, and added a postscript about it. That solution is Tailcat, a tool that creates lightweight, temporary, peer-to-peer encrypted tunnels, built by the same people who built Tailscale. Instead of a permanent tailnet, you download a file, share a key, and make an ephemeral connection that goes away when you’re done.

    I could have used that in helping “Dan” with his radio configuration. I did not learn until this week that he is setting up the same full-duplex AllStar node that I have!

    Node 588418 on AllScan ANF101

    AllStar node 588418 on AllScan ANF101

    The device is an AllScan ANF101 full-duplex node. Behind the backplane is a Dell Wyse 3040 thin client machine that powers it. It runs my AllStar node 588418. You can see the frequency I transmit into (431.1800 MHz) and the frequency the node transmits over to me (147.4700 MHz). This is one of my favorite AllStar devices.

    I was really tickled to help “Dan” get his machine up and running.


    8-Day Contest Feed Removed

    The 8-day contest feed on EtherHam.com was swamping other results in the feeds. Since no one has ever said “I like the contest feed” I removed it. Please let me know if you’d like it to return!

    Leave a comment

    3. New in the Shack

    When I say “shack,” I really mean all the places where I have a ham radio presence: the Lake House (Washington), the QTH (Oregon), and the cloud server (Seattle).

    My 1980s-Style BBS at a Real IP Address

    Let’s cut to the chase: why? Why put an old-school-ish BBS online?

    Well, why not? I wanted to learn more about packet systems, and I wanted to put one of my 44Net addresses to use on a low-bandwidth service. A packet BBS is exactly that.

    There’s something quietly satisfying about standing up a BBS on my own public IP address — not a port forward, not a dynamic DNS name that breaks when the cable modem hiccups, but an actual routable address on 44Net, amateur radio’s own slice of the internet. I now have two: 44.27.19.242 for AllStarLink node 588416, and 44.27.19.243 for an old Intel Mac Mini running LinBPQ as a packet node, BBS, and chat server at packet.etherham.com. Both sit behind a MikroTik hAP ax2 in a Portland rack — power and internet aren’t reliable enough at the Lake House for a public-facing box, so Portland was the better choice.

    The 44Net Connect side turned out to be the easy part. ARDC’s self-service tunnel provisioning handed me a WireGuard endpoint and a /28 within minutes, and adding the Mac Mini to an already-working setup was close to anticlimactic — new port, new bridge, done.

    The hard part had nothing to do with networking. LinBPQ runs three separate engines — node, BBS, and chat — and by default only the node starts. Setting BBS=1 merely permits applications; an APPLICATION line merely adds “BBS” to the command list. What actually launches the mail server is a bare LINMAIL line in bpq32.cfg, and without it every symptom points somewhere else: no config file, because the engine that writes it never starts; no debug log, rather than an empty one; a web config page that appears to save and then quietly reverts. I chased permissions, session tokens, and form behavior before finding the answer in G8BPQ’s own install notes — one sentence, easy to miss. LINCHAT does the same job for chat. Once both lines were in place, everything came up on the first try.

    The last piece was making sure it comes back by itself. LinBPQ runs as a systemd service now, and a small unit flips the bit that tells this 2014 Mac Mini to power itself back on after an outage — the same thing macOS does behind the “start up automatically after a power failure” checkbox. I tested it the only way that counts: pulled the cord and watched it come back on its own. For a station I administer from three hours away, that’s the part that actually matters.

    I now have a small cadre of folks helping me test this system. We are all learning together. I don’t know if there is a solid place for an old-school BBS in these modern times, but without trying it, I really can’t know.


    Insta360 ACE Camera Is Back in Service

    Not radio but technology.

    When my wife and I made a long road trip to Kansas, I included a (then) new Insta360 ACE camera. That sat on the pickup truck dash with a sandbag mount which kept it in place, most of the time.

    Well, I was digging through a box and ran across a 1-terabyte microSD card. Back when I bought it, I think I paid $88 for it. Today, a new 1TB card is like buying gold! I stuck it in my laptop to read the card and found videos from that trip, particularly the stretches in and around Moab, Utah. Great memories.

    I dug around some more and found the Insta360 ACE camera. The mount was missing so I bought a new one and have been using the camera+mount on the truck dash for the past few weeks.

    Insta360 ACE action camera

    No longer current Insta360 ACE action camera

    The other morning, on a dark, early drive for my morning coffee (this is my thinking time) I rounded a corner to find a deer standing in the middle of the road. I slowed down and let the animal finish crossing. The Insta360 ACE caught it:

    Of course, the cam also picks up people who cut me off in traffic, or who pass me and then hit their brakes. I’m sure I have one video where someone has shown me with their hand that I’m #1. I don’t need to share those videos but it’s good to have a record.

    I just looked at the price of this camera on Amazon. Oh my. That cost has gone up — way up. I think I bought mine on sale when Insta360 was transitioning to the new ACE PRO series, because I don’t remember prices anywhere near what I’m now seeing.

    4. APRS

    Here’s a nice product to point you toward: the iGateMini. This is a VHF, single-board device with one-watt out that can serve as a tracker, an iGate, or a digipeater. I think it is particularly well suited to serve as a fill-in digi/iGate in your shack. Hat tip to Ham Radio Workbench for this. See HRWB 270 – Satellite Tracking with CSN Technologies.

    And while I like the looks of the iGateMini, I must say I do like my LightAPRS Gateway 1.0 device that I wrote about here and here. At $130, the price is quite reasonable for a tracker, iGate, and digipeater. There’s a lot to like with this little device. As you can see below, it is working well for me, despite the antenna being inside the garage, located in a basin surrounded by hills.

    A screenshot of my LightAPRS Gateway display showing a map of northwest Washington State and APRS stations heard by my device

    Screenshot of my LightAPRS Gateway display, 2026-09-16

    Does it seem like APRS applications are proliferating? There is the long-standing #APRSThursday check-in, and I do that occasionally over LoRa APRS. There is APRS OTA, and I confess it looks like fun. There is SpaceAPRS which will become more useful when the ISS APRS station comes back online.

    And there is APRS Connect and APRS Chat for Android. Although I don’t have a modern iPhone, there are great apps for Apple phones, too.

    In fact, there are so many new APRS things going on I know I’ve forgotten a few that I meant to share. Hopefully I’ll remember them before Friday’s publication deadline! Bottom line: APRS seems to be making a bit of a resurgence. I’m okay with that.

    5. A Repeater 250 Miles over Your Head

    Since I touched on the ISS APRS station above, what about the VHF/UHF repeater on the ISS? Do you know how to work it?

    Aboard the International Space Station, in the Columbus module — ESA’s European lab, built in Italy by Thales Alenia Space — the amateur radio crossband repeater is up and running. Heads up, though: ARISS has a scheduled outage coming September 18 (15:20 UTC) through September 19 (16:50 UTC) for spacewalk support, so don’t be surprised if it goes quiet for a day.

    ▸ Uplink: 145.990 MHz FM, 67 Hz CTCSS tone

    ▸ Downlink: 437.800 MHz FM

    ▸ Radio: any dual-band FM handheld or mobile will do

    ▸ Antenna: a handheld whip works; a small directional gains you the margins, best is a little portable YAGI antenna

    The technique:

    1. Look up the next high pass for your location (any ISS tracker app or website — pick passes above 40° elevation).

    2. Program both frequencies before you go out — remember the 67 Hz tone, or the repeater stays silent.

    3. Listen on 437.800 first. When the pass starts you’ll hear traffic from stations already working it — the downlink comes with Doppler shift, so tune around slightly.

    4. Transmit on 145.990 when there’s a gap, give your call, and listen for yourself coming back through the orbiting machine.

    That’s it. Your signal goes up, gets retransmitted from space at up to 25 watts out, and comes down half a continent away.

    6. QSO One Continues to Grow

    I’ve got to hand it to Frank KD8JKK — he has really pushed QSO One forward. He writes:

    QSO One is live on Google Play, right now, in 177 countries. https://play.google.com/store/apps/details?id=com.qsoone.qso_one

    That’s a pretty big deal. I feel better knowing the code has passed through Google’s gauntlet. No guarantees that it is safe, but it feels safer than before, so I installed it on my phone.

    Screenshot of QSO One on Google Play Store

    Screenshot of QSO One on Google Play Store

    There is one aspect to setting up your AllStar credentials in the phone app that I think is incorrectly described. For the IAX2 password, Frank says to go to AllStarLink.org and find your node password. That is not what I think of as my IAX2 password. I have passwords for various contexts in my /etc/asterisk/iax.conf file. Those are the ones I think of as IAX2 passwords, so that’s where I went first…and none of them worked. What did work is exactly what Frank described. I used the node password from my AllStarLink.org portals page for node 588418 and that worked. I just don’t think it is best described as an IAX2 password. That confuses me.

    Other than that small quirk, this is brilliant software for the Android smartphone ecosystem. Job well done, Frank!

    7. ARDC Seeks Volunteers in 2027

    Amateur Radio Digital Communications (ARDC) needs your help.

    ARDC is now accepting applications for our 2027 volunteer cohort. Applications are open Sept. 15 – Oct. 30, 2026. They are looking for qualified individuals to contribute their time and expertise across several committees and teams:

    Read more at: https://www.ardc.net/volunteer-with-ardc-in-2027/

    8. AllStar: Best Practice for Node Information?

    Several days ago, I heard a fair question about the AI net-transcription project I’ve been running on my AllStarLink node 588416: should participants be told their traffic is being captured?

    The short answer: probably not required by U.S. law. Amateur radio carries no expectation of privacy under FCC rules or federal wiretap law, and that’s by design, not an oversight. But the more interesting answer turned out to be practical, not legal: even if I wanted to notify people, AllStarLink’s own infrastructure gives a node owner almost nowhere to say anything at all. The node registration portal, which is where you might expect people to go to find node details, has exactly one optional text field, capped at 20 characters, meant for a frequency label. That’s it.

    But not legally required doesn’t mean not necessary. The very first item in the Radio Amateur’s Code is Considerate. Informing people they may be recorded — even though it’s not required to do so — is courteous amateur radio behavior.

    For AllStar nodes, there is no standard place to publish this kind of information.

    The gap is worse for a node like mine. It’s a hub — no radio, no coverage area, nothing that fits neatly into the tools that already exist for this hobby. QRZ covers callsigns, not node numbers. RepeaterBook covers physical repeaters with frequencies and PL tones, not link nodes. And the one thing I’d already built — a small web page served directly off the node itself — had an obvious flaw: it disappears exactly when the node goes down, which is precisely when someone might most want to know what’s going on.

    My fix was to stop hosting that information on the node at all. I built a free node page on GitHub Pages instead — no server to run, no uptime to maintain, and it publishes automatically from plain text files the moment I push a change. I put it under a new GitHub organization named for my callsign rather than folding it into my existing EtherHam brand, since a callsign is what is associated with my node number, and it keeps my station’s own documentation independent of whatever EtherHam does or doesn’t become down the road.

    The page itself is short: what the node is and how it’s used, a plain-language disclosure that traffic may be recorded, a description of the transcription project specifically, and a running changelog of what’s changed on the node over time. I then pointed the node’s own web address (which lives on the node at /var/www/html/index.html) at this new page with a simple redirect, so there’s exactly one place to keep current rather than two drifting copies.

    A simple page about AllStar node 588416

    A simple page about AllStar node 588416

    None of this took more than an evening, and most node owners are in an easier spot than I was — running one or two nodes rather than a dozen, which makes this a single small repository rather than anything to architect around. If you operate a hub or link node in particular, where there’s no repeater and no physical footprint for the usual directories to hang a listing on, I think this is worth thirty minutes of your time. I’ll be writing up the full how-to soon; consider this the introduction to what may be a best practice for AllStar node owners.

    I added a how-to document at EtherHam.com — AllStar Node Info Pages: A Step-by-Step Guide — if you want to give this a try. It’s really not too hard.

    9. QRT: End Transmission

    The QRT section is a bit of a catch-all this week.

    PocketCHIRP

    I haven’t tried PocketCHIRP yet, but I will.

    PocketCHIRP is an Android radio programming app for amateur radio, GMRS, radio enthusiasts, commercial/business users, DMR, and other supported radios, with tools for reading, editing, saving, and programming compatible amateur radios over Bluetooth or USB — plus repeater search, satellite Doppler channel generation, custom groups, cloud backups, Android TalkBack accessibility, custom drivers, diagnostics, and more.

    Now available in the Google Play Store.


    Question about my DMR hotspot

    My WPSD-driven DMR hotspot is set up to look to Brandmeister first, then to PNWDigital. I’m not sure that works well when I’m keying up to connect to PNWDigital. For my purposes, this hotspot only needs to contact PNWDigital, so I’m wondering if I should remove Brandmeister altogether. I’d appreciate thoughts from folks more experienced in DMR than me! Contact me at KJ7Tom@gmail.com.


    Rain barrels…not radio but it is technology of a sort

    My technology interests range widely, and sometimes they intersect with my natural resources conservation field. Rain barrels can be useful but they are hard to site in a way that looks attractive (which is probably why most people put them in the backyard or behind a side yard fence). You can also use cubic IBCs (Industrial Bulk Containers), but again, they take up a lot of space and look, well, industrial.

    In contrast, I love this concept I just ran across: the Rainwater Wall. Jump to The Rainwater Wall: A Space-Saving Water Harvesting Tank and scroll down to see it. It’s clever. Compared to round barrels and cubes in cages, it looks pretty nice situated along a wall or fence. I hope this idea takes off.


    Windows RDP and drive redirection

    I learned something new about Windows Remote Desktop (RDP), which I use over Tailscale to operate my work computer remotely. The new thing: I can map a local drive so it shows up on my work computer. (Technically, it’s called drive redirection.)

    How?

    • Open Remote Desktop Connection on your Windows computer (search for it in the Start menu)

    • Click Show Options in the lower left corner

    • Click the Local Resources tab

    • Click More… under “Local devices and resources”

    • Expand Drives and check the drive(s) you want accessible

    • Click OK, then click Connect

    I needed to move a script from my Lake House NAS box to the work PC, by through drive redirection, it was easy. I could simply drag-and-drop or copy-and-paste the folder I needed. I don’t know why I never knew this before, but that was a gold nugget AHA moment. It saved me from the whole zip-the-folder-and-email-it-as-an-attachment method.

    All you networking gurus who are rolling your eyes, well, I’m just happy to learn a new, useful thing. Old dogs, new tricks, and all that!

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 199: We’re Big on AllStarLink This Week​Random Wire℠

    Tom Salzer KJ7TRandom Wire 199: We’re Big on AllStarLink This Week​Random Wire℠

    Welcome to Random Wire issue 199. We are one week away from hitting the 200 issues milestone! I’m not sure why this surprises me but it does. The Random Wire exists because you subscribe to this free newsletter. Thank you, and please share with your radio friends.

    Share Random Wire℠

    1. QRV: Are You Ready?

    Random Wire issue 199 is big on AllStarLink this week, including:

    • an updated how-to for installing to a Dell Wyse 3040 thin client machine;

    • getting a node up on 44Net;

    • part two of a series on transcribing AllStar nets; and

    • new apps for AllStar.

    If I provided this level of coverage for AllStar every week, my tagline might be: AllStar, All the Time! Fortunately, topics change from week to week.

    Random Wire/EtherHam Community Links

    2. Random Wire and EtherHam

    I get asked now and then why I run two publications instead of one. Here’s the short answer.

    Random Wire is the journal. It’s where I write about what’s happening — what I built this week, what broke, what I’m noticing, what’s rattling around in my head. It doesn’t have to be finished or tidy. A half-formed thought about digital modes, a detour into geology or fly fishing, a reaction to something going on in the hobby — it all belongs here. When I write this, I’m writing to you, one of 2,500 people who get it in their inbox every Friday.

    EtherHam is the workbench. It’s where the ideas from Random Wire actually get built. The full how-to, the firmware quirk that cost me an afternoon, the radio that doesn’t leave the bench until I’ve pushed on it from every angle — that level of detail lives there, not here. If Random Wire tells you I moved my AllStar node onto 44Net this week, EtherHam is where I show you exactly how, mistakes and all.

    Short version: read Random Wire to keep up with what I’m doing. Read EtherHam when you’re ready to do it yourself.

    3. New on EtherHam

    Installing AllStarLink on a Dell Wyse 3040 (2026 Update)

    A reader wrote in, stuck on getting Debian Linux onto a Dell Wyse 3040 thin client machine. After I responded, I realized my older guidance from June 2023 was quite outdated…so I updated it and published the fresh guide on EtherHam.com.

    And then I realized I was simply wrong on some points, so I went to David Gleason’s (NR9V) AllScan.info site for truth and found it. That means if you read the article last Friday evening before 8:30 pm, it had incorrect information. The article as posted now is much better.

    If you have a 3040 on the bench you want to dust off, or if can get your hands on a used unit in good shape, it remains a superb platform for building an AllStar node.


    Putting My AllStar Node On 44Net

    This is the thing that took much of my time this week: moving my AllStar node 588416 from an address on my LAN to a 44Net static IP address. Sounds simple but it wasn’t. I feared this would be too complicated for me so I put this off for months, but it turned out to be a little easier than I expected. Simple? No. I was challenged, but I also achieved a positive outcome.

    I moved my AllStarLink node 588416 onto a public 44Net address, nine months after ARDC announced the WireGuard-based 44Net Connect service in December 2025. The article opens by admitting the node already worked fine, so why do this? My motives may be just as interesting as the technical details: learning routing and tunnels by hand rather than in the abstract, owning an address block tied to a call sign instead of renting one from Comcast, and actually occupying address space the hobby already owns rather than admiring it from a distance.

    My build centers on a MikroTik hAP ax2 router placed behind an existing GL.iNet Flint 2 router, which achieves complete isolation between 44Net and household traffic without VLANs or a managed switch.

    The article closes on the day’s actual lesson: the modern, unfamiliar part worked on the first try, and every real problem was local — port defaults, PoE behavior, and a bug in a config file.

    Parts two and three are in the works.

    Related: MikroTik routers being attacked. Do a Google search or check here and here.


    Automatic Net Logging, Part 2: What Five Live Nets Taught

    Over on EtherHam, I’ve published Part 2 of my automatic net logging series, and this one’s about what happens when your code works perfectly in isolation but falls apart against real traffic. I tested my AllStarLink net-detection system against five actual nets and found four separate bugs — the kind that only surface once you throw real repeater audio at something instead of a clean test case. Each one alone just nudged the accuracy down a little; together, they made the whole system unreliable.

    The bigger lesson wasn’t about any single bug, though. It’s this: unit tests can tell you every piece works and still miss the failure that only shows up when the pieces interact. Fixing that took real listening, not just better regex. If you’re building anything that has to survive contact with real-world audio, it’s worth a read.


    The Anatomy of Remote Assistance over SSH

    This is the tale of helping someone get AllStarLink installed on their Dell Wyse 3040 thin client machine, using an SSH reverse tunnel to take control of the terminal on the other end of the pipe. With no desktop environment installed, the usual screen sharing applications were not going to work. On top of this, the user was not an accomplished computer user, so I needed to find the simplest steps he could accomplish to provide me with remote access.


    Weekly Reports

    • Short Stack is even longer this week with the addition of some space-related feeds.

    • Band Conditions look to be on the mend, so now’s a good time to get on the air and make up for lost time.

    • Digital Radio News — The M17 Project released a new draft of the M17 specification. AllStarLink’s app_rpt code received more fixes. There’s a new commit for MMDVMHost. And LoRa APRS iGate posted some updates.

    • Groups.io Digest saw RepeaterBuilder leading the pack with 155 messages, followed by TinySA (85 messages), ARDC 44Net Connect (75 messages), and APRS (46 messages).


    Retevis RT85 Cheat Sheet

    A subscriber asked if I had a cheat sheet for the Retevis RT85 dual-band handheld radio. I did not…so I made one. There are still a few unresolved or unconfirmed items, but if you have one of these radios, find version 7 of the cheat sheet at https://etherham.com/downloads/#how-to

    I have several of these radios so the cheat sheet is a help to me, too. This is one of the easiest dual-band VHF/UHF HTs available that is both reliable and usable. When I checked earlier this week, the price for the 2-pack was about $35 on Amazon. Yes, $35, for two radios, antennas, batteries, desk chargers, belt clips, and hand straps.

    Retevis RT85 Handheld Ham Radios, Portable Dual Band Walkie Talkies, 2 Pack. Emergency Two Way Radio Long Range, Built in VFO, 200CH, VOX, FM, DTMF, Flashlight, 1400mAh, for Survival Preppers Off-Grid (this is an affiliate link)

    Creating the cheat sheet was an interesting exercise because some published information was missing or conflicting. The Retevis RT85 cheat sheet joins another cheat sheet I made for the RT3S when flashed with OpenGD77 firmware. Both are in the Downloads section of EtherHam.com: https://etherham.com/downloads/.


    New Reference Pages

    I’ve added some Reference Guide pages to the EtherHam site. The first set are:

    Find these in the main menu under the Downloads selection. Please let me know if you have suggested edits, or if there are topics for which you’d like a simple reference sheet.

    Leave a comment

    4. New Amateur Radio Applications for AllStar

    There is so much going on today with all-in-one dashboards! What a great time to be a ham.

    One of the newest suites comes from Terry Claiborne KC3KMV. Terry first contacted me about a year ago about IAX and AllStar nodes. He dove in and hasn’t looked back. He writes:

    I have a deep background in the IS field, spanning everything from Assembler, Fortran, and COBOL to C, B, C++, Unix, and Turbo Pascal. I retired at 55 and am turning 70 next year. My journey into this space started with HamVoip before I transitioned to ASL3. When I first emailed you about creating a user in iax.conf, it sparked a deep dive, and I haven’t stopped since. My main goal now is to share different options and presentations to make things easier for others in the community.

    Find his Amateur Radio Applications listed on his QRZ page:

    • Alltune2 is a high-performance utility for BM, TGIF, YSF, D-Star, P25, NXDN, AllStar, and EchoLink nodes on ASL3.

    • AllStar View is a standalone, read-only web monitor for AllStarLink 3 / app_rpt systems.

    • AllStar Connect is a web dashboard for controlling and monitoring AllStarLink and EchoLink connections on an ASL3 node.

    • DVSwitch Cockpit is a modern web dashboard for watching what your ASL3 / DVSwitch node is doing in real time.

    • AllStar Web Transceiver — Windows is a native AllStarLink client for Windows.

    • AllStar Web Transceiver — Android is a native AllStarLink client for Android 12+.

    I installed the AllStar Web Transceiver on my Windows laptop. I was curious if it would install because my laptop runs on an ARM processor, but it installed just fine via the Microsoft Store. I’m listening to the W6EK Coffee Break Net using Terry’s AWT (my abbreviation) application while I type this.

    It sounds great:

    AWT is pretty convenient. Once you add some stations to the Favorites list, a click of the mouse and you’re connected. If you install AWT, be sure to connect to node 55553 over Web Transceiver mode to test your audio. Mine returned with “just about right.”

    The dark mode is particularly nice:

    I’ll be trying some of the other applications as time permits. I’m particularly interested in AllTune 2, billed as “One Dashboard. All Your Networks.” That sounds like a very practical way to use a Raspberry Pi.

    Kudos to Terry for providing some great tools to the amateur radio community. Well done.

    5. A Touchscreen for Your Physical AllStar Node?

    Speaking of AllStar, how about this pull request for touchscreen support in the wonderful AllScan app! See: https://github.com/davidgsd/AllScan/pull/32/

    Add a new /simple/ interface focused on quick, touch-friendly favorite node control. The interface is designed to behave more like a channelized radio than the full AllScan control page: favorites are shown as large channel buttons, and the normal workflow is to select one channel/node at a time.

    When a channel is selected, the Simple interface uses the existing connect API with autodisconnect enabled so the local node is first disconnected from other nodes before connecting to the selected favorite. If additional connections are still present, the page shows a warning state and offers a disconnect-all control instead of treating that as the normal single-channel state.

    Having a compact AllStar device that incorporates a touchscreen and simple user interface seems like a winning combination. It will be interesting to watch how this develops.

    6. Interesting: SDR Without a PC

    OrcSDR: Why folks no longer need a $650 SDR tells the tale:

    The OrcSDR project centers on the M5Stack Tab5, a battery-powered handheld tablet powered by a dual-core RISC-V ESP32-P4 processor. By plugging an RTL-SDR directly into the Tab5’s USB host port, the ESP32 handles the heavy lifting: it processes the raw digital radio stream, demodulates audio, and renders a live, touch-responsive spectrum and waterfall display on a 5-inch color screen without a PC.

    This is literally a tablet with an RTL-SDR dongle plugged into it:

    The simplicity of this approach, the compactness of the configuration, and the capability of the RTL-SDR makes this a very interesting project indeed.

    7. These Are a Few of My Favorite AllStar Nets

    Set that title to the tune of My Favorite Things from The Sound of Music. Is that stuck in your head now? You’re welcome!

    WA7ABU in Salem, Oregon — AllStar node 543260 — A daily tech net at 10 am Pacific. Topical nets each evening. A community filled with rich skills and experiences. The daily tech net is also linked in listen-only mode through AllStar 55915 and AllStar 57945.

    W6EK in Auburn, California — AllStar node 51018 — A daily social net, the Coffee Break Net, from 7:30 am to 10 am Pacific. An All-Nodes tech net on Monday at 6 pm Pacific. And just a friendly bunch of hams who know each other well. AllStar node 51018.

    PSRG in Seattle, Washington — AllStar node 2462 — Daily social nets at 9 am, noon, and 9 pm Pacific. Also a daily Boater’s Net that starts at 7:47 am Pacific (that time must be a nod to the Boeing 747 aircraft).

    8. Another Logo Design

    I’m trying — inexpensively — a variation on the EtherHam logo, with an order for vinyl decals from Sticker Mule. These are “two-fers” that tell others you are an EtherHam who enjoys tinkering with technology.

    Custom stickers like this are the cheapest way to check the resolution of the design. My cost for 30 decals is $48, delivered. That works out to, what, $1.60 per decal? My calculator says yes.

    I can hold it up to a ball cap to see how it looks. I ordered them a bit larger than hat size because I also want to see how they look on T-shirts and sweatshirts. At 4” × 2.25”, they will work well on water bottles and the back window of the pickup truck.

    These are “kiss cut” vinyl stickers. What does kiss cut mean? It’s a printing and cutting technique where a blade cuts through only the top layer while leaving the protective backing paper completely intact. Peel and stick. Done. Vinyl is more resistant to washing (think: reusable water bottles) and weather. For a sticker that might go on a laptop, vinyl will also be more resistant to damage from sliding the computer in and out of a bag.

    I’m looking for feedback. If you like this, let me know and I’ll add some items to the EtherHam Store. I’d like to get a coffee mug that stares back at me with ”I tinker with technology”.

    9. Transcribing Examples

    These are excerpts of summaries produced by ChatGPT from my Transcript Viewer captures. Functionally, I specify the start and stop times in the Transcript Viewer page, run the query, then download the resulting text file.

    I feed that text file to ChatGPT with this prompt:

    Attached is a transcript of an amateur radio net, captured off the air and transcribed automatically by speech recognition. The transcription is imperfect. Call signs are frequently garbled: sometimes spelled out phonetically (“November 6 Quebec Delta Yankee” = N6QDY), sometimes hyphenated (“K-E-6-R-A-X” = KE6RAX), sometimes mangled outright.

    Please give me: 1. Net control station — callsign and name, if identifiable. 2. Stations that checked in, in order, with names where mentioned. Reconstruct each call sign as best you can. Mark any you are uncertain about with a trailing question mark. 3. A summary of the net in 3-5 sentences. 4. Anything notable: announcements, technical topics, traffic passed.

    Do not invent callsigns. If a station’s identity is genuinely unclear, say so rather than guessing.

    W6EK Coffee Break Net, Friday morning, 9/4/26

    The entire AI-processed transcript is italicized below:

    The Coffee Break Net was hosted by Tom, NN6H, on the W6EK repeater and associated AllStarLink/EchoLink connections. The net followed its usual informal rag-chew format, beginning with quick check-ins and later moving into longer conversations about weather, amateur-radio networking, AllStar nodes, QSO1, and personal activities. Stations checked in from across the United States and internationally, including the United Kingdom, Wales, Idaho, Pennsylvania, Oklahoma, Texas, and Hawaii. The net closed shortly after 10:00 a.m. Pacific, with Brian, AI6US, identified as the next day’s net control operator.

    Announcements and Net Information

    • The net is sponsored by the Sierra Foothills Amateur Radio Club.

    • It normally runs every morning from 7:30 a.m. to 10:00 a.m. Pacific.

    • The primary repeater is W6EK, with AllStar node 51018 and EchoLink access.

    • Tom mentioned the club’s support for the Auburn food bank, in connection with National Food Bank Day.

    • Brian AI6US was announced as the Saturday net control.

    Technical Discussion

    The most substantial technical discussion involved:

    • QSO1, an application used for connecting to AllStar systems.

    • Possible conflicts when running multiple AllStar nodes or applications behind the same IP address.

    • The IAX port, 4569, and the need to avoid port conflicts.

    • The distinction between using QSO1 in IAX/node mode versus WebRTC/web-transceiver mode.

    • Aaron W1ATV was troubleshooting behavior involving his AllStar node and another node apparently using the same credentials/node number.

    • Greg reported apparent audio dropouts that occurred in QSO1 while RF audio continued.

    Compare that AI-cleaned summary with a raw transcript — errors and all — from the WA7ABU Tech Net from September 8, 2026. You can find that on EtherHam.com at https://etherham.com/automatic-net-logging-part-2-what-five-live-nets-taught/#what-does-a-raw-transcript-look-like.

    10. Gadgets

    You wouldn’t think a headset would be related to AllStar, but this one is. I bought a Retevis headset, not really knowing what would arrive. Thirty bucks later, this arrived:

    Retevis EHK012 Two Way Radio Headset with Mic,for RT22 RT68 RT86,1 Pack

    This was especially chancy, since Amazon notes: “Frequently Returned Item: Consider linking to similar products with lower return rates.” No affiliate link in the product link above because Amazon doesn’t like frequently returned items.

    But I took a chance anyway and am not disappointed. This set of cans feels pretty robust. The microphone in the Amazon photo is not covered, but mine arrived with a foam cover over the microphone element.

    The K1 connector works on my Retevis radios, of course, but also on other radios with a K1 interface. I’ve tried it on my AllStar node 588411 built on a Computer Module 4 platform with AllScan UCI90 interface and it worked fine…after I figured out I had to turn the volume up on the UCI90.

    Comfortable? Not really. These firm-fitting headphones sit very securely on my medium head. They also isolate sound quite well. If you need to hear outside sounds for situational awareness, these are not for you. But if you need sound isolation and a secure fit, these are fantastic.

    I get a little bit of hiss (maybe better described as grungy hum) on my transmitted signal but it is not objectionable and does not interfere. If I was working a bike race with an HT while motorized traffic was zipping by — and if I was safely positioned away from traffic — these headphones would be a top choice.

    Verdict: a viable choice for a noisy environment, where sound isolation and a firm fit trumps comfort.

    11. More on My FTM-300DR Shutdown Problem

    The same day Random Wire 198 published, I made a trip to Port Orchard, Washington. The Yaesu FTM-300DR was set up for APRS operation on 144.390 MHz on VFO B, as always. The antenna was the temporary “Justin Case” mag-mount COMPACtenna, the one that I put into service a week earlier because with the old Comet antenna, the radio was shutting off when it beaconed.

    And wouldn’t you know it, but the radio shut off when it beaconed, even with the COMPACtenna. I powered the radio up and watched it while I drove, and twice more it shut down when it beaconed.

    Two completely different antennas and feedlines, and the identical problem. This points away from the antenna system and shifts my attention to the power delivery system.

    Final update: it wasn’t the antenna. I even tried a third antenna with the same symptom appearing. So it was time to test the power delivery and see if that affected the radio’s behavior. That was easy to test by swapping out the 12VDC power cord. The result? Problem solved. Somewhere in the old cord there is a bad connection or corrosion I just didn’t see.

    12. QRT: End Transmission

    Helping a Ham Get a New AllStar Node on the Air

    I was honored to help a fellow ham figure out how to load Debian on his little Dell Wyse 3040 thin client machine and get AllStar running. For those of us who have done this several/many times, it’s easy to forget how utterly daunting it is to attempt this for the first time. As the other ham and I exchanged emails, I could hear his frustration through his words. But he persevered and succeeded. I have to admit that it feels pretty good to help someone experience success.

    Color me surprised when I learned that Chuck bought me some coffees!

    Thank You to Hunter Inman and Steve Stroh

    I have really enjoyed fiddling with Hunter’s creative solution to transcribing net traffic carried by AllStar. He is moving forward on this with a revised system that is running autonomously now. See it in action at https://kk7nqn.net/viewer.html.

    A big thank you to Hunter Inman KK7NQN and Steve Stroh N8GNJ (Zero Retries newsletter) for their kind words about the work I’ve been doing with Hunter’s script (see https://www.zeroretries.org/i/212220420/update-on-kk7nqn-ai-net-logger).

    #APRSThursday

    I checked into #APRSThursday last week from my LoRa tracker as KJ7T-3:

    HamClock OHB Beta Has APRS

    Great to see APRS in the HamClock display. It even picked up my portable LoRa APRS station (KJ7T-3) on a LilyGo T-Deck Plus.

    Eagle-eyed readers may notice the Starship Enterprise on the display. September 8 was Star Trek Day and the HamClock software includes a built-in easter egg to commemorate it. That was a fun discovery.

    Jupiter-Moon Conjunction

    If you happened to be looking at the pre-dawn sky on September 8th, you might have seen what one of my radio friends remarked on: a bright star next to the Moon. But it was actually Jupiter, not a star. If memory serves, we saw a Venus-Moon conjunction back in May. It was easy to see the Jupiter-Moon conjunction because most of the Moon’s disc was dark.

    13. Closing Reflections

    Amateur Radio: More Than Just a Hobby

    When the attacks on September 11, 2001, knocked out cell towers, police and fire radio systems — as well as the city’s own emergency command center in 7 World Trade Center — hundreds of amateur radio operators stepped in. RACES and ARES volunteers ran health-and-welfare and medical traffic, supported the Red Cross and Salvation Army, and shadowed city officials so they could keep communicating with each other when nothing else worked. It’s one of the clearest examples of why “emergency” is built into so much of this hobby’s service tradition. We “play radio” because we enjoy it, but we also give back to the communities where we live, work, and play.

    Balancing Radio and Life

    When I drove to Portland on Sunday to work on putting node 588416 on my 44Net address, I had a feeling something wasn’t right back home with my wife, who needs care around the clock. Nothing to point to yet — just a feeling — so I started packing up to head back to the lake house. Before we’d wrapped up everything we needed to do that day on the node move, my daughter texted: “Dad, something’s up with Mom.” The feeling had been right.

    What followed was a 911 call and another ambulance ride by Mason County’s great EMS folks to an Olympia hospital. There, the doctor was certain he needed interventional radiology to assist, but nobody was available. Then came the two-hour scramble as the ER staff looked for another hospital to treat her. Finally, a very experienced nurse popped in and asked: would you mind if I try to fix this? Please do, I said. Ten minutes later, we were arranging transport back home because the problem was fully resolved. I have to say it: nurses rule.

    Next week: issue 200!

    With that, I’ll say 73. Remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 198: Some M17. Some AllStar, including capturing transcripts of nets. And a whole lot more.​Random Wire℠

    Tom Salzer KJ7TRandom Wire 198: Some M17. Some AllStar, including capturing transcripts of nets. And a whole lot more.​Random Wire℠

    To Jon, Travis, and Ann: a huge Random Wire Thank You for your support!

    Thank You from the Random Wire and EtherHam

    Thank You from the Random Wire and EtherHam

    1. QRV: Are You Ready?

    Welcome to meteorological fall (September 1st). Astronomical fall lands on September 22nd, so I guess this is a “take your pick” kind of thing. For me, when the school buses start to slow my rate of travel between the lake house and some barista-brewed coffee, that’s my signal fall has arrived.

    I’ve been asked why I use the tagline “Remember to touch a radio every day” at the close of every Random Wire newsletter. My answer is both simple and perhaps not so simple. On the simple side, when you use a radio frequently, you tend to continue to use a radio frequently. Simple.

    The more complex answer is that when you remember to incorporate radio into your everyday life in some way, it becomes more a part of who you are. It lives closer to the surface of your thoughts. You begin to see commonplace things and wonder: how could that be adapted to support my radio play?

    And I think it is in that space that we become more involved, more engaged, and more excited about the many ways radio touches our lives.

    My tagline is a gentle reminder to work toward having that kind of indispensable relationship with radio, because as we already know, radio touches all of us in some way, every day.

    RW/EH Community Resources

    And there are still some slots left in the EtherHam groups.io space. Join at https://groups.io/g/EtherHam.

    2. New on EtherHam

    There is some meaty content on EtherHam.com this week. First up is trying to get OpenRTX running on a Retevis C62 for M17, and unfortunately, it’s just not there yet. Then I modified my “shutdown your ASL3 node with three quick key-ups” script, based on reader input. The third item is the start of a three-part series on automatic transcribing of AllStar nets, but guess what? That really means it can capture any voice traffic on AllStar.

    Flashing OpenRTX for M17 on the Retevis C62: Almost There

    The Retevis C62 is one of the more interesting radios to land in the M17 space. Unlike the RT3S and other MD-UV380-class radios — where M17 requires physical hardware modifications, SMD rework and fine wire work — the C62 is a firmware-only target. No soldering. Flash it over the programming jack and you’re done.

    That’s the promise. This is a field report on how far you can actually get today, written after a full day at the bench with a charged radio, three programming cables and a working build.

    Short version: the flashing pipeline works and is now well understood. The firmware doesn’t boot yet. Both halves of that are worth documenting for those of us experimenting with this.

    Addendum to: Shutdown an ASL3 Node with Three Key-Ups

    A reader (thank you, Bill) wrote in after upgrading a SHARI Pi3U (kits4hams) node from HamVOIP to ASL3. He’d had a pushbutton triggering shutdown just fine before, and gave this script a try — but found three quick key-ups weren’t being recognized. He got it working by bumping WINDOW_SEC up to 10, and specifically by keying up, waiting for his node’s ack/courtesy tone to finish, then keying up again — repeating that three times.

    The addendum documents my thoughts about the cause of this condition, and the solution. And then I did what I should have done in the first place: published the script to a proper GitHub repository.

    Automatic Net Logging, Part 1: Who It’s For, and Getting Audio Out of a Hub Node

    An idle AllStarLink hub node — no radio attached, nothing plugged into it but power and Ethernet — turns out to be a good place to record and transcribe net traffic. Part 1 covers three quite different people who’d want that: someone logging nets, a repeater owner who wants a searchable record of what happens on their machine, and an operator who can’t follow the audio and would rather read it. They need the same pipeline set up differently — the net logger would rather it mistake a rag chew for a net than miss a real one, and the repeater owner wants exactly the reverse.

    It’s built on the KK7NQN-TranscriptionLogger project by Hunter Inman KK7NQN, with the audio capture, transcription step and a web viewer added. There’s an awkward bit, too, which is how you record from a node that has no receiver and therefore never fires the event every guide tells you to watch for. Over three days my system captured five live nets across four repeaters and turned up four real bugs, one of them quietly discarding sixteen percent of everything it recorded. Parts 2 and 3 cover those. The code is on GitHub if you’d rather read Python than prose.

    One thing in there is worth thirty seconds of your time even if transcription doesn’t interest you at all: check whether your node’s Asterisk Manager Interface is bound to 0.0.0.0. Mine was — port 5038 open to the internet and being actively scanned. One line in manager.conf fixes it.

    Weekly Report: September 3, 2026

    This week, the Short Stack from the Interwebs is added to the Weekly Report!

    The higher HF bands, especially 10, 15, and 20 meters, should be in fine shape for both DX chasing and regional contacts.

    AllStarLink code received a batch of stability fixes. The Hams Over IIP wiki was updated with a MicroSIP navigation page.

    The top three monitored Groups.io groups are Repeater Builder (205 messages), TinySA (70 messages), and APRS (59 messages). Runners-up include: HotSpot Radios, M17 Users, SHARI, and 44Net Connect.

    3. Ham Radio Workbench #269 on AllStarLink

    I included the link to this podcast last week, and I include it again this week because it’s just such a great show.

    George and the HRWB team kept me company on a drive from the lake house to Portland last Sunday. I’ve been playing in the AllStar space for several years, but I learned quite a few new things, and developed a better understanding of how AllStar works. If you are interested in AllStar, this is worth listening to. It has information for AllStar beginners and aficionados alike.

    And Jason dropped some great gems toward the end of the show. He also mentions the Ampersand-ASL project by Bruce MacKinnon, which I’m running on a couple of different devices (but start here if you’re interested in running this software).

    One tidbit I particularly enjoyed was learning how the AllStarLink system was designed to avoid a typical star topology (hub and spokes). The federated distribution style of the AllStar ecosystem appeals to me.

    The show closes with a live demonstration of Mike Walker VA3MW getting his node up and running, then connecting to nodes for other show members.

    AllStarLink is an all-volunteer effort and they need support:

    The implementation of this system and its monthly upkeep is very costly. Any monetary help that you can and wish to give will be much appreciated. Allstarlink Inc. is a 501(c)(3) non-profit organization.

    AllStarLink Donations

    You’ll get a thank you when you donate:

    AllStarLink donation thank you page

    AllStarLink donation thank you page

    4. FreeDV RADE: For Your FlexRadio and Your Pi

    ARDC has published a great introduction to FreeDV RADE, the open-source digital voice mode that swaps the usual DSP tricks for a machine-learning “radio autoencoder.” The pitch: SSB-beating voice quality down to -2 dB SNR, in about 1.5 kHz of bandwidth — half what SSB needs. It’s now built directly into FlexRadio’s 6000/8000/Aurora line as a selectable mode, but you don’t need one of those to try it — it runs just fine on a Raspberry Pi 4 or 5.

    If you’ve ever had trouble picking voices out of the noise on HF, RADE might make the band feel accessible again. Hams in Australia, Japan, Europe, and South America are already running weekly RADE nets; VK3TPM says it’s noticeably easier on the ears than analog HF.

    RADE v2 is in the works, targeting sub-1kHz bandwidth!

    Learn more: FreeDV RADE: A New Approach to Digital Voice Over HF

    5. Hunter’s Transcription Script

    “I Like Nets Transcribed” meme image

    “I Like Nets Transcribed” meme image

    I can’t always listen to a net, even when I really do want the learning that comes from hearing so many great questions and answers. Then I remembered Hunter Inman’s KK7NQN Transcription Logger project from the first Zero Retries Digital Conference and decided to give it a try on a spare AllStar node. Read Hunter’s overview at https://kk7nqn.net/. It is pretty amazing stuff.

    However, getting it working required inferring some information and making some choices. A key choice for me was to use regular expressions instead of an AI for some transcription tasks. The system also tries to detect whether it has captured a net. Just like me, it does struggle with call signs.

    Ultimately, I forked Hunter’s code and incorporated some fixes, including some new files. One of those was creating a simple transcript viewer web page. That saves me from having to SSH into the node and run a complicated MySQL query just to see a transcript. The Transcript Viewer lets me use date selectors to set a start and end date/time for the query. The query output is parsed into a table, and the transcript is downloadable as a text file.

    I tested it on Sunday evening with the Puget Sound Repeater Group’s 9 O’Clock net:

    Transcript viewer script output

    Transcript viewer script output

    This showed the system is working. Then I tried using my local OpenWebUI machine running gemma3:4b to generate a net summary and correct some call signs, but it was slow. The call sign detection wasn’t much better than what I could do just by reading the transcript. However, I can feed that text file to an online AI (I used ChatGPT) to get an acceptable summary, if desired. With this one test, I think the RegEx transcript will usually be good enough.

    I tested the logger again on Monday morning with the WA7ABU TechNet, a daily net at 10 AM Pacific that is often jam-packed with great technical information.

    The script I implemented, plus the transcript viewer, are available on GitHub if someone wants to experiment with it.

    As noted above in the New on EtherHam section, Part 1 is published: Automatic Net Logging, Part 1: Who It’s For, and Getting Audio Out of a Hub Node

    Part 2 (Automatic Net Logging, Part 2: What Five Live Nets Taught) will publish on September 8, and Part 3 (Automatic Net Logging, Part 3: The Bug That Ate 16 Percent) on September 15.

    When Making the AI Smarter Made It Worse

    The net logger on AllStar node 588416 has been running well enough that I’ve moved on to its weakest part: call signs. Whisper hears “Whiskey Bravo 3, Charlie, Sierra Yankee” and writes exactly that — which is useless if what you want in the log is WB3CSY. The obvious fix is a bigger transcription model, so Wednesday I sat down to benchmark one.

    It didn’t work, and neither did the next two things I tried. Whisper medium is nearly three times slower than small on that little i5 computer, and on the clips that actually contained call signs, it won one and lost one across seven tests. Where it lost, it lost badly: “Kilo foxtrot zero Sierra Mike Delta” came back as “Kilo, Flaxstrad 0, Sierra, Mike Delta.” Flaxstrad isn’t a word. Conversely, the smaller model had transcribed it correctly.

    So I tried priming instead — feeding Whisper the phonetic alphabet and a list of call signs it should expect. On a transmission with nothing intelligible in it at all, the primed model produced “KJ7T-OR.” That’s my own callsign, which I had put in the primer. It hadn’t heard anything; it just gave me back what I’d told it to look for, formatted to look exactly like a real check-in. Hotwords, the third approach, mangled “Sierra Alpha Yankee” into “ALFAYANKI” — which made me laugh, and which is also unrecoverable.

    The pattern took me a while to see. A bigger language model has a stronger sense of what English is supposed to sound like, and the phonetic alphabet is deliberately built from words that don’t sound like ordinary English. They are unique more than normal. That’s the whole point of it. So the model’s instincts, which help everywhere else, actively fight this particular vocabulary. Priming makes it worse, because a model told to expect call signs will manufacture one out of thin air.

    What finally worked was about forty lines of Python and a lookup table. small‘s literal, unclever transcription turns out to be the most useful output available, precisely because it doesn’t try to be smart — “Whiskey Bravo 3, Charlie, Sierra Yankee” converts to WB3CSY every time, reproducibly, with no AI model involved. Running it across 1,754 transmissions found more than thirty call signs that no regex could see, because they’d only ever been spoken phonetically. It also turned up a failure mode I hadn’t noticed: the first phonetic word of a call sign goes missing constantly, almost certainly caused by PTT key-up clipping at the start of the transmission. Even the net control operator’s own call sign came through truncated three times in one net.

    The best part came last. Digging through Hunter Inman’s (KK7NQN) original database schema, I found he’d already built the lookup table I needed. He included a corrections table with the phonetic alphabet in it, including “king” and “box” from the old military alphabet that still sees plenty of use on the air, plus manglings he’d collected in the field. My resolver now reads from his table. Adding a new correction is one line of SQL instead of a code change.

    The code and the full write-up are in the GitHub repo, and parts 2 and 3 in the series are scheduled for publication. As additional refinements are put in play, it’s possible a part 4 will emerge.

    6. DroidStar 9M2PJU Mod Update

    It turns out the DroidStar 9M2PJU Mod app has an update available, but you won’t find it on the Google Play Store. Go to https://droidstar.hamradio.my/ for the link to download the APK directly (but be prepared for nag screens — I counted six popups before I could proceed).

    Go to https://droidstar.hamradio.my/ to find updates

    Go to https://droidstar.hamradio.my/ to find updates

    7. New and Notable: Nexus Amateur-Radio Software

    I picked this up from the Tuesday Project and Ham Radio Hobby Net on the WA7ABU 145.29 MHz repeater (also on AllStar node 51018). I was driving from Portland to the lake house Tuesday evening, so I had my node 588416 connected to 51018 to capture the net and catch up on it later — see the note on Hunter’s Transcription Script above. Glad I did, because I would have missed this otherwise.

    Brett KG7GDB brought up a program called Nexus Modern Operating Workstation and described it as an ambitious attempt to fold a bunch of familiar ham radio applications into one modern environment. According to the net, Nexus handles:

    • Rig control

    • WSJT-X-style digital modes, including FT8 and FT4

    • APRS — beaconing, messaging, mapping, following other stations, weather

    • Slow-scan television

    • Logging

    • A waterfall display and modern GUI

    Most of that already exists somewhere else. What caught my ear was having it all in one place. Anyone who’s built a digital-mode station knows how the software stack creeps — one program for the radio, another for FT8, a third for logging, maybe a fourth for APRS, each one wanting its own serial port or audio device or CAT interface. It works, but it gets tangled. An integrated app could cut down on that.

    Nexus on my laptop

    Nexus on my laptop

    The APRS talk tied back to some recent conversation the group’s had about projects for radios like the Icom IC-7100. On the SSTV side, nobody had actually put hours into it yet — this was more of a “hey, look what I found” than a review. That’s usually how these things start.

    Rob AJ7HR zeroed in on two details: Nexus is GPL-3 open source, and it’s written in Rust. He’d like to see more open-source software in the hobby — a lot of what we depend on is excellent, but plenty of it is tied to one platform, one maintainer, or one development model, and open source gives the community more room to poke at it and keep it alive. Rob also admitted Nexus had already gone farther than the all-in-one app he’d once thought about building himself. I think every technically minded ham has had that “I should build something like that someday” thought, right before someone else does.

    It also runs everywhere — Raspberry Pi, Linux (.deb and AppImage builds), Windows, and macOS, including Apple Silicon per Brett. For a hobby that runs on everything from Pi Zeros to Windows shacks to Macs, that cross-platform reach matters.

    Nobody on the net claimed Nexus replaces WSJT-X, your logging program, or your rig control software. But it generated enough interest that I’m filing it under “worth downloading and trying.” That’s usually how it goes: one ham finds something, another notices it’s open source, somebody else wonders how it’d fit their station, and pretty soon three people are experimenting. That’s a lot of how amateur radio actually gets done.

    8. Meet CORE

    I was introduced to the Central Ohio Radio Enthusiasts (CORE, at https://core.radio) by Justin KF8DEU. I have to say: this sounds like my kind of radio club!

    From Justin:

    It’s a radio club in a very broad sense, as in we talk about not only amateur radio but pretty much ANYTHING radio (mesh technologies, digital radios, reticulum, weather balloons, SDRs, etc) and meet once per month, listen to whoever wants to present something to us, while eating pizza.

    Tech talk, radios, and pizza. Sounds like a winning combination! Kudos to the CORE team. They are active on Discord.

    9. Configured a Spare DMR Hotspot

    Digging through some storage bins, I ran across my first homebuilt hotspot, made with a Raspberry Pi 3 board, a duplex MMDVM board, and a C4 Labs case. Cosmetically, it looks identical to the later RPi 4 hotspot I built.

    After futzing with it for a while to get the configuration right, I downloaded a backup of the working RPi 4 hotspot and restored that config to the RPi 3 hotspot. That worked perfectly…probably because the MMDVM board was exactly the same.

    Along the way, I realized I only want to use one hotspot for PNWDigital traffic. The Retevis RT3S is flashed with the PNWDigital codeplug, so it’s already set up that way. The hotspot is configured to reach Brandmeister first and PNWDigital second. I’m thinking now this doesn’t make a lot of sense.

    10. Forgotten: My ADSB Exchange Machine

    On a recent trip to the Portland, Oregon QTH, I pulled up my router admin dashboard to make sure firmware was up to date. And then I noticed a machine in my client list I had completely forgotten about, named adsbexchange.

    I had covered this more than two years ago in Random Wire 87.

    The other thing I had forgotten was Tailscale running on my local-to-Portland ADSB machine. So I logged in, updated the Debian operating system, and made sure Tailscale was updated.

    ADSBExchange running on Raspberry Pi

    ADSBExchange running on Raspberry Pi

    When I got back to the Lake House, I opened the Tailscale address for the machine and there it was: my flight tracker running in Portland, showing on my laptop more than 100 miles away.

    I’m surprised at the coverage I’m getting with this simple antenna, mounted inside by the sliding glass doors on the ground floor:

    Upgrade Version Loop Antenna MLA-30+ Plus 0.5-30MHz Rainproof Ring Active Receive Antenna Low Noise Medium Short Wave (this is an affiliate link)

    The ADSB Exchange dongle for my Raspberry Pi is no longer listed on Amazon. Try the ADSBx Hardware page if you’re interested in flight tracking.

    11. Gadgets

    Pocket AI Recorder

    I put this off for several months, but finally pulled the trigger on the Pocket recording device (https://heypocket.com/pages/pocket). It is billed as being your personal AI assistant.

    Is it life changing? No. Is it helpful? Yes. I’ve started using it to listen alongside me while I monitor nets. The post-net AI-produced summary is generally good enough to provide a solid overview of the topic discussed. Pocket doesn’t do well recognizing different voices, so when there is a statement in the summary that Tom said something, I have to take that with a big grain of salt. But overall, I’m glad I made this purchase.

    The M17 Net summary below was generated by Pocket AI. It listened to the net, presented me with a written summary, and I made corrections and some edits for easier reading. Pocket AI, like other AI engines, really has difficulty with amateur radio call signs.


    This session was recorded live from the Tulsa Maker Faire (Maker Fest), where Jeff (AE5ME) served as Net Control for the weekly M17 digital voice net on the Kansas Citywide system. The meeting focused on technical updates for the M17 protocol, the M7 application, and upcoming amateur radio events.

    M17 Protocol & Hardware Updates

    • LinHD Project: Development continues on the Linux-based handheld (LinHD). A “Revision C” design is forthcoming. The project utilizes the Retevis C62 as a donor for the case, keyboard, and display.

    • Hardware Compatibility: Participants emphasized using the English version of the Retevis C62 rather than the European version to ensure compatibility.

    • OpenRTX Firmware: Version 0.1 is approaching release, which will introduce packet and SMS engine capabilities. Supported hardware includes the CS750, M17 Plus, and Module 17 boards.

    • Hotspot Options: For high-performance M17 hotspots, the CC1200 and SX1255 boards were recommended over standard MMDVM/Raspberry Pi hats due to superior signal purity.

    M7 Application Development

    Greg provided a status report on the MSeven app:

    • Scan Feature: New functionality allows scanning across multiple reflectors and channels.

    • Dual-Receive Modes: Users can choose between a “stop and listen” mode (full audio for a set duration) or a “priority” mode where the active channel plays at full volume while others are ducked to 30%.

    • Hardware Pairing: The app successfully pairs with the Mobilinkd TNC4, enabling M17 operation on any 9600-baud capable radio.

    Community & Events

    • Zero Retries Conference: Scheduled for October in San Ramon (about 35 miles east of San Francisco). Jeff confirmed he will attend in person to present on M17, noting that a Zoom attendance option is available for those unable to travel.

    • Maker Movement: Jeff highlighted the 10th anniversary of the Maker Faire, emphasizing the importance of organic, non-commercial development in amateur radio to attract younger generations (STEM/youth groups).

    • Zero Retries Info: Registration and details are available at www.zeroretries.org/p/conference.

    Net Operations

    Due to the high-noise environment at the Maker Faire (35 dB to 50 dB noise floor), the National Traffic System (NTS) portion of the net was bypassed. Technical discussions and check-ins were prioritized via both RF and the netcontrol.live text stream.


    I have no experience with other devices that purport to do the same thing, so I can’t make recommendations. I can tell you where Pocket falls down, and that is Bluetooth…because there is no Bluetooth. If it had Bluetooth, maybe a phone call over a headset or earbuds could be picked up. As it is, it only picks up my side of that conversation. The solution is to use the speakerphone function.

    I’m not going to touch on privacy laws, since every state has something a little different. My state is a dual consent state (both sides have to agree) so I usually don’t bother with Pocket on phone calls.

    Cute Little Radio Project

    It’s not two-way radio, but it’s still radio. It’s an ESP32-based web radio, says this Blogspot post:

    I built this ESP32 based web radio this week. I’ve used a 1.9” IPS display with ST7789 driver. For the audio I’ve used MAX98357A I2S audio amplifier. This web radio is based on the excellent yoRadio project https://github.com/e2002/yoradio

    I’ve said it many times: I like small devices. This build is certainly small!

    12. QRT: End Transmission

    It was a hectic weekend-ish time. I made three day trips to Portland: one on Friday, one on Sunday, and one on Tuesday. Sunday was particularly long as I climbed into the pickup at 5:30 am and got back to the Lake House around 8 pm. Lots of driving, but that also meant time for audio books, listening to nets, and not-to-be-missed: listening to the Ham Radio Workbench podcast.

    Debian 13

    I lean heavily on Debian Linux, particularly Debian 13. That is usually my “go to” distro. Turns out I’m in good company. CERN is implementing Debian 13. I guess if it’s good enough for high-energy particle physics, it’s good enough for my home lab!

    146.52

    I don’t hear hams on 146.52 MHz very often up in the Olympia, Washington area, but it is quite common to hear traffic in Portland, Oregon and Vancouver, Washington. In Portland and Vancouver, 146.52 is treated more as a simplex channel for sometimes long conversations. I don’t think I’ve ever heard a contact in that area on 146.52 followed by a request to QSY to a different frequency. Different places, different customs. Always interesting.

    Mobile antenna

    And with three round trips, I got to test what was going on with my VHF/UHF antenna on the pickup. I’ve had good luck with Comet antennas, so the dual-bander on the truck is the Comet SS680SB. But something is wrong: when my Yaesu FTM-300DR transmits an APRS beacon, the radio shuts off. I thought: must be high SWR, I’ll check it. I pulled out my RigExpert STICK-500 analyzer and measured a very acceptable SWR below 1.3 near the APRS frequency. So I hooked up the radio again and as soon as it beaconed, it shut off.

    I had a spare antenna under the seat, named for my good friend Justin Case. That antenna is a mag-mount dual-band COMPACtenna. Before connecting it to the radio, I measured the SWR and found it was well above 2…but that’s still acceptable. And here’s the part that doesn’t make any sense to me: the radio works fine with the COMPACtenna.

    Of course, I’ve had that antenna on the roof of the pickup for more than two years. It’s seen a lot: rain, snow, hail, rocks, tree branches, a Washington-to-Texas road trip, and more. I live in western Washington so salt-laden moisture could be a factor. Maybe there is an intermittent connection that I missed when I tested the SWR. I’ve cleaned and tightened connections, but the radio still shuts down when it transmits an APRS beacon through the Comet antenna. I tested this over and over on my three long drives. (As I think about how the antenna is configured, I’ll bet it comes apart, which means I haven’t really cleaned all the connections yet.)

    The next time I pop down to Portland, I’ll grab a spare antenna from the Justin Case antenna tube and try it on the same mount. If that works, then it’s the antenna. If the radio still shuts down, it’s the mount or feedline. In the meantime, my stubby COMPACtenna is doing the job for me.

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 197: News and a Retevis C62-to-M17 teaser​Random Wire℠

    Tom Salzer KJ7TRandom Wire 197: News and a Retevis C62-to-M17 teaser​Random Wire℠

    It’s been such a busy week my writing time got short. It’s Thursday night and I’m making a late push to get this out the door on time. In the background, I’ve got Solomon Hayes singing in my ears on Spotify. His style reminds me of Joe Bonamassa (who I also enjoy), just a little less electrified.

    1. QRV: Are You Ready?

    Last week I hit DMR topics pretty hard. Then the weekend brought us a medical issue with my spouse, and Monday I made a day-long trip to Portland and back. Add in the work I did this week on the Retevis C62 build (more on this below) and I lost about four days of potential writing time.

    Fortunately, life settled back into place by mid-week, giving me some time to play with the Retevis RT3S/OpenGD77 radio on DMR. Last week, I configured my Yaesu System Fusion hotspot running WPSD software on a Raspberry Pi 4 machine to DMR. That left me without a YSF machine unless I switched the RPi4 back and forth between DMR and YSF. Instead of doing that, I plugged in my spare RPi5 hotspot and configured it for YSF. Works great.

    I used the RT3S to monitor the PNWDigital Not-a-Net” gathering on Wednesday evening…with some self-created hiccups along the way. When I got set up a few hours before the gathering, I could not get reliable reception with the RT3S. I went down several rabbit holes before the light went on in my head: my DMR hotspot was using the same frequencies as my YSF hotspot. Whenever the YSF hotspot was active, my DMR reception was terrible. The fix was simple: move the DMR frequencies for TX and RX to a different pair that no longer collided with the YSF frequencies. Problem solved.

    I also switched my LightAPRS Gateway antenna from a small mag-mount on a cookie sheet to an actual vertical dipole. Surprisingly, it didn’t do much. My direct connections decreased slightly while my total connections increased. Maybe in my hilly location, the more spherical pattern of the mag-mount works better than the flatter pattern of the vertical dipole. But that is purely a guess. Bottom line: both antennas work, so I’ll leave the dipole up for a while and see how it goes.

    And are you ready for fall and winter? Now is the time to check your outside coax and connectors — before you notice your SWR is sky high and you have to brave that cold fall rain dripping down the back of your neck.

    And speaking of antennas, my Yaesu FTM-300DR in the pickup truck started shutting itself off yesterday. My first thought was the wiring harness had gone bad…because that had happened before. But as I kept turning it on and watching as it powered down, I realized it was shutting down every time it transmitted an APRS beacon. Uh oh. I probably have a shorted antenna cable somewhere! This happened late yesterday so I’ve not had time to dig into it.

    This week, I checked into #APRSThursday over LoRa APRS:

    I also did some scoping of a potential project for my daughter. She likes to identify birds, so I looked at software that would allow me to identify birds by their songs. Looks like one of the most reasonable approaches is to use an old cell phone as the outdoor microphone, and have it connected wirelessly to a Raspberry Pi computer inside. More on this if/when it develops!

    2. New on EtherHam

    3. AllStarLink? Listen to Ham Radio Workbench #269

    If you are into, or are interested in, AllStarLink, this is for you. Without further ado, here’s the link: HRWB 269 – AllStarLink with Jason McCormick N8EI.

    N8EI is an active technical contributor on the AllStarLink Community Forum, frequently discussing system troubleshooting, software transitions, and node configuration.

    4. QSO One Continues to Improve

    You’ll want to take a look at QSO One, even if you don’t plan on using the software. Why? Because of the convenient Net Finder directory available on the QSO One website:

    Why would you want to use QSO One? If you are looking for an all-in-one, integrated platform for all your nodes and modes, this could be what you’ve been waiting for.

    For me, it looks like a great solution for my Uniwa F400. Note this excerpt from a post in the QSO One group on Facebook:

    Using QSO One on a new Uniwa F400 has brought a ton of fun into my life since first installing the app. The features have helped me to gain access and experience some new-to-me digital networks (Allstar, Echolink, and YSF), and I appreciate that very much.

    I wrote this early in the week and saw a few more announcements after I captured this piece. QSO One is rapidly evolving.

    5. DroidStar 9M2PJU Replaced My DroidStar App

    A strong alternative to QSO One is the DroidStar implementation by 9M2PJU. I’ve been testing it and finally deleted my old DroidStar app from my phone this week. The DroidStar 9M2PJU app won that battle and now reigns supreme, at least on my smartphone.

    But I think I’m going to also install it on my Uniwa F400 device. Fingers crossed it works well there, too.

    Learn more at https://droidstar.hamradio.my/ (but be prepared for multiple nag screens when you first open this link).

    6. M17 Net

    Last Saturday’s weekly M17 digital voice net on the Kansas City Wide system, led by net control Jeff AE5ME, focused on the technical evolution of the M17 protocol, upcoming firmware releases, and the protocol’s advantages over proprietary digital modes.

    M17 Project & Technical Updates

    M17 is a public domain digital voice and data protocol designed to eliminate the need for proprietary hardware or licensed codecs. It has received two $250,000 grants from Amateur Radio Digital Communications (ARDC) to fund its development.

    • OpenRTX Firmware: Currently at version 0.4.3. The upcoming v0.5 release will be a major milestone, introducing SMS messaging and packet radio capabilities directly to radios like the MD380, MD390, and the CS7000.

    • LinHT Project: A Linux-based handy talkie (HT) with a software-defined radio (SDR) core. This project enables multiple modes (M17, Tetra, DMR) and paging protocols like POCSAG to run on a single device.

    • Hardware Compatibility:

      • Retevis C62: Development is ongoing for M17 support via the OpenRTX PR branch (Pull #15). Currently, it supports FM only. There was a brief discussion regarding the complexity of building the OpenRTX firmware from source for the Retevis C62. While the PR branch exists, it is not yet an “official” binary, requiring users to use a Linux command-line environment.

      • CC1200 Boards: New hats for the Pi Zero W 2 are available for M17-only hotspots.

      • Module 17: A project that allows converting existing mobile rigs into M17-capable radios.

    Technical Q&A & Signal Routing

    A significant portion of the net focused on how M17 signals move through different layers of infrastructure.

    • SMS in QSO1: It was confirmed that the QSO1 software supports SMS text messaging via the M17 chat feature.

    • Emergency Communications: The net highlighted the risks of relying on PTT over Cellular (POC) radios during disasters due to network congestion. M17 and the National Traffic System (NTS) were emphasized as more robust alternatives for handling health and welfare traffic when infrastructure fails.

    7. Coming Soon: Cracking Open the Retevis C62 for M17

    A $50-ish dual-band handheld built around a chip most hams have never heard of, running an open-source firmware port that’s still wet cement — that’s the Retevis C62, and it’s the next radio through my test bench. OpenRTX, the same open firmware project behind those RT3S M17 mods you’ve read about here, is now being ported to the C62’s ListenAI CSK6011B chipset, and I’ve spent the last few evenings getting a Windows toolchain to actually produce working firmware for it. Spoiler: it compiled clean, memory headroom to spare, on the first successful run — which sounds simple until you hear what it took to get there.

    To be clear, what I’m trying to do is still experimental. Translation: it’s not ready for production. But I’m curious, and I know I’m not alone in trying to do this.

    Well, it didn’t go smoothly. The official build instructions pointed at a Git branch that doesn’t exist where the docs say it does — turns out it only lives on a contributor’s personal fork. Then the container-based build tool quietly configured itself against the wrong internal workspace entirely, silently failing every dependency-fetch command with errors that looked like typos but weren’t — the kind of bug that eats a whole evening before you find the one diagnostic command that exposes it. I ended up manually placing four separate module repos by hand once I figured out what the build system actually wanted, and only then did the whole thing link successfully.

    And that was just the build. Getting the finished firmware onto the actual radio turned into its own saga — burn mode entered fine, but the PC flatly refused to see the radio over USB, no matter what cable or computer I threw at it. Two “should’ve worked” programming cables later, and a lot of Device Manager archaeology across two completely different machines, I finally landed on the real culprit: not a driver problem, not a Windows problem, but the cable itself missing the one active chip this radio’s flashing mode actually requires. The right cable is in hand now.

    I haven’t had a chance to actually flash the radio yet — that’s the next step, and I didn’t want to rush it just to hit a publishing deadline. So consider this the trailer: full build procedure, the module-workaround nobody’s documented anywhere else, the cable gotcha that cost the most time, and — assuming the C62 boots up on the other side — first impressions of OpenRTX running on genuinely new hardware. Next issue, once I’ve had the chance to actually pull the trigger.

    8. PNWDigital Not-a-Net Gathering

    I listened to much of the Wednesday evening “Not-a-Net” gathering held by the PNWDigital folks. I noted check-ins were made via Zumspot, Pi-Star, OpenSpot, BlueDV, and DV Mega devices, along with RF via DMR repeaters. That was a bit more texture than I expected —> many ways to get your message out on DMR.

    9. Gadgets

    Cardputer

    I traveled a bit off the beaten path with this: the Cardputer ADV. It was about $42 from Amazon (affiliate link). As I flashed different firmwares to it and explored this tiny platform, I decided to give it a try with MeshCore. That required a special hat for the Cardputer: SX1262 LoRa Module w/GPS GNSS for Meshtastic (affiliate link).

    Was this a useful purchase? Absolutely not. It was just for fun. The firmwares are interesting and I look forward to discovering what else I can do with the Cardputer.

    Some people use these for hacking, but that’s not me. This is just a fun little device that slips into a shirt pocket. A word to the wise: if you use reading glasses, you might need a second pair to read the tiny screen!

    I expected a fun weekend dev-platform toy. What I got instead was a proper hands-on review project, complete with a firmware bug, a Bluetooth mystery, and eventually a working MeshCore node. If you’re eyeing one of these for your own bench, here’s what actually happened, warts and all.

    The keyboard takes some getting used to. There’s no touchscreen, so everything — including menus that look like they want a tap — is driven through the Fn key and a cramped arrow cluster hiding under the semicolon, comma, period, and slash keys. The keys themselves have a habit of double-registering if you’re not deliberate about your typing, which cost me a garbled WiFi password more than once.

    The bigger surprise was the stock “factory” firmware — the demo suite M5Stack preloads, with its little hardware-test apps for the keyboard, IMU, SD card, and so on. The Clock app turned out to have a hardcoded UTC+8 offset that I could not override.

    From there I went firmware-hopping, which turned out to be very interesting. You load firmware with the M5Burner app on your computer and a data-capable USB-C cable. M5Apps (a community launcher) fixed the keyboard quirks but couldn’t get WiFi to stick. Bruce (yes, that’s the name of the software) nailed the clock and timezone handling on the first try, confirming that the clock problem was not the hardware but the M5Stack demo firmware.

    None of that was really the point, though. With a LoRa+GPS cap clipped onto the top, the real goal was turning this thing into a MeshCore node that could talk to the repeater already running on my roof and to my phone app.

    That last stretch was the real adventure. Getting a MeshCore build flashed and receiving traffic on the Public channel was straightforward once the LoRa cap was installed. But getting it to join my own private #etherham channel was not easy. Bluetooth pairing failed repeatedly, even with the correct PIN. USB serial access turned out to be flash-mode-only on that particular build (a nice meshcore-cli detour taught me that the hard way). Even manually copying the channel’s secret key over didn’t get channel messages flowing.

    What did work was sidestepping channels entirely. MeshCore nodes discover each other via broadcast “adverts,” and once the Cardputer and my T-Echo Plus heard each other’s adverts, direct messages worked immediately. No shared key was needed, since DMs use per-contact key exchange instead of a channel secret.

    This is a genuinely capable (albeit quirky) little radio node, provided you’re willing to treat the software side as part of the hobby rather than as an inconvenience. If you’re comfortable flashing firmware, poking around GitHub issues, and treating a stuck menu as a puzzle instead of a dealbreaker, you may find the Cardputer ADV to be a fun diversion. However, if you just want a mesh terminal that works out of the box, this likely isn’t it.

    Interesting: Mecha Comet

    Shipping October 2026:

    Mecha Comet, handheld Linux computer that’s truly yours to own, build and mod.

    What is it? HowToGeek has a write-up. I do like a small-but-powerful device!

    New battery for Yaesu VX-6R

    I mentioned last week that I bought a charger and a new battery for my Yaesu VX-6R. The original battery would not charge and was not recognized by the radio. I was hoping that putting it on a higher amperage charger might wake it up and allow it to accept a charge, but alas, that is not what happened. In fact, nothing happened. So that battery will go to hazardous waste. The new one charged swiftly and works fine. And the wall charger also works with my Yaesu FT-70D, so this is a “two-fer” for me.

    TRMNL

    Many moons ago, I supported a Kickstarter for a programmable display called TRMNL. I plucked it off the wall during a recent trip to the Portland QTH and brought it up to the Lake House.

    It’s not doing anything fancy, like showing news or quoting famous people. I just want to see the weather at a glance, and for that, it works just fine.

    The e-ink display draws very little power from the internal battery. I usually only have to charge this thing once every several months.

    But I got to thinking about other ways I could use this nice screen. One thing I am always interested in is the status of my AllStar nodes. I have many because I experiment with them, but I usually only keep a handful “up” at any one time. So I wrote a custom Python script to poll the status messages at AllStarLink about my nodes. Then, with a little HTML magic, I was able to display the statuses of my nodes on the TRMNL.

    Of course, it was really more complicated than that, so I’ve covered the ins and outs at EtherHam.com. That article also has the actual Python script I built to accomplish the polling of my node numbers.

    10. QRT: End Transmission

    Whew. Not the quality I like to share, but there is probably a little of something for everyone in this casserole-like issue of the Random Wire!

    This week marked our 49th wedding anniversary. Those who have subscribed for a while know my wife has severe medical issues. She can no longer stand, sit, or walk. She can’t swallow or talk. Her disease has substantially impaired her cognition. And yet when I brought a bouquet of flowers to her today, she beamed out a great smile and her eyes told me all I needed to know. Over the past year, I’ve wondered if we’d see this milestone, but here it is: we made it to 49. Seizing these brief moments in the midst of this difficult journey is important and I’m grateful we still have time left together.

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom wire 196: DMR codeplugs, from writing your own to importing someone else’s​Random Wire℠

    Tom Salzer KJ7TRandom wire 196: DMR codeplugs, from writing your own to importing someone else’s​Random Wire℠

    1. QRV: Are You Ready?

    I went a bit DMR crazy this week. Hit the DMR category on EtherHam and you’ll see what I mean. Here’s the elevator version: I used OpenGD77 on a $100 Retevis RT3S radio to install the PNWDigital codeplug. What I learned along the way is shared in my new DMR articles.

    I also took a dive into Winlink, APRS, and EmComm. I wonder how this essay will land, especially with folks deeply experienced in search-and-rescue, incident command, and related activities. I suspect that my take on incident command may go against the grain for some folks. But maybe not.

    A scripting error corrupted my work database, and that took a day to unravel the cause and another day to clean the data. Paraphrasing a database guru I learned from many years ago: there is no such thing as a perfect database, only those with an acceptable number of errors. The number of errors I had this week was unacceptable so I dove in and fixed the problem.

    And that pretty much sums up my radio and technology week: a lot of digital radio and little bit of coding and cleanup.

    I saw good uptake of the new EtherHam Groups.io space. Remember: in this first phase rollout, it is limited to 100 subscribers. We’re almost halfway there so sign up now if you are interested!

    2. New on EtherHam

    Winlink Tells You What Happened. APRS Tells You What’s Happening. — I’m afraid I went a bit overboard on this essay, simply because of my background in emergency services/management. I’ve been an EMT on a rural ambulance service, a hospital commissioner, an underground mine rescue EMT, a search-and-rescue member. I was part of an ARES group for a while and also served as a state agency representative to the state’s emergency management department. Those roles gave me deep appreciation for how incidents actually unfold and get managed in real time…and I think that biases my point of view toward those working at the forward edge rather than those in the command center. It’s a long read so I included a table of contents to help you. One of the best moments for me while I wrote this was learning more about how LoRa radio actually works to pick out signals buried in the noise.


    This was “DMR week” at EtherHam, with parts 2, 3, and 4 published. Part 5 will cover on-air etiquette and troubleshooting — including PTT habits, why they matter more on digital than on FM, and the answer to: if you can’t scan the band to find people, how do you actually find someone to talk to?

    Introduction to DMR, Part 2: The ID, the Radio, and the Hotspot — Part 1 promised the ID, the radio, and the hotspot before ever touching a codeplug — this is that piece, delivered after the fact. It walks through registering a free DMR ID at RadioID.net, then lays out the actual fork in the road on radio choice: the AnyTone AT-D878UVII Plus for anyone who wants a download-and-personalize codeplug the same afternoon, versus the Retevis RT3S and OpenGD77 path this series has been running on, for readers who want the talkgroup/frequency separation badly enough to tolerate a rougher first hour. From there it’s a full step-by-step Raspberry Pi hotspot build — parts, assembly, and WPSD configuration — reused and adapted from an earlier hands-on build, plus a hard look at how much hotspot hardware costs today versus when that build first went up. Read this one before Part 3, even though it was written after it.


    Introduction to DMR: Part 3 — Building Your First Codeplug — I flashed a new Retevis RT3S with OpenGD77, built a codeplug from scratch pointed at my hotspot, keyed up — and got silence. Then got silence again, for an entirely different reason. This is the unvarnished version of that afternoon: what a codeplug actually becomes once the four concepts from Part 1 turn into specific numbers that have to match specific other numbers somewhere else, why DMR answers a single wrong value with total silence instead of a useful clue, and what it does to your troubleshooting when fixing a genuine problem changes nothing you can see. If you’ve been putting off building your first codeplug, or you’ve built one and can’t work out why it won’t talk to anything, this one’s for you.

    I added an addendum at the end of this article, titled: The settings, field by field. The addendum gives you a screen-by-screen accounting of the settings I used in the OpenGD77 CPS.

    It’s a long article, so if you want the answer to the question “does the Retevis RT3S DMR radio work when programmed with OpenGD77,” the answer is yes:


    Introduction to DMR, Part 4: Loading Somebody Else’s Codeplug — Part 4 of the Introduction to DMR series takes the opposite approach from Part 3: instead of building a codeplug from scratch, I downloaded PNWDigital’s ready-made OpenGD77 codeplug — 125 channels, seven zones, someone else’s careful work — and it took longer than building one by hand. Not because the codeplug was wrong. Because a community codeplug is built for that community’s network, and my hotspot was pointed at BrandMeister. That single unasked question sent me chasing filters, timeslots, and call types for hours while the actual problem sat one layer up.

    Along the way: the CPS button that’s invisible at the wrong browser zoom, why the codeplug arrives wearing another operator’s callsign, the difference between a repeater talkgroup list and a hotspot one, and talkgroups that stay asleep until you kerchunk them awake. The piece also includes something I felt would help you picture how DMR is structured — a single diagram of how zone, channel, contact, talkgroup list, and network actually chain together, and why you should build that chain backward from the network rather than forward from the CPS.


    Retevis RT3S + OpenGD77 Cheat Sheet: Every Control, Remapped from the Radioddity GD-77 — OpenGD77 was written for the Radioddity GD-77, and it runs beautifully on the Retevis RT3S — but the two radios don’t share a control layout. The GD-77 has four arrow keys; the RT3S has two buttons and a rotary knob, so the firmware reassigns them, and it reassigns them differently depending on whether you’re sitting on a main screen or inside a menu. The result is that a documented shortcut doesn’t fail cleanly, it does something else: the key combination the manual gives for changing zones will quietly change your transmit power instead. This sheet is every control translated for the RT3S, with the ones I’ve confirmed on my own radio marked as such and the rest flagged as untested.

    Retevis RT3S in hand

    Retevis RT3S in hand

    Weekly Report: August 20, 2026 — Band Conditions This Week / Digital Radio News / Groups.io Digest. Summary:

    • The predicted A-index of 11 suggests we’re not entirely out of the woods yet, so keep an eye on the numbers before investing an evening in a long-haul DX session.

    • The MMDVM firmware for DMR received a merge (PR #362) that adds a configurable audio‑fidelity link option.

    • AllStarLink’s app_rpt was updated to version 3.10.4; the patch series (PR #1205‑#1207) adds a client‑disconnect helper, removes duplicated sanity checks, disables autoservice during safe‑sleep, and fixes thread‑creation leak bugs.

    • The LoRa APRS iGate repository received three commits on 2026‑08‑16 that update the T‑Deck hardware requirements, refresh the README, and add new image assets.

    • Community posts on the AllStarLink forum report connection refusals from keyed nodes, intermittent telephone‑portal operation, and general remote‑node connectivity failures.

    • Groups.io: 31 groups checked, 15 active, 493 total messages, 11 quiet. The most active groups in the set were Repeater Builder, APRS, and TinySA.

    3. QSO One, the CGNAT Killer?

    QSO One was built so hams could get on AllStarLink, EchoLink, IAX Direct, DMR, System Fusion, and M17 from a single app, without a Raspberry Pi, a radio interface, or a weekend of Linux. It’s free. Sign up with your callsign, download it for Windows or Android, and you’re on the air in about five minutes. More platforms are coming.

    But one of the magical aspects of QSO One that we’re not hearing much about is that it works with CGNAT: “node mode and WT mode for AllStarLink are solid, with cellular and CGNAT handling that actually deals with carrier networks instead of just failing.”

    As IPV4 addresses continue to become less available and CGNAT networks become more common, I suspect that QSO One’s secret sauce will be its ability to carry traffic through CGNAT networks.

    4. APRS

    #APRSThursday follow-up: the check-ins actually worked

    In the previous issue, I mentioned that my #APRSThursday check-in attempts — from the LoRa tracker as KJ7T-3 and from APRSdroid as KJ7T-5 — went unanswered by ANSRVR and APRSPH. Turns out that wasn’t quite right. Digging through Sergei KJ5LOX’s APRS Observer dashboard, both check-ins are right there in the log, addressed to ANSRVR and timestamped clean. The messages went out fine; I just never got a reply back.

    The reason surfaced in Michael Diturno’s weekly #APRSThursday recap: ANSRVR itself had been down, and Jeff W4JEW and the APRS Foundation rebooted it to get the net back on track for the 752 operators who checked in that week. So the silence wasn’t anything on my end — it was a server having a rough week, now fixed. Good reminder to double-check the infrastructure before assuming the bug is local.

    One more thing that dashboard surfaced: KJ7T-5 (APRSdroid) is reporting altitude cleanly, but KJ7T-3 (the LoRa tracker) shows up as “Unknown” for altitude every time. Almost certainly a config setting I haven’t dug into yet — but to even get in there, I’ll need to break out the ToughBook. My regular laptop is ARM-based, and the T-Echo just won’t talk to it over USB. More on that once I sort it out.

    This week? I got checked in no problem:

    Did you happen to notice the MeshCore checking from K7OLI? That looks interesting!


    APRS OTA

    A few days ago, I received a very nice email from Jared K0TFU, the ham who built https://aprsota.org. He wrote:

    It’s been fun to watch hams begin to use this. One highlight for me was this string of QSOS from OE7BOE in the Tyrolean Alps https://aprsota.org/OE7BOE/ops/2.

    I’ve now got a stats page up and running at https://aprsota.org/stats so everyone can see the usage of the service. We should pass 500 QSOs made using APRS OTA sometime later today, and have hams in 14 countries who have participated.

    When you read his radiograms you can see this is fresh work. I predict APRS OTA will become another popular way to use radio and technology. It looks like it is off to a great start.

    5. The Surprising Family Tree of Yahoo! Groups

    If you’re a ham who misses the old Yahoo! Groups, here’s a piece of trivia that might reframe things: the person who built the service you’re pining for is the same person who built the one a lot of us use now.

    Groups.io’s founder, Mark Fletcher, didn’t start with Yahoo! Groups — he started with a service called ONElist back in 1998, a free mailing-list host built for exactly the kind of niche system hams have always relied on. ONElist soon merged with a competitor called eGroups, and in June 2000 Yahoo! bought the combined company and rebranded it as Yahoo! Groups.

    For a while it thrived. But Yahoo! management largely stopped investing in it. Over the next fifteen-plus years, the platform calcified under their watch: clunky moderation tools, a dated interface, and eventually real spam and security problems that group owners had no good way to address. Fletcher, watching from the outside as the company let his creation rot, eventually decided to build the successor himself. Groups.io launched in beta on September 23, 2014 — six years before Yahoo! finally pulled the plug on Groups on December 15, 2020.

    That timing turned out to matter a lot for amateur radio. When the Yahoo! Groups shutdown was announced, hundreds of ham-related mailing lists — build groups, DX nets, kit-support forums, digital mode communities — suddenly needed somewhere to go, fast, with their years of archived messages intact. Groups.io was ready and purpose-built to catch them, and hams migrated in numbers well out of proportion to the general population of orphaned Yahoo! Groups. Today, ham radio groups punch way above their weight on the platform. By one count, 10 of Groups.io’s top 40 largest groups (out of roughly 100,000 total) are amateur radio communities, with the Softrock40 group alone landing at #4 overall with over 8,000 members, trailing only a couple of non-radio giants and IBM’s internal list. YouTuber Callum, better known as DXCommander, is often credited with giving the migration wave an extra push by publicly encouraging hold-out groups to make the jump.

    We are living with the legacy of Yahoo! Groups. It didn’t vanish when Yahoo! finally killed the service in 2020. Instead, it moved, largely intact, onto Groups.io, which is why the platform now provides such outsized support to the amateur radio community specifically. The free, low-friction, member-run model that made Yahoo! Groups worth missing in the first place is exactly what its original builder set out to preserve and protect from further neglect when he built its successor.

    If you’re active in a ham radio group on Groups.io today, you are standing on infrastructure with a direct lineage back to a scrappy 1998 mailing-list startup — one that Yahoo! bought, neglected for two decades, and finally killed, only for its original builder to come back and keep it going for communities like ours.

    6. Old IEEE Articles on Amateur Radio & Tech

    It’s been far too long since I dove into the past offerings of IEEE Spectrum. I did that this week, harvesting a handful of interesting titles for you to consider. Maybe one will spark a project idea.

    7. Gadgets

    Yaesu VX-6R charging

    I bought an $11 USB charging cable for my Yaesu VX-6R handheld radio. A side benefit: it also fits my Yaesu FT-70D handheld. I am finding that it works fine to charge the FT-70D battery but conversely, not with the VX-6R. I get a “NO BAT” message on the VX-6R’s screen when I try to charge with the USB cable. The radio operates as if it is on external power when I turn it on with the cable connected. When I disconnect the cable and try to turn on the radio: nothing.

    USB Charger Cable for Yaesu Radio CD41 CD47 CD15A CD26 (this is an affiliate link)

    So I’ve ordered a fresh battery and high-capacity charger, and neither are original Yaesu products. Fingers crossed on this purchase.

    It may be that my original battery sat fully discharged too long and now the radio doesn’t even see it when it is connected. I’m guessing this might be the case. Perhaps fully charging it with the hi-cap charger will work. If not, I’ll still have a new battery.

    Tri-Band Yaesu VX-6R Submersible Amateur Ham Radio Transceiver (144/222/440) (this is an affiliate link)

    The VX-6R is a tri-band analog FM transceiver. The 220 MHz band operates at 1.5 watts out instead of the full 5 watts out on 70 cm and 2 meters. In the U.S. market, it comes with NOAA weather channels and maritime channels. But what I like most about the VX-6R is how it feels in my hand. It is a compact radio that fits my medium-sized hands just right. The case has enough texture to feel secure in my grip. And since I live in a place with a lot of winter rain, the IPX7 rating gives me some comfort when I carry this radio on my journeys.

    8. Short Stack from the Interwebs

    The Short Stack from the Interwebs, pulled from the aggregated feeds on EtherHam (etherham.com/feeds/), items from August 13–19.

    SDR & Signal Hacking

    Digital Modes & Mesh

    Gear, Builds & Reviews

    POTA & SOTA Field Reports

    Shortwave & Listening

    DX, Contests, Satellites & Awards

    Podcasts, Community & Events

    Advocacy, Licensing & Growing the Hobby

    Software & Apps Roundup

    Linux, Homelab & Self-Hosting

    9. QRT: End Transmission

    I’m very curious how the DMR radio will work. So far, I’ve been pleased with the Retevis RT3S DMR handheld. Discovering the differences between it and the Radioddity GD-77 radio was enlightening and helpful. I’m happy I was able to map important key combinations this week.

    And if DMR traffic in my neck of the woods proves interesting, I might start looking for a mobile rig to carry in the pickup truck. The PNWDigital group has a good number of DMR repeaters in the region so I would have reasonable coverage most of the places I regularly travel to and from.

    On the tech and software side of the house, I’m looking at notifier systems like Pushover and Pushbullet. It would be convenient to develop a stack of circumstances that trigger automatic notifications pushed to my smartphone. My tech stack is deep enough at the house that it’s actually hard to notice if something has gone offline or if the IP address changed because the upstream provider made changes. I have a notifier set up for some websites but those “down” notices come through as emails, meaning they get swamped by all the other emails I receive. For the sites I manage, getting those notices by SMS or pushed to an app would be helpful.

    And that’s it from the great Pacific Northwe(s)t, where we are actually in a drought and experiencing a record number of wildfires. I hope all who have been affected get the help they need to recover from these disasters.

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 195: LoRa APRS on a T-Deck, New Groups.io space, and the IP400 project​Random Wire℠

    Tom Salzer KJ7TRandom Wire 195: LoRa APRS on a T-Deck, New Groups.io space, and the IP400 project​Random Wire℠

    0. Updates!

    Windows

    Last week it was a Debian 13 update with security vulnerabilities plugged. This week, it’s Windows: Microsoft Plugs Nearly 400 Security Holes. One of the most fundamental ways to protect yourself is to keep your computer updated.

    August 11, 2026: Microsoft today released updates to remedy at least 398 security vulnerabilities in its Windows operating systems and supported software, including one weakness that is already being actively exploited and two others that were publicly detailed prior to today.

    HamClock OHB

    If the version number on your HamClock OHB display is red, an update is available. Click that red version number and follow the prompts to upgrade. Nice additions since I last upgraded:

    • An email icon that presents a link to the OHB status page. Useful.

    • An airplane icon that opens an ADSB flight tracker for your location. Interesting.

    • A blue wind icon that opens the Windy.com website.

    Screens are presented as a collage below because inserting them all here would take up too much space:

    HamClock version upgrade collage

    HamClock version upgrade collage

    1. QRV: Are You Ready?

    It’s been a rather frustrating week. Usually, I’m gleeful when I find problems to fix. This week, I just wanted things to work…but they didn’t. Resolving issues this week dramatically diluted my writing time. That I do find frustrating.

    And I’ll gripe a little bit (again) about Claude’s Sonnet 5 model because it jumps to conclusions. That ended up costing me several hours of time this week as I chased a couple of long, involved issues down dark and twisty rabbit holes, when time was in short supply. The Opus 5 model does much better but it also burns through my credits much faster. The problem here is really twofold: I don’t know Sonnet is going to make mistakes until it makes them, and I’d rather not spend the money on Opus if I don’t have to.

    Huh. Here I am complaining about AI. I wonder if this is going to become the new normal on repeaters. You know the drill: what’s the weather, what equipment are you running, how is your health, and now, what have you been doing with AI?

    I have to say, though: it is so very easy to overlook all the great help now available to me through the many AI engines available. I have far more successes than difficult detours. It feels a tiny bit uncomfortable to say this plainly, but I will: at this moment in time, I am grateful for AI.

    2. New on EtherHam

    • Writing EtherHam Content: Untangling the Ball of Yarn — Meetings (and radio nets) rarely move in a straight line. Someone circles back to a point you thought was closed thirty minutes ago, and a strict outline can’t keep up. Thirty years of facilitating meetings taught me why; mind mapping taught me how to actually capture it. This piece walks through that shift — from a hallway conversation with a frustrated note-taker decades ago to the technique I still use today, turning a tangled ball of yarn of ideas into the straightened, sequential pieces you read on EtherHam.

    • LoRa APRS: Part 3 — A T-Deck Plus Tracker, Offline Maps, and a Long Detour Through OpenStreetMap’s Terms of Service — A LilyGo T-Deck Plus running LoRa APRS will render an offline vector map of the terrain you’re standing in, hold threaded APRS conversations, and pass Winlink email — none of which a plain tracker does. Getting there took most of a day and five stacked failures, each one hiding the next: a wiki that contradicts the firmware it documents; an SD card in the wrong filesystem; 1,793 downloaded map tiles that turned out to be OpenStreetMap’s “Access blocked” graphic saved 1,793 times; a tile generator that had to be compiled from source inside Linux; and — after all of that — a map that had been working the whole time but wouldn’t render until I pressed the zoom button three more times. Somewhere in the middle, the tracker started reporting itself in the Southern Ocean while its own screen showed the correct coordinates. If you just want something that beacons your position, buy a T-Echo and enjoy long battery life. If you want the map and the messaging, here’s the whole path with the wrong turns left in, because the wrong turns are the part worth reading.

    • Weekly Report: August 13, 2026 — Catch up on band conditions, digital radio news, and the Groups.io digest.

    3. New: EtherHam Community Space

    Over the years, the conversations around the intersection of amateur radio and technology have grown incredibly rich. While the newsletter is a great way to share these concepts, I want to give us a dedicated space to hold deeper, multi-sided discussions.

    Today, I am excited to officially launch the EtherHam Groups.io Community.

    This is our new clubhouse on the web—a text-based space where you can ask technical questions, share project updates, discuss technology integration, shape future Random Wire and EtherHam topics, and connect directly with other subscribers.

    ⚠️ A Note on Capacity (First-Come, First-Served)

    Because we are launching on a lean, independent infrastructure, space is strictly limited to the first 100 members.

    To protect our space from automated bots, spam, and bad actors, membership requires manual approval. We are prioritizing licensed radio amateurs, though tech-minded enthusiasts are welcome too.

    How to Secure Your Spot:

    1. Click here to visit the group homepage: groups.io

    2. Click the Apply For Membership button.

    3. You will receive an automated email asking for your amateur radio callsign (or an explanation of why you want to participate).

    4. Reply to that email immediately to lock in your application for review.

    Once we hit our 100-member cap, the doors will close while we settle into this new space. If you want to help shape the foundation of the EtherHam community from day one, please submit your application today.

    See you in the ether,

    Tom KJ7T
    Editor, Random Wire
    www.randomwire.us

    4. IP400: The Story Behind This Important Project

    I’m sure you’ve noticed the changes over time on VHF/UHF repeaters: coordinated frequencies sitting quiet, hardware from the 1990s doing the same voice relay job it’s always done, and a shrinking pool of operators who show up to keep it maintained. For years, my friend Steve Stroh N8GNJ has been touting a project called IP400, and for good reason. A recent section of his Zero Retries newsletter will likely convince you that IP400 really is an exciting initiative in our amateur radio hobby. Why? Because he’s right.

    But where did IP400 come from? It traces back to a longtime radio amateur, Martin Alcock VE6VH — who spent years designing commercial broadband wireless systems before focusing that experience toward amateur radio. Alcock looked at what already existed — AREDN, HamWAN, New Packet Radio — and noticed they all shared the same limitation: they either ran on license-exempt spectrum with real power restrictions, or they came with enough administrative overhead that they never spread much beyond a dedicated core of builders. What amateur radio didn’t have, in his view, was a data and mesh networking system built from scratch for the hobby, on ham bands, without those constraints. That observation became IP400, developed under the Alberta Digital Radio Communications Society (ADRCS), the group Alcock helped found in 2022 and where he’s been able to line up grant funding — including a 2025 ARDC grant — to keep development moving.

    As the project has developed, it became clear that IP400 is not trying to replace DMR, D-STAR, C4FM, or your local FM repeater. Instead, it sits next to them. IP400 is additive to our hobby, not subtractive. The hardware — a controller board called the AMNC — talks to a radio you already own and adds a data layer compatible with AX.25 KISS framing, with an eye toward working alongside Winlink, AllStarLink-linked repeaters, and eventually AREDN’s mesh network. The goal is to give existing infrastructure a reason to be upgraded rather than replaced.

    What’s running today rides on ordinary FM audio, but that’s really just the first step. Alcock’s longer-term plan involves dedicated software-defined radios with a direct I/Q interface, aimed at speeds well beyond what’s possible when squeezing data through a mic jack. Where that lands, and how fast, is exactly the kind of thing Steve is covering well.

    I think there’s another reason for this, one that’s a little harder to say out loud: a lot of newer hams just aren’t as focused on voice communications as the hams who came before them. These new hams grew up in a data-driven, IP-enabled world, and IP400 speaks that language. I’d bet this brings a fair number of tech-fluent people into the hobby who might not have bothered otherwise.

    In my view, IP400 is one of the most exciting and fundamental developments in amateur radio today. I’ve not covered it in the Random Wire newsletter because Steve does such an outstanding job of keeping his subscribers updated on IP400. This project is worth digging into, getting excited about, and supporting. IP400 may well be one of the most important technology improvements we’ll see in amateur radio.

    For more, I suggest following this topic in the Zero Retries newsletter where it is sure to be very well covered by the ZR team.

    5. Curious About 44Net?

    Here is your chance to learn about 44Net and about John Burwell KI5QKX, on Eric Guth’s great podcast series, QSO Today, in Episode 539.

    John Burwell, KI5QKX, found his way into amateur radio through 44Net, the Class A public IP address space set aside for amateur radio almost 50 years ago, now managed by ARDC. John’s interest in connecting devices over the Internet led him to this remarkable ham radio resource. In this interview, we go deep into IP addressing and networking, opening the door to new ways licensed amateurs can learn, experiment, and build Internet-connected projects. KI5QKX is my QSO Today.

    6. QSO One 3.8.5 — Your Update Has Arrived

    3.8.5 is live for beta testers, and this one is almost entirely about audio. From the announcement:

    The mic gain scale actually works now, a real 0 to 100 instead of everything living in the bottom sliver. There is a new audio test for every network, you talk, it meters you, and it grades you hot, good, or quiet while you adjust. And the clever part, once the app has heard enough stations on a network, it grades you against how that network actually sounds, not against a number from a lab. Every network also gets transmit protection now so you cannot blow anyones ears off, Windows choppy audio got a real fix, and Bluetooth PTT buttons finally respect your PTT mode setting.

    Socials:

    It’s good to see this project moving forward.

    7. POTA Heil Headset

    I’ll just say this here: this new headset from Heil isn’t just for Parks On The Air, but it’s a great choice for POTA. From Michael Martens KB9VBR:

    8. Waiting on Two Radios: DMR & M17

    Retevis RT3S DMR Radio

    I ordered this a few weeks ago:

    RT3S Dual Band DMR Radio Non-GPS/Built-in GPS

    Why? Because I want to try OpenGD77 as the codeplug editor, and OpenGD77 says the RT3S is compatible. In fact, there are plenty of blog posts and reviews available on this exact pairing. (I’m not hyperlinking this radio here because I’ve not received or reviewed it yet.)

    I got interested in this after a subscriber asked me how to get into DMR at a reasonable cost. Of course, I do like my AnyTone 878 radio very much, but that’s a more premium option than a $100 radio and free CPS software.

    I promised a part two on DMR that I’ve been picturing as a how-to on developing your own codeplug. The RT3S with OpenGD77 is going to fit right into that slot. I’m looking forward getting this working and sharing the journey with you.

    A few days ago, the RT3S radio was in Chicago. Wednesday, I received the extra bits: a speaker-microphone, antenna, and spare battery. Maybe the RT3S will arrive in time for initial impressions…but probably not.

    Retevis C62 Dual-band Radio…for M17

    And then I ordered another radio from Retevis:

    Retevis C62 UV Dual Band AI Noise Reduction 5W Long Range Durable Business Two Way Radio

    What comes up on that page is a 6-pack of radios. I ordered the single radio for $55.

    Then I got an email: “We noticed that you purchased the (EU version) radios. To avoid any issues, would you like us to change your order to the US version[gmrs] instead?”

    I paused and thought for a few minutes about this, then replied: no. The experimental work being done by the M17 Project with the C62 is happening — I believe — in Europe, so perhaps I should stick with that version. We’ll see, of course, if it works once it gets here and I load OpenRTX on it. If it works I’ll have an M17 handheld for $55! If it doesn’t work, I’ll have another radio for the unused radio bin.

    9. APRS OTA

    I’ve not tried this yet, but APRS OTA does sound interesting:

    APRS OTA combines the vibe of a POTA activation with a native APRS messaging bot and a website to show what’s happening. Find an operator on the air, send one message and a position report to work them, and your contact is logged, mapped, and scored here as it happens.

    A bot serves as a relay and automatically logs contacts:

    APRS OTA is an activity and a bot…the OTA bot relays the exchange and logs every contact as it happens. There is nothing to install and no account to create: if you can send an APRS message, you are already in.

    It’s a three-part system, with a host, a bot, and chasers.

    Intrigued? Visit https://aprsota.org/ for more. If you try it, let me know what it’s like!

    10. And Then I Had an APRS Messaging Moment

    I was driving to get my morning coffee, watching carefully for deer. Sure enough, I had to hit the brakes so a young buck with velvet antlers could bound across the road. I’ve learned to look where the deer came from, too, and saw a doe and fawn turn back into the bushes. It was at that moment that I saw my APRS radio and a thought completely unrelated to wildlife popped into my mind.

    I’ll write this up in long form and post it to EtherHam.com, but my EtherHam website is offline at the moment due to a major power loss at the web host’s Phoenix data center. No word on when services will be restored (and I hope “power loss” is not code talk for “fire in the data center” because that would be very bad).

    What was that APRS thought? I wondered if I could send an APRS message from APRSdroid (I’m running the 9M2PJU Mod version) to my LoRa APRS tracker. Surely that could not work, because one system flows over cellular data and the other is LoRa radio. But the aha moment for me was realizing that both probably pass messages via APRS-IS. So I tested this by sending a message from my phone (KJ7T-5) to my tracker (KJ7T-3).

    I was surprised and delighted to find this worked perfectly. Replying from the tracker to the phone also worked, so APRS messaging works in both directions.

    Let me just pause and sit with that for a moment, because it was a revelation to me. We get pretty locked in about whether we’re working over RF or cell or satellite or wifi or whatever. Hung up on this, even. Lost in those details is the realization that APRS shares a common backbone: APRS-IS.

    APRS-IS stands for the APRS Internet System, and it’s the quiet piece of infrastructure that ties every flavor of APRS together. Stations riding RF — my LoRa tracker included — reach it through something called an IGate: a small relay station, often nothing more than a radio and a cheap computer in someone’s attic (or in my case, the garage), that listens to local radio traffic and forwards it onto the internet. Apps like APRSdroid skip the radio step entirely and log straight into APRS-IS over cellular data.

    Once a packet lands on APRS-IS, its origin stops mattering. It’s all just APRS-IS traffic from that point on — it can get relayed back out over RF somewhere else, or handed off to a site like aprs.fi to show up on a map. That’s what clicked for me on the drive: my phone and my tracker aren’t two separate systems that happen to talk to each other. They’re two different doors into the same room.

    And this is the secret sauce that makes APRS such a powerful tool: different radios, different frequencies, different modes, different mechanisms can all communicate cleanly because they all use the same pipeline behind the scenes.

    There is more to this test, because I also tried Winlink between my laptop and my APRSdroid app. That test yielded a surprising-but-educational result I’ll share once EtherHam.com comes back up.

    Finally, in a “why not?” moment, I tried checking in to #APRSThursday from the tracker (LoRa APRS as KJ7T-3) and from APRSdroid (KJ7T-5). Unfortunately, both ANSRVR and APRSPH did not respond to messages or commands. I hope the #APRSThursday folks get that fixed.

    11. Short Stack from the Interwebs

    Well, with EtherHam.com offline, I had to resort to a special mega feed URL which fortunately worked. The following Short Stack items were harvested from this week’s aggregated ham radio feed, covering items from August 5–13, 2026.

    SDR & Signal Hacking

    Digital Modes & Mesh

    • Digital Voice over HF with FreeDV Information from Kirk KN6UMV — MichiganOne DMR Tech Net — Follow-up notes from a net discussion on FreeDV, with pointers on where Maidenhead grid squares fit into the picture beyond just contesting.

    • DX Explorer and the Thinknode Meshcore M1 transceiver — Roger G3XBM’s (Mainly) Amateur Radio Blog — A rundown of a new video on the Thinknode M1 LoRa transceiver, with a reminder that Meshcore vs. Meshtastic popularity varies a lot by region.

    • QSO One 3.8.5 – Getting closer! Your update has arrived — MichiganOne DMR Tech Net — A beta release focused almost entirely on audio fixes, including a mic gain scale that finally behaves like a real 0–10 range.

    • SliceLogger — With Varying Frequency – Amateur Radio Ponderings — W4TME’s logging tool gets a rebrand and a fresh v1.0.0.0 general release on GitHub.

    • Digital Mobile Radio Market Size to Hit USD 16.90 Billion by 2032 — MichiganOne DMR Tech Net — An industry market report pegs U.S. DMR growth at a 12.81% CAGR through 2032, largely driven by public-safety adoption rather than the hobby side.

    • Travel Internet CW — With Varying Frequency – Amateur Radio Ponderings — A cautionary field report: internet CW over shipboard wifi via a vBand adapter proved unusably laggy, and a backup Vail Adapter hit its own snag mid-trip.

    Gear, Builds & Reviews

    POTA & SOTA Field Reports

    Shortwave & Listening

    DX, Contests, Satellites & Awards

    Podcasts, Community & Events

    Advocacy, Licensing & Growing the Hobby

    Software & Apps Roundup

    12. QRT: End Transmission

    Booking it

    I finally finished editing the 17 chapters in my book on conservation district management and governance. The first draft of the content happened swiftly back in May. Then I invited some experts to review the draft chapters. Now that the review phase is over, I’ve been trying to make final edits. Editing of chapters 1 through 9 went smoothly. Then life got very busy and I set it aside for a week…then two weeks…then two months. This past weekend, I pulled it up and got through editing the remain chapters, and then sent the manuscript to the publisher. I’m sure I will have another round (or two) of edits coming up, but the core content is complete and good.

    “Writing a book” is far more complicated than I thought it would be. I thought writing would be the hardest part, but what I discovered is that when you care deeply about a topic and have solid life experience in it, the book almost writes itself. I spent months crafting a very detailed outline and that proved to be the turning point for the manuscript, allowing me to get started and stay on track. So what was difficult? All the other steps that come with it, like finding a publisher, selecting graphics, choosing a format, hiring a service to convert it for e-book publication, and more. As I travel this road, I’m learning a lot.

    Along the way, I realized that a good purpose-built tool for managers to keep regular short notes on employee performance just wasn’t available. A diary-like approach can be very helpful for capturing such notes, and reviewing that history is invaluable when it comes time for performance reviews and implementing other employment-related actions. But finding nothing like that, I made one. It’s simple and rather austere, but it does the job. With a few Python commands, you can turn it into an EXE file to run on Windows or an APP file for macOS. Find it on GitHub.

    I could have made a template for something like this in Notion, but then if someone used the template, their data wouldn’t be held locally. I prefer to be in 100% control of employee information at all times.

    Coding

    I also had some WordPress coding fun, creating a plugin that converts a text-based schedule of meetings to an online display. Some of the text descriptions are rather complicated, e.g.:

    The [fill in the blank] Board meetings are on the second Wednesday of October thru May. Meetings in September, October, March, April, and May are at 7 p.m. Meetings in November, December, January, and February are at 6:00 p.m. Meetings are in the US Post Office Building Conference Room.

    I built a parser to extract the key pieces and convert the data into a CSV file, then rendered the CSV in a monthly calendar format, with a list-based schedule below the calendar. When meeting dates or locations change, I simply download the CSV, update it, and upload it back to the server. I also added the ability to temporarily mark a meeting “canceled” without going through the whole CSV download-and-upload sequence.

    All that is built into a custom WordPress plugin that produces a shortcode for use on any page on the website. It’s working great.

    And then, since I was on a roll writing plugins, I wrote one to convert my 518-row spreadsheet of high school classmates into a database maintained on the class website. It has two roles: data admins and data reviewers/approvers. I included a real change log that allows changes to be rolled back. It renders output with shortcodes to display a full class list, our missing classmates, and classmates who have walked on before us. Fun little project.

    That should do it for me for a week or two with WordPress plugins!

    Home

    I’m not really a big fan of tomatoes, but I make an exception for home grown tomatoes harvested on a sunny day at the peak of ripeness. Since I’m the only one who eats them, I have one plant growing in a pot on the deck. Unfortunately, a chipmunk (we named it Chippie) has decided it likes my tomatoes, and it is much faster to harvest them than I am! To try to protect them, I’ve covered the plant — ripening tomatoes and all — with a net. I left the net loose on the bottom the first day and the chipmunk got in and decimated a few almost-ripe tomatoes. The net is now tied tight, and I’m hoping it keeps Chippie out so I’ll get to enjoy the fruits of my own labor soon!

    And speaking of home, my childhood home may, or may not, have been affected by the wildfires that have destroyed parts of Spokane, Washington. I wish I knew the status of the old neighborhood as I have many great memories of growing up there. I’m sure I’ll try to make a road trip this fall just to reassure myself that all is well with the old house in northwest Spokane.

    Wildfire has been an active force on Pacific Northwest landscapes, particularly east of the north-south Cascade Mountain range:

    Source: Washington Large Fires 1973-2025

    EtherHam website down (but back up late Thursday)

    Thursday morning dawned with a different kind of tech problem: a message from the EtherHam web hosting company!

    We’re currently responding to an emergency caused by a power outage at our Phoenix datacenter…undergoing emergency maintenance…experiencing network issues. Websites may be slow, unavailable, or return 503 errors. Hosting panel access may also be affected.

    Starting my day with a web outage is always a bit unsettling. At least it wasn’t something I caused (and yes, that has happened before, more than once).

    As Thursday draws to a close, resolution is in sight, but it still hasn’t happened. By Friday morning, the EtherHam.com website should be is back online.

    73, and remember to touch a radio every day!

  • Tom Salzer KJ7TRandom Wire 194: MeshCore, LoRa APRS, and more​Random Wire℠

    Tom Salzer KJ7TRandom Wire 194: MeshCore, LoRa APRS, and more​Random Wire℠

    Running ASL on Debian 13? Time to Update

    Here’s the headline: New Debian 13 “Trixie” Kernel Security Update Fixes 68 Vulnerabilities. The takeaway: If you’re running AllStarLink (ASL) on Debian 13, it’s time to update.

    1. QRV: Are You Ready?

    Welcome to Random Wire issue 194. Sometime in the past week, subscriber numbers hit 2,300…and kept climbing. This was a surprise because a few dozen subscribers ended their subscriptions last week, too.

    This week, I got my MeshCore repeater functioning. The problem was a simple on-off switch I failed to see when I put the repeater into service the first time.

    I also got a T-Echo (not the newer Plus version) configured as a LoRa APRS Tracker. It is communicating with my LoRa APRS igate/digipeater in the garage.

    2. New on EtherHam

    • Building a MeshCore Node — Part 2: The Repeater That Should Have Been Easy — Part 1 ended with a MeshCore repeater configured in ten minutes and beaconing right on schedule — a clean win, or so it seemed. Part 2 is the two weeks that followed. I encountered a debugging tool that was quietly resetting the very device I was troubleshooting, my antenna’s blind spot, a paywalled feature with a free workaround that didn’t actually work, and a repeater that went dark for five days over something hiding in plain sight the whole time. By the end, the hardware and firmware check out clean. What doesn’t check out, it turns out, is the ten miles of Pacific Northwest terrain standing between me and my nearest MeshCore neighbor.

    • LoRa APRS: Part 2 — LoRa APRS Tracker with a T-Echo — A brand-new LilyGo T-Echo goes dark after a routine firmware flash — no display update, a red LED blinking like an alarm, and every obvious fix leading nowhere. What follows is a genuine debugging rabbit hole: a Windows error that’s secretly good news, a bootloader chase that turns out to be a red herring, an independent firmware swap that finally proves the hardware was fine all along, and a BLE pairing quirk that ends up eating more time than everything else combined. If you’ve ever stared at a “bricked” board and had to figure out which symptoms were real and which were noise, this is that story, from first red flag to a live beacon on aprs.fi.

    • Weekly Report: August 6, 2026 — Catch up on band conditions, digital radio news, and the Groups.io digest.

    3. My Talk2Me Radio is Working Well

    My little Talk2Me PoC (push-to-talk over cellular) radio is working quite nicely. Last Saturday, I had a long drive to a high school class reunion. Unfortunately, that drive coincided with Saturday’s weekly M17 net. The M17 net is always interesting and I learn a lot every time I tune in.

    Talk2Me radio in hand

    Talk2Me radio in hand

    To the rescue: my Talk2Me radio. I already had it set to listen to America’s Kansas City Wide network using Hamlink PoC (programmed into the radio by the vendor). So while driving at 60 MPH toward Tacoma, Washington, I turned it on, turned up the volume a couple of notches, and slipped it into the chest pocket of my shirt. I listened to the complete net during the drive and even checked in from the pickup truck.

    I usually pick up the M17 net at home over my hotspot, or with BlueDV on my laptop, or with my M17 radio and an M17 hotspot. Before the Talk2Me radio, I could not get KC Wide over RF while I’m driving in the Seattle-Tacoma area. Now I can listen in and participate, thanks to my Talk2Me STANDARD PLUS radio.

    Honestly, I’m quite impressed. Because of this fabulous little radio, I was able to enjoy one of my favorite nets while I traveled to my reunion. The radio? It. Just. Worked. Isn’t that what we really want? For our devices to just work? This one does.

    4. My MeshCore Repeater Made the Map

    I finally got my MeshCore repeater working. I don’t know why I so often get a product without any instructions, but in this case, there was supposed to be a card inside the box…and there wasn’t. So I experimented for days, trying different things. Finally, I put my magnifying visor on and took a careful look at the boards inside, only to discover an on-off switch! It was a small little slider, hiding from my unmagnified view.

    After sliding it to the on position and charging the 18650 battery, I put the repeater outside on top of the gutter. (By this time, I had been up and down the ladder at least a dozen times to place/retrieve the repeater on the roof. Testing on the gutter was a lot easier and safer than climbing up on the roof over and over.) And it worked. It beaconed on startup, but more importantly, it beaconed regularly after that.

    About a day later, it showed up on the MeshCore map:

    I’m still getting to know how this all works. I can’t reach other stations directly with my handheld device (T-Deck Plus), which is why I put up a repeater. Currently, my local MeshCore chain has three pieces: a repeater, a relay, and an app. The PeakMesh repeater is on the roof. A LilyGo T-Echo Plus at 910MHz with Bluetooth serves as a relay between the repeater and my phone. The MeshCore app is on my Android phone.

    I also have a LilyGo T-Deck Plus at 910MHz with internal antenna that is a portable, handheld device. It isn’t a necessary part of my MeshCore chain.

    If you happen to be using a MeshCore device, try adding the #etherham channel and pushing a message my way. That would be fun to try.

    5. My LoRa APRS iGate/Digi Works

    It works! The LoRa APRS igate/digipeater I installed in the garage actually works. The range? Minuscule, but more on that in a moment.

    I bought a second LilyGo T-Deck Plus on 433MHz and configured it as a LoRa APRS tracker. Then I went for a drive. My igate/digi (KJ7T-2) picked up the mobile tracker (KJ7T-3) about 1/8 mile from the digi. It works.

    But it only works for a short distance. The small external antenna on the T-Deck Plus is insufficient for much range when the igate/digi is located in a basin…and that is what a lake is: a topographic low filled with water. I’m surrounded by hills so that tiny antenna doesn’t stand much of a chance of getting a signal out.

    You can actually see the signal strength (RSSI = Received Signal Strength Indicator) drop off as I drove away from my igate/digi (KJ7T-2) yesterday morning.

    SNR (signal-to-noise ratio, in dB) is arguably the more meaningful number here. It describes how far above the noise floor the signal actually was, which is what determines whether the receiver can hear it well enough to decode it at all.

    Looking at the photo, the oldest is at the bottom of the list of three exchanges. The signal went from -61 RSSI/SNR 7 (strong, near the start of the drive) down to -107/-5 and then to -117/-14 as I drove farther away, right before it dropped out entirely around 1/3 mile distant.

    Here’s something worth noting: successfully decoding at -14 dB SNR is a real demonstration of LoRa’s advantage over conventional radio. FM APRS generally needs a positive SNR to decode anything — LoRa’s chirp spread-spectrum modulation (especially at SF12, which you’re running) has enough processing gain to pull a signal out well below the noise floor. That last successful frame wasn’t a fluke; it’s LoRa working as designed, right up until the combination of distance and terrain finally buried it.

    I’m considering putting up the dual-band dipole antenna I have on order (note: ordered more than a month ago and my emails to the company are bouncing!) on a pole outside the garage. Maybe I can try a diplexer and run the LightAPRS Gateway on the VHF dipole and the LoRa APRS igate/digipeater on the UHF dipole. Two devices, one feedline, a diplexer, and the dual-band antenna. Just another 10-15 feet in clear air and I’ll bet I can reach at least a mile away on LoRa.

    As noted in the New on EtherHam section above, I configured the T-Echo (not the Plus) as a LoRa APRS tracker. The advantage of the T-Echo is long battery life. It’s a small device so I can easily tuck it out of the way inside the pickup truck cab.

    6. AI: Trying DeepSeek

    I use Claude. I use ChatGPT. At the suggestion of a friend, I’ve started using Gemini a bit more. And now I’m exploring DeepSeek, which I’m finding to be very fast…but also more shallow than those other engines. Whether it will stand up to Claude when it comes to coding, I don’t yet know, but I doubt it. I’ve added DeepSeek to my Open Notebook instance running on my Proxmox server.

    One thing to be aware of with DeepSeek: it stores API data on servers in China and its terms permit training on your inputs by default. I don’t plan to use it for anything important, but if you handle sensitive information, you’ll want to bear this in mind if you choose to use DeepSeek.

    Me? I still lean toward Claude for the things I do.

    7. Short Stack from the Interwebs

    Pulled from the aggregated feeds on EtherHam (etherham.com/feeds/), items from July 30–August 5. This Short Stack turned into a Long Stack!

    SDR & Signal Hacking

    Digital Modes & Data

    Gear, Builds & Reviews

    POTA, SOTA & Field Ops

    Shortwave & Listening

    Podcasts & Community

    Linux, Homelab & Self-Hosting

    Also Noted (Tech)

    8. QRT: End Transmission

    Radio history

    I do enjoy reading radio history, and The Discovery of Radio Waves was an article I found very interesting.

    “When the concept of electromagnetic waves was first proposed around 1864, it was met with great skepticism…It took several decades for a handful of dedicated persons — infatuated with the mysteries of electricity and magnetism — to finally put the theory on a solid footing.”

    Just proves to me once again that we all stand on the good work of those who came before us.

    Claude and CSS debugging

    As I was debugging a CSS load problem (the problem being a specific file was not loading) on a website, I started to use a tried-and-true method: turn off plugins one by one, test, re-enable, move to the next plugin. Well, this site has 67 plugins and that takes an awfully long time.

    And then I thought: I wonder if Claude can help me with this? Using the Sonnet model, Claude had trouble understanding what I wanted and kept trying to hand it back to me. So I switched to the Opus 5 model and was delighted when — after I gave it permission — it proceeded to walk through all 67 plugins and test them, without me having to intervene.

    Claude found one plugin that no longer parsed CSS after the plugin was recently updated. We rolled that back to a previous version, resolving the problem. That saved me hours of digging.

    LoRa radio

    I’m enjoying learning about this technology. New? Not…but it feels new to me, simply because while I’ve dabbled my toes in the LoRa waters, I haven’t taken a dive like in the past several weeks. It’s interesting stuff, especially how it is able to send and receive data way below the noise floor.

    73, and remember to touch a radio every day!