Random Wire Review: Issue 131

May 16, 2025: A medical issue may interrupt the Random Wire a bit. In issue 131: DroidStar web transceiver mode; new DroidStar build available; a few thoughts about M17; and more.

Medical issue interrupts regular publication

As Issue 130 was ramping up to a scheduled publication, my spouse had an unexpected medical event. She was taken by air ambulance to a superb medical facility in Seattle, Washington. I am typing this while sitting in her room in the critical care unit. We don’t yet know the cause or the prognosis. We are both taking this moment to moment, riding the waves life is throwing at us as best we can. I may be writing less for a while…or I may keep up with writing as a helpful distraction. I have minimal radio gear with me, but that doesn’t mean I’m not thinking about amateur radio.

Issue 131 is dated for Friday, May 16, 2025, but I’m publishing it on Thursday because we’re not sure what our day is going to look like.

And this will sound like a strange leap from the previous paragraph, but my new laptop is a blessing. The battery life is astounding. That makes a huge difference when I’m trying to write, respond to emails, and share information on our socials, all while I am in various parts of the hospital. I don’t have to take the power adapter with me to those places because the battery lasts so long. I know that a long battery life is a small thing, but in the face of everything going on in our life right now, it amounts to one less thing I need to remember.

DroidStar in web transceiver mode

One advantage of DroidStar is that you can use your computer for making connections. I travel a lot, so this is another way I can use what I already take with me (laptop and headset) for clear audio in both directions.

You can also work the world without a radio. While I know that many people don’t consider this to be “real ham radio,” I also know that this capability benefits many radio amateurs who are unable to install stations that would allow them this same capability. You may know an amateur radio operator who lives in an apartment or in an assisted living facility or even in a neighborhood with strict restrictions on antennas. Internet-connected radio can help those amateurs remain active in our hobby. I am squarely in “the more the merrier” camp on this.

While sitting in the hospital, I was able to spend more time with DroidStar. When I had previously tried it in web transceiver (WT) mode with AllStarLink, it didn’t work for me. Knowing that I was pretty tired when I tried it, I later wondered if maybe I had fumble-fingered the password. When I was rested, I copy-and-pasted the AllStarLink password in DroidStar. That did the trick. I connected from Seattle to my node 578493 in Portland, Oregon. This worked perfectly well.

If you’d like to try this, try using my “node in the cloud” 57945 on port 4569. Below is how I entered the host information in DroidStar for node 57945 in web transceiver mode. I can vouch that this works (your AllStarLink password and other settings entered in DroidStar must be correct, of course):

IAX 57945 wt 4569 allstar-public allstar

This is set in the Hosts screen in DroidStar:

When I make that connection, AllScan shows it as an Echolink connection to node 57945:

The DroidStar build I’m using comes from PizzaNBeer.net at http://pizzanbeer.net/droidstar/ and I’m using the win-x64.exe version.

With so many modes available through DroidStar, hours and hours of listening to nets and talking with other amateurs is possible, all without a radio, using gear you probably already have. And the cost for DroidStar? Zero. That is amazing.

Updated DroidStar available

By the way, I saw in the DroidStar group on groups.io that a new build of DroidStar is available at http://pizzanbeer.net/. The new build is dated May 13, 2025.

I downloaded the new win-x64.exe version and it runs fine on my Windows 11 laptop. I note that it imported my settings from my previous installation so upgrading amounted to downloading the .EXE file and running it. Boom, just like that, my settings were still there. That is my kind of upgrade!

M17 protocol: feedback and ideas

About a week ago, I put a new M17 reflector online. The M17-PNW reflector is aimed at the M17 community in the Pacific Northwest, USA, but there aren’t any geographic restrictions on who can use it. If I see abuse, I’ll block it, but I doubt this will be an issue.

Feedback

So far, feedback from folks who have tested the M17-PNW reflector has been: (1) it doesn’t work for me, and (2) do we really need another M17 reflector?

If your M17 client hasn’t updated recently, it won’t have the correct host information. The answer to “it doesn’t work for me” is to update your client, forcing the latest host information to update. Alternatively, you can simply specify the M17-PNW details in your client’s Hosts settings. For example, in DroidStar, the M17-PNW reflector settings are shown below:

