开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. N2adr-Sdr
  2. Topics

TCI (Transceiver Control Interface) Protocol

 

Hello Group,

Well, I spent quite a bit of time on the TCI (Transceiver Control Interface) protocol. After writing 300 lines of C I finally had a working server that handles the data channel. That still leaves the audio channels and the control message protocol. With some more work I can duplicate the performance of Hamlib.

But I find the TCI protocol hard to love. It is very poorly specified in the protocol document. I would need to resort to experimentation with client apps and SunSDR hardware to figure out how it works. And it is needlessly complicated. The use of websockets is frustrating. I think the problem is that it is really designed to be remote control software for SunSDR hardware. Other manufacturers make remote software. There is Flex SmartSDR, Icom C-IV and Elecraft K4 Remote. They are all incompatible.

Remote control software for radios is bound to be complicated. But what we need is a simple protocol so that external programs can get a few data items and audio streams from a radio, either a hardware radio or a software defined radio. The current way to do this is to use Hamlib CAT commands for the data items, a virtual audio cable through the PC sound system for audio and maybe serial port control lines for keying. It is long past the time that we should be using a serial port for anything, and PC audio systems are a nightmare.

We need a simple protocol that enables digital mode programs, logging programs, CW and digital skimmers and keyers to work with a transceiver all at once with no fuss. I thought that TCI might be that protocol. But alas, it is not.

So I am removing TCI from Quisk and will not be supporting it. There are other projects to work on that are a better use of my time.

Jim
N2ADR
 

Jim, my advice is to do as I did in piHPSDR:

Implemnt a minimal subset of TCI only meant to support PAs and logbook programs.

Peoply will shout at you to do more, simply reply "program yourself".

Am 11.02.2025 um 21:44 schrieb jimahlstrom via groups.io <jahlstr@...>:

Hello Group,

Well, I spent quite a bit of time on the TCI (Transceiver Control Interface) protocol. After writing 300 lines of C I finally had a working server that handles the data channel. That still leaves the audio channels and the control message protocol. With some more work I can duplicate the performance of Hamlib.

But I find the TCI protocol hard to love. It is very poorly specified in the protocol document. I would need to resort to experimentation with client apps and SunSDR hardware to figure out how it works. And it is needlessly complicated. The use of websockets is frustrating. I think the problem is that it is really designed to be remote control software for SunSDR hardware. Other manufacturers make remote software. There is Flex SmartSDR, Icom C-IV and Elecraft K4 Remote. They are all incompatible.

Remote control software for radios is bound to be complicated. But what we need is a simple protocol so that external programs can get a few data items and audio streams from a radio, either a hardware radio or a software defined radio. The current way to do this is to use Hamlib CAT commands for the data items, a virtual audio cable through the PC sound system for audio and maybe serial port control lines for keying. It is long past the time that we should be using a serial port for anything, and PC audio systems are a nightmare.

We need a simple protocol that enables digital mode programs, logging programs, CW and digital skimmers and keyers to work with a transceiver all at once with no fuss. I thought that TCI might be that protocol. But alas, it is not.

So I am removing TCI from Quisk and will not be supporting it. There are other projects to work on that are a better use of my time.

Jim
N2ADR
 

Hi Jim,

I did some small TCI python scripts trying to connect SDC to different radios other than SunSDR (sold mine some years ago). So yeah, it lacks some documentation, and websockets might be painful outside of web programming, but TCI at least has some level of adoption across HAM programs. As you've spent some time on that already I wouldn't throw that code away but put it in as is. Maybe someone else wants to take that as basis.

From a user perspective TCI was working fine for me with SDC and JTDX back then when I still had the SunSDR DX, much better than any virtual serial ports, virtual audio cables etc.

73 OE6HKE

On 12.02.25 09:26, Christoph v. Wüllen wrote:
Jim, my advice is to do as I did in piHPSDR:

Implemnt a minimal subset of TCI only meant to support PAs and logbook programs.

Peoply will shout at you to do more, simply reply "program yourself".



Am 11.02.2025 um 21:44 schrieb jimahlstrom via groups.io <jahlstr@...>:

Hello Group,

Well, I spent quite a bit of time on the TCI (Transceiver Control Interface) protocol. After writing 300 lines of C I finally had a working server that handles the data channel. That still leaves the audio channels and the control message protocol. With some more work I can duplicate the performance of Hamlib.

But I find the TCI protocol hard to love. It is very poorly specified in the protocol document. I would need to resort to experimentation with client apps and SunSDR hardware to figure out how it works. And it is needlessly complicated. The use of websockets is frustrating. I think the problem is that it is really designed to be remote control software for SunSDR hardware. Other manufacturers make remote software. There is Flex SmartSDR, Icom C-IV and Elecraft K4 Remote. They are all incompatible.

