This is a continuation of a two part series about how to configure hamlib for Linux ham radio users.
To get started, be sure to read through Part 1.
In the last post, I pointed out that hamlib was create to simplify the once fragmented world of computer control for amateur radio. With hamlib in place, developers can interact with hamlib which serves as an abstraction layer of sorts for software development. Developers don't need to worry that you're running a particular model of radio, so long as you get your radio working with hamlib, your radio is supported.
I'm going to assume you have /dev/radio and /dev/rotator already configured (since we did that in the previous post). Now, we're going to configure the daemons (servers) that allow a myriad of radio related applications to interact with your amateur radio equipment.
Hamlib centers around two core daemons: rigctld and rotctld. The daemons receive commands from applications via TCP. It is possible to have these daemons controlled via the network if you so wish. That functionality is a bit beyond the scope of this article, but the concepts below are exactly the same and just requires the correct ports be opened. Speaking of ports, rigctld and rotctld use ports 4532 and 4533, respectively. Also note that there is no security built into these devices. Should you need external connectivity, you should create an SSH tunnel.
Find your equipment
The first step in configuring rigctld is to find if your particular radio (and rotator for rotctld) is supported. Here is a list of all supported radios for rigctld (chances are, if it's a modern radio with computer interface, it's supported). For rotctld, things get a little more difficult. In order to see if your rotator controller is supported, you need to identify which protocol is supported. As I stated before, my rotator is a Yaesu G-5500 and my interface is the ARRL Satellite Tracker Interface. I know from prior experience and documentation this uses the EasyComm 1 protocol. Armed with this information I can proceed with configuring each daemon independently.
Gathering Radio Settings Information
Now that we know our radio is supported, we can determine all of the command line options necessary to setup rigctld. My radio is a Yaesu FT-847, so I'll be using that for my examples - adjust accordingly. For starters, we need to be on the command line so open Terminal or a shell. This whole time I've been referencing rigctld, but for initial configuration and testing we're going to use rigctl. The two programs are essentially the same except the daemon is "headless" (no uder interface) listens for commands via a TCP port. rigctl gives us an internal command line wherein we can issue commands to check communication with our radio. Both rigctl and rigctld require 3 pieces of information, although you can get by with only 2 (we'll give it 4 just to be specific and safe).
The first information rigctl wants to know is what kind of radio are you using. You can find rigctl's list of radios by issuing the following command
(That's a lowercase L, by the way - short for "list") That's going to be a long list though. You could scroll and find your radio or you can pare it down with grep
rigctl -l | grep 847
That's more like it. Now I only see the line of info for my FT-847. The key information we're after is the number on the left. In this case, 101.
The other pieces of information rigctl wants are the device name and the speed at which we'll communicate with the device. For the name, we created the symlink /dev/radio using udev in the previous HOWTO. For the speed, you'll need to check your radio's menu settings. It should be be something like CAT rate, COMM rate or Serial rate (refer to your manual for assistance). I currently have my FT-847 set to 9600 baud, though it's capable of 57600 and 4800 as well. rigctl takes our pieces of information in the form of command line arguments which are -m for model, -r for device (rig) and -s for speed. Another argument we'll pass to rigctld later on, just to be specific, is -t for TCP port. note: you Icom users will need to specify the CI-V address of your radio using the -c argument.
Running and testing rigctl
To establish a connection with the radio, we'll issue the following command:
rigctl -m 101 -r /dev/radio -s 9600
Once rigctl is up and running, you'll be able to issue commands to the radio directly to either read a setting or set a setting. If you have successfully started rigctl, try issuing the "read frequency" command. To do this, simply enter f by itself and press enter. The radio should respond with it's current frequency in Hertz.
To set the radio's frequency, enter F followed by the frequency in Hertz. (In hamlib, capitalized letters set, lowercase letters get)
For example, to set the radio frequency to 146.520:
Switching over to rigctld
If everything has checked out thus far, we can now quit rigctl (enter q) and begin moving over to rigctld.
Essentially, you can run rigctld with the exact same settings as rigctl. For safety, I also issue -t 4532 to specify the port I want rigctld listening to. This is the default port and is unnecessary, but it's nice say exactly what you mean even when it's implied. :)
So, to start rigctld, we run something like the following:
rigctld -m 101 -r /dev/radio -s 9600 -t 4532
(You can run the command above with an ampersand at the end to "background" the process, but for the time being it's unnecessary.)
With the daemon running, you should now be able to interact with your radio with you program of choice. If you do not yet have a program installed, check out grig which should have come with hamlib. grig is a Graphical Rig that gives you a generic radio graphical interface where you can change frequency on the screen and see the frequency change on the radio and vice versa. It's nothing special and you probably will get a more useful interface with your application of choice, but this is a good testbed.
To keep things tidy (and so I don't have to manually run rigctld everytime I boot up, I created an entry in rc.local (found in /etc) to run with the same settings I used above. (Just remember to "background" the process by putting a & at the end.
Now with rotctl...
Configuring rotctl and rotctld isn't all that different from rigctl. Refer to the man page for rigctl for specific command line flags for it, but you should have no difficulty if you already know the rotator controller's protocol. It's very satisfying to issue a command to rotctl and hear the rotator turning and see the indicator needles moving.
My setup looks like this:
rotctld -m 201 -r /dev/rotator -s 9600
Once you have rotctl setup how you like, create an entry in rc.local using rigctld, configure your application for the appropriate settings (remember rotctld likes port 4533 by default) and enjoy the fruits of your labor. (Again, don't forget to background the process with & at the end of the line in your rc.local entry.
So, with everything working correctly, I shouldn't have to do anything to get the functionality I want. udev detects our device connecting our radio and rotator and creates the symlinks of our choosing. rc.local, after the OS has mounted the devices, will startup rigctld and rotctld with the settings specific to our radio and rotator. All that's left is to run our application of choice (CQRLog, gpredict, fldigi, etc) and configure the application to talk to our daemon running on localhost.
Overall, the whole process is not too terribly complex. It's a few new steps you may not have done before, but in the end it all works out nicely. 73 and good DX!