rouggy 55a643d9a4 feat(kpa): the Elecraft KPA500 / KPA1500 protocol, decoded and pinned
One package for both amplifiers: they share the Elecraft command set — a
caret, letters, a semicolon, case-insensitive in and upper case out — the
same family as the K3/K4 panel. What differs is the transport and which
commands exist, not the grammar.

Everything here comes from the KPA1500 Programming Reference, and the
document's own examples ARE the test:

  ^WS1204 014;  1204 W and SWR 1.4:1 — power and SWR in one exchange
  ^VI513 061;   51.3 V and 61 A — volts in tenths, amps whole
  ^FL91;        HEX, and 0x91 is 'antenna not connected?'

That last one is why the parsing is pinned rather than eyeballed: read as
decimal, 90 and 91 become 144 and 145 and match nothing, so an amplifier
shut down by high reflected power would report a fault OpsLog could not
name. SWR in tenths is confirmed by the reference too — 'expressed in
tenths, 123 is 12.3:1' — where it had only been inferred from Hamlib.

The client is question-and-answer under one lock, never two questions in
flight: the reference states there is no flow control and that commands
are paced by waiting for the reply. Fast cycle four times a second for
power, SWR and the fault; the rest once a second.

Faults are named in the operator's terms — 'the ATU found no match', not
'fault 92' — and an unknown code from a newer firmware still says
something rather than nothing.

Not wired to the app yet, and two commands are deliberately absent: ^TX
makes the amplifier transmit from software, and ^ON0 cuts the main
supplies with Wake-on-LAN as the way back. Neither belongs on a poll loop
or behind a button that can be pressed by accident.
2026-08-26 17:43:32 +02:00
2026-06-18 10:48:23 +02:00
2026-07-08 23:37:29 +02:00
2026-08-21 01:43:14 +02:00
2026-08-21 18:21:33 +02:00
2026-08-21 23:28:55 +02:00
2026-08-21 23:28:55 +02:00
2026-08-21 18:21:33 +02:00
2026-08-20 17:53:55 +02:00
2026-08-20 17:53:55 +02:00
2026-06-21 02:30:01 +02:00
2026-08-22 08:35:49 +02:00
2026-08-21 23:28:55 +02:00
2026-08-21 23:28:55 +02:00
2026-08-20 17:53:55 +02:00
2026-08-20 17:53:55 +02:00
2026-07-21 18:26:34 +02:00
2026-08-20 17:53:55 +02:00
2026-07-26 16:57:19 +02:00
2026-07-26 16:57:19 +02:00
2026-08-21 23:28:55 +02:00
2026-08-26 11:44:40 +02:00
up
2026-05-28 21:32:46 +02:00

Transceiver Control Interface

Introduction

TCI (Transceiver Control Interface) is a network interface for control, data transfer and synchronization between transceiver/receiver, contest loggers, digital mode software, skimmers and other software, as well as external power amplifiers, bandpass filter units, antenna switches, radio controllers and other devices.

TCI was created as a modern alternative to the outdated COM port and audio cable interfaces, it uses a full duplex web socket protocol that runs on top of a TCP connection and serves for server-client communications, providing cross-platform connectivity. Transceiver works as a server, all other software and devices as clients. The server and clients can be inside the same computer (program-server, hardware log, etc.-clients) and/or in separate physical devices connected through the local network (classical transceiver, power amplifier, antenna switch, FFT unit, etc.).

The TCI interface contains basic transceiver control commands (analog of CAT system), receives CW macros from clients and broadcasts them, outputs transceiver IQ stream to clients, receives spots from skimmers and Internet clusters, receives/outputs audio signal to work in digital modes.

The TCI uses an extensible architecture and can be supplemented with new functions and commands, while keeping the old ones operational. Thus, the TCI interface can be extended and supplemented to meet the specific needs of any software manufacturer and/or device manufacturer (receivers, transceivers, power amplifiers, switches, etc.). The presence of a device identifier allows the manufacturers of transceivers and receivers to switch to the TCI interface while maintaining the device model designation. The extensibility of the TCI interface allows you to create an individual set of commands and functions for each device model, while maintaining the basic command set inherent to all transceivers.

Our company advocates universal unification of data exchange between devices and software by creating the TCI interface for this purpose. Modern transceivers and software must communicate using one protocol - the TCI protocol.

Interface description

Any command represents an ASCII string that contains a command name and a list of arguments corresponding to this command. There are reserved characters that cannot be included in the command name and command arguments.

List of reserved characters: «:», «,», «;».

Command structure:

  1. Name of the command;
  2. Separating character between command name and arguments «:»;
  3. Separating character between arguments «,»;
  4. End of the command character «;».

If a command has no arguments, an end of command symbol is placed after the command name. If the command is invalid, it is ignored. The case of letters does not matter.

The ExpertSDR3 program acts as a server, which can have several client connections at the same time, they will be synchronized with each other by the server. When connecting to the ExpertSDR3, the client receives the current status of the ExpertSDR3, first sending initialization commands, then parameters to set the status, such as frequency, modulation, etc.

When a parameter change occurs in the ExpertSDR3 (server) program, the server notifies all connected clients, i.e., clients do not need to poll the server constantly, any change of state will be sent in time to all clients. If the client sends a new state, the server will set it to itself, as well as send it to all clients, that is, the server acts as a synchronizer. All clients connected to the server will be automatically synchronized. This way of work allows to minimize network load, reducing traffic.

The TCI protocol implements the transmission of receiver IQ stream to clients, which is necessary for the work of special skimmer software, they automatically find the station and decode it throughout the band, and it also allows you to record radio signals in the file.

TCI is also used to transmit audio signals of the receiver to clients and to receive audio signals from clients, i.e., the client can transmit audio signals to ExpertSDR3 for radio transmission. The audio stream exchange is designed to work with digital modes, where encoding and decoding is performed by third-party software, as well as in voice modes, where audio macros can be broadcasted, which is very much in demand in contest loggers.

When working in contests, it is important to record all on the air operation, for this purpose the audio stream from the line-output is sent to all clients. The resulting audio stream can be recorded to a file or played back with a PC sound card.

S
Description
Ham Radio Logbook
Readme
43 MiB
2026-08-27 05:55:38 +07:00
Languages
Go 55.1%
TypeScript 43.1%
JavaScript 1.1%
CSS 0.5%
NSIS 0.2%