Tag Archives: Raspberry Pi

Ham radio VoIP and K8JTK Hub DVMIS Presentations

Presentation on Ham radio VoIP (Voice over IP) modes and the K8JTK Hub Digital VoIP Multimode Interlink System which integrates many Ham radio modes, both analog and digital.

Framework

The framework I chose to use for the presentation slides is called reveal.js. It is an HTML framework meaning it will run in any HTML 5 capable browser. Looks a little better than a PowerPoint presentation.

Navigation

Useful navigation keys in the presentation. In addition to navigating with the keys below, you can swipe (tables/smartphones) or use the navigation arrows on screen in the lower right.

Toggle full screen: press [F11].

Advance to the next slide: press [n] or [SPACEBAR].

Go back to the previous slide: press [p] or press and hold the [SHIFT] key while pressing the [SPACEBAR].

Display presentation overview: [ESC] then use the arrow keys or mouse to select a slide. [ESC] again will exit overview mode.

Links

Clickable links are colored in brown text.

Presentations

Three variations are available: presentation version is viewable in a browser. Printable version for printing or saving in a different format (Chrome, Chromium, and variants compatible only). Finally a PDF version.

They may take some time to load because I left original images untouched and some were a couple MB in file size.

Slides

The presentation is around 60 minutes in length.

Version 3

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
West Chester Amateur Radio Association on 7/6/2023.

Version 2

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
West Chester Amateur Radio Association on 5/6/2021.

Version 1

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
Portage County Amateur Radio Service on 3/8/2021.

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:

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

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)

Dashboards:

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

K8JTK Hub DVMIS Presentations

Presentation on the K8JTK Hub Digital VoIP Multimode Interlink System which integrates many Ham radio modes, both analog and digital.

Framework

The framework I chose to use for the presentation slides is called reveal.js. It is an HTML framework meaning it will run in any HTML 5 capable browser. Looks a little better than a PowerPoint presentation.

Navigation

Useful navigation keys in the presentation. In addition to navigating with the keys below, you can swipe (tables/smartphones) or use the navigation arrows on screen in the lower right.

Toggle full screen: press [F11].

Advance to the next slide: press [n] or [SPACEBAR].

Go back to the previous slide: press [p] or press and hold the [SHIFT] key while pressing the [SPACEBAR].

Display presentation overview: [ESC] then use the arrow keys or mouse to select a slide. [ESC] again will exit overview mode.

Links

Clickable links are colored in brown text.

Presentations

Three variations are available: presentation version is viewable in a browser. Printable version for printing or saving in a different format (Chrome, Chromium, and variants compatible only). Finally a PDF version.

They may take some time to load because I left original images untouched and some were a couple MB in file size.

Slides

The presentation is about 10 minutes in length which aired on the AmateurLogic.TV podcast on 11/13/2020 for episode 149.  It includes additional slides referenced in the video segment.

Presentation version
Printable version
PDF version

Segment:

Ohio Section Journal – The Technical Coordinator – September 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:

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

DSCF5081 K8JTKHey gang,

On this month’s edition of “Pi Talk” – just when you thought I couldn’t talk about Pi anymore! I received a question from Chet – K8KIZ who has a laptop used for station operation. He wanted to replace it with a Raspberry Pi. In searching, he found way too many choices and wanted help to set him on the right path. This might be a question that others have or one they are considering. He soon found out it was a lot more complicated than originally thought.

Over the past number of years, I’ve done a lot of integration work which involves making one system or application talk to or replace another. It frequently involves bridging communications with other services such as databases or API’s (application programming interface) and facilitating data flow between them. Sales, Account Managers, and System Engineers for the new vendor will always throw around buzzwords and catch phrases – “setup and integration are easy and seamless,” “automated,” “zero configuration,” “drop-in replacement,” “pays for itself in three days” (not really), “reduce costs.” List goes on and on. It is never any of those things.

They have absolutely no idea about your environment, how involved, and how costly it will be to utilize their services. They just want you to buy them. Soon after comes the nickel-and-dimming: “you want to process how much data? That’s an extra couple thousand dollars” or “that doesn’t come with the license you purchased, that will cost you an extra-large-number with many 0’s!” Internal business units do this too. They weren’t prepared or made it seem like they are in position to handle a situation and were not. Feature requests take an extraordinarily long time to implement or claims of not having enough man-power soon follow.

The FCC is in a situation similar to this or they’re making it seem like they are: ‘oh, our licensing process is all digital and we can eliminate that pesky licensing fee!’ And the peasants rejoice. Reading the latest news about the FCC wanting to reinstate license service fees, “…we propose a nominal application fee of $50 due to automating the processes, routine ULS maintenance, and limited instances where staff input is required.” Wait, isn’t that why they went digital to reduce these costs? Someone sold them a bill-of-goods that didn’t actually reduce their costs or they’re looking to recoup costs elsewhere.

Not wanting the same thing to happen to Chet, where the alternative didn’t actually improve his situation, I took the approach of having him think about his station. What does he use his station for and what he would consider “a success” of replacing his laptop with a Raspberry Pi? Anytime anyone is looking to replace X with Y, an evaluation of this nature. What is X used for and are the pros/cons of Y sustainable?

In Chet’s case, replacing a laptop used for ham radio with a Raspberry Pi, he would need to consider things such as:

  • Is the current laptop setup Windows or Linux?
  • If it’s Windows, would he want to climb the Linux learning curve?
  • Is he using any software apps that are Windows only? Examples would be: RT Systems programmers, Ham Radio Deluxe, N3FJP logging, SmartSDR, N1MM, Wires-X, etc., etc.
  • Can those Windows only apps be replaced by Linux apps – and are those Linux apps equally as good?
  • Does he have any hardware requirements (like multiple serial or parallel ports)? The Pi has UART via GPIO pins but two or more serial ports require USB-to-Serial converters.
  • How many USB ports are required? Pi’s only have 4. 2 ports would be taken up by using a wired keyboard and mouse.
  • Do all of his hardware devices and interfaces work in Linux? These would be things like radio programming, control (CI-V) or firmware flashing, audio mixers and audio interfaces.

This is not an all-inclusive list especially since I didn’t know anything about his station – though I seem to remember he was into Vibroplex CW key tuning and repair from a local hamfest. I thought through scenarios that might apply to the majority of HF operators and came up with that list.

G4DPZ running GPredict on a Pi (amsat-uk.org)

Some Windows programs can be run under Linux using a compatibility layer program such as WINE or run virtual machines (VMs). That would contribute to the Linux learning curve. Raspberry Pi isn’t powerful enough today to run VMs. VMs or hypervisors maybe an option for some Linux desktop/laptop situations.

Instead of wired keyboards and mice, Bluetooth devices could be a replacement option but are more costly. Wired is preferred to wireless for reducing interference problems. Built-in antennas for Bluetooth or Wi-Fi aren’t going to be as good as laptop antennas. Additionally, monitors without HDMI or mini-HDMI connectors will need adapters, cables, or outright replaced if it doesn’t have compatible connectors. USB hubs are an option for expanding the number of USB ports. I have yet to find a USB hub that is problem free. They don’t work well with some operating systems, attached devices do not fare well with temporary connection interruptions, and they tend to break down after a short time.

Best way to track these considerations and more is to make a list. Start by looking at all connections to the existing laptop, both physical and virtual (like with an SDR). Include any software used during operating (radio control, prediction modeling, packet, digital, etc.). Programming radios? Those tend to be Windows (or DOS) programs along with firmware updaters. If using a Raspberry Pi is still desired, another Windows machine will be needed for programming and firmware updates. Include all of these in the list and evaluate solutions on the Raspberry Pi or Linux platform for alternatives that meet the requirements. Consider splitting non-supported, but essential, functionality to another Windows machine.

Another way to approach evaluation would be to operate with a new “Pi” system, hands-on, but keeping the old system up-and-running nearby. The old system would be used as a reference for program settings, coping or migrating data files (such as export from one and import to the other), and a comparison point when evaluating Linux programs.