A possible complication is that registrations are shifting to DVREF, so if a reflector owner hasn’t changed their registration, their reflector may not show up in the updated list. If you use Yaesu System Fusion and WIRES-X, this also applies.

The other feedback about “do we really need another M17 reflector” is harder to answer. Do we need more than one reflector? I suppose the answer is: not until M17 usage takes off and/or that one reflector goes offline. I submit, though, that in the spirit of experimentation (which is central to our amateur radio hobby), that this isn’t the right question. It ought to be: how many reflectors can the M17 community use, and how do we make that system more usable and robust?

Ideas for improving M17 for users

I have two thoughts on improvements to the array of M17 reflectors. The first is one that I posted to the M17 Users group on groups.io, where I asked whether a parrot service would be helpful to M17 users. I think it would be. And it turns out that this functionality seems to exist in the software. More on this as it develops (fingers crossed on this).

The other thought is about helping M17 users find activity among the various reflectors. AllScan has this capability for AllStarLink nodes. With AllScan, you create a list of favorite nodes and then AllScan shows you which of those nodes has been recently active. That makes it much easier to find active nets. I need to dig in to learn if there is a way to poll a list of M17 reflectors to check on recent activity. Having something similar to AllScan, but for M17, would help users utilize M17 reflectors more.

Supporting the Random Wire is voluntary

The topics I cover in this newsletter do tend to be somewhat random, hence the name: the Random Wire. Surprisingly, trying different things in amateur radio does cost money. If you get value from the Random Wire newsletter, please consider providing support. The Support page has all the details.

Whether or not you help support this work, I appreciate you taking the time to share this amateur radio journey with me. The hobby is made better when people like you subscribe, comment, and help support our community of radio amateurs. Thank you.

I asked CoPilot how to build AllStarLink node

My new computer features Microsoft CoPilot. I wondered if CoPilot could answer amateur radio questions, so I asked it to “explain the sequential steps needed to build a radio-less allstarlink node with a raspberry pi, and include links to information sources.” Here’s the answer, unedited save for minor formatting.

CoPilot explains how to build a radio-less AllStarLink node

CoPilot’s answer is shown in italics.

Building a radio-less AllStarLink node with a Raspberry Pi is a great way to connect to the AllStar network without needing a physical radio. Here’s a step-by-step guide:

1. Gather Your Components

You'll need:

• Raspberry Pi (Pi 3 or newer recommended)

• MicroSD card (at least 8GB)

• USB sound card (CM108-based recommended)

• Headset with microphone (USB or analog)

• Ethernet or WiFi connection

• Power supply for the Raspberry Pi

2. Install AllStarLink Software

• Download the AllStarLink image for Raspberry Pi.

• Flash the image onto the microSD card using software like Balena Etcher.

• Insert the microSD card into the Raspberry Pi and boot it up.

3. Configure the Node

• Access the Raspberry Pi via SSH.

• Set up AllStarLink by editing configuration files (rpt.conf, iax.conf, etc.).

• Assign a node number from AllStarLink.

• Configure audio settings to work with your USB sound card.

4. Test and Optimize

• Connect to a test node and verify audio quality.

• Adjust microphone gain and speaker levels.

• Ensure network settings allow proper connectivity.

For a detailed step-by-step guide, check out resources like this one or this tutorial. Let me know if you need help with any specific part!

And that ends the step-by-step instructions from CoPilot. You know, they aren’t bad. The steps are light on details but as an overall plan for making your own radio-less AllStarLink node, this isn’t bad.

The two links at the end of the guidance are a bit dated. One is by David Gleason NR9V in 2023. AllStarLink has since evolved. The other link is also older but the details presented are excellent. While the sources referenced are out of date, they aren’t very out of date and thus they provide solid, useful information.

However, when I enabled the “Think Deeper” capability of CoPilot, I got a better answer. I asked the same question and got back more detailed information.

Same question with “Think Deeper”

CoPilot’s answer is shown in italics:

