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.

Image Rotation and EXIF Data

If you’ve looked at some of my earlier posts in Firefox, you may have noticed something odd about them. Some of the photos will appear to be rotated in the wrong direction, but if you view the same post in Chrome or on an iPhone, they’ll appear to be rotated correctly.

When I’m working in my garage, I take all of my photos on my iPhone, and I’ve recently found out that when I take a picture in landscape orientation (with the home button held to the left or the right, rather than the top or bottom of the screen), iOS doesn’t rotate images to match the orientation of the phone when it writes them to storage. Instead, it writes the image data in the same orientation as the camera, and saves some time by writing the orientation information separately into the metadata that it attaches to the image. This lets the device take pictures faster, but means that some of the images have to be rotated before I post them.

Unfortunately, I didn’t notice this behaviour up until now, thanks to a series of unfortunate circumstances:

  1. As previously mentioned, Chrome looks at images’ EXIF data and re-orients them as necessary
  2. The file browser on my Ubuntu 14.04-LTS machine also auto-corrects for iOS’ sloppy behaviour
  3. Unlike the other parts of my toolchain, WordPress ignores EXIF orientation information when images are uploaded, taking the stance that it’s not interested in automatically modifying users’ images.

So what to do? Well, I could open each of the images in an image editing program like Pinta, apply the necessary rotation and resize the file. On the other hand, that sounds boring and time consuming, and I’d rather figure out how to do the job automatically.

Since we’re modifying images, the go-to tool in our kit will be an amazing suite of image editing tools called ImageMagick. It’s 100% free and open source, runs damned-near anywhere, and can do pretty much anything that you might want to do with an image file.

I’m working on an Ubuntu system, so I’ll install ImageMagick like this:

$ sudo apt-get install imagemagick

If you’re on some other platform, you can read up on how to download the tool here.

Now we just have to string together some command line switches to do what we want. Here’s what I came up with:

$ mogrify -auto-orient -resize 584x438 -strip -quality 85% *.jpg

The command that we’re running is called mogrify, and will modify your images in place, so you’re going to want to cd into a directory that contains a copy of your images before running it.

After the mogrify command, we specify a number of command line switches that change how it behaves:

  • -auto-orient fixes the iOS image orientation problem described above
  • -resize resizes the image to the size provided (specified as maximum width x height in pixels), and respects the source image aspect ratio if it can’t make the image exactly that size
  • -strip removes all EXIF data and other metadata from the image, including timestamps, GPS location data, and information about the device that took the image. It also removes the pesky orientation data that caused Chrome and Safari to automatically correct for iOS’ behaviour, which is important, because we’ve just rotated the image, so if we leave the metadata in place, the image might actually appeared double rotated after I post it
  • -quality specifies the compression level to use when resizing the image (specified as a percentage between 0 and 100)

The last thing in the command, after all of the command line switches, is *.jpg, which tells mogrify to do all of the previous steps on every file in the current directory that ends with .jpg.

Once I’ve run this command, I’m left with a directory full of properly oriented images that are the right size for posting on my website, with all of the private/identifying metadata stripped out of them.

Handy, right?