Tag Archives: Digital Modes

Ohio Section Journal – The Technical Coordinator – May 2024 edition

May 11, 2024 Jeffrey Kopcak

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:

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

Hey gang,

One thing that has kept me busy this year is work. We’ve been traveling for deployments and other work projects. Pilot sites get someone onsite to make sure the transition goes (relatively) smoothly. In addition, cutovers for other sites and other systems have been occurring off hours – early mornings or late at night. One of the perks of traveling for work is the ability to extend a trip using personal time.

The first trip was an M&A (merger and acquisition) in East Hartford, Connecticut last March. One reason I wanted to extend this trip was because East Hartford is about 15 minutes away from Newington – otherwise known as the location of ARRL HQ.

I like to drive and this was a drive at 9 hours. It ended up being more like 10 or 11 with stops and detours. Extending this trip, partially because of ham radio, and getting to drive means I take a lot more ham radio stuff. I put on music and will switch off listening to VHF & UHF. I have an ICOM IC-2820 radio with a homemade cigarette lighter power cable. Using the cigarette lighter (now called an accessory port) is more than good enough to power the radio especially when listening more than transmitting. Since this wasn’t my car, the install has to be very temporary. Most accessory ports are fused at 10A. That limits me to low or medium transmit power. Low power (5W) draws 4A and medium power (15W) is about 7A (a little less on 2m). No reports of alternator whine either.

I know there are those who make lists of repeaters when traveling. With electronic sources such as RFinder and RepeaterBook, it’s easier more than ever to import repeater data into radio programming software. The Travel search in RepeaterBook makes it even easier by selecting a travel route or highway. A problem with that feature is the repeater owner or a contributor to RB have to tag a repeater as being accessible on or from a particular route. I-80, which I traveled through most of Pennsylvania, only lists 25-2m/440 repeaters end-to-end. I traveled 270 miles of I-80 in PA. That seems low.

Instead, I use band scan memories or scan edge memories. To me, it’s easier than making banks of repeaters for different cities along the way. Scan edges are memories available on most modern radios. Set the start and end frequency and the radio scans frequencies in-between, stopping on any signals received. Once it hits the end frequency, returns back to the start frequency and begins scanning again. These memories are often notated as “xA/xB,” “xL/xU,” or similar memory locations noting beginning and ending frequencies respectively.

The 2820 is capable of dual-band operation with two receive frequencies at one time. On the left side of the radio, I had a scan starting with 144.000 and ending at 148.000, which covers the 2m ham band. On the right side was 440.000 – 450.000 for the 70cm ham band. The “step” setting determines frequency increments. 15.0 kHz step starting on 144.000 will then scan 144.015, 144.030, 144.045, and so on. A step of 5.0 kHz starting on 144.000 will then scan 144.005, 144.010, 144.015, etc. Most 2m ham band repeater plans are 15 kHz and 25 kHz on 440. I stick to those as my step settings.

W1AW digital equipment Rack 1: APRS/D-STAR/HF MARS. Rack 2: Demo. Rack 3: Echolink & Winlink. Rack 4: IRLP

Setting the step to 5 kHz catches more transmissions in cases where a repeater might be coordinated on a non-standard frequency or simplex conversation had on a weird frequency. It does take much longer to scan and the radio will stop on much more interference from the car or other near-by transmitters. Not worth it to me setting such a small step value.

In this day and age, noise will be an issue and the scan will stop frequently. Stopping frequently can be further reduced by turning up the squelch or attenuator, but you’ll miss weaker signals. Some radios have a ‘skip’ (sometimes called “lock-out”) function that will skip over problematic frequencies. I use the radio’s “scan resume conditions” to resume scanning 10-seconds after arriving on a signal. This is nice so I don’t have to keep messing around with the radio while driving. If there is an interesting conversation, it’s one button to stop the scan to remain on that frequency.

Before someone says ‘you should have flown,’ a co-worker did fly out of Cleveland. Since there are no direct flights to Connecticut, he flew from CLE to ORD (Chicago) then onto Connecticut. With layovers and delays, he left the same time I did from Cleveland and arrived only an hour sooner than I did. If I would have cut out my own detours made in New York, probably would have beat him there.

Unfortunately, this was a grueling trip. Driving wasn’t really bad until I got to Scranton, PA, but it was still a lot of driving. We were on site Friday through Tuesday, working 10-to-12-hour days. Didn’t do much operating on the front end of this trip. Once we ate and got back to our rooms, it was time to get some sleep and do it all again the next day. We got it done, though. Left the site Tuesday a little after 2pm and tried to catchup on rest. I planned a ARRL HQ visit the next day, Wednesday, March 20th.

I took a bunch of pictures outside of the towers and arrays. Apparently, they don’t give tours of HQ anymore (except virtually). I was pretty disappointed. When they did give tours, you could see things such as the ARRL Lab, testing equipment, ham radio archives, and outgoing QSL Bureau. Not to be had this time. Headquarters lobby and bookstore were open and the only parts accessible.

On my last visit with the family, by the time we got to the visitor’s station – W1AW, storms were on their way in. I made calls on HF but made zero QSO’s before NJ1Q had to shut down the station. Being one of my first few times on HF was really bummed not to make any QSO’s and learn how things worked. A year after that trip, I got an HF station setup at the home QTH – which my dad had a big hand in setting up.

Studio 3 operating positions. I operated as W1AW from the station at left.

This time was quite different. No storms to worry about. I had over an hour – probably an hour and a half – operating as W1AW in Studio 3 with a Yaesu FTDX9000D, Heil Microphone, and Alpha 9500 amp running about 600 watts. I don’t remember which antenna/array they had be working on. Operated mostly on the upper part of 20 meters, around 14.290. Changed frequencies once or twice to avoid other stations that were coming up out of the noise. Had a great path into Ohio as I worked many stations from the Section. Those in Northeast Ohio informed me I missed the two inches of snow. Dodged that bullet. Unfortunately, didn’t note exactly how many contacts I made. I had 40+ contacts after an hour, probably 50 or so QSOs in total. If you happened to make contact, QSL cards are available direct to the ARRL HQ mailing address.

I had such a good time operating that I stuck around even longer and talked with Joe, NJ1Q – Station Manager and Trustee. Fascinating person to talk to. He had finished testing, fixing, and was packing a portable station for a school contact with the ISS in Colorado. Spoke to him about their digital setup including Winlink station. I’ve previously used W1AW on HF to exchange messages from the home QTH. “It must be working,” said Joe. It sure is. Wish I had their racks of digital equipment in my shack and towers in my backyard. He also gave me some tips for things to try with some issues I am having. A veritable fountain of wisdom.

For being at the visitor’s station, you now receive a certificate for either visiting or operating. Remember to bring a copy of your valid amateur license in order to operate. The certificate was something carried on since the centennial 10 years ago. I didn’t receive one on my last visit. We figured out it had been 11 years (2013) since my last W1AW visit and certificates started just after that.

The remainder of that trip was non-ham radio activities. One of the wide-area linked repeater systems with 10 sites had a pretty bad hum. The owner and some users were trying to track it down. I don’t own a repeater but it is a thankless job.

Snapshot from video I took – near the end of totality, 4/8/2024

Couple weeks later, I was in Waco, TX. Since I was flying, I took the IC-91AD HT with me but didn’t have much time to use it. I take hardly any ham equipment when I fly because I don’t want to deal with TSA.

Waco was in the path of totality for the April 8th Eclipse. I thought about extending the stay but decided against it. Good decision because they had storms. Contacts at the site wanted to see my pictures from Ohio because it turned out to be a crummy day for them. I also heard car rentals were up around $600/day in Dallas.

Speaking of the Eclipse, I took the day off and contributed to HamSCI by transmitting and uploading spots for WSPR. I had to make preparations to get my camera setup and had family coming over. Since I wasn’t seeing many special event stations on the DX Cluster in the morning, left the radio to do WSPR spotting. Maybe HamSCI will be at Dayton/Hamvention and I’ll talk to them about the data gathered from Ham Radio stations.

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – April 2024 edition

March 30, 2024 Jeffrey Kopcak

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

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:

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

Hey gang,

A couple months ago, the ARRL published news regarding the FCC amending Amateur Service rules. This change, which went into effect on December 7, 2023, removed the symbol rate (baud rate) restriction replacing it with a 2.8 kHz bandwidth limit on many HF bands. This change allows for greater flexibility, faster communication speeds, and greater options for digital modes on the low bands. Waivers are no longer needed in times of emergency temporarily granting faster communications such as later PACTOR modes.

Replacing the baud rate restriction with a bandwidth limitation on digital transmissions has brought more activity to the bands. More hams are experimenting with PACTOR. Winlink stations are utilizing the bandwidth to send in even more weekly net check-ins.

With the additional activity, there have been some unintended consequences. Stations are not checking to see if the frequency slice is available before transmitting. Other fly-by-night stations are not minding the volume level delivered to the radio leading to over modulated signals. To be fair, these have been happening for a long time and are not new challenges to efficient digital operators.

The problem with digital operation has gotten so bad the FCC is stepping in and considering a competency test for operating. Passing the test will result in issuance of digital endorsement for existing, valid, Ham Radio licensees. “This initiative will clean up the digital ham bands” according to Polly Ester at the FCC.

The proposed rulemaking will involve candidates completing a written exam – similar to licensing exams given for Technician, General, or Extra. A second portion will involve a lab demonstrating the candidate can operate a station within accepted limits.

