TCI - Transceiver Control Interface: is it the future?
TCI - Transceiver Control Interface: is it the future?
TCI - Transceiver Control Interface:
https://eesdr.com/en/software-en/software-en
Is this the future? It sure would be nice to see all those nasty serial connections go away, both real and virtual. But right now it appears to be limited to a mostly obscure ecosystem of SunSDR adherents.
On the radio side, it's almost certainly too much to expect the Big Three, plus Elecraft, to adopt this standard. That leaves Flex and the openHPSDR community. If Flex adopted it that would be a major impetus for further adoption, not sure about openHPSDR (e.g. Thetis).
On the application side, there's no mainstream software on the list right now with the possible exception of Log4OM. But without the usual suspects: WSJT-X, Fldigi, CW Skimmer, DXLabs and N1MM, again there's little impetus for further adoption.
Of course this is a classic chicken and egg scenario. With no app's there are no radios. With no radios there are no app's. And, worse, no amps, no tuners, no antenna switches, no rotators, etc.
Thoughts?
https://eesdr.com/en/software-en/software-en
Is this the future? It sure would be nice to see all those nasty serial connections go away, both real and virtual. But right now it appears to be limited to a mostly obscure ecosystem of SunSDR adherents.
On the radio side, it's almost certainly too much to expect the Big Three, plus Elecraft, to adopt this standard. That leaves Flex and the openHPSDR community. If Flex adopted it that would be a major impetus for further adoption, not sure about openHPSDR (e.g. Thetis).
On the application side, there's no mainstream software on the list right now with the possible exception of Log4OM. But without the usual suspects: WSJT-X, Fldigi, CW Skimmer, DXLabs and N1MM, again there's little impetus for further adoption.
Of course this is a classic chicken and egg scenario. With no app's there are no radios. With no radios there are no app's. And, worse, no amps, no tuners, no antenna switches, no rotators, etc.
Thoughts?
Re: TCI - Transceiver Control Interface: is it the future?
My vote: +1
I implemented TCI into my 2 tools (TunerReminder and 4square-Controller), it was an easy job. I guess the most work will be the mapping of the countless Thetis-Commands to the TCI-Interface.
73 Ernst
I implemented TCI into my 2 tools (TunerReminder and 4square-Controller), it was an easy job. I guess the most work will be the mapping of the countless Thetis-Commands to the TCI-Interface.
73 Ernst
Re: TCI - Transceiver Control Interface: is it the future?
My vote: +1
My RF-Kit PA is TCI ready!
My RF-Kit PA is TCI ready!
73, Norbert - DL8LAQ - ANAN-G2 w/display - Richie's latest Thetis version and pihpsdr by N1GP&DL1YCF
Re: TCI - Transceiver Control Interface: is it the future?
√ ...gets my vote.
Re: TCI - Transceiver Control Interface: is it the future?
Not seeing a lot of responses. And most of them are kind of corner cases.
It would be great to see the kind of effort that would be necessary for TCI to be put into something that would be more universal, like a macro button capability.
It would be great to see the kind of effort that would be necessary for TCI to be put into something that would be more universal, like a macro button capability.
Re: Thetis 2_8_11 changes/ideas/wants/wishes
@Scott: Would you be so kind and move this post to the TCI-Tread? Thank you!
IMHO we need only one tcp-port for TCI and it would be nice if we didn't have to sacrifice a serial port for this.
I am not sure, if the N1MM tcp/cat implementation meets any existing "standards". As far as I know there is a 3rd party tci/n1mm middleware application available, which "translates" N1mm-network to TCI... I doubt that this is the right way...
What would have to be clarified in any case is whether a server-side TCI implementation is covered by the expert electronics license.
Below a simple TCI interface (client) from one of my projects.
73 Ernst
IMHO we need only one tcp-port for TCI and it would be nice if we didn't have to sacrifice a serial port for this.
I am not sure, if the N1MM tcp/cat implementation meets any existing "standards". As far as I know there is a 3rd party tci/n1mm middleware application available, which "translates" N1mm-network to TCI... I doubt that this is the right way...
What would have to be clarified in any case is whether a server-side TCI implementation is covered by the expert electronics license.
Below a simple TCI interface (client) from one of my projects.
73 Ernst
Code: Select all
Imports System.Net
Imports System.Net.Sockets
Imports System.Net.WebSockets.ClientWebSocket
Imports System.Text
Imports System.Threading.Tasks
Imports System.Net.WebSockets
Imports System.Threading
Public Class TCICore
Dim ws As New System.Net.WebSockets.ClientWebSocket()
Public Async Function Connect(ip As String, port As String) As Task
Dim hoststr As String
hoststr = "ws://" + ip + ":" + port
Dim uri As New Uri(hoststr)
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 Or SecurityProtocolType.Tls11
Await ws.ConnectAsync(uri, CancellationToken.None)
End Function
Public Sub reConnect(ip As String, port As String)
ws = New System.Net.WebSockets.ClientWebSocket()
#Disable Warning BC42358 ' Because this call is not awaited, execution of the current method continues before the call is completed
Connect(ip, port)
#Enable Warning BC42358 ' Because this call is not awaited, execution of the current method continues before the call is completed
' End If
While ws.State = WebSocketState.Connecting
'Form1.writeConnStatus(False, "TCI: CONNECTING...")
End While
If ws.State = WebSocketState.Open Then
Me.StartListen().Wait(1000)
End If
End Sub
Public Function getWSState()
getWSState = ws.State
End Function
Public Sub OpenConnection(ip As String, port As String)
#Disable Warning BC42358 ' Because this call is not awaited, execution of the current method continues before the call is completed
Connect(ip, port)
#Enable Warning BC42358 ' Because this call is not awaited, execution of the current method continues before the call is completed
While ws.State = WebSocketState.Connecting
Form1.writeConnStatus(False, "CONNECTING...", "TCI")
End While
If ws.State <> WebSocketState.Open Then
Form1.writeConnStatus(True, "NO CONNECTION! (try reconnect every 5s)", "TCI")
Form1.commState = False
TCIinterface.tcidevice = ""
Else
Form1.writeConnStatus(False, "successfully connected", "TCI")
Form1.commState = True
End If
If ws.State = WebSocketState.Open Then
Form1.writeConnStatus(False, "successfully connected", "TCI")
Form1.commState = True
Me.StartListen().Wait(1000)
End If
End Sub
Public Async Function StartListen() As Task
Dim result As WebSocketReceiveResult
If ws.State <> WebSocketState.Open Then
Form1.writeConnStatus(True, "NO CONNECTION! (try reconnect every 5s)", "TCI")
Form1.commState = False
TCIinterface.tcidevice = ""
End If
While ws.State = WebSocketState.Open
Form1.commState = True
Dim buffer = New ArraySegment(Of Byte)(New Byte(1023) {})
Do
result = Await ws.ReceiveAsync(New ArraySegment(Of Byte)(buffer.Array), CancellationToken.None)
If result.MessageType = WebSocketMessageType.Close Then
Exit Do
Else
Dim str = Encoding.UTF8.GetString(buffer.Array, 0, result.Count)
Form1.receivedTxt.Text = Form1.receivedTxt.Text & str & vbCrLf
TCIinterface.parseTCI(str)
str = ""
End If
Loop While Not result.EndOfMessage
End While
End Function
Public Function sendTci(txt As String) As Boolean
If ws.State = WebSocketState.Open Then
sendTci = True
Dim message As Byte() = Encoding.UTF8.GetBytes(txt)
ws.SendAsync(New ArraySegment(Of Byte)(message), WebSocketMessageType.Text, True, CancellationToken.None)
sendTci = True
Form1.writeConnStatus(False, "successfully connected (Receiver " + Form1.recnrStr + ")", "TCI")
Form1.commState = True
Else
Form1.writeConnStatus(True, "NO CONNECTION! (try reconnect every 5s)", "TCI")
Form1.commState = False
TCIinterface.tcidevice = ""
sendTci = False
End If
End Function
End Class
Re: Thetis 2_8_11 changes/ideas/wants/wishes
oe3ide wrote:@Scott: Would you be so kind and move this post to the TCI-Tread? Thank you!
IMHO we need only one tcp-port for TCI and it would be nice if we didn't have to sacrifice a serial port for this.
I can't see why "sacrificing" one of four ports is a problem? Particularly if all ports could be set to either serial or IP mode.
I am not sure, if the N1MM tcp/cat implementation meets any existing "standards".
There's no special standard required, per se. CAT is already the message payload standard, that continues unchanged, and the IP socket/port standard is what it is. Don't overcomplicate this.
An IP port interface is one thing. CAT and TCI over that port are apples and oranges, or chalk and cheese, or whatever they say in your neck of the woods. TCI could easily work over RS232 serial or IP. Since Thetis already supports CAT if you add the IP port capability you then get CAT for free via that kind of connection. TCI is an entirely different protocol that would have to be added. But one step at a time. First let's get the IP port interface.
In other words: don't conflate TCI with IP port comm's.
Another way to understand this: the serial port (real or virtual) and the IP port comprise layers 1-4 of the OSI model. CAT and TCI comprise layers 5-7.
Re: TCI - Transceiver Control Interface: is it the future?
I'd like to see the full TCI implemented into Thetis; Audio & CAT. I use a RF2K-S amp which has TCI client, Log4OM & JTDX all have TCI capability. I am waiting for TCI in Thetis. I'm not really interested in trying the experimental version's being used right now. I'll patiently wait for the approved released version of Thetis.
Thank's Richie for all your efforts.
Dave
k4em
Thank's Richie for all your efforts.
Dave
k4em
Re: TCI - Transceiver Control Interface: is it the future?
Dave30019 wrote:I'd like to see the full TCI implemented into Thetis; Audio & CAT. I use a RF2K-S amp which has TCI client, Log4OM & JTDX all have TCI capability. I am waiting for TCI in Thetis. I'm not really interested in trying the experimental version's being used right now. I'll patiently wait for the approved released version of Thetis.
Thank's Richie for all your efforts.
Dave
k4em
I speak as a software developer (not for Thetis).
Without testers who also test experimental versions, it is very difficult and time-consuming to produce software that runs 100% bug-free.
The software developer usually does not have the opportunity (and time) to test all eventualities and features.
It is part of the ham spirit for me (especially on open source projects) to test prereleases or beta versions and thus let the software mature.
73 Ernst
Re: TCI - Transceiver Control Interface: is it the future?
I am having trouble with seeing an application for audio over TCI.
Will someone please edify me?
73,
Bryan W4WMT
Will someone please edify me?
73,
Bryan W4WMT
Re: TCI - Transceiver Control Interface: is it the future?
Does the TCI implemented in Thetis have PTT control. I know it has CAT but is there PTT control too.
Dave
k4em
Dave
k4em
Re: TCI - Transceiver Control Interface: is it the future?
Dave30019 wrote:Does the TCI implemented in Thetis have PTT control. I know it has CAT but is there PTT control too.
Dave
k4em
TCI is a different protocol entirely that runs over WebSockets, invented by ExpertElectronics and included in their ExpertSDR2 and ExpertSDR3 software.
As far as I know, we are currently the only other SDR radio software that has a form of their TCI server running. However, it is a work in progress and still has a number of missing facilities, including sensors (swr/power/etc/etc), rit/xit, cw macros, volume control, mon control, agc changes, dsp control, and audio/iq over the stream.
If you use the correct client software that uses TCI, such as Log4om, JTDX, and many others, then you can remove the need for virtual com ports.
The protocol is here : https://github.com/ExpertSDR3/TCI/blob/ ... %20TCI.pdf
A non exhaustive list of 3rd party TCI software is here : https://eesdr.com/en/software-en/software-en
Richie.
Richie - MW0LGE - https://www.qrz.com/db/mw0lge
Latest Release [2.10.3.5] : https://github.com/ramdor/Thetis/releases/tag/v2.10.3.5
Latest Work In Progress : https://github.com/ramdor/Thetis/releas ... .3.6-dev_2
Latest Release [2.10.3.5] : https://github.com/ramdor/Thetis/releases/tag/v2.10.3.5
Latest Work In Progress : https://github.com/ramdor/Thetis/releas ... .3.6-dev_2
Re: TCI - Transceiver Control Interface: is it the future?
I can, sort of, understand the desire for I/Q over TCI. To run digi-mode software with Thetis, without having to resort to COM ports, right?
But what could possibly be the motivation for scalar audio over TCI? I just don't get it
But what could possibly be the motivation for scalar audio over TCI? I just don't get it
Re: TCI - Transceiver Control Interface: is it the future?
First, remember that IQ data and "scalar audio" (I'll just call it audio) data is different. The vast majority of third party software (e.g. WSJT-X) uses plain audio. That's what makes it important. There are a few app's that use IQ, primarily to create a panadapter display, but there are exceptions, such as CW Skimmer. Nevertheless, the most popular app's just use audio.
The primary attraction of TCI is that it aspires to be an all-in-one solution. Put in a couple of IP and port addresses and you are done. No need to install, configure or understand virtual COM ports for command & control, or virtual audio cables for IQ or audio. This makes it conceptually simple for both the operator/user and the software developer.
The other attraction of TCI is that every radio that is TCI complaint produces the same interface. This also potentially makes it a lot easier on software developers. Rather than having to support a different library of CAT commands for every type of radio, there is just the single set of TCI commands. Of course there will still be some differences, e.g. not all radios have two receivers, but it becomes a question of what subset of TCI is supported as opposed to a completely different set of commands.
Of course the downside is that, at least at this point, TCI remains a white elephant, with only Expert Electronics having a full implementation, and Thetis a partial one. With the excellent CAT language rig control support afforded by HamLib and other implementations, as found in all of the most popular software like WSJT-X, Fldigi, DXLabs, etc., TCI is elegant but it is, to a certain extent, reinvention of the wheel, not that it isn't a "nicer wheel". And, it's already been shown that doing away with the virtual COM port for a traditional CAT language interface is trivial. This leaves simplifying the transfer of IQ or audio data between app's, something which remains as a community challenge. If the latter could be brought forth as a competing standard, the large body of work out there that already implements a CAT language interface might not be sufficiently motivated to implement TCI.
Finally, there is a challenge in convincing radio manufacturers that there is a market advantage in supporting TCI instead of supporting a proprietary CAT protocol. While we might see such forward thinkers as Elecraft or Flex jumping on the bandwagon, does anyone believe a Japanese radio manufacturer would consider this?
The primary attraction of TCI is that it aspires to be an all-in-one solution. Put in a couple of IP and port addresses and you are done. No need to install, configure or understand virtual COM ports for command & control, or virtual audio cables for IQ or audio. This makes it conceptually simple for both the operator/user and the software developer.
The other attraction of TCI is that every radio that is TCI complaint produces the same interface. This also potentially makes it a lot easier on software developers. Rather than having to support a different library of CAT commands for every type of radio, there is just the single set of TCI commands. Of course there will still be some differences, e.g. not all radios have two receivers, but it becomes a question of what subset of TCI is supported as opposed to a completely different set of commands.
Of course the downside is that, at least at this point, TCI remains a white elephant, with only Expert Electronics having a full implementation, and Thetis a partial one. With the excellent CAT language rig control support afforded by HamLib and other implementations, as found in all of the most popular software like WSJT-X, Fldigi, DXLabs, etc., TCI is elegant but it is, to a certain extent, reinvention of the wheel, not that it isn't a "nicer wheel". And, it's already been shown that doing away with the virtual COM port for a traditional CAT language interface is trivial. This leaves simplifying the transfer of IQ or audio data between app's, something which remains as a community challenge. If the latter could be brought forth as a competing standard, the large body of work out there that already implements a CAT language interface might not be sufficiently motivated to implement TCI.
Finally, there is a challenge in convincing radio manufacturers that there is a market advantage in supporting TCI instead of supporting a proprietary CAT protocol. While we might see such forward thinkers as Elecraft or Flex jumping on the bandwagon, does anyone believe a Japanese radio manufacturer would consider this?
Re: TCI - Transceiver Control Interface: is it the future?
Okay, thanks, I think I see now! Being completely ignorant of digital modes, I had missed your points above. So what type of audio interface would we need with TCI? Per receiver, where the client would tell the server which receiver to stream? Or both receivers mixed, like what we get with the audio codec in the hardware?
Reason I ask, is that it comes from two different places in the channel. So one would have to know where to start.
Reason I ask, is that it comes from two different places in the channel. So one would have to know where to start.
Re: TCI - Transceiver Control Interface: is it the future?
One big difference is that any changes, such as vfo, window focus, etc, etc, in Thetis are sent to any connected clients, without those clients having to poll the server. TCI clients can decide if they want to use the info coming in, or just ignore it.
Cat based setups are mostly implemented as a polling system. Sometimes the Kenwood AI command is used, but afaik this is not correctly handled by Thetis, just a check box in Setup which 'broadcasts' a couple of bits of info. This aspect of Thetis needs re-working, and moved to the delegate system, but I did not get around to it, as it falls outside my 'interest' area
R.
Cat based setups are mostly implemented as a polling system. Sometimes the Kenwood AI command is used, but afaik this is not correctly handled by Thetis, just a check box in Setup which 'broadcasts' a couple of bits of info. This aspect of Thetis needs re-working, and moved to the delegate system, but I did not get around to it, as it falls outside my 'interest' area
R.
Richie - MW0LGE - https://www.qrz.com/db/mw0lge
Latest Release [2.10.3.5] : https://github.com/ramdor/Thetis/releases/tag/v2.10.3.5
Latest Work In Progress : https://github.com/ramdor/Thetis/releas ... .3.6-dev_2
Latest Release [2.10.3.5] : https://github.com/ramdor/Thetis/releases/tag/v2.10.3.5
Latest Work In Progress : https://github.com/ramdor/Thetis/releas ... .3.6-dev_2
Re: TCI - Transceiver Control Interface: is it the future?
W4WMT wrote:Okay, thanks, I think I see now! Being completely ignorant of digital modes, I had missed your points above. So what type of audio interface would we need with TCI? Per receiver, where the client would tell the server which receiver to stream? Or both receivers mixed, like what we get with the audio codec in the hardware?
Reason I ask, is that it comes from two different places in the channel. So one would have to know where to start.
Now you are getting outside of my knowledge space
I don't use any software that relies on TCI, so other than from a high level, philosophical standpoint, I'm not familiar with the nuts and bolts.
You should probably read the entire TCI document here: https://github.com/maksimus1210/TCI/tree/master/doc
It's a little rough, probably a Russian to English translation.
IQ and audio streams appear to be arbitrary. Assign them however you wish, from 1 to n. I haven't read the document in great detail, I assume this matches up with VFO or DDS constructs in some logical manner. At the bottom of the document are the definitions for formatting the streams.
P.S. thanks for pointing out that other potential advantage, Richie, i.e. push vs. pull on radio state data.