Category Archives: Amateur Radio

Piping External Audio into Zoom

When the stay at home orders that resulted from the outbreak of the COVID-19 pandemic went into effect, the Kitchener Waterloo Amateur Radio Club (KWARC) was forced to start holding our meetings remotely.

Being a radio club and having some members who suffer from unreliable internet access at home, we were loathe to move proceedings entirely to Zoom, and started holding club meetings on our VHF repeaters. In time, we realized that some of our members did not have access to a VHF radio at home or were out of range of our repeaters, and would be better served by a Zoom call.

In an effort to serve all club members equitably, we decided to combine the two technologies. Meetings would be held primarily on VHF, but we would pipe the audio from the meetings into Zoom, allowing members who couldn’t get on the air to at least listen to the proceedings.

My VHF radio, a Kenwood TM-281, tuned to local repeater VE3RCK

v1: The Hardware Based Solution

Our initial stab at a solution was hardware based. One of our club members, Patrick VA3PAF, put a spare VHF radio and his wife’s smartphone into a box, logged into the Zoom meeting on the smartphone, recording the audio from the radio and sending it directly into Zoom.

This approach worked well, so long as the box was far enough away from Patrick’s primary radio and other sources of interference so as not to be swamped with noise. Because it wasn’t monitored during meetings, we had a couple of problems with the phone’s battery dying or Zoom crashing that caused the audio signal to drop until Patrick could troubleshoot the problem.

v2: The Software Based Solution

In an effort to improve on the hardware-based solution, I started digging into software solutions. I realized that my primary VHF radio, a Kenwood TM-281, features a 3.5mm output jack on its back panel. I purchased a short 3.5mm male to 3.5mm male audio cable, and plugged the radio’s output into my Scarlett 2i2 audio interface. This setup allowed me to record any signal received by my radio on my computer, or to pipe that audio directly into Zoom.

My (somewhat dusty) Focusrite Scarlett 2i2 audio interface. It’s old, but an extremely reliable and versatile piece of equipment

After a little bit of testing, I realized that this setup still had a problem – it was only capable of recording audio that came out of the radio, and that audio cuts out any time I transmit. This meant that people listening on Zoom could hear everything that was happening on the repeater, except for my transmissions.

The fix for this problem was to introduce a software mixing solution. My primary computer is a Windows 10 machine, so I chose to use VB-Audio VoiceMeeter Banana, a donationware application that allows you to mix the audio from two or more devices together in software, and send the resulting signal out to some other audio device.

VoiceMeeter Banana mixing two audio signals together. Hardware Input 1 is the output from my VHF radio, while Hardware Input 2 is the microphone on my webcam

This piece of software was a total game changer for me. It allowed me to mix my webcam’s microphone in with the signal from my radio, in theory allowing the folks on Zoom to hear a perfect re-creation of what was actually happening on the repeater.

One problem remained, and that was figuring out where to send the audio to. By default, the only output devices that are available on a Windows computer are physical ones. I could send the resulting mix out to my laptop speakers, or to the output of my audio interface, but I couldn’t send it to Zoom, because Zoom is designed to listen to audio inputs.

Once again, the folks at VB-Audio came to the rescue, this time with VB-CABLE Virtual Audio Device, a software audio device that presents a virtual audio input device that is connected to a similarly named virtual audio output device via software. I could configure VoiceMeeter Banana to send the audio mix to the CABLE Input virtual device, and then tell Zoom to use the CABLE Output virtual device as a microphone.

I’ve configured Zoom to use the virtual CABLE Output audio device as a microphone, which contains the mix of my VHF radio and webcam microphone

Troubleshooting Choppy Audio

The setup described thus far worked great for the first year and a half of online KWARC meetings. One evening, I turned on my VHF radio, logged into Zoom, started the audio feed, and was immediately inundated by complaints from the folks listening on Zoom, all of whom were telling me that the audio was choppy.

I set about tweaking all of my audio settings, checking and double checking that everything was configured correctly, that none of the audio signals were being over-driven, and testing the audio signal at various points in the pipeline. After a bit of digging, I found that the issue seemed to be caused by the VB-CABLE Virtual Audio Device.

If I piped the audio from VoiceMeeter Banana out to my laptop’s speakers, the audio signal was clear as a bell. If I piped it into the CABLE Input, and monitored the corresponding CABLE Output with Zoom or recorded it with Reaper, the signal was choppy and unlistenable.

Some furious googling led me to this forum post, where the OP described the exact issue that I was having, and noted that the solution was to increase the size of the WDM Buffer.