Written exam is expected to be taken from a question pool of 255 questions. The randomly selected 25 question multiple choice exam can be taken at any existing VE test session. Lab portion will be administered through FCC contracted testing companies that will be able to accommodate their testing requirements.

Debate was had if the FCC was going to administer the lab on their own or contract that portion out. Prior to the VE program, exams were administered when the FCC came to town. Restarting that program was explored. However, it was decided testing centers will conduct the lab portion.

Lab portion consists of using different software, computers, and radios – demonstrating operating ability to configure popular software applications on Windows, MAC, and Linux machines. Radios by common vendors will be selected at random. Radios could be anything from modern SDR radios to boat anchors – with none of the common connectors for digital operation. Proficiencies demonstrated include: adjusting sound levels from the computer, checking audio and transmit levels using radio meters and indicators, listen and check for other signals nearby, what to do when another station does not check if the segment is clear, selecting power output appropriate for the radio and duty cycle. Finally, operating in a crowded band. Details have not been released by the NCVEC if software simulating these activities will be available for practice.

Licensed operators whom have passed the written and lab portion will receive their digital operating endorsement and can operate digital at legal limit. Operators will be required to re-test every three years to refresh skills and demonstrate proficiency.

Stations without the endorsement will be able to operate digital at a maximum of 5 watts ERP. A second option of 10 watts will be available provided the station pars with a “monitoring” station. The monitoring station provides timestamped screen shots showing the segment on the waterfall which the station was operating. This screenshot of the waterfall and textual output of the segment will show there is no monkey business at a place called shenanigans. This evidence will prove stations are who they say they are and are following regulations.

Fines for stations operating without an endorsement or those with an endorsement, but not following proper protocols, will be based on frequency. For example, operating on without an endorsement on 14.233 will be $14,233 in fines.

These new regulations should lead to less interference, more contacts, and not blowing up equipment because someone is running full power at 100% duty cycle.

Thanks for reading, April Fools, and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – December 2023 edition

December 30, 2023 Jeffrey Kopcak

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

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:

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

Hey gang,

Finally, a step in the right direction allowing ham radio to modernize – being able to use and develop new data communication methods and have greater flexibility encouraging experimentation. Last month, an announcement from the ARRL recapped a ruling made by the FCC to amend the Amateur Radio Service rules. Commissioners voted unanimously to remove the symbol rate (baud rate) restriction replacing it with a 2.8 kHz bandwidth limit on the HF bands.

Émile Baudot was an engineer and inventor of the first means of digital communication called the Baudot code in 1870. Instead of using dots and dashes as used in Morse Code, he invented a system of bits to represent each character when transmitting messages over a telegraph line. The “baud” unit was named after him. Baud is the number of symbols transmitted per second across a medium. Baudot’s system allowed for multiple transmissions over a single line.

In modern electronics and computing, baud is often associated with serial communication. Most of us remember or have used serial ports. Stating a serial port operates at “9600 baud” means that serial port can transfer up to 9600 bits per second.

Telephone modems, such as those used to access BBS’ and early Internet, had baud rates that matched bit rates. As technology developed and faster communications were demanded, modems used multiple signaling events. The V.32 ITU-T standard allowed for data transfers at 9.6 kbit/s or 4.8 kbit/s at 2,400 baud. This means there were 4 or 2 signaling events respectively occurring at 2,400 baud to achieve the transfer rate.

In their decision, the FCC stated “baud rate limits were adopted in 1980, when the Commission amended the rules to specify ASCII as a permissible digital code. The Commission adopted the limits so that ASCII signals would occupy no more spectrum than traditional radioteleprinter signals associated with the use of Baudot code (FCC Amends Amateur Radio Rules for Greater Flexibility).”

Hams are (for the time being) limited to 300 bauds on the 2200m-12m bands. 1200 bauds on 10m. 19.6 kilobauds on VHF (6 & 2m) not exceeding 20 kHz. 56 kilobauds not exceeding 100 kHz on 220 and 440. A symbol rate is not specified for 33cm and above (97.305).

The ARRL’s petition asked the commission to delete all references to a symbol rate and establish a bandwidth limit of 2.8 kHz for data emissions below 29.700 MHz (2200 and 630-meter excluded). FCC commented that amateur radio can still play a vital role in emergency communications, but is hindered by current baud rate limitations. This ruling removes the old standard of ‘how much data can be sent per second’ replacing it with ‘how much data can be packed into 2.8 kHz of RF spectrum’ on the HF bands.

2.8 kHz occupies the same bandwidth as common side-band (voice) signals seen on HF bands. Even though sections permit wider transmissions (AM, FM in portions of 10m), the limit is imposed uniformly across all HF bands. 2.8 kHz was decided upon because placing the limit below 2.8 would preclude some modes that are already legal.

Radios that do not have a specific “digital” mode setting use SSB when transmitting digital signals from a computer or other device. Radios capable of SSB can be used when newer data modes are made available if offered in a traditional sound card configuration and the radio doesn’t have a hard roll off at 2.7 kHz that cannot be adjusted. Newer ICOM radios (like the 7300) and Software Defined Radios can transmit full bandwidth. Offerings may decide to use standalone hardware or a modem with the assistance of a computing device to transmit and receive signals.

Pactor 4 Radio Modem (landfallnavigation.com)

The ruling did not change anything else. Only symbol rates below 29.7 MHz are affected. 6m and up are unaffected and remain at the published symbol rates in Part 97. The commission proposes removing baud rate restrictions in favor of bandwidth limits on MF, VHF, and UHF too. Band plans and sub-bands remain the same. Digital portions remain digital portions, voice remains voice. Band plans are not something the FCC rules on either. Band plans are typically established by gentleman’s agreement among hams. 2.8 kHz is a maximum. A single PSK or FT8 signal is not going to start utilizing all 2.8 kHz – though some operators act like it. Stations must still set audio levels correctly to reduce digital splatter from their station.

The ARRL previously stated they are in favor of bandwidth limits on other bands but wanted to review limits that might be imposed. I believe it gets tricky with modes of varying bandwidths. For example, many would probably say most popular on the 2m band is FM, including repeaters. There are 2m SSB sub-bands too. 6m is similar with the low-end being DX windows and the upper end being largely FM and repeaters. Could there be multiple limitations implemented per band? DX windows get a 2.8 kHz limit while FM portions are limited to 15 or 20 kHz? Maybe. One problem with this theory, existing permitted legal bandwidths (e.g.: 100 kHz) would be excluded. These and other considerations are likely being reviewed by the ARRL.

An immediate effect of the bandwidth ruling permits later PACTOR modes. In nearly every hurricane or disaster where hams are involved with emergency communications, the FCC would grant a waiver allowing greater than 300 baud transmissions. This temporarily allowed PACTOR III & IV transmissions, which are faster and more reliable than other modes. No more symbol rate waivers will be needed. I’m noticing more Winlink RMS stations in the U.S. listing 2750 Hz VARA HF. There was some question whether 2750 is legal under existing rules in the U.S. and these new listings could be in anticipation of the upcoming changeover.

PACTOR-III has a “data rate of up to 3600 bits per second and a symbol rate of 100 bauds” while PACTOR-IV is “capable of a data rate of 5800 bits per second … [at] a symbol rate of 1800 bauds (Amateur Baud Rate NPRM).” PACTOR-III would be permitted. PACTOR-IV, which does not occupy anymore bandwidth than PACTOR-III, is prohibited and not spectrally efficient.

The new rules go into effect 30 days after publication in the Federal Register. The document was published on December 7, 2023 with amended Part 97 rules. The new Part 97 HF bandwidth rules go into effect January 8, 2024!

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – November 2023 edition

November 25, 2023 Jeffrey Kopcak

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

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:

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

Hey gang,

Pi-Star was great. It solved big problems for hams wanting to use VHF and UHF digital modes around 2016-2017. Personal hotspots were becoming popular. Consisting of a digital interface (modem) board capable of transmitting and receiving digital modes such as DMR, D-STAR, and System Fusion. These transceiver options are low power at about 10mW. The modem interfaced with software to manage network connections. Many devices were created for the popular Raspberry Pi or Arduino single-board computers using the GPIO headers. Others were USB-based devices that could be used with a desktop computer running any operating system or plugged into a Raspberry Pi.

The hardware was pretty solid. Software, not so much. Nearly each group attempted to make their own software distribution. In general, this failed as users couldn’t get the software to work consistently and settings didn’t work as expected – even across users with similar setups. Many didn’t have monitors connected. VNC, a remote desktop sharing application, was used. VNC generally works well desktop-to-desktop, but not desktop-to-mobile. These problems weren’t helping promote digital modes and personal hotspots.

Then along came Pi-Star. Created and maintained by Andy – MW0MWZ, it solved nearly all those problems. On the hardware site, Pi-Star supported every digital modem in a single platform. MMDVM is the software capable of “speaking” different digital mode protocols and managing network connections. It came with a web front-end that did everything needed to configure and manage devices, update network settings, update device firmware, and have a nice usable dashboard. Ultimately, the Pi-Star platform superseded all previous attempts at a viable interface for digital ham radio hotspots.

On the Pi-Star site, version 4.1.5 dated October 2021 is the latest image available for Raspberry Pi. However, 4.1.6 is available through the update sequence pistar-update then pistar-upgrade at the command line, both prefixed with sudo. Pi-Star 4.1.5/6 release is based on Raspbian 10 (buster) which has reached end-of-life. Raspbian, the standard Raspberry Pi operating system, follows the Debian release schedule. Debian 10 is out of standard security updates and into LTS (long term support). Raspbian does not offer LTS.

