The TCP Protocol and Quisk

By Jim Ahlstrom, N2ADR, the author of Quisk SDR

Initial draft June 7, 2026. Expect frequent updates.

Please use the group https://groups.io/g/n2adr-sdr for discussions.

This paper discusses software that I do not use myself. Please report errors.

What is TCI

I am interested in adding TCI to implement Rx and Tx audio streams that connect Quisk to external digital mode programs, CW skimmers, logging programs and contest programs. These programs typically use only a few control commands, often just PTT and frequency. TCI provides many more controls such as output power control, filter width, CW macro speed and AGC mode. It is a more general transceiver control protocol.

The TCI protocol was developed by Expert Electronics. Their SDR hardware is controlled by their ExpertSDR3 and legacy ExpertSDR2 software. TCI is a protocol built into this software that enables external programs to control the radio and have access to the receive and transmit audio streams. This can be used by external digital mode and logging programs.

The TCI protocol uses a network connection and it eliminates the need for COM ports and virtual audio cables. This is an attractive feature. The digital mode program WSJT-X supports TCI, and to connect it to a radio you select the radio "TCI" and the audio "TCI audio" and you are connected. Using PC audio to transfer digital samples between computer programs has always been a bother.

• TCI is a client/server protocol. The radio that can tune in signals and provide audio samples is the server. Clients are external programs that need to receive Rx audio and perhaps send Tx audio to be transmitted.


• TCI protocol version 1.4 is described here.


• TCI protocol version 2.0 is described here.

Why I Don't Like TCI

I am the author of Quisk SDR software. When my users first requested TCI, I initially declined. I don't like the TCI protocol for these reasons:

• TCI uses the Websocket protocol over TCP. Websocket was developed to add a persistent TCP connection to a normal web page. To open a websocket you start by opening a normal html web page. That is more complicated than is needed.


• The TCI protocol is poorly specified. Version 1.4 does not define the number of channels, and so we can expect that different program authors will invent different conventions. For either version 1.4 or 2.0 it is not clear to me whether Stream.length represents the number of frames (L/R stereo pairs) or the number of floats (one stereo pair equals two floats).


• The use of TxChrono should not be needed. The client sent PTT to the server, and the client should just start sending Tx audio by itself.


• The TCI protocol contains a large number of commands that are peculiar to their SunSDR hardware. There should be a defined subset of commands that would support a data connection to external programs.


• There is no mechanism to indicate to a client that a command is unavailable except that the command will not be echoed. There is no mechanism to negotiate acceptable audio sample rate and type parameters between a client and server.


• The change from older versions like 1.4 to the latest version 2.0 created problems of compatibility, and TCI provided no solution or upgrade path.

Experiences with WSJT-X

Although I don't like the TCP protocol, my users want to connect to WSJT-X, and it supports TCI. So I felt obliged to add TCI to Quisk. I have WSJT-X version 3.0 on Linux and version 3.1 on Windows to test. I could not find a technical description of the TCI protocol as used by WSJT-X (is there one?) so I looked in the source code. I saw a comment that indicated an early version 1.2 of TCI and I saw the Stream header lacked the number of channels. So I had to resort to experimentation to figure out how to connect. I discovered the following:

• WSJT-X only uses these TCI commands:
  • The VFO command is the Tx/Rx frequency.
  • The SPLIT_ENABLE is always set to False.
  • The TRX command changes between Rx and Tx (PTT).
  • The AUDIO_START and AUDIO_STOP commands control Rx audio to the client.


• WSJT-X does not recognize the number of channels in the header array at index 8, and this can contain garbage when it sends data.


• The Rx audio stream sent from Quisk to WSJT-X must have two channels with the same data in each channel. The Stream length is the number of floating point numbers, not the number of left/right pairs.


• The Tx audio stream sent from WSJT-X to the server is two channels, and the Stream length is the number of floats. But the binary message received has a data segment twice as large as requested with garbage in the second half.

Experiences with deskHPSDR

I do not have the software defined radio deskHPSDR but I have been in contact with its developer Heiko, DL1BZ. He has implemented TCI version 2.0 and has successfully connected to the clients JTDX, MSHV RumLogNG and UT4LW's SDC (Software Defined Connectors) and its build-in CW Skimmer. He has no interest in supporting protocols earlier than the current version 2.0 of TCI.

I don't disagree with Heiko but this creates problems for me. My TCI version 1.4 currently connects to WSJT-X, and I believe that TCI version 2 will not. So changing to version 2 will anger my users. The problem goes away when and if WSJT-X upgrades to version 2, but that may never happen. And there may be other TCI version 1.4 software out there that I don't know about, and I will break it too.

I am not a philosopher, I am an engineer with the mindset of a businessman. I want to make my users happy and contribute to the advancement of amateur radio. We should be using modern technology, not COM ports and audio hacks.

What to Do

An ideal solution would be to assemble all authors of client and server software and hash out a protocol that is simple to implement and satisfies everyone. But this is not an ideal world. I proposed this to FreeDV and they were too busy with their own software. But I think it is possible to invent and publish a "best practises" document for TCI that will guarantee connection to most or maybe all clients. For example, if a client requests audio stream parameters that are not in TCI 1.4 but are in 2.0, then the server knows to use 2.0. These commands are:

• AUDIO_STREAM_SAMPLE_TYPE
• AUDIO_STREAM_CHANNELS

I expect that most modern clients will send their AUDIO_STREAM parameters to the server at an early time, and so no real changes will be needed. There should also be a small set of commands and their meanings that are guaranteed to be available. This is not a restriction on the server, and the server can implement additional commands as desired. But clients can depend on the VFO command to always set the Rx and Tx frequency.

I need the support of TCI client and server software authors to make this work. I welcome feedback, both positive and negative. Please let me know what you think on the news group named above.

Jim Ahlstrom, N2ADR