Ohio Section Journal – The Technical Coordinator – November 2024 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Tom – WB8LCD and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Tom has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the Ohio section will need to use the mailing list link above.  Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).

  • Go to www.arrl.org and click the Login button.
  • Login
  • When logged in successfully, it will say “Hello <Name>” in place of the Login button where <Name> is your name.  Click your Name.  This will take you to the “My Account” page.
  • On the left hand side, under the “Communication” heading (second from the bottom), click Opt In/Out
  • To the right of the “Opt In/Out” heading, click Edit
  • Check the box next to “Division and Section News.”  If it is already checked, you are already receiving the Ohio Section Journal.
  • Click Save
  • There should now be a green check mark next to “Division and Section News.”  You’re all set!

Now without further ado…


Read the full edition at:

Archive index: https://arrl-ohio.org/ohio-section-newsletter/


THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

Hey gang,

It’s been nearly ten years since I first registered an AllStar Link node and what a ride it has been. From political issues, to software and network forks, and license violations. Through all of it, I’ve been fascinated with the potential options and flexibility of Asterisk, a SMB (small/medium business) phone system, being turned into a multi-function amateur radio system. It suffered from a lack of the 3-T’s: time, talent, and treasure. Finding time to work on the project with all their other responsibilities. Talent – developers, system administrators, coordinators with good working knowledge of best-practices getting things up and running and sustaining that level of effort. Treasure – donations to help the open-source project with costs associated with running a network and improving integrations, upgrades. With the release of “ASL3,” AllStar Link has made a huge leap forward with help from one of Ohio’s Technical Specialists.

AllStar Link, often called AllStar or ASL, is an Amateur Radio linking system on a Linux computer running on top of the open-source PBX telephone switching platform called Asterisk. An AllStar module called app_rpt turns Asterisk into a powerful, full featured, Ham Radio repeater controller and linking package. It is theoretically capable of controlling hundreds of nodes at a time. Jim Dixon – WB6NIL (SK), developed app_rpt and is considered the father of AllStar.

Like other analog Voice over IP systems (VoIP), such as EchoLink or IRLP, AllStar Link links radio systems together. AllStar is flexible enough to link other infrastructures together as well. I, for example, have a connection to a VoIP phone provider. This allows the ability to add autopatch and reverse-autopatch to my node. For the younger hams, this is the ability to make phone calls from your radio when you don’t have cell phone coverage. Or don’t want a cell phone. It offers the ability to make emergency calls or issue node control commands over the phone. Though my node barely covers the block I live on, accomplishing this was more of a “can I do this?” exercise.

AllStar nodes can be:

  • Repeater: full duplex node and user functions accessed by DTMF or webpage (when given access)
  • Simplex node: “hotspot” half-duplex node, also with user functions available by DTMF
  • Remote Base node: a half-duplex, frequency agile HF, VHF, UHF remote base, or connected to a repeater controller. Will not respond to DTMF on the RF side of the remote link.
  • Radioless node: without any RF hardware. Uses a mic and headphones, speaker, or Bluetooth. Can also be a “Hub node,” a common connecting point (similar to Conference or Reflector) with plenty of Internet bandwidth to handle many connections at one time.

Nodes can be public, private, or a combination of both. A public node would be accessible by any other public node on the AllStar network. These nodes require Internet access to the AllStar network for the phonebook of other public nodes. Private nodes can be limited to select users or on a completely private network. Great for connecting repeaters at different sites over a mesh network, point-to-point link, limited bandwidth, VPN, or even over the public Internet.

Allmon v3 running on AllStar Link node 42441

Getting AllStar Link to work on modern operating systems was painful especially if you couldn’t necessarily control the operating system, in the cloud for example. System design could have been better. The system that provides routing and mixing of audio streams between Asterisk and physical systems, DAHDI, always seemed to cause problems on newer Linux kernels and operating systems. The full list of AllStar public nodes is downloaded every 10 minutes by each and every node on the network.

This drove me nuts one evening. My home node, 42441, just came back online after being offline for a couple days. Having just booted the node, wanted to connect to a remote node, 2000 for example. It could take 10 to 15 minutes (on average) before that link could be established. 42441 needs to successfully register with the AllStar Link servers notifying them it is online. Once registered, both nodes (42441 & 2000) need to have downloaded the public node list and have each other’s information available before the two can connect. On average, this cycle took about 15 minutes. I had no idea this was a thing until I encountered this scenario.