Lastly, completely ditching the previous system and entirely starting from scratch is an option. This type of evaluation style is more draconian by ripping and replacing. Most people have their own operating style and rarely want to deviate from their ritual. Rip-and-replace might be needed if they’re fed up with a current setup and want to start over with something else. The operator, in this case, would not care about migrating previous data, starting out anew, and take whatever options are offered by a different platform.

Raspberry Pi 3 projects for Ham Radio with 7-inch touchscreen (qrznow.com)

To future proof, I’d recommend going with the latest version of the Pi. Currently, that would be a Raspberry Pi 4 Model B with at least 4GB RAM ($60), 8GB ($90) if able to spring for the extra RAM. Quality of the power supply and SD card plays a role in stability as I talked about in July. Data corruption possibility is still not zero. Even on a desktop PC. Corruption seems to be more prevalent on Pi’s, likely because of cheap components chosen by the user.

I strongly recommend making frequent data backups. This applies to any system. There should be 3 copies of data: the local copy (on the Pi), another copy on a storage device like a USB Hard Drive or Network Attached Storage (NAS). A third copy, off-site, located at a friend’s house, relative’s house, or a work location. Another off-site storage location would be cloud storage or backup service provider. Think about where you would be if you lost those LOTW logs, FT8 contacts, SSTV images, or Winlink messages. This strategy is known as the 3-2-1 backup strategy and should be used for ANY important data. 3 copies of data, 2 on different medium, and 1 copy off-site.

Starting out, I would consider the “Ham Pi” or “Build a Pi” projects I discussed in August initially. “Ham Pi” has just about every Linux ham radio application pre-installed. That would allow an operator to try different programs, find one that suits their needs or one they prefer. “Build a Pi” can be a little more tailored to operating style. You can also get down and dirty by compiling programs from source, depending on Linux experience or desire to tinker with Linux.

That just about covers broad considerations. Chet realized this was a larger undertaking than finding a plug-and-play option. He appreciated the analysis of the issues at hand. I hope he is able to find a working solution to replace his station laptop. When considering major overhauls such as this, know that for most people, it’s a little more complex and involved than most realize.

A quick note about Winlink. The WINMOR protocol has been deprecated systemwide and will soon be removed from the client software application. First introduced by Rick – KN6KB in 2008, it was the first ‘sound card’ mode offered by Winlink as an alternative to modem hardware needed at the time. Rick and the Winlink Team have moved on to developing robust and speedier protocols such as Amateur Radio Digital Open Protocol (ARDOP) and VERA HF. RMS gateways will only support ARDOP, VARA HF, and Pactor 3 or 4 (where applicable) near term. If you are still using WINMOR, it’s likely been hard to find gateways that support the protocol because sysops have been asked to remove in favor of the other modes. WINMOR had a great run and was the mode I used when I first got on Winlink.

Thanks for reading and 73… de Jeff – K8JTK

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

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

DSCF5081 K8JTKHey gang,

My article last month covered Raspberry Pi and problems users have experienced with the Pi 4 since its release last year. I gave some tips for keeping your Pi running like a top including choosing better power components, SD cards, and having the Pi run cooler despite higher idle temperatures. This month will cover recent projects you can make with the Raspberry Pi to learn about the device, computer programming, or Linux.

Ham Pi – formally the “W3DJS Raspberry Pi for Ham Radio image” is an operating system for the Raspberry Pi with over 80 ham radio applications pre-installed – which include digital modes, APRS clients, antenna programs, SDR, Morse Code, radio programming, and more. Dave wanted to have a Pi image loaded with any ham radio software application he might ever want to use. He initially shared it with a few club members and soon realized there was demand when his image had over 8,000 downloads. Since then, the build process is automated using an Ansible playbook. The playbook is also available on his github which is useful if you want to learn a provisioning technology or build your own customized version. A long time ago, I wrote instructions that just compiled Fldigi and Flmsg on a Pi2 for a go-box. Ham Pi is a definite must for anyone that has a Pi already in their go-box or wants to add one to an existing box.

Build a Pi – wanting a way to have ham radio applications installed on a Pi, Jason – KM4ACK wrote a script that does just that. Having many issues with the first couple implementations, which were mostly copy-and-paste installs, it was not flexible enough to update applications once installed. Version 3 includes an automated way of installing and configuring both ham radio applications and the operating system on a fresh Raspberry Pi OS installation. Differing from Ham Pi in that a stock Raspberry Pi OS download can be used, the user can also pick-and-choose which applications they want to install. A quick tutorial video is available.

Rig Pi Station Server – is a Raspberry Pi that controls your station and on-air activities. With a Station Server install and web browser or smartphone app, you can control a radio, rotor, use CW, operate digital modes, look for spots, and even upload your log. If you don’t want to spend much time learning about the Pi or Linux with the above projects, this is the way to get on the air remotely as quickly as possible. Hackaday did a review on the Rig Pi Remote Server.

“Rig Pi” may sound familiar because it was picked up and packaged by MFJ as the 1234 with a Pi and audio interface HAT. Before I receive complains (I’ve already seen them online), you can download the help and schematics as well as any of the software on the github repository absolutely free. Rig Pi is open-source. Not only that but no one needs to buy the commercial package. It can be installed yourself. People that complain about “selling” open-source projects really don’t understand how that typically works. It is common practice to release an enterprise grade software application as FOSS (free and open-source). A company/individual/whomever will make money on their application by selling licenses, services, or hardware. Same concept here. Assuming the license allows it, a vendor can package the program as part of a device. I’m going to assume the developer is getting a cut or donation as part of MFJ’s sales (but I don’t know this) as the product is promoted on the project page.

Pi-Star – create a digital hotspot or repeater with a Pi and transmitter. Providing complex services and easy configuration via a web interface, Pi-Star solved the problem of fragmentation when different hotspot boards all had their own Pi image. Most didn’t work well if at all. Pi-Star solved that problem by providing an easy to use interface for the beginner and allowing a tinkerer to dig deep into settings. Using the MMDVM suite from G4KLX, it can operate DMR, D-STAR, NXDN, P25, and System Fusion (depending on modem) and use many different protocols. This software is packaged and sold with different hotspot devices such as the ZUMSpot. Another example of software being packaged with hardware and sold commercially.

Ultimate Raspberry Pi Build

Ultimate Raspberry Pi Build – Julian – OH8STN from Finland covers topics related to off-the-grid and grid-down operating. He brings us an excellent instructional video on making a very portable QRP digital station using a Raspberry Pi. He set out to build a smaller and, in turn, much more portable setup than is available commercially with other devices. This video details hardware mods, HAT options, and software needed to operate digital, off-grid, from anywhere.

PiClock

Pi Clocks – a couple of clock projects are available depending on your level of interest. The first one is created by Kevin – N0BEL. It’s not a project specifically for Hams rather for anyone interested in making a nice weather display. His PiClock is a clock (“duh” – as he says) with weather forecast and radar map display. Though it could be used in the shack, it is better suited for a common area in the house, such as the kitchen, with an HDMI monitor. Everyone likes weather information. Emile – KE5QKR from Amateur Logic did a PiClock tutorial.

HamClock project – from Elwood – WB0OEW is geared toward the ham shack. It has clock (again, duh), current temperature and weather conditions, solar conditions, VOCAP predictions, satellites, DX spots and daylight map. His project can be built on any UNIX-like operating system including the Raspberry Pi. It cannot run naively on Windows but can run on a Unix system and displayed on Windows using X server forwarding. This has the appearance of a regular Windows application. Tommy – N5ZNO of Amateur Logic did a segment on setting up the HamClock.

Open Repeater – I lost track of this project. I first heard about it back in 2014 when they didn’t yet have a domain name for the project. Goal is to create an open-source and simple to use repeater controller. Utilized for high-profile repeaters or basic simplex nodes, the software walks the user through setting up a repeater controller. Owners can have traditional Morse IDs or create longer messages at every hour via audio recordings. Having SVXLink at the core allows seamless integration with VoIP modes like Echolink. Additional modules can be added to the core package providing more functionality.