If you’ve read my column long enough, you know the majority of vulnerability issues can be avoided by keeping systems updated and patched. I’m also reminded of the time when I went searching and found there are Pi-Star’s accessible directly from the Internet, with the default password. What could possibly go wrong?

By all accounts, and as of this writing, Andy is no longer maintaining Pi-Star. Looking at his post count in the forums: zero in 2023 and ten in 2022. There are very few updates to GitHub repositories in the last two years, which are used to update Pi-Star devices. I’ve seen references to lack of updates due to lack of interest. Pi-Star is also lacking the latest additions to MMDVM including M17 and FM for boards that support those modes (usually through firmware updates).

The next iteration of Pi-Star (or fork) comes to us via W0CHP, called “W0CHP-PiStar-Dash (WPSD).” I learned about WPSD when AmateurLogic ran a segment in January on this new offering. I started using it shortly after. Though it was early on in the project, WPSD was labeled “not for the faint of heart” by the author.

It was really rough around the edges. I had to debug scripts in order for updates to run successfully. The dashboard would show the modem in “TX D-STAR” when only P25 was enabled. There were issues with the configuration file manual editor too.

Regardless, development is very active. WPSD has become much more stable and now considered the Pi-Star replacement. Alot has changed in the time I’ve been using WPSD and presume things will continue to evolve.

One such change, there was an option for installing WPSD on top of an existing Pi-Star installation. That option is no longer available or supported. The distribution must be flashed directly to an SD card (flash memory), exactly like Pi-Star.

I always recommend using a new card or different SD card from the current, existing installation until everything is working as the user expects. Having the old (original) card available allows switching back easily in case of problems or need to reference something from the previous installation.

Pi-Star with Nextion display (ailunce.com)

A recent blog post by the author called out people who claim WPSD is an “overlay.” At one point, it could have been installed on top of an existing Pi-Star installation. WPSD is not an overlay. It is its own software distribution.

WPSD works with most Raspberry Pi offerings (Zero, Zero 2, 2, 3, 4, …) including the Orange Pi and Nano Pi Neo variants. The Raspberry Pi Zero W 1.1 is not really recommended for use but it will work. The Zero W 2 is recommended instead. A Zero W 1.1 needs extra configuration steps after flashing the SD card. These include: creating a wpa_supplicant.conf and placing it in the /boot partition. Waiting at least 30 minutes for the image to boot and configure itself before accessing the dashboard. Steps are detailed in the link above.

While using WPSD with my Pi Zero W 1.1 it is quite a bit quicker, taking about a minute to save changes on the configuration page of the dashboard. Compared to the Pi-Star which took two to three minutes to save changes. Pi Zero W 2s are still very hard to find. If you can find one, a male header strip still needs to be soldered to the GPIO. Pre-soldered ones are nonexistent.

Not only is WPSD on a supported operating system (bullseye, Debian 11) but there are a TON of enhancements and updates over Pi-Star. Though the visual layout has changed, it’s intuitive enough for any existing Pi-Star user. Changes I noted right away were the addition of M17 support (though I don’t have any capable devices) and Nextion support built-in. Nextions are displays and/or touchscreens that can be attached to the modem or added through a TTL serial converter, such as those based on the CP2102 chipset. Adding Nextion support to the original Pi-Star was a terrible experience using hacky scripts that had to be run a couple times before the drivers and software could be usable.

Non-exhaustive list of enhancements: full APRSGateway support. DGId support. DMR Roaming Beacon Support for repeaters. Caller details include name and location. Talkgroup names are populated. On the fly changes of talkgroups/rooms/reflectors/networks including ability to pause networks for attending nets or quieting a busy mode. Live Caller mode which is a browser based (virtual) version of a Nextion display. Ability to disable cron (scheduled) updates. Updated dashboard including wider, bigger, updated fonts, user configurable options including CSS styling and fonts. Full dashboard display or Simple View with only RF and gateway activity. Configurable number of last heard stations. Configuration/Profile Manager, similar to OpenSpot, where the user can save multiple versions of a setup and restore them based on use.

A Profile Manager feature was added to WPSD, which did not exist in Pi-Star but exists in the OpenSpot devices. This allows the user to save device settings into a profile to be recalled later. These could be travelling profiles, or ones specific to a mode, network, or configuration for a net. Initial implementation of this feature did not backup saved profiles when using the Backup/Restore feature. Only the current active profile would be backed up or restored. Now, within the last two months, Backup/Restore saves ALL device profiles in the backup archive.

That is an example of the constantly evolving nature of this new WPSD distribution. Updates happen quite frequently. WPSD was updated nearly daily for a long time. Updates still happen quite frequently but at the pace of about once a week, maybe more.

Speaking of backups, it’s not recommended to use migrated configuration files or backups from Pi-Star, due to differences. If Pi-Star files are used with WPSD and there are issues, the user will be required to begin configuration from scratch.

One change I do not particularly care for is the requirement to use DMRGateway. In Pi-Star, I used Direct Mode which is the selection of a single DMR Master. For example: select BM_3104_United_States for Brandmeister and TGIF_Network for TGIF as the DMR Master. I liked this for two reasons: this functionality is similar to how a repeater would operate and it simplifies codeplug programming for talkgroups with the same TG ID across different networks. Ohio Statewide is 3139 on multiple networks meaning I only had to setup Ohio Statewide once. Though it seemed most users did use DMRGateway in Pi-Star.

DMRGateway supports simultaneous connections to six networks. With all those network connections there must be a way to differentiate which network is to receive a transmission. That way is through “prefixes,” a single number prepended to the talkgroup number. DMRGateway doesn’t appear to use a prefix for Brandmeister, 3139 would remain 3139. TGIF talkgroups are prefixed with a 5. 3139 would become 53139. HBLink prefix is 8. My HBLink would be 831983 instead of 31983.

If you’ve programmed a codeplug for a DMR radio, it’s not as easy as just making a new contact with the prefix. Adding the contact to an RX group, creating new channels, and reorganizing or creating new zones are all needed. Maybe I’ll purge the ‘nice to haves’ in my codeplug as I typically only use a handful of talkgroups or just make a new simplified codeplug for use with WPSD.

Changes have been made to the scripts and tools. Commands rpi-rw and rpi-ro have been removed. These were used to switch between a read/write file system and a read-only file system. There has been debate whether a read only file system corrupts any less or shortens the lifespan of the SD card when left in read/write mode. Pi-Star was constantly changing from read only to read/write during settings changes, updates, and hostfile update cycles. Mine seemed as though it could never successfully change from read/write back to read only after an update. Eliminating those scripts just ‘fixed’ those resource busy messages.

Pi-Star scripts that began with pistar- have all been removed and replaced with a smaller set of wpsd- scripts. It was great because all WPSD updates were taken care of by going to Admin -> Update. Though, a recent change has removed operating system updates from that feature. Admin Update only updates WPSD currently (probably due to those lengthy Raspbian kernel updates). To update the operating system, SSH to WPSD or go Admin -> Advanced -> Tools -> SSH Access. After logging in (same credentials used to login to the Admin or Configuration dashboards), at the command line, enter (capitalization is important):

sudo UP_OS=1 wpsd-update

As with Pi-Star, if an update fails or installation becomes borked, re-flashing the SD card with the latest available image will bring the device to a known working state. Remember to save a new backup before updating! WPSD images are updated more frequently than Pi-Star. Updates released since the image was published won’t take quite as long to apply.

There is a lot to read, including some edge features that have been removed, on the WPSD page (linked above). Comparing WPSD to Pi-Star (‘this used to work on Pi-Star,’ ‘when I revert back to Pi-Star this thing works,’ etc.) is verboten when asking for support. The main page on W0CHP’s site is a blog detailing direction and state of the project as well as reasons for changes. I recommend Pi-Star users update to W0CHP-PiStar-Dash – if nothing else, for the supported operating system and OS package updates though there are many improvements and welcome features.

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Computing, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – February 2023 edition

February 27, 2023 Jeffrey Kopcak

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

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:

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

Hey gang,

I finally did it. What would that be? Over the Christmas holiday, during my time-off, I cleaned and organized the shack. Unseasonably warm weather at the end of December made this job much easier. I don’t know how many years I’ve been threatening to do this. PC problems kicked off the whole cleaning process and I (finally) upgraded to Windows 10. N8SY pointed out: shouldn’t you be upgrading to Windows 11? Yeah, no.

Dust, dead bugs, miscellaneous parts from various projects, all the baggies, twist ties, and boxes are all cleaned up. Using small stackable plastic containers with lids (available at the local superstore) organized computer parts, Raspberry Pi parts, radio cables/accessories, and keep parts of a project together. Some time ago, bought a Power over Ethernet (PoE) network switch from a co-worker. Finally set that up and it’s now powering my Cisco phone used for Hamshack Hotline, Hams over IP, and AmateurWire. In addition, gained more Ethernet ports as those were in short supply.

Parts of the shack were reconfigured. I wanted a spare/second power supply. Astron stopped making their desktop switching supplies with analog meters. I found an SS-30M with analog meters on QRZ and purchased it from a local ham. That supply will be used to power network radios for AllStar Link and Wires-X. An old laptop is put back into service running the Wires-X node, full time. Wires-X was previously running on the same PC I use for operating and I didn’t want to keep that one running all the time.