Below is a detailed, step-by-step guide for building a radio‑less AllStarLink node using a Raspberry Pi. Each step is designed to help you progress through the process, from gathering the hardware to testing your finished node. I've also included links to several information sources for additional context and troubleshooting tips.

1. Gather Your Hardware

• Raspberry Pi: A model with reliable networking is recommended (e.g., Raspberry Pi 3, 4, or Zero 2W).

• MicroSD Card: At least 8 GB (class 10 recommended) to hold the operating system and AllStar software.

• USB Sound Card: A CM108/CM119-based device is commonly used for its plug-and-play audio capabilities.

• Audio Devices: A good quality microphone and speaker (or headphones) to handle audio input and output.

• Power Supply & Cables: A proper Raspberry Pi power supply and any necessary cables for networking (Ethernet or Wi-Fi).

Understanding your hardware requirements is critical to ensure stable performance once online. For more insights on setting up a radio‑less node, you can check out the detailed AllScan Guide and related posts on the AllStarLink Community Forum.

2. Download the AllStarLink (or HamVOIP) Software Image

There are pre-built images available that bundle both a Linux-based operating system and the AllStar (or HamVOIP) software needed to run the node. Here’s how to proceed:

• Visit a trusted guide (such as this AllStar Setup article) to download the recommended image file.

• The image is ready to flash onto your microSD card, saving you the trouble of manually installing dependencies.

This step ensures you’re starting with a configuration tailored for radio‑less operation.

3. Flash the Image to Your MicroSD Card

• Use a tool like Balena Etcher or Win32 Disk Imager to write the downloaded image onto your microSD card.

• Follow the tool’s instructions carefully and verify that the flashing process completes without errors.

This process converts your microSD card into a bootable disk that contains all the necessary software and configurations.

4. Boot Up the Raspberry Pi

• Insert the flashed microSD card into the Raspberry Pi.

• Power on the Pi—if you have a display and keyboard connected, you can follow the on-screen instructions; otherwise, you can connect remotely via SSH over your network (using clients like PuTTY or MobaXterm).

• Make sure your network connection (whether via Ethernet or Wi-Fi) is active so that you can later access the node remotely.

Booting into the preconfigured environment saves you additional setup time while allowing access for further adjustments.

5. Perform the Initial Configuration

Once online, you’ll need to do some initial configurations:

• SSH/Local Terminal: Log into the Raspberry Pi.

• Password and Network Settings: Change default passwords and verify your network configuration.

• Node Settings: Run the initial setup script provided by the image package, which will help you set:

  • The node number.

  • Regional settings.

  • Internet connectivity settings.

These adjustments are crucial to ensure that your node can securely connect to the AllStar network and be managed remotely.

6. Configure AllStarLink Node Files

There are several configuration files you must edit to tailor your node’s operation:

• rpt.conf: This is the core configuration file where you set your node’s identity, call signs, and connection parameters.

• manager.conf: Configure remote management settings, including secure access protocols.

• httpd.conf: (If applicable) Enable and adjust settings for the web-based control interface (often linked to the Supermon interface).

Editing these files (typically found in a directory like /etc/allstar/ or a similar path depending on your image) ensures that your node communicates properly with other nodes in the network.

7. Connect and Configure Your USB Sound Card

• Plug In the Device: Attach your USB sound card to one of the Raspberry Pi’s USB ports.

• Audio Device Setup: Connect your microphone and speaker to the sound card.

• Test Audio Input/Output: Use utilities like alsamixer or other audio-testing commands to fine-tune the levels. Adjust the configuration files (or in-line configuration scripts) that come with the AllStar software for optimal audio performance.

Ensuring a properly configured audio chain is essential since the node’s purpose is to provide clear voice transmission without traditional radio gear.

8. Test the Node and Network Connections

• Activate the Service: Start the AllStar service (often using a command like sudo systemctl start allstar or a custom script from the image).

• Remote Testing: Use tools such as the Node Remote App or access the Supermon web interface to try connecting to your node.

• Perform Audio Tests: Make test calls between nodes to check for clarity, volume levels, and any latency issues.

• Review Logs: Check log files (usually in /var/log/) for any errors or warnings—this will help with troubleshooting.

These tests ensure that your node is fully operational and capable of joining the network properly.

