Tag Archives: TGIF Network

Ohio Section Journal – The Technical Coordinator – August 2022 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,

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:


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

Ohio Section Journal – The Technical Coordinator – December 2020 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 Scott – N8SY 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 Scott 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 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:

Jeff Kopcak – TC

DSCF5081 K8JTKHey gang,

One of the things I’ve been working on during my time at home is the Digital VoIP Multimode Interlink System (DVMIS), also called the K8JTK Hub. About a year-and-a-half ago, I came up with this bright idea to setup a system that would interlink many different ham radio VoIP (Voice over IP) modes for interoperability and experimentation. Through trials and tribulations, it’s experiencing some success, caught the interest of some nets, and a podcast.

Many digital modes sit on their own island and are restricted from crossing over to the analog world or to other digital networks. Some may say this is for quality-of-service but does nothing for interoperability or the ability to link and communicate across different systems. Original D-STAR DPLUS reflectors banned analog connections. My Hub supports ham radio experimentation by allowing hams to discover ways of utilizing a system that can link different modes. Utilization of ham radio spectrum is a priority through the use of hot spots and repeaters. Connections without RF are not a priority. Hamshack Hotline was provisioned because of use in Emergency Operation Centers. Many times, I’ve been asked about stations that don’t have access to RF hotspots or radios. They still have options including the Echolink app on Android and iOS devices, Hamshack Hotline phone which can be purchased for $30 (I’ve heard deals as low as $5 for a compatible phone), or the DudeStar app. The servers are hosted in a Chicago data center to provide resiliency against hardware, power, weather, and Internet outages, but still be fairly inexpensive.

All this is possible through integration of open-sourced packages including: AllStarLink which is a world wide network of Amateur Radio repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. Built on an open-sourced PBX system called Asterisk, Jim Dixon – WB6NIL (SK) built the apt_rpt module emulating functionality of a repeater controller. Jonathan – G4KLX authored programs that support D-Star, DMR, System Fusion, P25, and NXDN which are utilized in MMDVM devices like most hotspots. DVSwitch is a suite of applications for provisioning and operating Amateur Radio digital voice networks maintained by Steve – N4IRS and Mike – N4IRR. The DVSwitch Mobile app was designed to operate analog and digital modes utilizing an Android phone in conjunction with server applications running on a Linux server or Raspberry Pi. The ASL to DMR documentation (groups.io account required) got me started experimenting with these applications and ultimately lead to the build out of the system. XLXD is a multiprotocol reflector server for D-STAR by Jean-Luc – LX3JL & Luc – LX1IQ. Skip – WB6YMH & others maintain thebridge, an Echolink compatible conference bridge.

Originally, hosted on 2 servers, after troubleshooting some issues, it was more reliable to host everything across 3 VPSes (Virtual Private Servers) running Debian Linux. Parts of the system can go down and individual parts will continue to function. Aside from the VPSes, a Raspberry Pi with a Northwest Digital Radio DV3000 provides D-STAR audio transcoding to the system. Wires-X is available through the use of additional remote hardware. Wires-X is proprietary to Yaesu radios and repeaters. Wires-X is not available through open-source implementations such as YSFReflector or MMDVM without additional devices. I’d like to get the DV3000s in a reliable data center but doing so is prohibitively expensive. AllStar Link is the “Hub” that provides connectivity and linking control between all networks.