Pi-Hole – not specifically Ham Radio related but a fantastic network appliance. DL6ER, a ham radio operator in Germany, is a Developer and Administrator for the project. Pi-Hole acts as a Domain Name System (DNS) sinkhole (returning a fake value) which blocks devices on a home network from accessing ad sites, trackers, or other malicious websites. Though originally intended for Raspberry Pi devices, it has been expanded to include any Linux operating system or docker container. It doesn’t filter bandwidth or inspect network traffic. The Pi-Hole acts as the DNS server for a home network instead of your ISP. DNS is referred to as the “phone book” of the Internet by looking up names such as arrl-ohio.org and returning the IP address in order for a network device to access the server hosting the Ohio Section website. When a request for a blacklisted website (such as some-malicious-website[dot]com) is requested, Pi-Hole intercepts and returns a different IP address so the access request will never reach the Internet. This is better compared to a web browser plug-in because Pi-Hole is inspecting DNS requests for all network devices.

Pi-Hole Dashboard (Wikipedia)

It’s great to block trackers and ad sites in theory, keeps digital footprints to a minimum and reduces the chance of fraud through scareware-type tactics. In practice, it often blocks couponing and deal websites as well as promotional email links from a favorite restaurant. Those emails are coded to tell the sender which links a recipient clicked and can be used to measure the effectiveness of an advertising campaign. Whitelist exceptions can be granted though the very nice web interface when legitimate sites are blocked. I have a similar application running on my network. After I received complaints about sites being blocked (but they wouldn’t tell me when there were problems to create exceptions), I disabled this blocking all together, effectively opening up the Internet. Within 10 minutes I was asked to turn it back on as pop-up ads immediately started to appear stating ‘your computer is INFECTED.’ Scared the, uh, stuff out of some. Other issues involve in-home advertising and monitoring devices, like Alexa, which freak out when the device can’t reach its severs. These devices flood the local network with hundreds of DNS requests per second. Smart TVs and Rokus often have similar problems when they can’t reach their servers to track what is being watched. Data feeds containing bad sites are aggregated for free, so you get what you pay for. Sites are frequently categorized as bad when they really aren’t. Some are legitimate services. Blocking these sites could cause undesired behavior, for example, using a favorite streaming TV service where you may receive errors.

Windows 10/desktop replacement – with the power and speed of the Raspberry Pi 4, many are finding ways to install traditional operating systems. Windows 10, in its many flavors, has an IoT stripped down version for devices like the Pi. The guide at Tom’s Hardware shows how to get the full desktop version of Windows 10 running on the Pi. It’s a little sluggish and not for the faint of heart but if you screw up, just start over.

There are plenty more ham radio and non-ham projects to do on a Raspberry Pi. Applications listed in the first couple projects can be installed standalone for single use setups such as a Slow Scan TV (SSTV) receiver when the International Space Station is sending images. A friend in Toledo recently used my instructions to setup an APRS RX Igate. DL1GKK’s site has instructions on installing ham radio applications as well. Raspberry Connect contains a list of ham radio applications that can be installed through the apt package manager which simplifies installation. There is no shortage of things to make on a Raspberry Pi.

Grant Imahara (Wikipedia)

News missed my article last month, but I wanted to mention the passing of Grant Imahara at 49 years old due to a brain aneurysm. Most probably never heard the name but have undoubtedly seen his work. Not a ham radio licensee that anyone can find, Grant was an electronics genius and maker in the truest sense of the word. Landing jobs at ILM (Industrial Light and Magic), the George Lucas special effects company, he modernized R2D2. He was one of three official domestic operators of the droid for the Star Wars movies. His special effects movie credits also include The Lost World: Jurassic Park, Terminator 3, and Matrix movies. Grant also competed on BattleBots where his robot was often highly ranked. The robotic sidekick on “The Late Late Show with Craig Ferguson” was also Grant’s creation. He was a designer for the animatronic Energizer Bunny seen in commercials. Joining MythBusters in 2005 is where I picked up his career in front of the camera during my college years. The program took on myths, legends, and Hollywood lure to see if they translated to real-life – oh, and they liked to blow stuff up. Grant not only provided technical expertise but participated in experiments and designed machines to take the place of a person for myths that were too dangerous. A tragic loss and he will be missed.

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – July 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:

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

DSCF5081 K8JTKHey gang,

Since its release, the Raspberry Pi 4 has had a couple problems. It’s not the first device in the lineup to have hardware problems. Raspberry Pi devices are single-board computers that are about the size of a credit card. The smaller Raspberry Pi Zeros are about the size of a 9-volt battery. Created to foster Computer Science in schools, they have become very popular with robotics, weather monitoring, and even ham radio. Size makes these devices very portable, they draw minimal power, and cost anywhere from $10 – $75 for a high-end model. In addition, they are capable of running Linux which makes them a great substitute for single applications or toying around with Linux – versus using older PC hardware consuming more power.

Raspberry Pi Zero and 9V-battery (lifehacker.com)

Dubbed the Xenon Death Flash, electromagnetic radiation penetrated the wafer-thin packaging of an on-board chip responsible for switching regulation. Taking a flash picture of the Pi would cause the entire board to shut down. A Power over Ethernet (POE) Hardware Attached on Top (HAT) module had major power fluctuations and delivered significantly less power to the USB ports than normal. The POE HAT was delivering 200mA. 500mA is standard through a USB 2.0 port.

This time around, the Pi 4 lineup was released but not all the necessary drivers were made available in the official Raspbian Operating System. A minor annoyance. This is an easy fix in software and corrected shortly after release.

Die resposible for the Xenon Death Flash in the WL-CSP package, enormiously magnified (raspberrypi.org)

The issue that received all the press: USB-C power port on the Pi 4 didn’t follow published specifications. USB-C connector is a symmetrical connector meaning it is reversible. Designed to deliver high power for charging, digital audio, digital video, and high-speed data. Android users are familiar with these connectors as phones in the last 4 years utilize USB-C replacing the Micro USB connector. Popular on PC docking stations as it allows the laptop to be charged while driving multiple HD monitors, including audio, utilize high speed Ethernet, and regular USB connections – all at the same time. E-marked (or electronically marked) cables will connect more of the 24 pins found in the USB-C connector unlocking features like additional power. These cables are found on power supplies of advanced devices such as Apple MacBooks and other laptops. These USB-C E-marked cables were a problem for the Pi. Non-E-marked cables worked fine.

In February, it was officially announced that a fixed model was available for the USB-C problem. How do you tell which board has the fix? That’s a little more complicated. Speculation is that board version 1.2 is the fixed revision. If you feel up to modifying an existing board by hand, that can be done too (insert standard disclaimers here). Best advice was to get a newer board and try it with an E-marked cable. Good going, guys.

That’s it, right? Not so fast. I found a post over at Hackaday that reported cranking up the HDMI resolution jammed the Pi’s own Wi-Fi. Using a display resolution of 2560×1440 (QHD resolution), the Wi-Fi drops out. At that resolution, the Pi emits noise in the range of Wi-Fi channel 1. Using a different channel might work but causing unnecessary RFI to other Wi-Fi users is unacceptable. The Raspberry Pi Foundation acknowledged the issue and issued a firmware update a few weeks later. Update the Pi using: sudo rpi-update at the command line if you haven’t done so in the last number of months.

I get it, designing things is hard especially devices that cost $35 and USB-C specifications running 329 pages. You would think the spec thoroughly covers power delivery but it does not. Consumers hope these issues would come out in testing and be fixed before they make a purchase. Working in the Information Technology field, likely these problems were observed in testing but was shrugged off as an ‘anomaly’ or ‘unable to reproduce’ or ‘affects a limited number of deployments.’ When the problem makes it into production and customers start complaining because everyone can now reproduce the problem, it gives customers a bad feeling about the device and company. Especially repeat offenders.

MacBook USB-C connector (wikipedia.org)

Unfortunately, the Great Lakes Division Convention and Toledo Hamfest was canceled in March due to the closure of the state. In my Raspberry Pi presentation, I was going to cover general tips when experiencing issues operating your Pi. They often boil-down to: crappie components. Stop buying the cheapest option overseas and expecting grade A+ performance!