I did much soul searching in regard to the shack PC. It is coming up on 10 years old. A Micro-ATX PC, Intel Core i5 4th generation (they’re up to 12th gen), 16GB RAM, 128GB SSD, and Windows 7. Due to family commitments and as a result of the shack being declared a disaster (by me), I wasn’t operating much the last 2-3 years. Most of 2022, I operated Winlink making few other contacts.

My intention was to get some operating time over the holidays and didn’t plan to spend that much time redoing things. While operating, quickly remembered ongoing problems with the PC. Cluttered with apps I was testing or no longer used, miscellaneous documents from net reports or drills – these were the least of my problems.

It had serious audio issues. As someone who operates mostly digital on the HF bands, this is incredibly annoying. The Windows audio subsystem, at times, simply failed to start where a red X would be shown over the speaker icon in the system tray. This prevented any audio program from functioning. Rebooting once (or twice) would clear that issue. Random receive cycles in WSJT-X (FT8) would not decode any stations. RX cycles before would decode fine, a number following would also be fine. The waterfall looked OK (not distorted). However, at seemingly random times, there would be 0 decodes. I started to pray that a fresh install would clear these issues.

In recent years, I’ve been using smaller desktop form factor computers. Not needing to replace poor included motherboard peripherals (other than graphics cards, separate issue), NVMe M.2 storage (very fast solid-state drive), and use of USB devices, I don’t need many full sized PCs. Included motherboard peripherals, like sound and Ethernet, are very good and don’t need to be substituted with expansion cards as was the case 20 years ago. M.2 SSD storage comes in a very small form factor: 22mm x 30, 42, 60, 80, or 120mm with read/write speeds of 7,000-7,500 MBps. Good 2TB NVMe M.2 storage devices are available for $150.

IBM had an excellent reputation for producing solid hardware. That soured a little when they were sold to Lenovo. I’ve had good luck with Lenovo devices at work compared to other vendors. Lenovo’s ThinkCentre PC line are enterprise orientated machines offering mid-to-high specifications. Even though older models have reached end-of-life, Lenovo still releases BIOS updates. In comparison, most vendors release a new motherboard followed by maybe a handful of BIOS updates during its lifecycle. Continued BIOS updates address compatibility problems and patch exploits. I’m impressed their end-of-life PCs are still updated.

M.2 Solid Sate Drive – 22mm x 80mm (Wikipedia)

I looked at and purchased “renewed” Lenovo ThinkCentre Tiny PCs from Amazon, an M900 & M910Q. Amazon renewed are pre-owned and refurbished PCs resold to keep E-waste down. There are condition guidelines published by Amazon. However, as I found out, quality is left to third-party sellers and varies greatly.

This form factor measures 1.36″ x 7.20″ x 7.05″ weighing in at 1.3 lbs. (M900). Renewed M900 specs: Intel Core i5 6600T, 16GB DDR4 RAM, 512G SSD, Wi-Fi, Bluetooth 4.0, and Windows 10 Pro 64 for $422 (purchased late 2021). M910Q: Intel Core i7-6700T, 32GB RAM, 1TB NVMe SSD, DisplayPort, Wi-Fi, Bluetooth, and Windows 10 Pro was $349 (purchased mid-2022). They’ve come down quite a bit and are now $180 and $274 respectively.

While you get the chassis, motherboard, and CPU (presumably) from Lenovo, everything else is stripped from these renewed PCs. M900 had ADATA SSD and RAM, though a fairly well-known discount name they’re not OEM parts. The M910Q came with a “KingFast” M.2 SSD. That’s right, just KingFast – no model number. The M900 came with a Lenovo branded power supply while the M910Q came with an aftermarket supply that makes an audible sequel when powered. I suspect generates interference, too.

I’ve had issues restoring disk images to the KingFast drive – Acronis complains it can’t read the drive at times. Both included a keyboard and mouse but they are no-name junk. These ThinkCentre’s likely came with Wi-Fi cards from the manufacturer. Those cards are removed and substituted with USB dongles. While I am not using nor did I test any of the dongles, USB dongles for Bluetooth and Wi-Fi are generally bad only working acceptably at short ranges. Additionally, I cannot tell original configurations of these machines because service tags and serial numbers are removed.

Initially purchased these for Homelab projects (virtual machine hosts) and situations where I need a physical Windows machine when a virtual machine wouldn’t cut it. Thought these might be a good replacement for the shack PC. After using them and seeing the poor choice of components, wouldn’t trust these for much of anything. If one desired to go the route of renewed PCs, I would invest in known good replacement parts which adds to the cost. Additionally, the CPUs were only two generations newer than my existing PC. I scrapped the idea of using these or similar “renewed” PCs for my shack.

What about new? Brand new machines like these would be great solutions in a car, camper, mobile shack, or boat due to their small form factor. With regard to USB, I need a minimum of six USB ports. While USB specifications and devices are supposed to be compatible, in practice this is rarely the case. To avoid headaches, I require USB cables controlling essential and important components (SignaLink, CI-V, mixers) be plugged directly into USB ports on the motherboard. I only use USB hubs for things I don’t consider essential (radio/scanner programming cables, RTL-SDR dongles). ThinkCentre Tiny PCs have 4 USBs in the back and 2 in the front. That number isn’t going to work for when I want to use additional devices.

I looked at Intel’s Next Unit of Computing (NUC) offering and mini PCs from BeeLink. They too did not have a sufficient number of USB ports. Using more than one small form-factor PC would be another idea. Unfortunately, don’t have room for another monitor and keyboard. If I ever found a quality keyboard, video, and mouse switch (KVM, or just the K and M), it may solve that. Also, power sources in the shack are becoming scarce. Not to mention current economic issues like higher prices, supply chain issues, shortages, and limited stock. I decided against a new PC until I discover better options or will revisit this when the economy rebounds. HA!

Deciding to keep the same PC, it was wiped and Windows 10 – LTSC installed. No hardware upgrades were performed. There wasn’t much debate for staying with Windows or going to Linux. Programs I use run natively on Windows, such as: radio programmers, scanner programmers, Winlink, Vara, Ham Radio Deluxe, and GridTracker.

Long-Term Servicing Channel (LTSC) is designed to keep the same functionality while not changing operating system features over time. LTSC is a decrapified version of consumer Windows 10, and it’s from Microsoft. It has none of the advertising. No Microsoft Store. No Cortana (virtual assistant). Telemetry still exists based on configuration screens. I used Group Policy Editor and Registry Editor to disable telemetry. A Pi-Hole, or similar, can block tracking at the network level. Consumer support for Windows 10 ends in 2025, LTSC is supported until 2027. Note: people confuse LTSC with the IoT version of Windows 10. This is probably a Microsoft branding issue. They are not the same.

An LTSC license is expensive at $210, or more. Though I did see a China based seller listing them for $19!!? – Caveat Emptor. I purchased through CDW. I’m willing to pay for bloat to be stripped from my Windows operating system. If you don’t want to play the license, that version can be found by doing some digging. I tried a number of the ways to remove bloatware in consumer versions of Windows 10 with programs and random scrips found online in the past. Removed crap often returns as part of “feature updates.” Windows 11 does not yet have an LTSC version and the reason I did not upgrade directly to 11, possibly released later this year.

A clean install of Windows 10 resolved my audio issues and my WSJT-X decode issues are gone as well. On Windows 7, switching between or launching applications would cause hesitation in applications that were running in the background. Opening the browser would cause digital programs to stop transmitting for example. That too is gone in Windows 10. I am happy with the results post upgrade.

Allow apps to access your microphone for ham radio sound card programs

There are some important settings to note in Windows 10 related to ham radio sound card programs. I’m overzealous turning off access to things that don’t need access. Most everything in Settings ? Privacy I have turned off. Doing so prevented ham radio sound card programs from functioning correctly. Programs such as: Echolink, Fldigi, DM780, FreeDV, WSJT-X, Vara, etc., etc., etc. Operating ham radio sound card programs in Windows 10 (and likely 11), Microphone access must remain enabled. Even though none of those programs are listed as accessing the microphone. While labeled Microphone, this setting prevents programs from accessing all sound input devices. These are input devices listed under the Recording tab in Sounds. Programs like SDRs use output from one program as input for TX, a double whammy.

Close any programs using sound devices
Go to Start -> Settings -> Privacy (Privacy & security in Windows 11) -> Microphone
Set “Allow apps to access your microphone” to enabled/on
Re-open programs that were using audio devices and sources

Sound card digital programs will now work. If there are still issues, move on to troubleshooting audio levels and verify correct audio sources are chosen in the respective program’s settings.

In Windows 7 and my guide for settings levels when using ham radio sound card audio programs, I recommended setting levels to 50%, or half. Some pointed out manufacturers indicated to choose the decibel scale, not the percentage scale I was referring. None of the references said why users should use that scale over percentage. After all, the slider didn’t change switching between the two scales.

After doing some digging and testing, figured it out. Different versions of Windows use different scales – even for the exact same audio device. The 50% setting will likely be different between Windows 7 and Windows 10.

Used my SignaLink to obtain these dB ranges:

Windows 7 – speaker (transmit audio): -128.0 dB to 0.0 dB
Windows 7 – microphone (radio receive audio): -192.0 dB to +30.0 dB
Windows 10 – speaker (transmit audio): -128.0 dB to 0.0 dB
Windows 10 – microphone (radio receive audio): -96.0 dB to +30.0 dB

