Tag Archives: M17

Ohio Section Journal – The Technical Coordinator – November 2023 edition

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

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

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

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

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

Now without further ado…

Read the full edition at:

Jeff Kopcak – TC

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.

WPSD Live Caller mode

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.

WPSD Dashboard

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