90% of the time, problems are power related. “Under-voltage detected!” in the system logs are the result of an under powered 5V power supply, one that cannot deliver consistent voltage, insufficient AWG power lines of the USB cable, or both. Early Pi’s (Pi 1) can get away with a 1A power supply. Pi 2 & 3 really need a 2A. Pi 4 need 3A USB-C. The Pi’s will only draw as much power as needed.

Everyone forgets about the USB/power cable from the supply to the Pi. Not all cables are created equal! Power supplies with wired cables can be assumed to carry the full output of the supply to the device. A power supply can output 2A but the connecting USB cable is likely limiting power delivery due to the wire gauge. For delivery of 2A to the Pi requires a cable rated 28AWG/24AWG. This is printed on the cable itself. The first specification is the data cable wire gauge (28AWG) and doesn’t matter for carrying power. The second specification (24AWG) is the power cable gauge. Unless specifically printed on the cable, cables can be assumed to be a lesser 28/28 specification. A lower number is better in this case.

This is the reason a cell phone will seem to charge slower. I had an OEM cable that came with a new cell phone rated 28/28. The phone would charge for hours. When I upgraded to a 2A power supply and a 28/24 cable, it was charged in under 90 minutes from drained. This only really apples to Android devices because they use standard connectors. Genuine Apple chargers and Lightning cables will meet Apple’s specifications for device charging.

It is hard to find the AWG rating because most sellers don’t list it. One place that does list that spec is Monoprice. This Type-A to Micro Type-B cable will work for a Raspberry Pi (not 4) as a replacement cell phone USB charging cable. Keep the cable as short as needed. Don’t use 15 feet when 6 will do because it will reduce the amperage that reaches the device.

Crashes and SD card corruption problems are often attributed to bad power too. However, the aforementioned quality of the component itself also plays a role. Look for SD cards with lots of positive ratings. Most often recommend are SanDisk SD cards. I’ve had no reliability issues with G.Skill cards either. Quality 32GB MicroSD cards are under $10 these days. Validate the card is at least “class 10” which is usually signified on the card itself by a “C” and a “10” in the middle of the C. They come in classes 2, 4, 6, 8, or 10 – with 10 being the fastest. UHS (Ultra High Speed) cards are on the market and are slightly more expensive at over $20 for a 32GB UHS-3. UHS will have a “U” with a “1” or “3” in the middle. Class 10 and UHS 1 are equivalent in write speeds at 10MB/s.

Raspberry Pi 4 USB-C power port modification (raspberrypi.org)

Pi 4 generates significantly more heat than their predecessors. I’ve heard estimates of 50% more heat is generated while idle compared to the Pi 3. Many cases include a fan which is a moving component that could fail and be a problem if the device is at a hard-to-reach location. Heat sinks are an alternative, assuming decent airflow. The Raspberry Pi Blog includes tips and updates to lessen CPU temperature.

Does your project require the latest and greatest Pi board? Consider the project. Will all that processor power and memory be utilized? An upgrade to a USB-C power supply is required for power and micro-HDMI cables/adapters if you plan to connect a monitor to a Pi 4. It may come down to price. I see many places currently charging more for the Pi 2 and Pi 3 than a 4. Pi 2 is sufficient for headless wired Ethernet applications. Pi 3 if a little more CPU or Wi-Fi/Bluetooth features are needed.

Pi 3 and 4 boards include a 64-bit processor. As of this writing, the Raspberry Pi foundation has not made an official 64-bit Operating System release. Though a beta is available. The Pi 3 boards have been out since February 2016 and the Pi 4 boards since June 2019 – and there’s still no official 64-bit OS? A 32-bit OS can only address 4GB of RAM (4,294,967,296 possible addresses) and no Pi had more than 4GB. Other images for the Pi have taken advantage of the 64-bit processor. The Pi foundation still recommends the 32-bit OS for all Pi devices.

An announcement at the end of May unveiled a new Pi 4 addition, an 8GB RAM version for $75. Some minor improvements were made but the device is basically the same as the other Pi 4 versions. A 64-bit OS will be needed to address all 8GB of RAM though. In the same announcement, the official Raspberry Pi Operating System images are now renamed to “Raspberry Pi OS.” It will no longer be referred to as “Raspbian” though the name will probably stick around out of habit. The name change will likely be gradual over time. A card I burned with the new Raspberry Pi OS still referenced Raspbian in /etc/os-release.

Next time I’ll talk about (mostly) ham radio things you can do with the Raspberry Pi.

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – June 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:

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

DSCF5081 K8JTKHey gang,

As Technical Coordinator for the Ohio Section, I oversee the section’s group of Technical Specialists. The Specialists and I are here to promote technical advances and the experimentation side of the hobby. We encourage amateurs in the section to share their technical achievements with others in QST, at club meetings, in club newsletters, hamfests, and conventions. We’re available to assist program committees in finding or providing suitable programs for local club meetings, ARRL hamfests, and conventions in the section. When called upon, serve as advisors in issues of RFI and work with ARRL officials and appointees for technical advice.

The Technical Specialists really make all this happen. In the Ohio Section, there are about 15 qualified and competent Specialists willing to help. They meet the obligation of advancing the radio art bestowed to us by the FCC. The TSes support the section in two main areas of responsibility: Radio Frequency Interference and technical information. EMI/RFI includes harmful interference that seriously degrades, obstructs, or repeatedly interrupts a radio communication service such as ham radio or public service agencies. RFI sources range from bad power insulators, industrial control systems, other transmitters or poorly made transmitters, personal devices like computers, monitors, printers, game consoles, to grow lights and poorly made transformers – including one’s hams brag about getting from China for a few dollars. I die a little inside when I hear this. Our Technical Specialists can help track down interference or locate bozo stations. Technical information is a wide-ranging category including everything from antennas to Zumspots.

How can we help? The knowledge and abilities of YOUR Technical Specialists are really quite impressive. Here are some examples:

  • Antennas (fixed, portable, and emergency operation type) and feedlines
  • Antenna systems such as towers, guying, coax, and baluns
  • RF and tower safety
  • Grounding
  • Propagation
  • Electronics and circuits
  • Tube technology, aka boat anchors
  • Digital modes – including D-STAR, DMR, Fusion, P25, APRS, IGates, packet, MT63, FT8/4, Olivia, PSK, and using programs like Fldigi
  • NBEMS – Narrow Band Emergency Messaging System
  • Computers, Windows and Linux, Raspberry Pi
  • Embedded devices
  • Networking: IP networks, AMPRNet, routers, firewalls, security, mesh, and microwave
  • Repeater controllers and high-profile systems
  • Internet and VoIP linking systems – Echolink, AllStar, HamVoIP, DVSwitch, and PBX/Asterisk
  • RFI detection from power lines and consumer devices including working with governmental agencies to track down interference
  • Professional certifications such as Motorola Certified Technicians, Certified Journeyman Electronics Technician, General Radiotelephone Operator License (GROL), and Society of Broadcast Engineers (SBE) affiliations

This impressive list of qualifications is an available resource to all in the Ohio Section. Looking for help in one or more of these areas? Need a program for your club? How about a technical talk or forum at your hamfest? Assistance or direction on a project? Feel free to contact myself. My contact info is near my picture and on the arrl-ohio.org website. I’ll assist getting you in touch with an appropriate Technical Specialist. One of the Specialists might hear a plea for help and reach out to you as well.

Over the last month, we gained 3 new Technical Specialists! I would like to welcome Nick – N1TVI who is a Certified Journeyman Electronics Technician and brings experience in commercial radio systems. He is Trustee for the Northern Ohio Digital (N8NOD) repeaters in the northern Ohio area. Other experience includes repeater systems, power, grounding, and antenna systems. Jason – N8EI brings us his experience in repeater building and maintenance for the W8WKY machines in Doylestown and others, supports SHARES organizations, voice and data digital modes, and IP technology. Last, but not least, John – N8CD is co-builder of many multimode repeaters and an AllStar linked repeater system. Both John and Jason maintain a resilient network of 5.8 GHz microwave and Internet links that connect repeaters they and others maintain. They put a lot of work into their network implementation and use AMPRNet (network 44) IP addresses. Welcome to our newest Technical Specialists! Contact them or myself should any of those topics be of interest to your club or hamfest.