Different scales for a SignaLink USB microphone device on Windows 7

Different scales for a SignaLink USB microphone device on Windows 10

In this case, speaker ranges are identical with -10.5 dB being 50% for both operating system versions. However, microphone input at 50% on Windows 7 is +24.0 dB. On Windows 10, +24.0 dB is roughly 96%. A wide variation and I noticed the level difference right away. Understanding this helped me translate my audio settings from Windows 7 to 10. I did find a Microsoft Learning document explaining Default Audio Volume Settings pointing out the differences in different versions of Windows.

I am very happy the shack is no longer a DMZ. My sound card digital programs are working again and I have a clean desktop install – for now, lol. Haven’t yet been consistently operating due to work and family commitments. When you do find me on the air, I’ll be (likely) logging contacts for Volunteers On The Air.

I would like to formally welcome the newest member of the Technical Specialists group, Ronald – NQ8W. He comes to us with a number of ETA International certifications in electronics, computers, and wireless communication. Ron is a former Master Electrician with degree in Mechanical Drafting. He obtained his GROL and has Emergency Communication certifications. When I talked with Ron a while ago, he was very pleased with the work of our Technical Specialists and wanted to give back with his skills. Welcome to the group!

Speaking of the Specialists. Earlier this month, I was invited to be the guest speaker at the Cuyahoga County ARES meeting. The topic: me, the Ohio Section Technical Coordinator. Not long before I was appointed Technical Specialist, I had no idea there was a technical organization at the section level. After being appointed TC, a group in Columbus asked for me to speak about ‘what does the TC do?’ Out of that came an opportunity to educate hams about the ARRL Field Organization and the work of our Technical Specialists. I had a great time at the Cuyahoga ARES meeting. There was plenty of discussion on technical topics and RFI stories (I cover troubleshooting techniques) after the presentation. If your group would like to know more about the technical and experimentation side of the Ohio Section, send me an E-mail.

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Computing, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – January 2023 edition

January 28, 2023 Jeffrey Kopcak

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

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:

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

Hey gang,

I’ve traveled for work to our other facilities and taken advantage of training related travel. We were thinking I would have more travel opportunities. However, due to business need, sequestered to our homes for 2 years, and the freaking economy – it hasn’t happened. I had the opportunity to attend a work conference earlier this month and it gave me ideas to promote ham radio.

Work conferences are an opportunity to attend sessions and talks to gain skills, education, knowledge, keep current with industry trends, and network with others. If you’ve been to forums at Dayton, work conferences are 2/3/4 days of forums focused on an industry or segment. These could be: sales, information technology, manufacturing, human resources, C-Suite topics, project management, or general trends – like how work-from-home has changed and challenged work in the last 3 years. Similar to indoor vendors at Dayton, companies will sponsor booths with giveaways, swag, and maybe an opportunity to find a new job.

A number of co-workers and myself attended a conference called CodeMash in Sandusky at the Kalahari Resort (near Cedar Point if you’ve never been). This year was CodeMash 10000 (binary for 16). It was my first time at this conference. The conference is developer (programmer) focused but had tracks for information security, data, and career development. There were fun things to do including board games, laser tag, a maker space, evening events including casino night, and access to the resort’s indoor waterpark. The full conference runs four days in two halves. The first two days are called the “Pre-Compiler” consisting of two four-hour sessions per day. These are deep dive table-top exercises, discussions, and hands-on labs. Second two days are more byte-sized (see what I did there?) one-hour talks.

For work-related conferences, travel and accommodations are often paid for by the employer because these are training and educational sessions related to employment, job description, or a particular project. The employer hopes attendees return with new ideas and out-of-the-box thinking.

Depending on conference, cost can be way above beyond one’s means to attend on their own. CodeMash tries to be reasonable allowing individuals to attend at their own expense, if desired. A full 4-day ticket is between $800-$1,100 and the 2-day between $400-$550. Booking rooms through the conference at Kalahari offers discounted rates over normal nightly rates, though attendees can opt to stay at near-by hotels to be more economical. Kids have their own events called KidzMash, free with a registered adult.

Presenters for this conference are chosen by submitting abstracts to the CodeMash committee. If chosen, presenters get a free ticket to the conference as compensation for presenting. Sponsored sessions are hosted by companies sponsoring the event – these are listed as such and were on the last day. Presenters can plug their business and/or employer as their company is likely covering remaining costs. At least one presenter said they were there on their own dime as their employer “didn’t see the benefit” – and yet their lab session was standing room only.

Intro to Docker session. I’m way in the back row on the right. Twitter: @OtherDevOpsGene

I figured I wouldn’t have much time to play radio as the schedule was pretty grueling with breakfast at 7 am and sessions wrapped up around 5 pm each day – not including evening activities. In the past, I’ll bring at least one radio, a mobile radio if I’m driving and know I’ll
have extra time. Though I was driving and staying at the resort for this conference, I brought an HT, hotspot, and a couple RTL-SDR dongles because I like monitoring the Ohio MARCS-IP public service system. I was not expecting to have ham radio interaction during the conference.

First day of the conference at breakfast, this guy sits down at my table. It looks like he’s got a Yaesu Fusion radio with a whip antenna. I asked him “ham radio?” He says “yep, you?” “Oh yeah.” Talked with Dan – AD8FY about ham activities and his experiences as a pilot. He informed me there was an unofficial UHF simplex frequency and there would be a number of hams at the conference. This did surprise me as I wasn’t expecting it but again, first time. Feeling pretty good about the conference and some connection to ham radio.

During one of the Pre-Complier sessions, learned there was a Slack instance for the conference. Slack is an instant messaging platform available on just about every device. Slack started out as a professional communications platform (like Microsoft Teams or Google Chat) but became accepted as a community platform for things such as this conference. In addition to messaging, Slack can do VoIP calls, video calls, file sharing, and text messaging in channels (like a conference room) or to individual users. A feature I like is persistent messaging allowing people to see prior messages after joining. For example, I joined the Slack instance on the second day of the conference but I was able to see messages from the previous day. This is different from other chat services which only show messages sent after one has joined the channel.

Guy – KE8VIY SDR live demo, receiving ADS-B broadcasts

CodeMash’s Slack had many different channels: events taking place during the conference, discussions around hotel reservations, and water park. Announcements – changes, cancellations, updates, and general information. General discussions. Major cities had channels for attendees from those areas to network, such as #cleveland. Pre-Complier portion of the conference had a channel for presenters to post their slide-decks and labs. Slides channel for presenters from the second-half of the conference. Hobby channels included beer, wine, music jam sessions, and ham radio. Oh, really?

KE8VIY asked to have a #ham-radio Slack channel. Ten people conversed about radio and when they were monitoring the simplex frequency. Call signs seen: WX8TOM, WX8NRD, KD8NCF, KE8VIY, and myself. I found out later KD8NCF gave a presentation at the conference on Real-Time Web Applications.

Thursday afternoon, while heading to an afternoon one-hour session, saw this guy (that’s his name too) outside one of the conference rooms pointing an antenna around. Figured he was doing Wi-Fi hunting or something. He too had a HT with him. This was Guy – KE8VIY. He was preparing for his presentation later that afternoon using software-defined radio to decode ADS-B (aircraft broadcasts). Though he was unsure there would be any aircraft to track as all flights were grounded earlier due to a possible cyber-attack.

I told him I would be attending his presentation. Knowing a ham was doing this session helped swing my decision in his favor because there was another equally interesting session on another hobby of mine, homelabbing. That decision paid off because not only was Guy’s presentation excellent, it got the wheels turning on more ways to promote ham radio. “Tracking Aircraft with Redis & Software-Defined Radio” (GitHub repo) was the presentation.

I’ve never used Redis. Reading up on it, the technology works mostly in-memory as a structured data store, often as a caching service (session, page, message queue) or key-value database. According to Wikipedia, Twitter uses Redis and Redis is offered by the big-name cloud providers AWS, Azure, and Alibaba.

Guy’s slides were professionally done and visually appealing. Coupled with the slides, his personality, humor, and live demos, (if I didn’t know anything about it) he made ham radio seem fun and interesting. He stated he is a new ham and excited about what he’s been able to do processing radio signals. The audience was highly engaged asking questions and feedback was positive from hams that saw the presentation.

Most maybe thinking: you don’t need a license to receive ADS-B, how is this related to ham radio? That’s the tie-in. He worked in history of digital signals, formats, and all the things rooted in ham radio: Morse Code, RTTY, and APRS. Then demonstrated how he used a modern technology platform and a radio to capture and process digital signals, all at a developer conference. Well done!

There are a lot of slides in his deck. Due to the one-hour time limit, the first 30 slides and some diagrams were covered. He utilized Dump1090 for turning signals into raw data. Then used Redis (also his employer) to process, store, and make data available to consumers.

These things fit my thinking of how ham radio should be promoted. Promoting to kids is admirable and exposing them to activities early in life is a great way to maybe hook them later in life. Credit to my parents because ham radio was one of those activities and it happened to stick. Though, I seem to be the exception rather than the norm. There are other things my parents had me join in school that didn’t stick and I really don’t miss those activities. A way kids get their license is part of a school program or curriculum. How many carry on and renew their license after 10 years is up? Retention needs work. Chances are better if family members are active and involved.

Guy – KE8VIY SDR live demo, ADS-B broadcasts shown on a map