Putting all of this together provides a system with access to ten different networks and eight different modes! Any user on one network can communicate with users on other networks. Access is available through these nodes and connections:

  • AllStar Link: 50394
  • DMR: Brandmeister Talk Group 3172783
  • DMR: TGIF TG 31983
  • D-STAR: XLX983A (A = Analog Bridge. Pi-STAR = DCS983A, OpenSpot = XLX983A)
  • Echolink: *DVMIS* conference 600008
  • Hamshack Hotline: 94026 (*99 – TX, # – RX)
  • NXDN: TG 31983
  • P25: TG 31983
  • YSF: K8JTK-Hub 31983
  • Wires-X: K8JTK-ROOM 40680 (available upon request)


Amateur Logic episode 149

Building this system has not been without problems. Luckily, I’m able to work around known issues. In order from least frustrating to most frustrating: all programs use IP addresses and ports to communicate, keeping all of that straight was a challenge initially. Using IPs allows for great flexibility utilizing network links such as private networks and VPNs. Dependency hell as a result of additions and changes to programs made a constant deployment from one day to the next an issue. XLXD changed its implementation to include YSF which then conflicted with the port used for the YSFReflector. Changing the YSFReflector port required propagation to Pi-STAR host files and OpenSpot DNS. DVSwitch has been rewritten two times since I’ve implemented it and they’ve released another round of changes. Data center provider choices resulted in issues with packet loss. Moving the servers to another provider yielded much better results. The previous provider finally acknowledged and supposedly resolved the issue a year after it was reported, and after I moved.

Use of physical hardware for D-STAR. OP25 software codec can transcode D-STAR but “you won’t be happy” to quote a post in the forums. D-STAR looooves IP addresses. DNS is great for switching IP addresses easily (like when moving data centers or spinning up different servers). However, D-STAR relies only on IP addresses. As a result, reflector IP changes take about a day to propagate to online hotspots/repeaters. Using AMBEServer with the DV3000 on a remote device resulted in very choppy audio. After some time, had the idea to move Audio Bridge to the same device as the DV3000 then use IP routing to send audio to and from AB. Worked great.

In order to compile AllStar Link from source takes a lot of time to get right and includes A LOT of dependencies. Finally, one that drove me crazy was the chan_echolink module for AllStar which provides Echolink connectivity natively to AllStar. When load testing with many connections, something was making stations sound as though they were transmitting underwater. After observing patterns, determined it was audio originating on the Hub being sent out to Echolink connections. Incoming audio from Echolink stations was OK and audio sent to all other nodes was also good. The problem seemed intermittent until I consulted groups.io and further determined chan_echolink has audio quality problems when more than three EL stations are connected simultaneously. Not ideal for a hub. Best workaround was to implement an Echolink Conference server. Then only allow chan_echolink connection to that conference server. Echolink users would then connect to the same conference server. This issue took a lot of time and a lot of hair pulling but implemented a workable solution that offers a quality system. Root cause is still unknown as an AllStar developer hadn’t chimed-in with any suggestions or possible reasons.

K8JTK Hub/DVMIS connections

The DVMIS hub hosts a couple nets. Tuesday nights at 9pm eastern, since about the first-time stay-at-home orders were put in place, is the Amateur Logic Sound Check net. The net encourages checkins to utilize as many modes as possible during the net to test equipment. If you haven’t seen the Amateur Logic podcast, it has been going for over 15 years and they release two shows monthly. The regular podcast has segments about technology and Ham Radio. “Ham College” is an educational show for those wanting to get licensed or upgrade. The guys asked me to put together a segment for the show. My segment can be found in episode 149. A huge thanks goes out to the ALTV crew and everyone checking into the net which helped me identify and resolve system issues. They’ve also been great in keeping up with all the changes over the last 9 months. At the end of December, I’ve been testing with the West Chester Amateur Radio Association – WC8VOA to add digital modes to their net on Monday evenings at 8pm.

Around the time my segment was airing on ALTV, Brandmeister did not approve of the linking method and linking to other networks. Brandmeister uses the MCC standard and they manage talkgroup IDs consisting of 3, 4, or 5 digits. 6- or 7-digit IDs are repeater IDs and user IDs respectively, and can be used however the assigned owner would like. The BM TG in the ALTV episode is now 3172783 and is correct in the listing above.

The Hub is open for all to use in testing equipment, software, or linking up with friends. I keep status updates listed on the page linked at the beginning of this article. For this and any linked system, please remember a couple practices. When keying your radio, pause a second or two to allow all links to rise, otherwise the first couple words maybe lost. Pause a minimum 3-5 seconds between transmissions to give time for links to reset and other stations to break in. Do not “tailgate.” Enjoy and join the nets to get a feel for the Interlink System’s capabilities.

Slow Scan TV has become big over the last couple years due to ARISS (Amateur Radio on the International Space Station) events. One of the longer events will have begun before OSJ publication: starting December 24 at 16:40 UTC and continue through December 31 ending at 18:15 UTC. Dates are subject to change due to ISS operational adjustments. Images will be downlinked at 145.800 MHz +/- 3 KHz for Doppler shift and the expected SSTV mode of operation is PD 120. Radio enthusiasts participating in the event can post images they receive at the ARISS SSTV Gallery at https://www.spaceflightsoftware.com/ARISS_SSTV/. After your image is posted at the gallery, you can acquire a special award by linking to https://ariss.pzk.org.pl/sstv/ and follow directions for submitting a digital copy of your received image. Even an HT can receive images from the space station. If you would like to receive images using MMSSTV on Windows, head over to my tutorial.

Congratulations to Scott Yonally – N8SY who won his election as Great Lakes Division Vice Director! Since he cannot hold more than one elected position at a time, he will be stepping down from his current Section Manager position when he assumes the Vice Director position on Jan 1. I wish him nothing but the best in his new role as he has done a lot for the Ohio Section during his tenure. We will then welcome Tom Sly – WB8LCD who will be appointed the new Section Manager for Ohio!

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