Pi-Star Update

Pi-Star 4.0 was released in beta earlier this year and 4.1 available as general release since most of us have been working from home, March 2020. According to the change log, these later versions bring many improvements for cross-mode support. These are YSF2xxx and DMR2xxx options: YSF2NXDN, YSF2P25, YSF2DMR, DMR2NXDN, DMR2YSF. There is no direct way to upgrade from 3.4.x or previous to 4.1.x. You must reflash your existing installation card or flash a new SD card. A new card is preferable in case you have a problem with the new version, pop-in the old SD card and boot. If your hotspot is a Pi-Zero, you should not overwrite your existing install right-away and give the new version a try on a separate card first.

Pi Zero W with ZUMSpot GPIO HAT board, compared to a quarter

Perform a backup in the web interface on the existing device. On the Dashboard, click Configuration, login, then click “Backup/Restore.” This will download a ZIP file with Pi-Star settings to your PC. Boot the new SD card and perform a restore by uploading the same ZIP file. I noticed some settings previously set were defaulted to initial values in the web interface. Do a once over for important settings and re-set them as necessary.

Pi-Star runs on nearly all Raspberry Pi models with a supported digital modem. It solved a problem, 3-4 years ago, when everyone making their own Raspberry Pi digital interface board with their own operating system image. It was anyone’s guess as to which worked and which was the “best” option. None of them worked well or consistently between users. Pi-Star solved that problem by taking the MMDVM software that can “speak” many different digital modes and network types, implemented a web front-end, and supported nearly all digital hardware boards. Once I got the hang of Pi-Star, I became a fan. The site by KE0FHS is probably the most complete documentation “notes” of the Pi-Star in one place. It’s a good read and provides a lot of great information about Pi-Star. I came across it looking up how to do custom host files for private reflectors.

One thing Andy – MW0MWZ, who wrote the Pi-Star web configuration front end, pointed out on the website was the move to Raspbian Buster for version 4.1 has been “painful” – citing missing drivers in releases among other issues. My experience with Pi-Star 4.1 on a Raspberry Pi Zero W was also painful. I’ll preface this by saying I tried 4.1 on a Raspberry Pi 3B and had less problems. I have a ZumSpot GPIO HAT for the Raspberry Pi. On the Pi Zero, after booting the first time, I was frequently greeted with weird errors and timeouts trying to configure the hotspot. Some settings were not remaining after I “applied changes.” Selecting my ZumSpot HAT from the modem list and saving, I would get a subsequent message saying I needed to select my modem from the list. Doing this a handful of times it would finally save. I saw ‘gateway timeout’ messages on both the Pi Zero W and Pi 3 during the first configuration session. I was able to seemingly avoid the timeout and configuration issues if I booted the Pi-Star on the new SD card and didn’t touch or connect for 15 minutes. Plug-it in and walk away for 15 minutes.

Pi-Star dashboard (v3.4)

Once I figured that out, configuration went smoother. The web interface, though, sluggish is a nice way to put it. On the Pi Zero W with a fully updated Pi-Star 4.1.2 install, making any changes on the configuration page would take (on average) 1:45 to save. That’s right, one minute and 45 seconds. This is unusable. I’m changing modes constantly. Think about a net you forgot about. If you have to turn off one mode and turn on another, that’s 1:45 right there. Needing to make further changes to the newly enabled mode (change previously used reflector or network), you’re looking at 5 minutes before you’re on the net – if you don’t screw up. Some nets are over in that time. In comparison: 3.4.17 is at a somewhat more tolerable 45 seconds to save using a Pi Zero. Running both versions on a Pi 3B was nearly identical at about 25 seconds after clicking apply.

CPU load was much higher using 4.1.2 on the Zero. I suspect the under-powered nature of the Pi-Zero, OS and kernel upgrades in addition to the updated code of MMDVM and associated modules is causing these delays. As popular as the Pi Zero form factor is for addon boards and portability, it’s just waaaaaaay to slow for me to be useful. Not making configuration changes in the dashboard you won’t notice these issues so much because it runs fine otherwise. Stick with 3.4.17 on a Pi Zero or consider moving to a faster Pi like the 3B if you need 4.1.2 features now.

K8JTK Hub – now with P25 & NXDN

A quick update on my interlink system pet project, K8JTK Hub, I was able to add two more modes: NXDN and P25. Both are TG 31983 using hotspots or repeaters running the MMDVM software. If I include Wires-X (because it’s not full-time), that’s 6 digital systems and 3 analog systems – a total of 9 – that can communicate with cross mode interoperability. Being part of the AmateurLogic.TV net on Tuesday evenings, I determined packet loss was causing frequent data drops and disruptions. I moved the system to a new provider and that has remedied the problem. The net right after saw a significant improvement in data stream reliability. Huge thanks to the AmateurLogic guys allowing their net to be a load test of the system. They have a lot of fun with it as participants check into the net multiple times testing different modes. The Hub is open for all to use and for testing setups, all the ways to get connected are available here.

Field Day Bonus Points

Field Day will likely be completed by the time you read this, keep this in mind for next year. Sending 10 messages over RF from your site gets you 100 bonus points – including Winlink messages. I love to receive messages about your setup, stations, operating, or social activities taking place. These can be sent via the National Traffic System (NTS) or Winlink – K8JTK at Winlink.org – to my station. The Field Day rules state messages must leave via RF from the site (7.3.6). It does not state “formal messages” be in any particular format or utilize any particular network. A message to the SM or SEC must be in radiogram format and leave via RF or no credit will be given (7.3.5). If there is any question or problems, send the message using the NTS network or Radiogram form in Winlink.

With July around the corner, if you’re looking to do something while flipping burgers at your 4th of July picnic, my favorite event is the 13 Colonies Special Event which will be on the air July 1 – 7.

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – July 2019 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:

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

DSCF5081 K8JTKHey gang,

The latest addition to the Pi family is here – Raspberry Pi 4. Boasting impressive upgrades, this latest version of the device is becoming a suitable replacement desktop PC or multimedia device. Pi 4 keeps the same form factor and still remains competitive at the $35 starting price.
Device highlights:

  • 64-bit quad core processor running at 1.5 GHz with built-in metal heatsink
  • 1 GB, 2 GB, or 4 GB RAM configurations
  • 2 USB 3.0 ports
  • 2 USB 2.0 ports
  • Gigabit Ethernet with Power over Ethernet (requires separate PoE HAT)
  • 2.4 and 5 GHz Wireless LAN
  • 2x micro-HDMI ports supporting 2 – 4K monitors
  • Micro-SD card slot for operating system and storage
  • 5V DC USB-C power connector
  • Standard Pi 40-pin GPIO with 5V DC

Instead of a single memory configuration, a new tiered pricing structure was introduced for the three different RAM configurations:

  • 1 GB: $35
  • 2 GB: $45
  • 4 GB: $55

Even the 4 GB model is very reasonable at $55. The addition of USB 3.0 and Gigabit Ethernet allows for faster network and data transfers. Great for rolling your own network storage or video streaming server.

The form factor remains the same but due to changes in the power and video connectors, existing Pi cases will not fit. The power connector changes from a micro-USB to a USB-C connector. Probably in an effort to alleviate the most common problem using the Pi, finding a quality power supply, the Raspberry Pi Foundation is selling an official USB-C 15W power supply. Micro-HDMI cables or adapters are required to connect a TV or video display.

Noobs/Raspbian remains the official operating system and comes with a push to the next version from Raspbian Stretch to Raspbian Buster. Existing Pi installations can benefit from a hardware upgrade even using the same SD card in a new Pi 4. MAKE SURE you have updated the Raspbian operating system to take advantage of the new chipsets. Existing installations WILL NOT work without an operating system upgrade. Availability in other Raspberry Pi projects not based on the official Raspbian operating system will depend on the project. A Linux Kernel update will likely be required and may come via package manager, manual update, automatic update, or at worst, a re-image of the SD card. Remember to backup first! The HamVoIP AllStar project I wrote about a couple months ago stated a Kernel update is required for Arch Linux and will come via their automated update menu option.