I have been a huge fan of initiatives by the ARRL and clubs to use Makerspaces as a way to breathe new life into the hobby. Makers are like-minded people whom like to learn, create, and invent as does the experimentation side of ham radio.

Gainfully employed individuals would be my next target audience – you know, if I were on a committee. Somewhere in the neighborhood of 25-45-year-olds – those looking to keep themselves busy – whether they’re single, don’t yet have a family, or had their kids graduate college. These individuals have disposable income for equipment and time that can be devoted to learning and operating.

A conference like CodeMash is a near perfect match for promoting ham radio to technically minded individuals, including kids. Not having any statistical data, I would say the median age was probably mid-30’s, early 40’s. Obviously, there were younger and older individuals. With few exceptions from my interactions, participants were gainfully employed as their companies were picking up the tab for them to attend the conference. There were an estimated 1,400 attendees at this year’s conference. (attendance was still down from previous years, close to half). That’s 1,400 technical people, a great audience to promote ham radio.

Does a conference you attend offer a communications platform like Slack? Ask for a ham radio group to be created. Post a simplex frequency for general chit-chat. Maybe organize a meetup during meal time or after events that day to network with other hams. Maybe non-licensed people will drop into the channel or drop in at the meetup. Maybe they’ll get bit by the bug and be looking for an Elmer.

Think about current job responsibilities, technologies or services your company provides. Guy, in the spirit of ham radio, took an existing technology, re-purposed it to receive signals and turn the data into events, maps, and an API (application programming interface, used for integrating with other applications) from aircraft broadcasts.

How can a technology you’re created, are familiar with, maintain, or work with become an interesting presentation that ties in ham radio? Figure that out and maybe you’ll get a free ticket to a conference with the employer picking up the tab for travel expenses!

I brainstormed examples using technologies seen at the conference to do radio related things:

Real-time data processors like Kafka for mapping propagation
Networking skills and technology to improve resiliency and security of mesh networks
Table-top-exercise to recover from a disaster. Assume all existing connection and authentication methods are non-existent.
Receive signal data from a distributed radio network
APIs to administer digital systems with many connections
Automate test-cases and frequent software updates with GitHub pipelines
Incident response to handle compromises of repositories or stolen credentials
Docker & Kubernettes to build simple, easily deployable applications
Can the “cloud” fit the general directive of not relying on other technology? How to handle and recover from outages?
Designing web apps to replace multi-platform applications
Write the next white-paper
Create technical documentation standards

Development work isn’t part of my daily responsibilities since I changed jobs a number of years ago. Initially wasn’t too sure about the conference. In reality, I learned a lot about technologies I hadn’t yet explored on my own. Ham radio connections made it a much better experience and hope to attend next year. Let me know if you’ve done something to promote ham radio in a similar conference-type setting to like-minded (non-ham) individuals or used modern technology platforms to improve and better ham radio.

Thanks for reading and 73… de Jeff – K8JTK

NOTE: an article written by Bob – K8MD on a portable operation during a work trip was included in the printed edition. That is available by the full edition links at the top of this post.

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – September 2022 edition

September 24, 2022 Jeffrey Kopcak

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

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:

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

Hey gang,

I was cleaning out my E-mail inbox, apparently no one else does this, and came across a request from a couple years ago. Mike – AB8MW contacted me wanting to know if it was possible to run multiple copies of Fldigi at one time. The scenario would be one copy for HF and one for VHF/UHF. For example: an EmComm event where they might want to monitor HF frequencies in addition to local VHF/UHF using a single PC.

Starting multiple copies of Fldigi & Flmsg will open multiple windows. Regardless of how many windows can be opened, all use the same user configuration directory to store settings. Mike wanted Fldigi to retain settings for each use. Settings such as soundcard inputs/outputs and rig control (if used). One radio might be using a SignaLink/RIGblaster/other soundcard interface and have no rig control. Another radio maybe using virtual audio cables (typical for SDR radios) and Hamlib for rig control. When multiple Fldigi & Flmsg windows use the same settings directory, last window closed wins. When the program is restarted, those settings are loaded. Additional Fldigi & Flmsg windows have to be configured all over again. Not convenient, especially with many uses on a single PC, in a pinch, or during a real operating event.

Why would someone want to run multiple copies (or instances) of Fldigi programs? Some operators use HF and VHF/UHF differently, including sound interfaces and rig controls. Instead of switching around configurations depending on band, have two instances configured, one for each radio. Other reasons could be a single all-band all-mode radio is used but have very different operating styles, personalities, or users – like in a club setting. Operating styles could be EmComm and contesting, or using different macros. Monitoring multiple repeaters or multiple HF frequencies during an EmComm exercise would be desired or any combination of these examples. Creating separate instances will allow each to have its own configuration settings.

Keeping separate settings is very doable, but it takes some work. There are additional issues when adding Flmsg (or other Fldigi programs) to the mix as one would use for NBEMS. Flmsg & Fldigi use a local IP port (often referred to as a “socket”) to facilitate communications between programs. The default IP and port for Flmsg to Fldigi is 127.0.0.1:7362. 127.0.0.1, also referred to as loopback or localhost, is a reserved IP address. This IP address is used by programs to communicate with other programs and services running on the same system. In Flmsg, when the operator hits AutoSend, it’s a crapshoot which Fldigi window will transmit the message when multiple windows are open. A message intended for VHF could go out over the HF radio. Not good, as that causes unnecessary confusion to other stations. Each pairing of Fldigi & Flmsg needs a unique set of IP ports.

According to the author of the Fldigi suite, Dave – W1HKJ, port/socket parameters for Fldigi, Flarq, Flmsg and Flamp are specified on the command line. Other TCP ports are configured in the Fldigi Configuration options under Misc -> TCP-IP sessions. There is some overlap between command line options and graphical interface options including KISS, ARQ, and XML settings.

When AB8MW originally contacted me, we worked out the configuration details over E-mail and he was going to get it working. I, of course, said ‘I am going to write this up’ and never did. That is until I came across those messages and finally sat down to document a procedure. My procedure outlines changes needed to run multiple instances in a NBEMS operational situation for both Fldigi and Flmsg. This might be useful for those participating in the upcoming October SET. This will also work for Fldigi instances without the use of Flmsg. The posting is on my site: Running multiple instances of Fldigi and Flmsg.

My write up labels one instance for “HF,” a second instance for “VHF/UHF.” There is no limit on how many instances can be created. I’ve heard stations using as many as six. The problem becomes manageability. When a setting is to be changed universally, it has to be done independently for each separate instance. When a new version is installed, shortcuts must be updated manually.

Multiple copies of Fldigi & Flmsg transmitting messages independently

My process creates separate directories for both Fldigi and Flmsg to save their settings. Copying of existing configuration settings is accomplished, if desired. Then creating and customizing shortcuts to use specific configuration directories. Finally, making unique configuration changes for each instance.

Running multiple instances of Fldigi programs is completely doable. It takes a little effort to configure the directories, IP ports, and settings. Once configured, clicking AutoSend in Flmsg will send that message to the paired Fldigi instance. I even show how to send messages received on HF to the VHF instance and vice-versa. No more guessing if it will go out over the correct radio!

If you were an early adopter of Hamshack Hotline and no longer have a green light for the HH extension, you probably need to make a configuration change. Another symptom, when the phone is rebooted, the phone gets stuck on “Checking DNS” and never moves past that screen.

Back when HH first started, the domain name wizworks.net was set by HH in the configuration file loaded onto everyone’s phones. The US server was hhus.wizworks.net. Since then, they transitioned to using the domain hamshackhotline.com, where the US server was changed to: hhus.hamshackhotline.com. The hhus.wizworks.net DNS record has been removed and is now invalid (NXDOMAIN). If a HH configured phone or device has stopped working around the end of August, check the registration domain.

In a web browser, go to:
http://<IP Address of phone>/admin/advanced/
Click the “Ext 1” tab – or whichever extension Hamshack Hotline is configured
Under “Proxy and Registration” look for: (1) Proxy & (2) Outbound Proxy
If they show: hhus.wizworks.net, change both to:
hhus.hamshackhotline.com
Click Submit All Changes

Cisco SPA phone configuration changes for Hamshack Hotline

The phone will reboot and be back online again after about 60 seconds. Verify the Hamshack Hotline extension is now green. Green means the phone was able to register successfully with the Hamshack Hotline server. If that doesn’t work, having trouble, or not sure, open a ticket with the Hamshack Hotline Help Desk.

I discovered this issue after powering down the shack due to storms. When I powered the phone back on, it stayed on the “Checking DNS” screen. I figured something fried during power off or the power supply was dying. There was no change after changing network cables and power sources.

I found the phone was getting an IP address by looking at my router/firewall and seeing an IP address handed out by DHCP. This meant it was accessing the network and I could do a packet capture. Packet captures capture network data for analysis and troubleshooting. These shed light on network problems such as DNS issues, firewall blocked traffic, packet size/MTU, retransmissions, etc. A capture won’t show problems with the application itself because it just looks like regular traffic/packets on the wire. Captures are often run on routers or firewalls as they are passing the traffic to and from the Internet or other networks. A switch with ‘port mirroring’ can send copies of data to a separate Ethernet port. A device connected to the mirror port, such as a PC with Wireshark, captures the traffic.

For my phone not finishing its boot, I identified the issue immediately in the capture. The phone was requesting the record for hhus.wizworks.net. The DNS server responded with “no such name.” That means the DNS record for hhus.wizworks.net, which ties the name to an IP address, does not exist. It was removed, as my phone worked previously.