Those are just a couple issues with legacy AllStar. Technical Specialist Jason – N8EI published news about AllStar Link version 3 being released in the August edition of the Ohio Section Journal. He decided to help the AllStar project by providing a newer, modern, web interface called Allmon v3. Jason became more involved as the project received a grant from ARDC, a programmer was hired, and a community of hams stepped up to support the project. These ARDC grants are a result of selling one-fourth of network 44.

Shortly after ASL v3 was released, my QTH node died. It appeared to be the Raspberry Pi itself because it can’t seem to boot from any SD card. I was running the downloaded Raspberry Pi ASL v2 image which was quite outdated. I kludged it together by manually compiling the latest ASL v2 code from GitHub. Armed with a replacement Pi, I started to look at the newly released version of ASL 3 and I am quite impressed with the modernization.

Version 3 improvements start with using the standard Raspberry Pi Imager allowing configuration of the image, including user name, time zone, and Wi-Fi settings, to be customized when written to the SD card. The base OS is Debian 12, a currently supported operating system. Asterisk was pushed from version 1.4 (released in 2006, end-of-life in 2012) to Asterisk 20.9.3. One new pre-installed app includes Cockpit, a web-based administration tool for Linux. Cockpit can view logs, configure network settings, update the system, and handle SSH sessions – all through the web browser. In addition, Asterisk no longer runs as root which increases security in case of compromise through Asterisk.

Configuration files from previous ASL versions cannot be restored because of changes in upgrading to version 20. One reason is 16 years of Asterisk and changes in that time. I document all my node config changes which made it easier to identify changes needed when merging them into the new configuration. It wasn’t quick but what migration is? Another change is node lookup can now use DNS which affords instant connections for recently powered on nodes. No more waiting before links can be established.

Node configuration is largely done through asl-menu, though, obviously, specific owner configurations need to be added manually. app_rpt supports templates. This means node configs can import a template with common settings. Specific settings can be overridden from the template by setting these values at the node level. This is useful for devices with two or more nodes having the same or similar configuration settings, such as a hub node. This drastically cuts down on the lines needed in rpt.conf, file size, and sanity of finding where you are making changes in a large configuration.

Cockpit on AllStar 3 node 42441

Documentation notes the EchoLink module has been rewritten for stability and now include features such as chat, timeout timer, and doubling prevention. I’ve used the EchoLink module but haven’t checked for issues I knew existed previously verifying they’ve been resolved.

All these changes are welcome. I’m finding lingering issues and edge cases. To the project’s credit, they have been diligently working out issues, resolving them in short order, and pushing out frequent updates – faster than any previous version of ASL.

Some of the autopatch issues have been resolved, though my configuration still requires quiet = 1 be added to the autopatch string because some autopatch bugs with half-duplex nodes remain. I also can’t get autopatch working with my provider, voip.ms, using SIP. This was an issue in previous versions too. I’m not sure where the issue lies but the provider recommended configuration is SIP. I can only get IAX to work. I’m not spending a lot of time tracking this down because I don’t see others having the same issue and don’t ever really expect autopatch to be used on my node.

Tuning menu options don’t include rxsquelchdelay or rxaudiodelay for squelch tail elimination in USB Radio. This is being added. I still have to manually add invertptt = no for my URIx and radio configuration, also not present in the tuning menu. This option exists in Simple USB but not USB Radio tuning menus.

Kudos to Jason and the rest of the AllStar Link team for the monumental work that’s been done to modernize the project and the work they continue to do. I’ll reiterate Jason’s pitch for support. Support the project through using ASL and reporting issues. Download the Raspberry Pi image or add the package repo to install ASL on a server or Virtual Machine. Supporting the project financially by donating keeps the system running and supports future improvements.

AllStar Link – https://www.allstarlink.org/
AllStar Link v3 manual – https://allstarlink.github.io/
Community forum/support – https://community.allstarlink.org/
GitHub code repositories – https://github.com/allstarlink

Thanks for reading and 73… de Jeff – K8JTK