A dedicated service at the centre of the station

CAT4OM separates radio control from the applications that operators see and use. A dedicated service connects to the equipment, interprets radio-specific protocols and maintains the authoritative station state. User interfaces and integrations connect to that service as clients.

This service-first design prevents every application from having to become a radio driver. It also allows the radio connection to remain in one controlled place while interfaces, dashboards and automation tools evolve independently.

A strong core and focused clients

The CAT4OM service is responsible for:

• opening and monitoring radio connections;
• selecting the correct transport and protocol behaviour;
• translating high-level operations into radio-specific commands;
• parsing replies and push messages;
• validating commands against the radio’s capabilities;
• maintaining consistent live state;
• coordinating control ownership between clients;
• enforcing transmit-safety rules;
• distributing state changes and events;
• managing groups, radio lifecycle and diagnostics.

Clients focus on presentation and interaction. They display the state supplied by CAT4OM, gather operator input and send high-level requests such as “set frequency” or “enable split”. They do not need to know how a Yaesu CAT frame differs from an Icom CI-V message or a TCI event.

The supplied desktop UI follows this model, but it is not privileged. A third-party integration can use the same public protocol and receive the same state.

Live state instead of constant client polling

When a client connects to a Control channel, CAT4OM provides an initial snapshot of the radios visible to that group. The service then pushes state updates whenever meaningful changes occur.

Depending on the radio, state can include:

• VFO A and VFO B frequency and mode;
• active and transmit VFO;
• split, PTT, RIT and XIT;
• filter width and supported operating modes;
• signal level, transmit power and SWR;
• connection status;
• available commands and their VFO scope;
• external-control and ownership information.

Clients do not have to query the service repeatedly to discover changes. They can react to the ordered updates and events CAT4OM sends, reducing unnecessary network traffic and making interfaces more responsive.

Polling and push radios under one model

Not every radio reports its state in the same way. Traditional serial CAT and CI-V equipment is commonly monitored with request-and-response polling. TCI and FlexRadio connections can provide asynchronous events as the radio changes.

CAT4OM selects the appropriate synchronization strategy behind the service boundary:

• polling-based radios are queried according to the rules and timing in their handbook;
• push-based radios feed incoming events through generic and protocol-specific processing;
• both paths update the same CAT4OM radio-state model;
• clients receive the result through the same WebSocket messages.

The client therefore works with capabilities and state instead of transport details.

Separate management and control channels

CAT4OM uses two WebSocket surfaces with different responsibilities.

Management channel

The Management channel covers configuration, handbook discovery, available serial ports, group and radio lifecycle, service status, diagnostics and compatible power operations. It provides the operational view of the CAT4OM service.

Control channel

Each running group exposes its own Control channel. This is where clients identify themselves, receive radio snapshots, request ownership, send operating commands and listen for live state and events.

Keeping these responsibilities separate prevents administrative activity from becoming entangled with time-sensitive radio traffic and allows management and control clients to evolve independently.

Capability-aware interfaces

CAT4OM publishes what each connected radio can actually do. Available commands, VFOs, supported modes and command scopes are part of the runtime information clients receive.

An interface can therefore hide or disable controls that do not apply to a particular model. An integration can check support before sending a request. This produces cleaner applications and avoids treating the lowest common denominator as the only possible feature set.

Designed to be extended

The service boundary makes room for new user interfaces without changes to the radio engine. The handbook system makes room for new radio definitions without embedding every model in client code. The WebSocket API makes room for integrations in any language capable of exchanging JSON messages.

CAT4OM is therefore more than a desktop controller. It is an architectural layer on which different station tools can cooperate.

Explore integrations and the API · Explore radio compatibility