Whenever audio is piped through a digital device or piece of software, some amount of lag is added to the signal. This lag is caused by one or more buffers – essentially a queue of audio samples – the software does its best to keep some number of samples in the buffer at all times so that it can ensure smooth audio processing and output. If a buffer is bigger than it needs to be, more lag will be introduced; if a buffer is too small, audio will not always be available, and the result will sound choppy.

I dug into the VoiceMeeter Banana settings panel, and found that the default WDM Buffer size was 512 samples. I increased this to 1024 samples, and lo and behold, the problem was resolved!

Increasing the Buffering WDM value from 512 to 1024 solved the stuttering audio problem

Leave a Comment

Filed under Amateur Radio, Software

Working RTTY with MMTTY and a Yeasu FT-450D

I recently competed in the CQ WPX RTTY Contest. Well, I say “competed,” but the truth of the matter is that I wasn’t remotely in danger of winning the contest. This was my first time working with RTTY, and I spent much of the contest getting my sea legs and learning how it works.

What is RTTY?

Radioteletype or RTTY, is a digital mode that was first used by the military and newspaper industry in the early 20th century. As practiced by amateur radio operators, it is a frequency shift key (FSK) mode, meaning that the broadcast signal is comprised of a tone that is sent on one of two different frequencies. The lower of the two frequencies represents a binary 0, while the upper of the two frequencies represents a binary 1. By switching back and forth between the two frequencies at an agreed-upon rate, a radio can broadcast a string of binary data that can be decoded by whomever receives it.

The binary string that your radio sends represents text that has been encoded with Baudot code, a system not unlike Morse code that assigns a five bit representation to each character or symbol. The five bit string is padded with one start bit and two stop bits, which means that in practice, each character is transmitted as an 8 bit byte.

When first invented, a teletype system consisted of three parts: a teleprinter that displayed the messages received by the system, a modem capable of translating text to code and back, and a radio that transmitted code and received code that was transmitted by another party. In modern amateur radio setups, a computer typically acts as both the teletype and the modem, and is connected to a radio via CAT control and/or an audio interface.

Connecting the Radio to the Computer

The Yeasu FT-450D features a six pin mini din port on its back panel that is referred to as the DATA jack. Readers of a certain age will recognize this type of connector as a PS/2 mouse/keyboard jack.

This image from the FT-450D’s manual shows the pinout of the DATA jack

This DATA jack exposes pins that allow external hardware to control the radio for Audio Frequency Shift Key (AFSK) or Frequency Shift Key (FSK) operations.

To connect my computer to this port, I purchased a cable that breaks the GND, DATA IN, and DATA OUT pins out to a pair of 3.5mm audio jacks. The output jack is connected to the input of a USB sound card, and the input jack is connected to the output of the same.

My USB soundcard, a Focusrite Scarlett 2i2, connected to my Yeasu FT-450D by way of the DATA jack

It should be noted that it’s possible to build your own data cable for this radio. I opted to purchase mine, but plans are available for making a similar cable, as well as a more advanced version that can be used for other digital modes.

Configuring the FT-450D

In order to send and receive RTTY via AFSK, you’ll need to tweak a few options on the Yeasu.

Start by pressing one of the BAND buttons until you find the band that you wish to work. The ARRL band plan will tell you where to find RTTY on each. It should be noted that 30m, 17m, and 12m are called WARC bands and cannot be used for contesting.

With your band selected, press one of the MODE buttons repeatedly until the DATA indicator appears on the front panel.

Next, we’re going to dive into some of the options in the F menu. Press and hold the F key until the MENU indicator appears on the front panel, and then turn the DSP/SEL knob to find each option. Press the DSP/SEL knob to select the option, and then spin the knob to change the value of that setting. One final press of the DSP/SEL knob will save your changes. Once finished, press and hold the F key until the MENU indicator disappears.

The following need to be adjusted for each band that you wish to work:

  • D TYPE: Change this to USER-L, which will cause your radio to receive and transmit data on the lower sideband.
  • DIG VOX: When using AFSK, the radio will automatically begin transmitting when the input audio level exceeds some threshold. The DIG VOX setting adjusts that threshold. Set the output volume on your computer to a reasonable level, start transmitting a RTTY signal, and then increase the DIG VOX value from zero until the radio starts transmitting. When you stop sending the RTTY signal from your computer, the radio should stop transmitting.
  • RTYRPOL: This is the polarity of your RTTY signal (i.e. if the lower pitched tone is considered to be a 0 or a 1). You’ll want to set this option to NOR.
  • RFPOWER: RTTY is more like SSB than other digital modes. When contesting, you’ll likely want to dial your RFPOWER up to 100 if you want to be heard through the pileups.
  • DIALSTP: This one is optional, but because digital modes take up less bandwidth than phone, you may find it useful to adjust the rate at which the tuning knob changes frequencies.

