Just a few words to get us started; let's see what others contribute.
Experienced ham radio operators using small satellite receivers would invariably find themselves in a situation where they were constantly juggling multiple tasks: holding the antenna while monitoring the "look4sat" website to see the satellite's position, adjusting the Doppler frequency, and listening intently to the conversation while recording it. This was especially challenging when using linear repeaters; without proper CAT control, the transmit and receive frequencies would be reversed due to Doppler shift, making it easy to lose contact or even drift into an unintended frequency band. While manual operation certainly showcased the ham's technical skills, wouldn't automated computer control be a more efficient and reliable solution?
In reality, modern radio stations heavily rely on computer-assisted communication, which offers convenience. With the help of a computer, you can easily change frequencies and modify VFOs (Variable Frequency Oscillator) simply by dragging with the mouse. Furthermore, automatic Doppler frequency compensation is possible when communicating with satellites, and you can also control remote stations via the internet. Therefore, these concepts ultimately point to the term CAT.
CAT(Computer-Aided Transceiver, CAT) refers to the technology that allows a computer to participate in radio communication control through serial ports or network connections. However, this is a very broad concept, and there isn't a single standard protocol; even at the link layer/physical layer, each manufacturer has its own implementation. For example, ICOM uses the CI-V protocol (half-duplex bus), while others still use serial ports. While Yaesu was the first to commercialize and brand CAT in the 1980s, the command formats for each of their models are very different, such as the ft817, ft857, and ft991 being incompatible. Yaesu uses binary (or hexadecimal) signaling, while Kenwood uses text-based commands (Elecraft also appears to use similar ASCII commands). In short, the ecosystem is highly fragmented. If a HAM software needs to support all radios, it must implement drivers separately for each manufacturer and even for each model.
Taking the popular open-source radio, uSDX, as an example, it uses the KENWOOD TS-480's CAT protocol (although only a subset is implemented, namely the sub-set). In simple terms, it uses text commands, with semicolons to terminate them, and a baud rate of 115200, 8N1 (8 data bits, no parity).Parity check, Stop position 1 (bit), and alsoDTR and RTS(DTR and RTS are two pins in the RS-232 serial port standard, through which communication partners can detect or decide to switch between receiving and transmitting states based on the high or low level of the signal – although this description is not entirely precise. You can find their presence in the settings interface of programs like WSJT-X or FT8CN.)
Here are some examples of CAT commands that can be implemented using uSDX:
| Command | Features |
|---|
FA; / FA00014195000; | Get/Set frequency (Hz) |
MD; / MDn; | Obtain/set mode (1=LSB, 2=USB, 3=CW, 4=FM, 5=AM), but uSDX does not support FM and AM transmission. |
IF | Obtain radio status (frequency, mode, etc.) |
TX0; | Entering launch status |
TX2; | Enter tuning mode |
RX | Entering receive mode |
ID; | Return radio ID (fixed return) 020, i.e., TS-480) |
In fact, there are also some extended commands, such as the CAT audio stream, which transmits control commands and audio data simultaneously over a single serial port. This eliminates the need for multiple 3.5mm audio cables, and many modern radio stations have similar designs, such as running audio and CAT control simultaneously via USB cable, like /dev/ttyACM0.
Omnirig and Hamlib
Therefore, the CAT protocols used by different radio stations vary widely, leading to a large amount of adaptation work. What should software developers do? Based on the principles of decoupling and abstraction, it's easy to think about creating an intermediate layer to handle the complexities of communicating with radio equipment. This would involve finding a specialized translator to handle the adaptations. This is what is known as a "middleware." According to my observations, there are currently two major middleware ecosystems: Omnirig and Hamlib.
Both of these devices essentially perform the same function: they connect to the radio's serial port (which may be a USB or Wi-Fi virtual port) and convert between the manufacturer's proprietary CAT protocol and the generic "standard interface language."
In addition to handling CAT protocols, Omnirig and hamlib can also control RTS/DTR serial port levels. Hamlib also supports VOX, which is voice-activated transmission.
OmniRig https://github.com/VE3NEA/OmniRig ) was developed by VE3NEA, with the design goal of "allowing amateur radio software on Windows to support all stations simply by writing one set of radio control code." The VE3NEA callsign is quite familiar, as it's also used by the author of the DX Atlas toolset, such as Morse Runner and CW Skimmer, as well as Skyroof, a multi-functional integrated software that is often used by those who enjoy satellite receiving and telemetry.
However, Omnirig currently only has a Windows version, which suggests it was developed earlier (before the early 21st century). It unfortunately relies on the ubiquitous and often problematic Microsoft ActiveX/COM technology. Fortunately, it has continued to develop well and has become a standard for many HAM software applications that are exclusively for Windows. For example, N1MM and Logger32 all use Omnirig.
Omnirig itself doesn't have a main interface; it's a system-level COM service. The configuration is also very Windows-like, and its core engine reads INI files. Each INI file contains the behavior description for a specific radio model. If a user adds a new device, they can simply create their own corresponding INI configuration, which eliminates the need to constantly send out new driver updates (especially in the early days of the internet when software distribution was difficult!).
Here's an example of a configuration file (Note that INI files use semicolons to start comments, not double slashes).
; Icom IC-7300
[Radio]
Name=IC-7300
; Baud Rate
BaudRate=115200
DataBits=8
Parity=None
StopBits=1
; Command Timeout
Timeout=200
; Poll Interval
PollRate=200
[Commands]
; Set Frequency
SetFreq=FE FE 94 E0 05 <FreqBCD5> FD
; Get frequency
GetFreq = FE FE 94 E0 03 FD
; Set mode
SetMode = FE FE 94 E0 06 <Mode> FD
; PTT control
SetPtt = FE FE 94 E0 1C 00 <Ptt> FD
I find the final part quite abstract, especially the setting commands, which are all in hexadecimal. Fortunately, the manufacturer's advanced manuals clearly state that they are designed for easy secondary development. I personally prefer human-readable text commands in this regard.
Now, we must definitely mention Open Source True God – Hamlib:
Hamlib https://hamlib.github.io/ ) Compared to omnirig, the advantage is cross-platform compatibility. If you're using tools like Ham Radio Deluxe on Linux or macOS, or if you need to adapt it for embedded systems (such as using a Raspberry Pi with a screen to create a spectrum viewer and control for traditional radios like the FT891), then omnirig is essentially your only option.
Hamlib is divided into three layers: the backend, the C API, and command-line tools. The backend consists of a large collection of driver libraries for various radio models. The C API is intended for developers who want to create their own applications, while most users primarily use its command-line tool – rigctl.d, rotctld, ampctldThe "ctld" suffix (control daemon) clearly indicates that it controls the radio, the rotator, and the amplifier. It's called a control daemon because, fundamentally, it can open a TCP listening port (defaulting to 4532), waiting for different software to send commands (using either stateless short connections or long-lived connections). This makes it an agent/daemon process.
For example, let's assume that the same computer running the software has a USB connection to an IC-7300. (In the hamlib library, the IC-7300 model code is 373; this relationship can be queried using `rigctl -l | grep -i "型号"` – no further explanation needed).
rigctld -m 373 -r /dev/ttyUSB0 -s 115200 & # Writing USB device paths in Linux
rigctld -m 373 -r COM3 -s 115200 & # Writing for USB Serial on Windows
As a result, this unit now has a 4532 ready to listen for control signals.
Then, on the same local network as my house, there was an FT991. Assuming that the exposed port is 8888, in order to avoid conflicts with the above, we need to change the listening port of the process, for example, to 4531.
rigctld -m 135 -r 192.168.1.100:8888 -t 4531 &
At this point, you can independently view the frequencies of both radio stations (and perform other control operations), and you don't need to worry about the different command formats used by various manufacturers; instead, use the standard hamlib commands.
# Specify the port when connecting as a client
echo "f" | nc localhost 4532 # Check IC-7300 frequency
echo "f" | nc localhost 4531 # Check FT-991 frequency
This is convenient, imagine using an IC-705 to engage in FT4 communication with the RS-44 satellite online. You would then need separate software such as WSJT-X (for FT4 encoding/decoding), gpredict (for celestial navigation and orbit tracking, including Doppler correction), and possibly other logging software. These programs can all communicate independently via TCP connections and rigctld, which gathers all incoming data streams into a queue and sends them to the radio's serial port, enabling bidirectional audio streaming and frequency adjustment.
Regarding the second ROTCTL, this is the network management agent for the antenna rotator, with a default port of 4533. I'm very familiar with this, as I've recently been working on open-source firmware for the antenna rotator and have had extensive interactions with it... As for the control protocol for the antenna rotator, there are many different options (a real mix), but some of the more well-known ones include AMSAT (Amateur Radio Satellite Company)'s easycomm I/II, Yaesu's GS-232A/B, Pstrotator (which has a corresponding control software), SPID Rot2Prog (based on binary), and Celestron NexStar (related to astronomical telescopes' equatorial mounts and star finders). Oh, and there are also rotator implementations using monitoring gimbals in China (especially the 301 gimbal and Yaesu 3040 gimbal), so they have inherited the control signals from the original gimbal manufacturers. Many experienced HAMs use "Amateur Satellite Software" developed by BG6LQV to control the rotator, which implements both of these gimbal protocols and the Yaesu GS232-B protocol. You can even see omnirig components directly integrated into the radio connection functionality:
In essence, controlling the antenna rotator simply involves specifying the azimuth (heading angle, AZ) and elevation angle.（EL）Several degrees. And to allow the rotator to report its current angle (so that its status can be determined). For example, the core EasyComm commands would include these. (If the EasyComm II command "AZ" or "EL" is used without parameters, it asks the rotator: What is your current orientation?)
| Command | Instructions | Example |
|---|
AZ<Angle> | Set heading | AZ123.5 |
EL<Angle> | Set the tilt angle | EL45.0 |
UP | Rotate upwards | |
DN | Rotate downwards | |
ML | Turn left | |
MR | Turn right | |
SA | Stop directional rotation | |
SE | Stop tilting rotation | |
Commands for up, down, left, right, and stopping/starting are intended for manual control (assuming no reliance on automatic calculation and closed-loop control). Closed-loop control does not require manual stopping/starting; when the error is within a certain range, the motor automatically stops. Therefore, only the first two commands are sufficient. This simple and easy-to-implement protocol is often used to create firmware for rotary encoders, such as running calculations and motor control on Arduino or ESP32.
I feel like I'm rambling. Let me clarify something: omnirig and hamlib aren't particularly prominent; this type of middleware might be integrated within the software itself. For example, WSJT-X allows you to select a radio model (or control command set), essentially calling upon hamlib in the background. Some software also lets you configure serial ports. If the software doesn't support remote radios, you can create a daemon process to listen for forwarding (which effectively adds a transparent proxy layer in front of the software). Furthermore, you can use hamlib to send custom commands in hexadecimal format (such as interacting with the temperature sensor on the antenna motor) and receive feedback. This is where hamlib's flexibility comes into play.
I hope this short article will help many ham radio operators better understand the communication mechanisms between ham equipment and computers (as well as some mobile apps, such as FT8CN, TX-5DR, IC705 controller, look4sat).
闽ICP备2021006864号-7
闽公网安备35020602002794号