Re: How to Use FreeDV RADE Mode with Quisk
Hi Jim,
I tried today on my windows setup (4.2.41 ) with a VB-Audio Cable , but that doesn't work properly. Nothing received in Digital mode, and a very bad sound on Analog mode.?
I have to wait you could includ rade mode into Quisk.
Best 73
|
Re: Plugin for ELAD TMATE TM-2
Is it possible to impliment the Tmate into pihpsdr?
|
Re: TCI (Transceiver Control Interface) Protocol
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.
toggle quoted message
Show quoted text
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
|
Re: TCI (Transceiver Control Interface) Protocol
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
?
|
Re: TCI (Transceiver Control Interface) Protocol
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
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
|
Yes I know it was discussed .... long time ago;)
So I was hoping that someone was fighting with it in the meantime;)
?
73 Dawid SQ6EMM
|
Re: TCI (Transceiver Control Interface) Protocol
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.
toggle quoted message
Show quoted text
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
|
Re: TCI (Transceiver Control Interface) Protocol
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
toggle quoted message
Show quoted text
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
|
Re: TCI (Transceiver Control Interface) Protocol
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".
toggle quoted message
Show quoted text
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
|
This issue has been discussed earlier.? It seems that Pluto has fixed sampling rates.? These are incommensurate with Quisk.? At the time Jim could not suggest a fix.
Lime does not have this issue.? I have used Lime mini with 1MHz bandwidth.?
?
73 Bob g3udi?
|
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
|
Hello group,
?
anyone was able to setup and use Quisk with Adalm Pluto as a TRX?
I play for few days already and I have two issues:
?
1. rx/tx bandwidt/sampling
2. transmitting
?
If anyone succeeded could you please share your configuration?
?
Regards,
?
VY 73 de SQ6EMM/SN6M
|
Pierre - FK8IH via groups.io napsal(a): Sorry Jim, I meant can these QRP-Labs Xcvr work with Quisk?
73 - Pierre - FK8IH IMHO it's Kenwood TS-480 serial CAT and USB SSB audio, so with trivial changes the Quisk KX3 configuration could be reused to make it work as an panadapter. At the moment there is probably no point to support TX, because these radios can currently emit only FSK, i.e. no SSB TX yet, but this may change with future firmware updates. If you insist on TX support to e.g. send CW, this could be done by custom hardware file as Jim wrote, but it's much easier to just hook to the paddle/key QMX port than generate waveforms in quisk and then make the QMX FSK detector to cope with it and "re-emit" the FSK signal 73! Jaroslav, OK2JRQ
|
Quisk Version 4.2.41 January 2025
I made some improvements to the top-level Config/Radios screen. There is now an option to make a new radio by copying settings from an existing radio. I worked around a bug in wxPython and gtk3 that caused drawing problems on the config screens. This problem is not present on Windows.
?
Jim
N2ADR
|
Re: How to Use FreeDV RADE Mode with Quisk
Has anyone here used the FreeDV-GUI program with Quisk yet?
?
Jim
N2ADR
|
I looked at the web page but couldn't find what software they recommended for the PC for SSB. But it looks like a SoftRock type radio with a USB connection to the PC. So you may be able to use it with Quisk if you write your own hardware file.
?
Jim
N2ADR
|
Sorry Jim, I meant can these QRP-Labs Xcvr work with Quisk?
73 - Pierre - FK8IH
|
I don't know. Please send this to the SparkSDR group.
?
Jim
N2ADR
|
Can these QRP-Labs products work with SparkSDR ans what would be the settings to use?
73 - Pierre - FK8IH
|
How to Use FreeDV RADE Mode with Quisk
The new FreeDV RADE mode is an exciting development in digital voice, but it is not yet built into Quisk. But you can use the FreeDV-GUI program with Quisk to get it. I have written a short paper to make this easier. Let me know what you think.
?
Jim
N2ADR
|
Pierre - FK8IH