Different radios, one consistent control layer
Amateur radio equipment does not share one universal control protocol. Manufacturers use different command formats, connection methods, mode names, VFO behaviours and response rules. Even radios from the same family can differ in small but important ways.
CAT4OM places these differences behind a common service model. Clients work with operations such as frequency, mode, VFO, split and PTT, while the service translates each request into the protocol expected by the configured radio.
Supported communication styles
CAT4OM’s adapter architecture supports several radio-control families.
Serial CAT
Many Yaesu, Kenwood, QRP Labs and other radios use text or binary CAT commands over a serial or USB serial connection. CAT4OM handles framing, timing, replies and model-specific value conversion according to the selected handbook.
Icom CI-V
Icom radios communicate through CI-V frames and model addresses. CAT4OM manages framing, addressing, echoes, acknowledgements and the differences between commands that affect the live dial and those that access background VFO registers.
Expert Electronics TCI
TCI radios use a network connection and a push-oriented protocol. CAT4OM can track receiver state, modulation, PTT and available telemetry while isolating the details of transceiver and receiver indices from ordinary clients.
FlexRadio SmartSDR
CAT4OM can connect to FlexRadio and map a configured pair of SmartSDR slices to its VFO model. Push status, interlock state and supported operating data are translated into the shared CAT4OM state.
UDP-based interfaces
The transport layer also supports radio definitions that communicate through UDP, allowing additional equipment and protocol styles to fit the same service architecture.
The XML handbook is the radio’s structured knowledge
Every supported model is described through an XML radio handbook. The handbook tells CAT4OM what the radio is, how to connect to it and how to interpret its behaviour.
A handbook can define:
- manufacturer, model and version information;
- connection type and default settings;
- serial parameters and CI-V address;
- available VFOs;
- supported modes and protocol value maps;
- read, write and initialization commands;
- command sequences and response parsing;
- polling groups and conditions;
- push-message definitions;
- valid ranges, formatting and encoding;
- model-specific capabilities such as power control or CW functions.
This structured approach keeps radio knowledge visible and maintainable. It avoids scattering model-specific assumptions throughout the server and every client application.
Capabilities are discovered at runtime
Not every handbook defines the same operations. CAT4OM derives the radio’s available commands from the selected handbook and publishes them as part of its state.
Clients can inspect:
- the commands currently available;
- supported operating modes;
- available VFOs;
- whether a command applies to the active VFO or a named VFO;
- whether special operations such as power-off are supported.
The user interface can then follow the radio. Controls appear because the configured model supports them, not because a generic screen assumes they should exist.
Model differences remain explicit
A common API does not mean hiding meaningful hardware limitations. If a radio cannot set a background VFO, does not expose split state or reports only a subset of metering data, CAT4OM publishes and respects that reality.
Radio Follower uses the same capability information when synchronizing modes. An exact mode is preferred; a compatible proxy can be chosen when appropriate; an unsupported change can be skipped without disrupting frequency synchronization.
Remote power operations are also handbook-driven. They are available only when the radio, physical connection and tested command definition support them.
Adding and refining radio support
Because much of the behaviour is described as data, support for a new model can often be added by authoring and validating a handbook rather than building an entirely new client or protocol stack. Existing handbooks can be corrected and expanded as behaviour is tested on real equipment.
Protocol families that require genuinely new transport or state-processing logic can be added behind the same adapter and service boundaries, preserving the API used by clients.
Compatibility that can evolve
CAT4OM’s handbook model provides a practical balance: one consistent platform for applications, with enough structured detail to respect the differences between real radios.
For the current list of included radios and the latest handbook documentation, consult the resources supplied with the current CAT4OM release.