When is the new hotness available? Well, now. Sort of. The Raspberry Pi 4 was released June 28, 2019 but you’re going to have a hard time finding them in stock. The Pi Foundation has a list of official vendors. Checking Newark Element 14, Micro-center, and my favorite place to buy Pi and quality components, Adafruit, were all out of stock. Estimates were 2-3 months before more would be available. Check out this substantial update to this credit card-sized computing device for your next project.

FT4?

HF bands dead lately? Not if you are an FT8 user. This mode has kept the bands active with the lack of solar activity. Unless it’s a contest weekend, I’m seeing little CW activity and less voice. There’s that 3 kHz of FT8 where there is always activity. I think FT8 keeps hams excited about ham radio and operating in general during an otherwise miserable sunspot cycle.

FT8 allows a complete exchange in 1:30, from CQ to 73. High power and high-profile antennas are not a requirement. Low power and “apartment” type antennas work well too. At times, I don’t see any trace on the waterfall of the station I’m working.

The program and protocol are open-source allowing others to build other applications using the protocol. Those include JS8Call which takes the robustness of FT8 and builds a messaging protocol with the ability to relay messages, similar to FSQ.

The good keep getting faster, better, cheaper. On July 16th, version 2.1.0 of WSJT-X was released for general availability and introduced a new mode, FT4. According to Dr. Taylor – K1JT, developer of the WSJT protocols, message types are the same as FT8. Improvements over FT8 include a mode that acts more like RTTY, meaning no more fighting to keep your computer clock synced with UTC and no designated transmit times. Transmission duration is 4.48s vs 12.64s of FT8. Bandwidth is 90 Hz. A compromise for quickness is the ability to dig out weak signals. FT8 is limited to around -21dB, FT4 is about -16dB. For reference, an excellent CW operator who can pull out weak signals is -15dB (figures from the video). Update now to start experimenting with the new exciting addition to the WSJT family!

Groups.io

A service for collaboration I’ve been using lately is Groups.io. Joined during my recent trip to D.C. because a mesh group was using it for collaboration. I quickly noticed other ham projects I was interested in were using it too, like the East Coast Reflector and NW Digital Radio. It’s a service similar to Yahoo and Google Groups but so much better. Groups.io doesn’t serve ads, track users, and has a better reputation than Facebook, which I neither use nor trust. Featuring a modern platform for communities to connect through messaging, calendar, chat, polls, database, photos, wiki, and integration with a list of other platforms. Great for projects to post documentation and offer support or a platform to keep in-touch with club members. It will even move your Yahoo or Google Group over to Groups.io. It’s a freemium service. Most will find the free offering more than adequate. The $10/month level adds the ability to directly manage memberships and take donations.

IC-7300 Clock Sync Video

Have an ICOM IC-7300? Want to keep the radio’s clock in sync with a PC while learning Linux and Python programming in the process? Check out the tutorial video by Kevin – KB9RLW, the “old tech guy.” He talks about why he wants to keep the clock synced and explains the program he wrote. His script is heavily commented which helps to understand the commands and he explains each part in the video. The script is available on GitHub which means it’s easily to build upon. I really like Python and started to use it when I was still doing programming. Alot of Linux programs are written using Python meaning it has to be a powerful language. Depending which survey, it’s #1 or in the top 3 most popular programming languages used today.

SDR Concepts

Onno – VK6FLAB produces a podcast called Foundations of Amateur Radio. Unlike others, each episode averages 5 minutes. They are short, very concise, and does an excellent job of explaining topics efficiently. Since April, episodes have been focused on Software Defined Radios (SDR). A must listen if you picked up an SDR-based radio at Dayton this year and want to learn more. Covering terminology like Direct Conversion and Sample Rate, even comparing SDR to ones with transistors or valves.

Apollo 11 50th Anniversary

When this article goes to press, we’re in the middle of the Apollo 11 mission 50th anniversary first landing on the moon. I’m already out there working those on the air special event stations. Many are operating until July 24, only have a couple more days! Check the Special Event Station listing or the DX Spotting networks.

Steve – W8HF sent me a website that is amazingly cool beyond words. When someone asks to define sites that make the Internet, this should rank near the top. Called Apollo 11 in Real-time, it is “a real-time journey through the first landing on the Moon” and is “entirely of original historical mission material.” When you visit the site, you can select to visit the launch 1-minute prior or visit the mission in real-time, 50 years ago. Included in the real-time elements are mission control footage, TV transmissions, 2,000 photographs, 11,000 hours of Mission Control audio and discussions, 240 hours of space-to-ground audio. All synced and organized chronologically. Truly an awesome website and I hope they keep it online for a long time.

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – April 2019 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:

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

DSCF5081 K8JTKHey gang,

One thing about ham radio, there is no shortage of linking systems. Most are familiar with analog linking like EchoLink and IRLP but there were less popular ones such as WIRES and eQSO. Digital has many more options because when someone disagrees with an implementation, they make another. This allows for options but leads to fragmentation and incompatibilities. The AllStar Link project can link different infrastructure systems together or be a completely independent system. I learned about this linking system and accepted a challenge from one of the Technical Specialists.

Some of your Technical Specialists and I have this spirited debate about Motorola radios. They are correct claiming Motorola radios can take a lot of beating and keep on ticking. Not quite Timex but close. Commercial radios are designed to endure extreme conditions. Think police trying to wrangle a criminal or fire fighters in extreme temperatures of a working fire. You don’t want to worry about your primary line of communication being destroyed in the process. Ham grade gear won’t stand up to that kind of use and abuse. Older Motorola gear is very popular with hams as dependable FM repeaters and for use on 900 MHz. They make great repeaters because they have excellent adjacent channel rejection (selectivity) which minimizes interference from other transmitters.

Motorola CDM1250

My counter is most of this gear is not capable of VFO, a must when working with other agencies and not familiar with their frequencies. Some models are better than others getting them to transmit in the ham bands if the radio’s band split is just above or below the ham bands. A common practice is to bring a radio with the 450-512 MHz split to transmit in the 440-ham band. Aligning the radio is often needed because it has drifted off frequency. A service monitor or RIB (Radio Interface Box) cable are needed. Everyone should have a service monitor or scope, few do. Many older radios require a PC with a serial port and/or DOS application to be programmed. Serial ports are becoming harder to find on computing devices. I’ve heard USB to Serial Port adapters work, for the most part, with the help of DOSBox. DOSBox is an emulation of DOS that works on modern operating systems. Primarily designed as a tool to run DOS-based games but it also works for other DOS applications. To download a legitimate copy of the Motorola CPS programming software, the subscription cost can get ridiculous. A Radio Reference thread indicated it could range from under $200 to $400 with an increase last year for MotoTRBO equipment. As a former programmer, pirating doesn’t support developers and doesn’t allow the company to put money back into developers and adding features. If you’re kind enough, someone with a subscription maybe willing to program the radio for you or find a ham-friendly radio dealer willing to do the same or sell the software at cost. Pro tip, don’t ask about pirated software in the RR or in other forums.

Out of this debate came a challenge from Bob – K8MD to try out a Motorola radio. I eventually found a project where I need a radio but the programming wouldn’t change often. I did a lot of reading and research on BatLabs and Repeater Builder which are great resources for repurposing commercial radios and building repeaters. The used market is where these radios will be found. Advice from those sites will be very useful in not getting ripped-off, especially decoding the radio model number. My project was to setup an AllStar Link node and it was a perfect time to try a Motorola CDM1250.

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

Like other analog Voice over IP systems (VoIP), such as EchoLink or IRLP, it links radio systems together. AllStar is flexible enough to link other infrastructures together as well. The ability to make connections on any IP network makes AllStar decentralized, meaning it doesn’t need to rely on other infrastructure. No central server for someone to pull the plug resulting in a complete collapse of the network. The concept of a node in AllStar terminology is a loose definition but they all run the same exact software. Node types are generally defined as:

  • Repeater: full duplex node and user functions accessed by DTMF
  • Simplex node: half-duplex node, also with user functions available by DTMF
  • Remote Base node: a half-duplex, frequency agile HF, VHF, or UHF remote base. Will not respond to DTMF on RF.
  • Hub node: a common connecting point (similar to Conference or Reflector) with plenty of Internet bandwidth to handle many connections at one time, has no RF connected hardware

