TCI needs more work

[ramdor]

TCI is in its infancy, as such many features are missing, including xit/rit, sensors, audio/iq over the stream, and others

[ramdor]

Inbound commands supported

modulation
vfo
trx
split_enable
tune
rx_enable
dds
if
spot
spot_delete
start
stop
set_in_focus
mute
rx_mute
mon_volume
mon_enable
spot_clear

Outbound commands supported

clicked_on_spot
rx_clicked_on_spot
app_focus
rx_enable
tx_enable
if_limits
drive
tune_drive
tune
split_enable
dds
if
vfo
trx
modulation
rx_filter_band
start
stop
device
protocol
receive_only
trx_count
channels_count
ready
modulations_list
mute
rx_mute
mon_volume
mon_enable

Commands not yet supported (some are one way, some bidirectional)

xit_enable
rit_offset
xit_offset
rx_channel_enable
cw_macros_speed
cw_macros_delay
cw_keyer_speed
volume
rx_volume
rx_balance
agc_moe
agc_gain
rx_nb_enable
rx_nb_param
rx_bin_enable
rx_nr_enable
rx_anc_enable
rx_anf_enable
rx_apf_enable
rx_dse_enable
rx_nf_enable
lock
sql_enable
sql_level
cw_macros_speed_up
cw_macros_speed_down
iq_samplerate
audio_sample_rate
iq_start
iq_stop
audio_start
audio_stop
line_out_start
line_out_stop
line_out_recorder_start
line_out_recorder_stop
line_out_recorder_break
tx_footswitch
tx_frequency
keyer
rx_sensors_enable
tx_sensors_enable
rx_sensors
tx_sensors

[makidoja]

Audio over TCI for each RX as per EESDR would be a great addition for SDC skimmer CW and RTTY

[ramdor]

Audio over TCI for each RX as per EESDR would be a great addition for SDC skimmer CW and RTTY

yes and is mentioned in the original entry right at the top of this. Thetis prides itself on low level latency for audio streams (unlike all other sdr software) and piping audio down a websocket is just going to add more latency. It is something on the list to look at, but has very little traction right now as you can just use virtual audio cables if it is something you want to do.

[makidoja]

VAC is great, however if VAC used with IQ then it cannot be used for operation How can we get a IQ stream from RX1 while also using headphones for operation? Jim M0CKE

…

________________________________ From: Richie ***@***.***> Sent: 16 December 2023 08:22 To: ramdor/Thetis ***@***.***> Cc: Jim M0CKE ***@***.***>; Comment ***@***.***> Subject: Re: [ramdor/Thetis] TCI needs more work (Issue #6) Audio over TCI for each RX as per EESDR would be a great addition for SDC skimmer CW and RTTY yes and is mentioned in the original entry right at the top of this. Thetis prides itself on low level latency for audio streams (unlike all other sdr software) and piping audio down a websocket is just going to add more latency. It is something on the list to look at, but has very little traction right now as you can just use virtual audio cables if it is something you want to do. — Reply to this email directly, view it on GitHub<#6 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMBPZZBQNB6OYX3UPL7GU2LYJVK4LAVCNFSM5SPP3JU2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVHA3TKOJYGU2A>. You are receiving this because you commented.Message ID: ***@***.***>

[ramdor]

ask over on the forums Jim, as this is not really the place for support for that topic, especially when this entry is related to TCI implementation. Read up on the new cmASIO stuff, which will enable you to do just what you want.

[N8SDR007]

TCI maybe a mood point going forward as I see it anyway- With EE trying to make TCI fit there V3 Software and rewriting things to make that work it has already broken what was working in past with 3rd party applications to begin with. EE with there now 1.06 beta release in which JTDX was the target they used to make better with their application, thus the 1,06 broke other 3rd party applications such as SDC and MSHV because the way EE decided to change coding, If they don't follow a standard and continue their way it will often break 3rd party applications Only to create a mess for others to deal with patching to get them working, frankly EEs best value to the Ham community was TCI, but there recent work is a disaster!