Remote control software for radios is bound to be complicated. But what we need is a simple protocol so that external programs can get a few data items and audio streams from a radio, either a hardware radio or a software defined radio. The current way to do this is to use Hamlib CAT commands for the data items, a virtual audio cable through the PC sound system for audio and maybe serial port control lines for keying. It is long past the time that we should be using a serial port for anything, and PC audio systems are a nightmare.

We need a simple protocol that enables digital mode programs, logging programs, CW and digital skimmers and keyers to work with a transceiver all at once with no fuss. I thought that TCI might be that protocol. But alas, it is not.

So I am removing TCI from Quisk and will not be supporting it. There are other projects to work on that are a better use of my time.

Jim
N2ADR
 

websockets is not difficult to do the "pedestrian" way, but you need
either the GNU crypt or the openssl library to do the SHA1 and
the base64 encoding. But I would not recommend to
link with libwebsockets, this may then at the end be less
portable.

Am 12.02.2025 um 12:13 schrieb Harald Klein <hari@...>:

Hi Jim,

I did some small TCI python scripts trying to connect SDC to different radios other than SunSDR (sold mine some years ago). So yeah, it lacks some documentation, and websockets might be painful outside of web programming, but TCI at least has some level of adoption across HAM programs. As you've spent some time on that already I wouldn't throw that code away but put it in as is. Maybe someone else wants to take that as basis.

From a user perspective TCI was working fine for me with SDC and JTDX back then when I still had the SunSDR DX, much better than any virtual serial ports, virtual audio cables etc.

73 OE6HKE

On 12.02.25 09:26, Christoph v. Wüllen wrote:
Jim, my advice is to do as I did in piHPSDR:

Implemnt a minimal subset of TCI only meant to support PAs and logbook programs.

Peoply will shout at you to do more, simply reply "program yourself".



Am 11.02.2025 um 21:44 schrieb jimahlstrom via groups.io <jahlstr@...>:

Hello Group,

Well, I spent quite a bit of time on the TCI (Transceiver Control Interface) protocol. After writing 300 lines of C I finally had a working server that handles the data channel. That still leaves the audio channels and the control message protocol. With some more work I can duplicate the performance of Hamlib.

But I find the TCI protocol hard to love. It is very poorly specified in the protocol document. I would need to resort to experimentation with client apps and SunSDR hardware to figure out how it works. And it is needlessly complicated. The use of websockets is frustrating. I think the problem is that it is really designed to be remote control software for SunSDR hardware. Other manufacturers make remote software. There is Flex SmartSDR, Icom C-IV and Elecraft K4 Remote. They are all incompatible.

Remote control software for radios is bound to be complicated. But what we need is a simple protocol so that external programs can get a few data items and audio streams from a radio, either a hardware radio or a software defined radio. The current way to do this is to use Hamlib CAT commands for the data items, a virtual audio cable through the PC sound system for audio and maybe serial port control lines for keying. It is long past the time that we should be using a serial port for anything, and PC audio systems are a nightmare.

We need a simple protocol that enables digital mode programs, logging programs, CW and digital skimmers and keyers to work with a transceiver all at once with no fuss. I thought that TCI might be that protocol. But alas, it is not.

So I am removing TCI from Quisk and will not be supporting it. There are other projects to work on that are a better use of my time.

Jim
N2ADR
 

Hi Jim,

Thanks for looking at TCI and spending some of your valuable time on a trial implementation.
I'm sorry it didn't work out - In fact I feel guilty as I supported looking at it, from a position of little knowledge.
I too was hoping for the holy grail of a simple universal digital interface.

It seems there is no joined-up thinking on this with each manufacturer/developer? either using the status quo or
addressing only part of the problem in a proprietary way. And without the buy-in from them a group trying to
create such a protocol as an open standard would be unlikely to get the required support.
I don't have enough knowledge even to write the requirements for such a protocol.?

Having tried a number of the program types you mentioned I have run into interface complexity issues with?
most of them. In one recent example we had a session in my club to get people set up for a UK combined PSK63
and RTTY contest, using N1MM+ for logging, Fldigi and MMTTY and various transceivers. It took 2 hours on Zoom?
to get everyone to the state where it looked like they could make and log QSOs on both modes. Even then
one amateur found he could not make QSOs during the contest. Frustrating.

73 Jim and thanks for trying,

Neil? G4BRK



On Tue, 11 Feb 2025 at 20:44, jimahlstrom via <jahlstr=[email protected]> wrote:
Hello Group,

Well, I spent quite a bit of time on the TCI (Transceiver Control Interface) protocol. After writing 300 lines of C I finally had a working server that handles the data channel. That still leaves the audio channels and the control message protocol. With some more work I can duplicate the performance of Hamlib.