Nodes can be public, private, or a combination of both. A public node would be accessible by any other public node on the AllStar network and requires Internet access to the AllStar infrastructure for the phonebook of public nodes. Private nodes can be limited to select users or on a completely private network, like a mesh network, where you don’t want many uses connecting over limited bandwidth links. These are great for connecting repeaters at different sites over a mesh network, point-to-point link, VPN, or public Internet. Private nodes are reserved node numbers ranging from 1000 – 1999.

A hybrid approach of both public and private nodes can be taken. Repeater 1 at location A, repeater 2 at location B, and repeater 3 at location C are all at sites with no or poor Internet. Setup Ubiquity point-to-point links between the repeater site and the Trustee’s house (for example) with a better bandwidth connection. AllStar nodes would be setup at the repeater site and use the Point-to-Point as the route to the Internet.

Say you don’t want public nodes to connect directly to the repeater over long-range WiFi, but wanted to link all three repeaters together and have controllable public access. Nodes at the three repeater sites would be setup the same except as AllStar private nodes. A fourth node would be setup with a public node number at the Trustee’s house. The three repeater nodes and any public nodes could be connected or disconnected from the fourth public node as needed. A friend of mine in Colorado, Jeff – K0JSC, has his WE0FUN “fun machine” repeater sites linked in a similar way. The 15 repeaters are private nodes connected over a private network to a central hub.

Asterisk supports standard protocols for making phone calls over IP, SIP and IAX. Using these standards makes integration easy with other systems that support similar protocols. Options range from softphones, hard phones, other Asterisk systems, to PBX systems on the Internet. A softphone app is an application which runs on a computer or smartphone providing the ability to make calls. Iaxrpt is the Windows PC softphone client and DVSwitch Mobile for smartphones. Hard phones are IP connected phones such as Cisco or Grandstream that support either protocol. A second line on the same Cisco phone used for Ham Shack Hotline is provisioned to dial into my AllStar nodes. An extension can be added to an existing Asterisk phone system allowing any handset to dial into AllStar. Last but not least, a cloud VoIP provider can add forward and reverse autopatch capability to any node! Loose autopatch ability due to new repeater hardware, an expensive addon board, or it became cost prohibitive based on use? Though an active Internet connection is required, a cloud PBX provider, such as voip.ms, adds autopatch functionality for fractions of a penny per minute (including long distance) with pay-as-you-go pricing. For younger hams, autopatches connected an amateur station (often repeaters) with the public land-line telephone system and were popular when cellphones didn’t exist or were expensive.

The first thing about AllStar I found interesting is the ability to interconnect with other ham radio systems. EchoLink support comes out-of-the-box. IRLP can be added but an existing node is needed to copy the system key. To obtain a new node number, the purchase of IRLP hardware is required. Cheapest way is to purchase the preloaded SD card with configured node on the IRLP Node Order Page for the Raspberry Pi.

AllStar has all the essential capabilities of a repeater controller, IDing every 10 minutes and adjustable time-out timer. The time-out timer can be disabled with a command – useful when broadcasting ARNewline, which can be played automatically with a script, or hosting windbag nets. The scheduler is replaced with Unix Cron. I’ve written custom scrips that announce weather conditions, PL tone, and number of connections at certain times during the hour. For a net, my node will check to see if it’s already connected to the far-end node hosting the net. If it is not connected to that node, it will drop all existing connections then connect to the remote node. Dropping all connections seems useful to avoid airing a local net over a large reflector or being booted from an IRLP reflector for being an irresponsible node operator. Some repeater owners like to place repeater objects on APRS maps showing repeater location and frequency. AllStar can inject these objects into the APRS-IS network.

DMK URIx

Not unlike the infrastructure flexibility, nearly any sound device recognized by Linux will work with AllStar. Cheap audio fobs (with a few modifications) to commercially or ham produced products are all options. The Repeater Builder site offers many options and products. The connecting device I choose was the DMK URIx. The USB connection converts data over to a DB-25 connector. Pin assignments are listed on the device itself for easy access. I wired up a connector using a Motorola connector kit I purchased off Ebay following instructions I found online from W2YMM. I’ve had a great experience and no problems with the URIx. However, it’s not cheap now running $85 including shipping. In addition, mailing lists are indicating a change in chipset is causing performance issues. I would wait awhile before purchasing this device again.

With Raspberry Pi as an option for running a node, portable nodes are popular for use in a vehicle or backpack. Open Internet ports, or port forwarding, is not a requirement for outbound connections. This is especially useful because cell phone companies make it impossible for open ports due to CGNAT. This was a big problem I talked about with WIRES-X before Yaesu introduced their portable node software. Incoming connections to a portable node on a hotspot will not be possible.

Diagram of connections to my AllStar node

There is a fork of the main project called HamVoIP. They were the first to release a Raspberry Pi image. A Beagle Bone Black image was available but it has been deprecated and no longer updated to concentrate on the Raspberry Pi image. About the time WB6NIL passed, the main AllStar project had some internal conflict, upgrades caused lengthy outages, distributions were becoming dated, and hard to setup. HamVoIP claims to pick-up that slack, improve on the project including infrastructure and code cleanup. Their assertion is having better than 70% of the AllStar market running their image. Recent strides have been made to improve the main AllStar project. I have used both distributions and feel HamVoIP does work better, has more features, frequent updates, and better documentation. Nodes running HamVoIP still utilize the AllStar infrastructure and are fully compatible with non-HamVoIP nodes.

There is a claim that HamVoIP is in violation of GPL license agreements. Again, being a former programmer and someone who publishes articles and presentations, I would be upset if someone was violating my usage terms. However, those making accusations are also making judgement calls based on lack of response – which doesn’t mean there is a violation. In addition, a claim can be filed with the Free Software Foundation or have the copyright owners of Asterisk make a decision. It does not appear either correct course of action is being pursued. Airing this grievance on social media accomplishes nothing, as usual. The HamVoIP side isn’t helping their case by not being transparent and some responses were “feeding the trolls.” A troll is a person online who posts a provocative message to an online forum with the intent of causing disruption and argument. You can read the Reddit thread (some language maybe NSFW) and HamVoIP response. I’m going to keep using HamVoIP until I see a response from someone that has standing in the matter.

AllStar is flexible but definitely a more an administrative (Sysop) system and not entirely user-friendly. Connecting to other AllStar nodes is pretty straight forward. The DTMF sequence is *3 to link and *1 to unlink. Integrations with EchoLink and IRLP can be implemented a couple ways: directly linked to an AllStar node where the AllStar and EchoLink/IRLP node act as one. EchoLink/IRLP can be setup on a different node (often private) on the same AllStar setup. Having separate nodes allows for disabling EchoLink or IRLP connections completely should those nodes cause problems. Great for control, not great for users. An RF user can link and unlink EchoLink/IRLP, not to specific nodes. It maybe possible to do with a script but would add complexity.

Having AllStar and EchoLink/IRLP on the same node allows RF users to link and unlink to those systems. Remembering the DTMF combinations is not easy, I know. Connecting to EchoLink nodes is the DTMF sequence *3 and *13 to disconnect. IRLP is *38 and *18 respectively. Example, EchoLink test node #9999 is *3009999 and *31009999 to disconnect. IRLP test node #9990 is *389990, and *189990. Not exactly straight forward, easy to remember, or the simple “73” IRLP users are used to for disconnecting. Sysops can use the Supermon webpage utility for easier control of a node and can make it read only for users.

I learned some things about using Motorola equipment. My CDM1250 is the high power (40 watt) UHF model. Radios such as the CDM have a 5% duty-cycle. This means transmitting only 3 minutes every hour. Don’t forget, these aren’t rag-chew radios – they’re designed for police and fire which only transmit for short periods of time. Two ways to improve the duty-cycle is to lower the output power and upgrade to active cooling by moving a lot of air over the heatsink. Lowering the power on mine is still 25 watts. These improvements allow the radio to operate normally for a 90-minute net, as long as the fan keeps working. The antenna connector is a Mini UHF female and very easy to break with an adapter and stiff coax. A Mini UHF male to UHF SO-239 female pigtail is a requirement. It relieves the stress on the radio’s connector.