Packet capture: first line is the DNS query for hhus.wizworks.net. Second line is the response “no such name”

Since my phone had an IP address, I could access its web-based configuration making the changes above. I probably could have guessed the new domain name. However, I was even luckier. I setup Hamshack Hotline on my softphone a couple of months earlier and their documentation had the new server name. Simply changing domains from “wizworks.net” to “hamshackhotline.com” was the only change I made.

A while back they told everyone to re-provision their devices. I thought I did. Thinking later, I probably didn’t because I configured additional extensions on my phone. Either way, making that change resolved my issue and my phone is operational once again.

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, Tutorials

Running multiple instances of Fldigi and Flmsg

September 23, 2022 Jeffrey Kopcak

There are situations where it would be easier for an operator to run multiple instances (copies) of Fldigi and Flmsg at one time. These programs are often used for NBEMS handling over a repeater and the HF bands.

Why would anyone want to run multiple copies (or instances) of Fldigi programs? Some operators use HF and VHF/UHF differently including sound interfaces and rig controls. Instead of switching them around depending on which bands, have two instances configured differently for each radio. Other reasons could be using a single-all band-all mode radio but have different operating styles or personalities. Those could be Emcomm and contesting, or different macros and settings for each operating style. Monitoring multiple repeaters or HF frequencies during an Emcomm exercise. Or any combination of these examples. Creating separate instances will allow each to have separate settings, macros, and log books.

Fldigi and Flmsg with the default configurations are not setup to run multiple instances on a single computer. While the programs can be started multiple times, all instances share the same configuration directory. Setting different configuration directories allows one computer to run multiple instances all with different settings (rig control, audio devices, even Fldigi software versions). All instances can transmit and receive independently of each other on any combination of radios, bands, frequencies that can be connected to a single PC.

I’m demonstrating using the popular combination of NBEMS programs: Fldigi and Flmsg. It appears possible to run multiple instances of the other Fldigi suite of applications, such as flrig, fllog, flamp. Configuration changes for each program and communication between the programs would be needed. Additional programs are beyond the scope of this write up. Look at the program documentation for command line parameters, running multiple copies, I/O configuration page, and posts on groups.io support forums.

I will use the distinction of “HF” for an example instance connected to an HF radio, and “VHF” for an example instance connected to a VHF/UHF radio. There can be any number of instances created for however many radios or bands or operating styles are desired. The issue is manageability of settings, received files, and program updates.

This will work in Windows and Linux/Raspberry Pi. Substitute C:\Users\<Username> (Windows) with /home/<Username> (Linux) where <Username> is the logon for the user.

Program versions

Program versions used in this document.

Windows 7 – 64 bit

Fldigi 4.1.23

Flmsg 4.0.20

It appears Fldigi 4.0.18 and Flmsg 4.0.9 and greater support the command line options needed to run multiple instances.

Pages: 1 2 3 4

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – August 2022 edition

August 28, 2022 Jeffrey Kopcak

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

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:

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

Hey gang,

When it comes to digital communications, especially in the Ohio Section, efforts have been focused on DMR. Repeaters are pricier than other digital modes. An abundance of end-user devices available from a variety of vendors, at fairly inexpensive prices, is a winner for users. DMR, being a commercial standard, was adopted to ham radio. Those that have not spent time to understand how a codeplug works and how to modify them ‘are just a bunch of appliance operators’ is a common argument. To link the majority of Ohio’s DMR repeaters, a network had to be chosen. Ohio standardized on Brandmeister.

What is BrandMeister? “BrandMaster/BrandMeister is an operating software for Master servers participating in a worldwide infrastructure network of amateur radio digital voice systems.” Stating that amateurs can and do use it for D-STAR and Wires-X, its main focus and selling points are related to DMR linking.

In the early days of DMR in ham radio, networks were setup identical to their commercial system counterparts. Repeaters had certain talk groups on specific time slots. Limited to 16 talk groups because that’s how many channels were available on the radio’s selector knob. Owners had little to no options for customizing talkgroup offerings. For example, if you were in eastern Ohio, a repeater might have Indiana statewide whether you wanted it or not. There were no such things as hotspots, at least as hams know and understand them. Like most new things, early adaptors did this for fun and no one really knew if DMR would take off and be accepted by the masses.

Three things helped DMR take off in ham radio: cheap radios, hotspots, and Brandmeister. Brandmeister turned commercially implemented DMR networks on their heads. Made it more like ham radio. A repeater owner could put any talkgroup on any time slot. Any user could make private calls to other users on any timeslot. Even make up a talkgroup number, hit transmit, and if another user was on that same talkgroup number, communication happened automatically. Later, simultaneous data messages and APRS were implemented. Being able to use ham developed gear, like the DV4mini and OpenSpot devices, was a huge draw. Hams familiar with commercial implementations of DMR were questioning ‘how could Brandmeister pull this off without causing chaos in the ham radio streets?’ Especially the ‘pick your own talkgroup number.’

With the explosion in popularity came use and abuse. Brandmeister had to start making decisions and decided to follow the strictest definitions of standards. You can still make up your own talkgroup but it is generally frowned upon. DV4Mini sticks were banned due to poor software – this was reversed after G4KLX wrote compatible software. There was a hissy fit Brandmeister threw about using DMR IDs starting with 1. Everybody and their mother, brother, and daughter requested talkgroups. No more 5-digit talkgroup numbers are assigned. Bridging to other digital modes, networks, and analog systems is verboten, explicitly forbidden on world-wide, regionals, and statewide talkgroups. Brandmeister considers 3, 4, and 5-digit talkgroup IDs under their control, as defined by the MCC numbering standard. 6-digit repeater IDs or 7-digit user IDs, the assigned owner can do whatever they want as Brandmeister sees themselves as “guests” for those IDs. There are more do’s and don’ts in the BM USA wiki.

For a good long time, development and, I would argue, interest by the development team was stagnant. There were long standing issues with many parts of the system, including the online audio web portal, Hoseline. For years it would not work correctly, had long audio delays or no audio at all, or the URL would simply be unavailable. Around June 2021, a new and much improved Hoseline appeared. Featuring a new and modern interface with the ability to monitor multiple talkgroups at a time.

Improvements in the name of security were made later the same year. Each Brandmeister hotspot user needed to generate a “hotspot password” for each DMR ID. This change impacted every Brandmeister user. I was contacted well into 2022 about users whom were unaware of this change.

Not-so-well-known changes affected some misconfigured hotspots and users of DVSwitch and MMDVM bridging. Master servers started checking parameters such as RXFrequency and TXFrequency in MMDVM. If the device was a hotspot, Brandmeister logic said if those two fields are not the same value, the device it must not be a hotspot because hotspots are simplex. If a hotspot (or DVSwitch/MMDVM Bridge) had RX Frequency not equal to TX Frequency, the device would be blocked from transmitting because it was deemed misconfigured. In order to work, they both had to be the same. Also, if either parameter was 0 – as in no RF output, such as an Internet link – also no work-y.

It’s their network and I really want to like them. Their decisions are making it hard for sysadmins to continue using Brandmeister. Communication regarding nearly all back-end changes have been poor to nonexistent. Changes affecting all users are publicized, even though a good percentage hit me up months later saying ‘all of a sudden my hotspot doesn’t work anymore.’ Sure, some changes might only “affect a small number of users,” post something in the groups.io. Instead admins are left to figure out, on their own, why the Brandmeister link is not functioning without being aware of changes on their end. Something about not peeving off your users, which they seem to be doing a lot lately. I get that they’ve had to make hard decisions and many policies are a result of the users whom abuse the system. Brandmeister probably received pressure from other network and talkgroup owners who want to quash analog cross linking. When the Brandmeister network was originally a ‘do-anything network,’ it’s not easy when they start pulling-back on those abilities.

August 19th, a major code upgrade was rolled out which implemented additional changes paving the way for better dashboard integrations, APIs, and hopefully more new features. If you setup your hotspots or applications with a Brandmeister API key prior to August 19, 2022, new keys are required. I was able to generate Brandmeister API v2 keys for Pi-Star: 4.1.6 / Dashboard: 20220819 and OpenSpot3 with firmware v62.

I was not able to save the API v2 key on an original OpenSpot (1) with the latest firmware available (0142). I was seeing the error message “Couldn’t save API key (Bad Request).” According to the support forums, they won’t be getting support for v2 either. New keys are supported on the 2, 3, and 4 OpenSpot models. If you had previously generated a v1 API key, it will continue to work for as long as Brandmeister allows.

I do not know if previous versions of Pi-STAR have been updated to support v2 API keys. To update a Pi-STAR to the latest revision, backup the existing configuration, download v4.1.4 on the Pi-Star site, flash to a new or the existing SD card. When configured, run update/upgrade and repeat, from the Configuration -> Expert option, until there are no more updates for both tasks. Pi-STAR cannot be upgraded version-to-version through the updater/upgrader.

Go to Configuration -> Expert -> under Full Edit, BM API. If you have an apikey entered these need to be updated, specifically apikeys that are 128-characters. It will look something like:

MWaztB3EcHWBEW@D$2gb89Y2kvvE4leSr.33Gey74d0IYVSKU58YGMSFmPHD.Q1fECUkIcj7E4leSr.33Getkjshdf987ywe2irligr908SFIdlsfkj08934sasdlveg