You can find more information about these and other settings in the Yeasu FT-450D manual (PDF).

Installing MMTTY

For my first time out, I chose to use a program called MMTTY as my terminal emulator. CQ WPX RTTY is a contest, and I use N1MM+ as my contest logger. N1MM+ knows how to talk to MMTTY, which should have meant that I would be able to work the contest in a familiar environment similar to the one that I use for SSB contests.

MMTTY trying to decode a portion of the 40m band. Some digital signals are visible on the waterfall in the top right corner, but they don’t appear to be RTTY

In practice, I was late getting started with the contest, and never did figure out how to integrate N1MM+ and MMTTY. Instead, I opted to log manually, which worked well enough for my first time out.

If you opt to use AFSK and connect your radio to a sound card like I did, you will need to configure MMTTY to use the correct piece of hardware. To do this, select Option > Setup MMTTY, and navigate to the SoundCard tab in the window that appears. Use the radio buttons on this page to select the appropriate hardware for input and output.

I configure MMTTY to use my Focusrite USB (the Scarlett 2i2 pictured above) for both input and output

One started, MMTTY will attempt to make sense of whatever white noise it hears on the portion of the band that you’re tuned to.

Sweep through the band while keeping an eye on the waterfall display in the top right corner of the window. You’re looking for two peaks in the audio signal that are the same distance apart as the two vertical yellow lines. If you line the peaks up with the yellow lines, MMTTY will be able to decode the signal, and you should start to see legible text appearing in the big text box in the centre of the window.

To transmit, type a message in the lower text box and then hit your F9 key, or press the red TX button in the upper left hand of the window. The transmit button is not a toggle, so you’ll have to click it a second time (or hit F9 again) to stop transmitting once your message has been sent.

Finally, if at any time you see the word “Overflow” in the top right corner of the waterfall display, that’s an indication that the audio signal from your radio is too loud. Turn down the input volume on either your external sound card, or in the Windows sound panel until the message disappears.

What’s Next?

This coming weekend, the North American QSO Party RTTY contest (PDF) is taking place from 1800 UTC on February 27 to 0600 UTC on February 28. I intend to use this contest as an excuse to either properly integrate N1MM+ with MMTTY, or to try decoding RTTY with fldigi. Maybe both.

Going forward, I’m hoping to use my newfound skills to play with other digital modes. I may even try to contribute some code to one of the many open source projects that are maintained by hams who play on this part of the band plan.

Until then, 73.

Leave a Comment

Filed under Amateur Radio

CAT Control with N1MM+ and a Yaesu FT-450D

When participating in amateur radio contests, my logging software of choice is N1MM+. This tidy little logger is highly optimized for contesting, automatically updating its user interface to prompt the user for the information required to log a valid contact.

One major quality of life improvement for me has been rigging up N1MM+ to talk to my HF rig via CAT control. This allows the logging software to automatically transmit pre-recorded macros on my behalf at the appropriate times during a contact, which saves me from having to yell my callsign over and over again when trying to break through a pileup.

Because every radio is different, configuring N1MM+ to control your rig can be a bit of a bear. Below are the steps that I followed to get things working:

Tell N1MM+ What Kind of Radio You Have

From the main window of N1MM+, select Configure Ports, Mode Control, Winkey, etc… from the Config menu.

In the Configurer window that appears, activate the Hardware tab. Select the COM port that your radio is attached to from the Port dropdown, and the make and model of your radio from the Radio dropdown.

Next, click on the Set button under the Details header. In the window that pops up, select the baud rate of the serial connection with your radio from the Speed dropdown.

Click the OK button twice to dismiss both windows and navigate back to the main window of N1MM+.

Customize the CAT Commands that N1MM+ Sends to your Radio

From the Config menu, select Change CW/SSB/Digital Function Key Definitions > Change SSB Function Key Definitions. In the SSB Message Editor window that appears, you can edit the contents of the config file that controls the CAT commands that N1MM+ sends to your radio at different stages of the contact.

When running (i.e. sitting on a particular frequency calling CQ and waiting for other operators to call me back), I execute the VM1TX function on my Yaesu FT-450D, which transmits a pre-recorded macro that says something like “CQ Contest CQ Contest, Victor Alpha Three Juliet Foxtrot Zulu”.