But I find the TCI protocol hard to love. It is very poorly specified in the protocol document. I would need to resort to experimentation with client apps and SunSDR hardware to figure out how it works. And it is needlessly complicated. The use of websockets is frustrating. I think the problem is that it is really designed to be remote control software for SunSDR hardware. Other manufacturers make remote software. There is Flex SmartSDR, Icom C-IV and Elecraft K4 Remote. They are all incompatible.

Remote control software for radios is bound to be complicated. But what we need is a simple protocol so that external programs can get a few data items and audio streams from a radio, either a hardware radio or a software defined radio. The current way to do this is to use Hamlib CAT commands for the data items, a virtual audio cable through the PC sound system for audio and maybe serial port control lines for keying. It is long past the time that we should be using a serial port for anything, and PC audio systems are a nightmare.

We need a simple protocol that enables digital mode programs, logging programs, CW and digital skimmers and keyers to work with a transceiver all at once with no fuss. I thought that TCI might be that protocol. But alas, it is not.

So I am removing TCI from Quisk and will not be supporting it. There are other projects to work on that are a better use of my time.

Jim
N2ADR
 

Hello Group,
?
Thank you for your interest and comments. My current understanding of digital interfaces is as follows. It may be wrong, so please supply corrections.
?
The term "digital interface" means the method used to connect PC programs to a ham radio. These external programs are used for logging QSO's, examining the spectrum for CW or digital signals, decoding CW, provide Rx and Tx for digital modes, and possibly keying the transmitter in CW mode. The most common way to do this is to use Hamlib CAT control for data and a virtual audio cable (VAC) for sample streams. Old hardware radios probably lack any control ports and require an external TNC. Newer hardware radios may have a DB9 serial port and perhaps USB, although the USB may be configured as a serial port only. Very new hardware radios may have an Ethernet port and a scheme to use the PC to control the radio at a remote location. That implies the ability to transfer data and audio streams from the PC to the remote radio. Software defined radios are remote by nature and probably have an Ethernet port.
?
The hardware vendors are working on digital interfaces, but they are designing for digital control of a remote radio, and this digital interface is probably not useful for our external programs. I think the hardware folks are working on their own problems. An interface for external programs is a separate problem and of secondary interest at best. So no one is working on a simple universal digital interface.
?
I was hoping that TCI would be such an interface. But most external programs do not have TCI support. I am thinking of popular programs like WSJT-X and N1MM+. Programs that do have TCI support can also use the CAT/VAC scheme unless they are dedicated to the SunSDR hardware. So I see no need to support TCI, and my time is better spent on improving the CAT/VAC code in Quisk.
?
I am willing to work on a universal digital interface, but unless it is adopted by multiple hardware and software vendors it won't be useful. I am not sure if widespread adoption is likely.
?
Jim
N2ADR
?
 

For the "restricted" case, TCI has very much the same scope as CAT-over-TCP. Such a "restricted"
implementation is easily made (look at the piHPSDR source code, I recently added this) but is
restricted to "talking with" logbook programs and PAs (sending our frequency and mode information).

A complete implementation will also include transfer of audio and even IQ data, but 90% of
our clients will be happy to with the "restricted" implementation.

However, logbook programs and PAs should support CAT then one can use hamlib.

Am 13.02.2025 um 17:16 schrieb jimahlstrom via groups.io <jahlstr@...>:

Hello Group,
Thank you for your interest and comments. My current understanding of digital interfaces is as follows. It may be wrong, so please supply corrections.
The term "digital interface" means the method used to connect PC programs to a ham radio. These external programs are used for logging QSO's, examining the spectrum for CW or digital signals, decoding CW, provide Rx and Tx for digital modes, and possibly keying the transmitter in CW mode. The most common way to do this is to use Hamlib CAT control for data and a virtual audio cable (VAC) for sample streams. Old hardware radios probably lack any control ports and require an external TNC. Newer hardware radios may have a DB9 serial port and perhaps USB, although the USB may be configured as a serial port only. Very new hardware radios may have an Ethernet port and a scheme to use the PC to control the radio at a remote location. That implies the ability to transfer data and audio streams from the PC to the remote radio. Software defined radios are remote by nature and probably have an Ethernet port.
The hardware vendors are working on digital interfaces, but they are designing for digital control of a remote radio, and this digital interface is probably not useful for our external programs. I think the hardware folks are working on their own problems. An interface for external programs is a separate problem and of secondary interest at best. So no one is working on a simple universal digital interface.
I was hoping that TCI would be such an interface. But most external programs do not have TCI support. I am thinking of popular programs like WSJT-X and N1MM+. Programs that do have TCI support can also use the CAT/VAC scheme unless they are dedicated to the SunSDR hardware. So I see no need to support TCI, and my time is better spent on improving the CAT/VAC code in Quisk.
I am willing to work on a universal digital interface, but unless it is adopted by multiple hardware and software vendors it won't be useful. I am not sure if widespread adoption is likely.
Jim
N2ADR

1 - 7 of 7