The 128-character API keys will continue to work for an undetermined amount of time. Follow the Brandmeister blog post to generate updated API keys. If you don’t have an apikey entered and don’t want one, you don’t need to do anything.

What alternatives are there to Brandmeister? Networks such as DMR+ and FreeDMR are popular in Europe/UK. HBLink reflectors are available but only offer a few select talkgroups. TGIF is a smaller DMR network implementation. They do not have many restrictions on device configuration. Though TGIF does have an “Ohio” talkgroup, it’s not the same everyone knows and loves on Brandmeister. As an admin, TGIF is much easier to work with. Running a linking system that has links to Brandmeister, TGIF, and HBLink, users don’t use alternative options, even though they complain about Brandmeister. Brandmeister is what they know and love. They won’t venture out to use other, more stable options, therefore remaining appliance operators.

Thanks for reading and 73… de Jeff – K8JTK

Amateur Radio, ARRL Ohio Section, Ohio Section Journal

Ohio Section Journal – The Technical Coordinator – November 2021 edition

November 28, 2021 Jeffrey Kopcak

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

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…

Read the full edition at:

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

Hey gang,

Users of the DROID-Star application ran into a problem with an update earlier this month. After upgrading, then trying to connect to a DMR, D-STAR, NXDN, or System Fusion network, users were greeted with a “no vocoder found” message.

DROID-Star is known to users of digital modes. Namely used by Android or iOS users, it connects the user to ham radio digital networks. Later AllStar support was added through IAX, not using the AllStar Link network rather through the Inter-Asterisk eXchange protocol. AllStar is built on Asterisk and IAX requires separate accounts for access. DROID-Star supports MMDVM in hotspot or standalone transceiver configurations. MMDVM is written by G4KLX and the standard for ham radio digital linking via hotspots, interface boards, and applications.

Modes that can no longer be used out-of-the-box, after the November update, are all of the AMBE modes. AMBE is the voice encoder used in DMR, D-STAR, NXDN, and YSF. The no vocoder found message is seen when connecting to any of these modes. Unaffected modes are IAX, M17, and P25. IAX uses codes available to Asterisk. M17 uses the free and open source Codec 2. P25 (phase I, as used in ham radio) uses the IMBE codec. All three of those modes can be used without additional configuration.

First thought, there was a licensing issue or dispute. I found a forum post where the Pi-Star author recommended keeping packages separate in DROID-Star making them easier to maintain and packages can be built without including unnecessary extras. I believe this to be the reason the packaged codec in DROID-Star was removed.

No vocoder found. No hardware or software vocoder found for this mode. You can still connect, but you will not RX or TX any audio. See the project website (url on the About tab) for info on loading a sw vocoder, or use a USB AMBE dongle (and an OTG adapter on Android Devices)

As the message indicates, the user can connect to a reflector or talkgroup, but no audio will be heard. That’s about as useless as a glass hammer. I guess you can connect to make your presence known, but transmissions and reception is done through ESP? First thing I did was to visit the project URL to obtain information about finding a vocoder as suggested.

I have no information regarding aquiring a software vocoder.

There are no software vocoder plugins available in this repository, and I have no information on obtaining one. DONT ASK!

Super helpful. It does say there is an option of using a DV3000 and OTG cable. If you haven’t seen a DV3000, it’s about the size of a USB thumb drive. Do DROID-Star users need to have a hardware dongle hanging off their phones to make digital connections? Maybe. I was planning to test this method but realized I switched to a phone with USB-C connector and the OTG cables I had for previous devices were Micro USB. Make sure to obtain the correct cable for your phone or tablet.

USB OTG stands for On-The-Go. By default, phones/tables act as a peripheral. For example, plugging into a PC allows access to the phone’s storage. In order to set the phone in host mode, allowing it to accept input from other devices, a special cable containing an extra pin is required. This cable with an extra pin informs the device to enter host mode. OTG cables are readily available from a favorite online store or local computer shop. Search for ‘Micro USB OTG cable’ or ‘USB-C OTG cable’ depending on the device’s connector type. Description should make reference to being an ‘adapter for smartphone.’

Not seeing any other solutions early on, I rolled back the application to an earlier version. This is not for the faint of heart nor for someone worried about installing unofficial versions of applications, called “sideloading.” Not responsible for any damage or legal issues. This is for informational purposes only. Updates to the operating system may keep this app from working properly in the future. Any app updates/enhancements/features/bug fixes to DROID-Star will not be available without using a later version and running a vocoder. Downgrading is not possible through the Play Store. I downloaded DroidStar 1.0 (58) from the APKPure website. Hashes and additional info available on this page. I had to remove the newer DROID-Star version (which removes settings) from my phone and install the downloaded version manually. There is a “How to install APK / XAPK file” on the download link. It will explain sideloading an app and required settings to change.

After doing more digging, I was able to find a more appropriate and supported solution. The instructions to load the plugin on the project page are wrong. Saving to the Download directory did not work. To install the vocoder on an Android device:

1. Install the latest version of DROID-Star (Play Store, 3rd party store, official APK).
2. In the browser of the mobile device, visit this website: http://pizzanbeer.net/plugins/

3. Press and hold the filename for your device (arm, arm64). If you’re not sure which one to use, in DROID-Star hit About and look for Architecture.

4. Tap Copy link from the popup

5. In DroidStar, go to Settings
6. Scroll to the bottom (now located just above the MMDVM and level settings in later versions) and paste the URL in the Vocoder URL field (tap the Vocoder URL box. When the cursor is displayed, press and hold the same field. Click Paste).
7. Tap Download vocoder

8. A message saying “Updating, Check log tab for details” is displayed. Tap OK.

9. The Log tab should display “Downloaded vocoder_plugin.android.arch.”

You’re ready to go! If this is not seen, there was an error or the download couldn’t complete. Though these instructions are for Android, they are nearly the same for iPhones and iOS devices, except choose the “darwin” platform file instead of arm/64.

These steps might have to be repeated often. The release I used as of this writing (Nov 24) DROID-Star did not retain the vocoder settings. Now, I could have corrupted a database or borked permissions during testing and re-installing previous versions on my phone. Apparently other users are experiencing the same issue. Doug – AD8DP, the author of DROID-Star, seemingly doesn’t want to be bothered with issues. His repositories state the applications are offered “as is.” There is no E-mail on his QRZ and the GitHub repository has the “Issues” tab disabled. Normally, the issues option is used to report bugs with GitHub projects for developers or other community members address.

Other links about AMBE and contributing to the projects:

For a breakdown of AMBE and where I was able to find a link to the vocoders: https://www.qsl.net/kb9mwr/projects/dv/codec/ambe.html
Additional vocoder download location with instructions: http://dudestar.gw8szl.com/
GitHub to the first link (pizzanbeer) for vocoder source code, to manually compile, or contribute: https://github.com/pizzabeerllc
There are two groups.io groups for DROID-Star. Neither of which seem to be official but rather run by enthusiasts: https://groups.io/search?q=DroidStar -> Droid Star and DROID-Star
I originally posted this information to the AmateurLogic groups.io and you can follow late-breaking developments.

W9OB meeting. Photo courtesy of Dave – KB9VZU

Although not in our section, I do know they read our OSJ, quick shout out to the Henry County Amateur Radio Club in New Castle, IN – W9OB. I gave a presentation on AllStar Link and linking with digital modes. Been awhile since I’ve done a meeting over the air. Presentation was done using their local repeater via my local AllStar node. If your club would like a presentation on digital and VoIP modes or how my DVMIS works, get in contact with me.

Time off of work or wanting a break from the madness is a great time to get on the air and work special event stations. Some nets will even get children, grandchildren, and neighborhood kiddos in touch with Santa! The Santa Net is held every evening between Thanksgiving and Christmas on 3.916 MHz at 8:15PM eastern time. If HF is not available, the DoDropIn Echolink conference is hosting the Santa Watch Net on Christmas Eve! It begins at 6:00PM eastern on the 24th and runs about 4 hours. Third party traffic is always on the nice list.

On the ARRL Special Event Station calendar, W9WWI is hosting Christmas in Bethlehem on Dec 4. KC5OUR is hosting Bethlehem on the Air, Dec 18-24. N0T, N0R, N0A, N0I, and N0N make up the Christmas Train crew to Celebrate Christmas Time and Holiday Cheer through Ham Radio, Dec 23-26.

Let us not forget, the attacks on Perl Harbor that happened Dec 7, 1941. A number of stations including W2W, W9CAP, NE1PL, N7C, N7D, and N7N will be on the air to commemorate 80 years and the men and women who served.

Thanks for reading. Happy holidays, Merry Christmas, and Happy New Year! 73… de Jeff – K8JTK

Jeffrey Kopcak, MBA – K8JTK

Tag Archives: Digital Modes

Ohio Section Journal – The Technical Coordinator – May 2024 edition

Ohio Section Journal – The Technical Coordinator – April 2024 edition

Ohio Section Journal – The Technical Coordinator – December 2023 edition

Ohio Section Journal – The Technical Coordinator – November 2023 edition

Ohio Section Journal – The Technical Coordinator – February 2023 edition

Ohio Section Journal – The Technical Coordinator – January 2023 edition

Ohio Section Journal – The Technical Coordinator – September 2022 edition

Running multiple instances of Fldigi and Flmsg

Program versions

Ohio Section Journal – The Technical Coordinator – August 2022 edition

Ohio Section Journal – The Technical Coordinator – November 2021 edition

Ham radio and tech.