To execute this command, I have to configure N1MM+ to execute the {CAT1ASC PB7;} command. CAT1ASC tells N1MM+ to send an ASCII command down the serial connection, and PB7; tells my rig to execute the VM1TX function, which transmits the pre-recorded macro.

Similarly, when searching and pouncing (i.e. tooling around the band looking for other operators who are calling CQ), I execute the VM2TX function on my radio, which transmits a different pre-recorded macro says my callsign. I use this when answering another operator and waiting for them to acknowledge me.

Executing this command is much the same as the previous. I configure N1MM+ to execute the {CAT1ASC PB8;} command, which tells my rig to execute the VM2TX function, transmitting the pre-recorded macro.

For reference, here’s the contents of my entire SSB Message Editor config file:

# SSB Function Key File
# Edits may be necessary before using this file
# Use Ctrl+O in the program to set the Operator callsign
#   RUN Messages
F2 Exch,{OPERATOR}\CqwwExchange.wav
F3 TNX,{OPERATOR}\Thanks.wav
# Add "!" to the F5 message if you are using voicing of callsigns 
F5 His Call,
F6 Spare,
F8 Agn?,{OPERATOR}\AllAgain.wav
F9 Zone?,{OPERATOR}\ZoneQuery.wav
F10 Spare,
F11 Spare,
F12 Wipe,{WIPE}
#   S&P Messages
# "&" doubled, displays one "&" in the button label
F2 Exch,{OPERATOR}\S&PExchange.wav
F3 Spare,
# Add "!" to the F5 message if you are using voicing of callsigns 
F5 His Call,
F6 Spare,
F7 Rpt Exch,{OPERATOR}\RepeatExchange.wav
F8 Agn?,{OPERATOR\AllAgain.wav
F9 Zone,{OPERATOR}\RepeatZone.wav
F10 Spare,
F11 Spare,
F12 Wipe,{WIPE}

Note of course that unless you also run a Yaesu FT-450D, lines 10, 13, 28, and 31 will need to be customized to send CAT commands appropriate to your radio.

Reading through the file may also suggest to you that there is more than one way to skin this cat; indeed, it is possible to configure N1MM+ to key your radio and then play a WAV file from your computer, assuming that you pipe the audio from your computer into your rig. This can be a solution for radios that don’t allow you to record voice macros, or for operators who want to use a wider range of macros than their radio supports.

Good luck and happy contesting!


Filed under Amateur Radio, Software

CAT Control from Log4OM 1.x Using hamlib

In a previous post, I wrote about using hamlib to control my Yeasu FT-450D from the Windows command line.

This time, we’ll look at integrating hamlib with Log4OM to achieve cat control from within the logging software, primarily so that I don’t have to record the frequency whenever I enter a new QSO.

If you haven’t already installed hamlib, you’ll want to follow the instructions in the previous post. If you can run the rigctl examples in that post, you should be good to go.

Configuring Log40M

First, we need to tell Log4OM to use hamlib. Unlike N1MM+, Log4OM does not come with the ability to talk to your radio, and it needs some help to do so.

From the Settings menu in Log4OM, choose Options, and in the dialog box that appears, select the Cat & Cluster tab. We only care about two controls on this tab:

  • Under the CAT SOFTWARE heading, choose hamlib
  • Under the CAT & Cluster heading, select the Open CAT on program start checkbox

Click on the big floppy disk in the bottom right corner to close the dialog box.

Back on the main screen of Log4OM, click on the icon that looks like a pair of headphones in the toolbar:

Why it’s a pair of headphones is beyond me. While I do wear headphones while using my HF radio, they don’t have anything to do with cat control.

Anyway, clicking on that button will open the Log4OM Cat dialog box, where you can configure cat integration with your radio. There are three settings that you want to change in this window:

  • Select the make and model of your rig from the RIG Model dropdown box. My primary HF radio is a Yaesu FT-450D, and I use the Yaesu FT-450 0.22.1 Beta | 127 profile.
  • Select the COM port that your radio is connected to. My radio typically connects to COM4, but that can change if I plug its serial cable into a different USB port
  • Choose the appropriate Baud Rate for your radio. My radio is set to 9600 baud, but this can be changed in its menu. The radio and Log4OM have to be expecting the same Baud Rate for communication to be successful

Once configured, press the Open button in the bottom right hand corner of the dialog box to test and save your settings. if the CAT Status indicator in the bottom left corner of the dialog box turns green, you can close the box.

So What’s the Point?

Once you configure cat control, Log4OM will communicate with your radio as you use it. Most notably, the frequency that your radio is tuned to will appear in the top right-hand corner of the logger, and will automatically record that frequency in any new QSOs that you enter.

Cat control also allows Log4OM to change your radio’s transmit/receive frequency, and to activate the radio’s transmitter. This in turn allows you to connect your radio’s audio input and output to your computer, and play pre-recorded audio snippets from the logger, which can be very useful while contesting.

Leave a Comment

Filed under Amateur Radio, Software

Using hamlib to Control my Yeasu FT-450D

A couple of years ago, I became VA3JFZ after studying for and passing my amateur radio exam. Since then, I have been building out my shack (ham radio enthusiast lingo for the place where you keep your rigs, er… radios).

As my setup has matured, I’ve started to look for interesting ways to interconnect my equipment. Most amateur radio operators use software packages called loggers to keep track of who they’ve talked to when on the air. I use two different loggers: log4OM is my everyday driver, and N1MM+ is for contesting.

Some of my recent contacts, or QSOs, as recorded in log4om

While contesting, I got used to N1MM+ automatically reading the frequency from my HF (that’s high frequency) radio, making for one less thing that I have to enter into the logger as I work contacts. While trying to figure out how to get log4om to do the same thing, I stumbled on an open source project called hamlib.

You see, while most modern rigs provide some form of CAT (that’s computer aided transceiver) control via an RS-232 serial port, every manufacturer’s radio responds to a slightly different set of commands. The goal of the hamlib project is to create a common interface that any piece of software can use to talk to all kinds of radios without having to re-implement all of their individual peculiarities.

After downloading the release 3.3 and running the exe file, I added the C:\Users\Jonathan Fritz\AppData\Roaming\LogOM\hamlib directory to my PATH and opened Powershell, where the following command started an interactive terminal:

$ rigctl --m 127 --r COM3 --serial-speed=9600

Let’s break down the arguments to this command:

  • rigctl is the name of the program, pronounced “rig control”
  • --m 127 tells rigctl that my radio is a Yeasu FT-450D
  • --r COM3 says that my radio is connected to the COM3 port; and
  • --serial-speed=9600 tells it that my radio expects serial commands at a rate of 9600 baud.

It’s worth noting that your radio might appear on a different COM port when connected to your computer via a RS232 to USB cable, and that you may need to adjust the baud rate of the serial connection to match the settings in your rig’s config menu.

You can find out what COM port your radio is connected to in Windows > Control Panel > Device Manager

Once you’ve started rigctl, there are a few interesting commands that you can run.

Get the frequency of the radio:

Rig command: f
Frequency: 7301000

Get the mode that the radio is in:

Rig command: m
Mode: LSB
Passband: 3000

Ok, that’s a neat party trick, but what’s the point? Well, rigctl can also be used to change your radio’s settings, and can be run in a non-interactive mode where commands are read in from a file.

Non-interactive mode

I started by writing my commands out to a file:

$ echo M LSB 3000 \r\n F 7150000 > 40m.txt

Once again, let’s break this command down:

  • echo prints whatever comes after it to the terminal
  • M LSB 3000 tells the radio to set the mode to lower sideband with a passband of 3000Hz
  • \r\n is a line break in Windows, which separates two commands from one another
  • F 7150000 tells the radio to set the frequency to 7.150.00MHz, the middle of the 40M band
  • > pipes the output of the echo command (the string M LSB 3000 \r\n F 7150000) into a file on disk
  • 40m.txt is the name of the file to pipe the command into

The result is a file called 40m.txt containing two commands that will set the radio to LSB mode and set the frequency to 7.150.00MHz.

Now, we can execute those two commands by running this command:

$ rigctl --m 127 --r COM3 --serial-speed=9600 - < 40m.txt

The first four arguments here are the same ones that we used to open the interactive terminal above. The remaining arguments are:

  • - tells rigctl to read the remaining commands from stdin, letting us pipe them in from a file
  • < the opposite of >, pipes commands in from a file instead of out to a file
  • 40m.txt the name of the file containing the commands that we want to send to the radio

Running this command will set the radio’s mode and frequency, initializing it for operations on the 40m band.

The rigctl manual contains a bunch of other really interesting commands, including the ability to activate the rig’s PTT (push to talk) switch, which could be used to write a script that puts the radio into transmit mode before playing pre-recorded message. That sounds like a very useful feature for contesting.

Finally, if there’s something that your radio can do that rigctl can’t, you can always use the w command to sent CAT control strings directly to the rig. The control strings for most rigs can be found on the manufacturer’s website.

73 (that’s amateur radio speak for “best regards”), and enjoy your newfound power.

1 Comment

Filed under Amateur Radio, Software