Learning about commercial radios has been a valuable experience. AllStar Link is a very flexible and customizable system that has excellent integration with other infrastructure. I still have a lot to learn and my next goal is to use AllStar for linking all digital modes – yes ones like D-STAR, DMR, and Fusion. Stay tuned!

If you would like to make an AllStar contact, it is best to setup a sked with me via Email.

AllStar node map: http://allstarmap.org/allstarmap.html

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – August 2016 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: http://n8sy2.blogspot.com/2016/08/august-edition-of-ohio-section-journal.html

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

DSCF5081 K8JTKHey Gang,

As I’m beginning this month’s article some nasty storms just ripped through Cleveland on the 11th. There were branches, trees, wires, power lines down, and road closures on the west side due to those hazards, including my QTH of Westlake. Luckily I’ve heard of no injuries. If you’re not part of the NWS Skywarn program, please consider joining as a spotter. Skywarn is a volunteer program that helps the local National Weather Service office know what’s happening on the ground and assists in warning people about dangerous weather conditions. Training typically happens in the early spring for spotters. Check with your local club or Skywarn organization.

The Republican Nation Convention went off without major incident in Cleveland. I was working from home and had the scanner on most of that week. Three major trunked radio systems were utilized: MARCS, the new MARCS-IP (Multi-Agency Radio Communications System), and GCRCN (Greater Cleveland Radio Communications Network). If you didn’t set a wildcard or use UniTrunker to watch those systems, you probably missed a lot of the event communications. There were about 12 primary talk groups on GCRCN where most of the action took place. These were previously unidentified so they were not in any lists or databases that use Radio Reference. A wildcard stops on any talk group whereas programming specific talk groups into the scanner will only stop on transmissions for those talk groups. The “old” MARCS system was shut down immediately following the convention as it was kept online largely for backup. It has been replaced by the MARCS-IP system.

This month we learned the sad news of Hara Arena’s closing. No more Hamvention at Hara Arena after 52 years. The Dayton Amateur Radio Association put into action their contingency plans. It was announced that Hamvention will still be in the Dayton area. The new location is The Greene County Fair and Expo Center located in Xenia, Ohio. Michael Kalter and Ron Cramer talked about the new location on Ham Nation for about 30 minutes in episode 259. Couple of links worth visiting:

-Why we are saddened by the loss of the Hara Arena: http://ad8bc.com/bc/?p=601
-Hamvention Announces Venue for 2017: http://hamvention.org/hamvention-announces-venue-for-2017/
-Ham Nation episode 259: https://twit.tv/shows/ham-nation/episodes/259, or YouTube link: https://www.youtube.com/watch?v=g_OaKmllEDY

One of our Technical Specialists, David KD8TWG, has been involved with setting up a DMR repeater in Cleveland. The frequency is 442.0875 (+5 MHz standard offset) using Color Code 1. The repeater is connected to the K4USD cBridge (http://www.k4usd.org/). On that website is a listing of the “standard DMR Logo configuration” for repeaters connected to the bridge. Right now, your code plug should follow the layout listed on the site. A cBridge is a feature that allows interconnecting of repeaters over the Internet and a Color Code is equivalent to a PL tone or DCS on analog repeaters.

When I picked up my DMR radio at Dayton, I found a code plug that had repeaters in Dayton and Columbus for the drive home. It was a nice opportunity to quickly get on the air with DMR but I kept threating myself to write my own. With the installation of the repeater in Cleveland, I took the opportunity to do just that. What is a “code plug?” Some history I found online notes the origins came from wire plugs, later jumpers, which were plugged into the radio to enable certain options or features. Since everything is now processor based, the term continues to stick with the radio world and is a fancy word for ‘radio configuration.’ It contains transmit/receive frequencies, tone selections, timeout values, IDs, configuration settings, etc. I used the one I found in Dayton as a reference. Tytera MD-380 There is also a sample one on K4USD’s site for my radio. I compared the two and designed mine the way I thought worked best. Just because someone designed a code plug one way doesn’t mean you can’t modify or do it differently. It’s analogous to one ham’s memory channels are not the same as another. In the end, it took about 3 hours to make mine! Keep in mind that was a lot of learning and comparing, in addition I programmed all 65 possible talk groups so I don’t have to add them in later. From discussions on the air indications are it took others a few hours as well. But my code plug works! I couldn’t be happier. Well OK I could, apparently I’m just far enough away that my 5 watts doesn’t quite make the trip. I took the radio to work and tested it from there.

I am writing an introductory series for the Wood County Amateur Radio Club on getting started in digital modes. The first few articles were for those who have never worked digital and want to upgrade their station. Remaining articles will focus on a specific mode. I’ve completed 3 so far (starting in February): an introduction, station setup, and working JT65/9. Published versions can be found at the club’s website WSJT-X Conversation in the CQ Chatter newsletter: http://wcarc.bgsu.edu/. As I point out in the second article, Technician class licensees can still participate. All of these sound card digital modes can be operated over FM simplex or even a net on a repeater using an HT! There are clear downsides like not being able to transmit as far as an HF station and occupying the full 10 to 15 kHz FM, even though the bandwidth of the audio generated by the computer is less. Yes, this defeats the purpose of narrow bandwidth modes. Someone wanting to learn and experiment with these modes may get bitten by the bug and lead to a license upgrade. That’s how I did it. I plan to write an article every 2-3 months.

My dad and I had the opportunity to join the Toledo Mobile Radio Association (TMRA) on August 10. They had Chris Wilson N0CSW, National Sales Manager for Yaesu talk about their System Fusion. Chris did make it clear that the company was paying for travel so there would be some ‘sales pitches.’ The presentation was short but the program ended up being driven by the audience with a lengthy question and answer session. Some things I learned: the DR-2X Yaesu DR-2Xrepeater announced at Dayton is not going to be a replacement for the DR-1X, though they may have improved on some shortcomings. The 2X is more of a full featured repeater. It will have the ability to operate dual receive and dual transmit (but not at the same time) creating two repeaters from one unit. They are including voice messaging (like club meeting announcements). Mailboxes were users can record messages for others. This reminds me of the mailboxes repeaters used to have when autopatches were more prevalent. The 2X can monitor a separate control channel for commands. This repeater will not support WiresX but will have “MSRL” (Multi-Site Repeater Linking) via an add-on Ethernet port. Their linking technology will allow the repeater to be linked over any IP based network, including mesh. This brought to mind an interesting use-case where multiple low profile/portable repeaters could be linked at sites with mesh such as air ports, hospitals, and Red Cross shelters. This would create a linked repeater system where not as many users would have to setup cross-banding or run to the other end of a hospital to reach a radio. In contrast, something similar can be done using the AllStar Linking system. At the meeting there was alot of: “I would like this feature/I don’t like this feature in the radio,” “we’re having this problem setting up the repeater to do X” kind of Q&A. My take away from that, their plan is to add features to radios by firmware update and not always release new radios.

In addition to all the work David KD8TWG has been doing to get DMR up and running in Cleveland, he’s been helping repair and upgrade analog repeaters, and setting up APRS IGates around town. He will be giving a presentation on APRS at the Lake Erie Amateur Radio Association’s club meeting on August 30th. Dinner starts at 6:30pm with the meeting at 7:30, don’t need to have dinner to attend the presentation. Haven’t seen an official announcement on location yet but it’s expected to be at the Play Arcade in Mayfield Hts (5900 Mayfield Rd, Mayfield Heights, OH). Check the LEARA website for updates and for dinner reservations: http://www.leara.org/.

Raspberry Pi 3I will be giving my introductory Raspberry Pi presentation at the Cuyahoga Amateur Radio Society meeting, September 13 at 7:30pm. It will be updated as there is new hardware and innovations available. Their meeting location is the Busch Funeral Home, 7501 Ridge Rd, Parma, Ohio. More: http://www.2cars.org/.

Thanks for reading and 73… de Jeff – K8JTK