9. Troubleshoot and Finalize the Setup

• Error Resolution: If you detect any audio or connectivity issues, refer back to configuration files and online documentation for possible fixes.

• Community Support: Engage with the AllStarLink Community Forum where other makers share common pitfalls and solutions.

• Documentation: It’s a good idea to screenshot your configurations or maintain logs as you fine-tune your setup. This documentation can be invaluable if you need help later.

Finalizing the setup involves ensuring that all settings are optimized, and that your node will reliably reconnect after reboots or power cycles.

Additional Resources

• AllScan Guide for Radioless Nodes: Detailed technical explanations and hardware considerations. AllScan Radioless Node Guide

• AllStar Setup Tutorial: A step-by-step walkthrough tailored to building radio‑less nodes. AllStar Setup - Build Your Own Radioless Node

• YouTube Walkthrough: A visual guide that might help clarify each step in the process. YouTube Tutorial on Radio-less AllStar Nodes

This comprehensive guide should provide a solid framework to build your radio‑less AllStarLink node with a Raspberry Pi. Each step is designed with both beginners and those with prior experience in mind, ensuring you have the tools and knowledge to get connected. Enjoy the process and make sure to engage with the community as you fine-tune your setup—there’s always more to learn and adjust in innovative communication systems!

Wow! That is a lot more thorough!

I think my takeaway from the times I’ve experimented with AI is simply this: if you are interested, go ahead and try it. It might prove helpful. The summaries that CoPilot provided were sufficient to help most radio amateurs make a plan to build an AllStar node. Just be sure you use your “radio common sense” (that is, don’t take everything the AI tells you as gospel) and I think you’ll be fine.

Headphones

This is a maybe-it-is-related-to-amateur-radio thing. I bought a pair of bone conduction headphones. When these first came out years ago, I bought a pair and found them to be truly awful, with muddy sound and painful vibrations. These new phones are bright, clear, and comfortable!

SHOKZ OpenRun - Open-Ear Bluetooth Bone Conduction Sport Headphones, Sweat Resistant Wireless Earphones for Workouts and Running, Built-in Mic, with Hair Band, Black

Bone conduction headphones are an acquired taste. These I find to be comfortable and the audio quality is good for open air headphones. I wanted a pair of earbuds or headphones I could use in the hospital that would let me maintain good situational awareness. I have noise-cancelling buds and phones with “pass through” technology, but they don’t really pass everything that is happening around you. They filter even when they try not to. These open-air headphones do let everything in.

Even as they allow outside sounds to come in without any filtering, the audio I’m hearing from Amazon Music is pretty darn good. Right now, I’m listening to Harriet, a British singer with the range and styling of Karen Carpenter. Her 2024 album, Trying To Get The Feeling Again, is like hearing Karen again. The sound feels immersive through these headphones. Because I can also monitor other sounds around me, I’m sitting here with my eyes closed, simply enjoying Harriet’s singing.

There is a microphone in these headphones. On M17 through DroidStar it seems very quiet, where quiet means not very good at picking up my voice. (I note it works okay with Zoom but is still a bit quieter than I expected.) I also tested with the AllStar enhanced parrot at node 55553 which said my audio was “pretty good.” It seemed a bit quiet to me but it was readable. There are clicks in the audio, and that could come from a variety of sources. I’m in a hospital, so this is definitely an RF-rich environment!

The takeaway for me is these open-air headphones sound pretty good for listening. They aren’t my first choice for delivering clear audio when I’m on a phone call or Zoom video conference.

As you might imagine, living this past week in a hospital room has not been particularly conducive to amateur radio experimentation. I brought my TD-H3 handie talkie with me so I could easily listen into the Puget Sound Repeater Group nets. Unfortunately, that’s hard to do while my spouse is resting during her recovery. Nevertheless, I’ve listened in on a few nets.

I’ve also put my earbuds in and listened to a few Ham Radio Workbench podcasts. Hearing the HRWB team is a wonderful way to spend some of my hospital time. I think several of them are in Dayton, Ohio now for Hamvention. I wish I could be there!

73 to all and remember to touch a radio every day!

https://www.qrz.com/db/kj7t