SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
187 views
Skip to first unread message
Pascal PBY
Jun 4, 2026, 11:38:49 AMJun 4
to Hermes-Lite
Hello,Screenshots of my settings.
I don't know if there's a better way, but these work. Common settings for WSJTX, VarAC, and YONIQ (MMSTV), and maybe others... ;)
I use the com0com programme to emulate virtual COM ports.
73, Pascal F6HCM
I don't know if there's a better way, but these work. Common settings for WSJTX, VarAC, and YONIQ (MMSTV), and maybe others... ;)
I use the com0com programme to emulate virtual COM ports.
73, Pascal F6HCM
Ron Lewkowicz
Jun 4, 2026, 11:55:49 PMJun 4
to Hermes-Lite
Virtual COM ports should not be necessary. These should all support hamlib NET. Default setting should be localhost:4532 WSJT-X should also work with TCI for both CAT and audio. I'm not sure about the other programs. For Windows that is probably about all you can do.
Pascal PBY
Jun 5, 2026, 3:38:10 AMJun 5
to Ron Lewkowicz, Hermes-Lite
Hello,
Thank you for your reply. I’m not familiar with the Hamlib library, so I’ll take a look at https://hamlib.github.io/ straight away.
73,
F6HCM, Pascal
>>> Envoyé depuis un Google Pixel
F6HCM, Pascal
>>> Envoyé depuis un Google Pixel
--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/dO91trJYAc0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/04f70fe0-6e15-4289-9130-1e783be86480n%40googlegroups.com.
Ron Lewkowicz
Jun 5, 2026, 12:52:02 PMJun 5
to Hermes-Lite
hamlib is built into all these programs to facilitate rig control. It supports serial ports but also supports network connections so you don't need to create COM ports to use it when the SDR software and all the other software can network together. TCI is an alternative way to facilitate rig control over network but not all software supports it as yet. Check your software to see. I know WSJT-X supports TCI. deskHPSDR and Thetis support TCI. piHPSDR also supports TCI I believe. I don't think any SSTV software supports TCI as yet but they should all support hamlib NET for rig control.
Mike Lewis
Jun 5, 2026, 1:53:36 PMJun 5
to Ron Lewkowicz, Hermes-Lite
You can add the new Zeus OpenHPSDR app and Quisk to the TCI capable list. Been use Quisk 4.2.52 on TCI 24/7 here and it is working great.
I have been running into issues with piHPSDR TCI that I hope to dig into shortly. Looking forward to seeing that stabilized in time.
I have been testing TCI setups on the same and separate CPUs with the goal of running WSJT-X and loggers and at times client SDR apps over a network connection. The goal is a ruggedized HL2 setup with compact 6M and 2M transverters (with amps) in my truck .
I want a compact radio console in the cab with MIDI control pod and 7” or 4.3” SDR app screen, and use a laptop in the cab, truck camper or trailer, campsite picnic bench nearby, or even in the house (HOA solution for some).
An IC-705 can be use and remoted too so the successful solution needs to be less cost and more capable where it counts. I am adding MIDI keyer and encoders/switches into my BT Keyboard+Touchscreen enabled version of K3NG Keyer so it can double as keyer and control pod using MIDI and/or GPIO (Pico2W or ESP32 today, Teensy4 without BT and screen so far).
Network protocol options like TCI really simplify things.
Running List that I have tried with TCI:
Thetis
Quisk 4.2.52+
piHPSDR
deskHPSDR
ZeusSDR
WSJT-X 3.0.1+
- Mike K7MDL
From: herme...@googlegroups.com <herme...@googlegroups.com>
On Behalf Of Ron Lewkowicz
Sent: Friday, June 5, 2026 9:52 AM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
hamlib is built into all these programs to facilitate rig control. It supports serial ports but also supports network connections so you don't need to create COM ports to use it when the SDR software and all the other software can network together. TCI is an alternative way to facilitate rig control over network but not all software supports it as yet. Check your software to see. I know WSJT-X supports TCI. deskHPSDR and Thetis support TCI. piHPSDR also supports TCI I believe. I don't think any SSTV software supports TCI as yet but they should all support hamlib NET for rig control.
On Friday, June 5, 2026 at 1:38:10 AM UTC-6 Pascal PBY wrote:
Hello,
Thank you for your reply. I’m not familiar with the Hamlib library, so I’ll take a look at https://hamlib.github.io/ straight away.
73,
F6HCM, Pascal
>>> Envoyé depuis un Google Pixel
Le ven. 5 juin 2026, 05:55, Ron Lewkowicz <ron.le...@gmail.com> a écrit :
Virtual COM ports should not be necessary. These should all support hamlib NET. Default setting should be localhost:4532 WSJT-X should also work with TCI for both CAT and audio. I'm not sure about the other programs. For Windows that is probably about all you can do.
On Thursday, June 4, 2026 at 9:38:49 AM UTC-6 Pascal PBY wrote:
Screenshots of my settings.
I don't know if there's a better way, but these work. Common settings for WSJTX, VarAC, and YONIQ (MMSTV), and maybe others... ;)
I use the com0com programme to emulate virtual COM ports.
73, Pascal F6HCM
--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/dO91trJYAc0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/04f70fe0-6e15-4289-9130-1e783be86480n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
hermes-lite...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/hermes-lite/c0a98835-e421-4bb1-b518-95b0f7e27418n%40googlegroups.com.
"Christoph v. Wüllen"
Jun 11, 2026, 9:23:40 AMJun 11
to Mike Lewis, herme...@googlegroups.com, n2ad...@groups.io
Hi Mike and all,
you reported about TCI problems with wsjtx, when the rig starts e.g. in CW mode
and then you make a band change where wsjtx switches the rig to the preferred
(USB or DIGU) mode.
I can confirm this problem with piHPSDR, but also with other programs, and it is
a bug in wsjtx. Basically in TCITransceiver.hpp timer#7 is used twice: for the
frequency change AND the mode change. One must use the (otherwise un-used timer8
for the mode change, and should also handle this properly on the next incoming
"CMD_MODE" from the SDR Program.
If you know wsjx people, please forward.
The following diff lets it work for me (do not care about the new mylog function, this
I included for debugging)
diff -Naur TCITransceiver.cpp.orig TCITransceiver.cpp
--- TCITransceiver.cpp.orig 2026-06-11 12:13:30
+++ TCITransceiver.cpp 2026-06-11 15:19:11
@@ -706,12 +706,17 @@
break;
case Cmd_Mode:
printf("%s Cmd_Mode : %s\n",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),args.join("|").toStdString().c_str());
+ printf("mode change:%d busy_mode_:%d timer1_remaining:%d timer2_remaining:%d",band_change,busy_other_frequency_,tci_timer8_->remainingTime(),tci_timer2_->remainingTime()); //was timer1 and timer2
if(args.at(0)==rx_) {
if (ESDR3 || HPSDR) {
if (args.at(1) == "0" ) mode_ = args.at(2).toLower(); else mode_ = args.at(1).toLower();
} else mode_ = args.at(1);
+ CAT_TRACE("Rx VFO Mode from SDR is :");
+ CAT_TRACE(mode_);
if (started_mode_.isEmpty()) started_mode_ = mode_;
- if (busy_mode_) return; // was tci_done1();
+ if (busy_mode_ && tci_timer8_->isActive()) { //return; // was tci_done1();
+ tci_done8();
+ }
else if (!requested_mode_.isEmpty() && requested_mode_ != mode_ && !band_change) {
sendTextMessage(mode_to_command(requested_mode_));
}
@@ -832,6 +837,13 @@
break;
}
}
+}
+
+void TCITransceiver::mylog(int line, const QString &msg) {
+ std::string str = msg.toStdString();
+ const char *c = str.c_str();
+ printf("%s:%05d:%s\n",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),
+ line,c);
}
void TCITransceiver::sendTextMessage(const QString &message)
@@ -1153,7 +1165,7 @@
if (!requested_mode_.isEmpty() && requested_mode_ != mode_ && !busy_mode_) {
busy_mode_ = true;
sendTextMessage(mode_to_command(requested_mode_));
- mysleep7(1000);
+ mysleep8(1000);
if (requested_mode_.isEmpty() || requested_mode_ == mode_) update_mode (m);
else {
printf("%s TCI failed set mode %s->%s",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),mode_.toStdString().c_str(),requested_mode_.toStdString().c_str());
> Am 10.06.2026 um 23:19 schrieb Mike Lewis <k7...@hotmail.com>:
>
> I pulled down your changes as of this morning and rebuilt.
>
> 1. I noticed that with TCI and WSJT-X, you cannot leave DIGU mode like you can with any other CAT protocol, to work a voice contact, Turning off WSJT-X Monitor solves that problem and you can tune the VFO from WSJT-X still. Quisk acts the same.
>
> That is advisable in any case when leaving WSJT-X running during non-digital contacts. I bounce around between modes a lot during contests and leaving Monitor on in voice mode cause updates to the logger overriding the mode and other parameters causing me to have to edit the contact after I log it to make it SSB.
>
>
> 2. The Discovery issue. It works on Windows (SparkSDR, Zues, Thetis). For all 3 of my Linux machines, as suspected this was due to firewall rules. Turning off the firewall it works. I added these firewall rules.
> sudo ufw allow from 192.168.2.240 proto udp
> sudo ufw allow from 192.168.2.241 proto udp
> where .240 and .241 are my HL2 rigs
>
> I have more rules added for 40002 range TCI ports and 50000 range control ports.
>
>
> 3. The band+mode change (ie in USB mode then use WSJT-X to switch bands, putting it into DigU) acts the same on Quisk. So likely WSJT-X side issue as you suspect. I turned on extended CAT logging in WSJT-X (place a wsjtx_log_config.ini file in the log directory) to look for timing.
> a. I set up several bands to be USB mode.
> b. Set piHPSDR to 7MHz USB.
> c. Started WSJT-X and changed bands to 20M where it popped up the retry dialog.
>
> I attached the resulting WSJT-X CAT control log. It looks like it wants to set a rxfreq and it is failing so it times out and restarts TCI.
>
> [2026-06-10 21:13:32.558183][00:00:12.297111][RIGCTRL:trace] 7143300
> [2026-06-10 21:13:32.558185][00:00:12.297113][RIGCTRL:trace] TCI failed set rxfreq. Requested Rx freq is:
> [2026-06-10 21:13:32.558187][00:00:12.297114][RIGCTRL:trace] 14074000
> [2026-06-10 21:13:32.558269][00:00:12.297196][RIGCTRL:trace] force signal: true
> [2026-06-10 21:13:32.558278][00:00:12.297204][RIGCTRL:trace] #: 11 what: TCI failed set rxfreq
> [2026-06-10 21:13:32.558285][00:00:12.297211][RIGCTRL:trace] reason: TCI failed set rxfreq
> [2026-06-10 21:13:32.558299][00:00:12.297224][RIGCTRL:trace] shutdown
> [2026-06-10 21:13:32.558304][00:00:12.297229][RIGCTRL:trace] state: false
> [2026-06-10 21:13:32.558306][00:00:12.297231][RIGCTRL:trace] TCITransceiver TCI close
> [2026-06-10 21:13:32.558394][00:00:12.297319][RIGCTRL:trace] TCITransceiver entered TCI onDisonnected and inConnected==false
> [2026-06-10 21:13:32.558428][00:00:12.297352][RIGCTRL:trace] deleted commander & closed websocket & deleted:
> [2026-06-10 21:13:32.558433][00:00:12.297357][RIGCTRL:trace] timer1
> [2026-06-10 21:13:32.558441][00:00:12.297364][RIGCTRL:trace] loop1
> [2026-06-10 21:13:32.558443][00:00:12.297366][RIGCTRL:trace] timer2
> [2026-06-10 21:13:32.558445][00:00:12.297368][RIGCTRL:trace] loop2
> [2026-06-10 21:13:32.558447][00:00:12.297369][RIGCTRL:trace] timer3
> [2026-06-10 21:13:32.558450][00:00:12.297371][RIGCTRL:trace] loop3
> [2026-06-10 21:13:32.558452][00:00:12.297373][RIGCTRL:trace] timer4
> [2026-06-10 21:13:32.558454][00:00:12.297375][RIGCTRL:trace] loop4
> [2026-06-10 21:13:32.558456][00:00:12.297377][RIGCTRL:trace] timer5
> [2026-06-10 21:13:32.558458][00:00:12.297378][RIGCTRL:trace] loop5
> [2026-06-10 21:13:32.558461][00:00:12.297380][RIGCTRL:trace] timer6
> [2026-06-10 21:13:32.558462][00:00:12.297381][RIGCTRL:trace] loop6
> [2026-06-10 21:13:32.558465][00:00:12.297383][RIGCTRL:trace] timer7
> [2026-06-10 21:13:32.558468][00:00:12.297386][RIGCTRL:trace] loop7
> [2026-06-10 21:13:32.558470][00:00:12.297388][RIGCTRL:trace] timer8
> [2026-06-10 21:13:32.558472][00:00:12.297390][RIGCTRL:trace] loop8
> [2026-06-10 21:13:32.558481][00:00:12.297399][RIGCTRL:trace] & closed TCITransceiver
> [2026-06-10 21:13:32.558491][00:00:12.297408][RIGCTRL:trace] force signal: false
> [2026-06-10 21:13:32.558497][00:00:12.297414][RIGCTRL:trace] #: Transceiver::TransceiverState(online: yes Frequency {14074000Hz, 0Hz} Mode: DIG_U; SPLIT: off; PTT: off; POWER: 0mWatts; SWR: 0; TUNE: false)
> [2026-06-10 21:13:32.558502][00:00:12.297418][RIGCTRL:trace] shutdown
> [2026-06-10 21:13:32.558504][00:00:12.297420][RIGCTRL:trace] TCITransceiver TCI close
> [2026-06-10 21:13:32.558506][00:00:12.297422][RIGCTRL:trace] force signal: false
> [2026-06-10 21:13:32.558508][00:00:12.297423][RIGCTRL:trace] startup
>
>
> 4. I retested the Not Working cases below. All working now for both Quisk and piHPSDR. Looks like it was firewall rules.
>
>
> 5. The piHPSDR dark them is growing on me as long as the background is not also dark. Need to find a way to have visible light color borders to tell where the window is vs. other dark window apps or desktop background.
>
>
> 6. I note that several times when changing TCI target addresses in WSJT-X (3.0.1) I do not get decodes and audio looks choppy. Restarting WSJT-X fixes that.
>
> 7. If you have not seen N2ADRs TCI implementation paper and related comments from the last few days, check out this thread.
> https://groups.io/g/n2adr-sdr/message/3824
>
>
> So in summary, things are looking very good. The band change mystery in WSJT-X is likely WSJT-X issue or perhaps the SDR app can respond to the rxfreq set request and make it happy.
>
> -----Original Message-----
> From: "Christoph v. Wüllen" <DL1...@darc.de>
> Sent: Wednesday, June 10, 2026 10:41 AM
> To: Mike Lewis <k7...@hotmail.com>
> Subject: Re: pihpsdr v3 update
>
> I can confirm that if you do a band change with wsjtx staying DIGU, then everything is OK.
>
> But when I start from a radio running CW on 20m and then switch to 40m, the TCI hangs, it gets a "Close" from the client. BTW I have tested deskhpsdr and it does the same.
>
> Such a "mode change" lasts very long (about 21 msec) since all sorts of operations may be involved, so I wonder what is the time-out for wsjtx when giving up.
>
> I just compile the wsjtx-3.0.1 from the sources to be able to insert some diagnostics there as well.
>
>
>
>> Am 10.06.2026 um 10:58 schrieb Mike Lewis <k7...@hotmail.com>:
>>
>> Abut the VMs, while I have worked with them on Windows since the first Hypervisor (aka Hyper-V) and the many incarnations that followed, WSLv2 on my Intel Corei7 NUC12 Win11 Pro compiles and run really snappy and looks and feels pretty much like any other app.
>>
>> Since the 90s I worked on designing, building, installing and supporting Telecom datacenter products worldwide, using fault-tolerant Stratus and AIX, then Solaris and Windows Server and clients. In '99 I moved to Microsoft Telecom/Internet and helped them moved into the Unix datacenter space with things like SQL Server and Hosted Exchange. Then came virtualization and modularization instead of hand building servers in a rack.
>>
>> I created and owned the Microsoft Deployment Toolkit program for 9 years and leveraged VMs in various ways as one tool to help with mass automated desktop and server migrations. I have little use for VMs since those days.
>>
>> I am retired since 2023 and run mostly on my Win11 desktop. piHPSDR is perhaps my favorite SDR app so it is nice to have it run so well in WSL now. The other machines are a Pi5, Pi4 and even a Pi3 still (ethernet band decoder for the IC-905 POE RF link), Linux Mint on a tablet and on an old NUC4. That is ignoring the other 6 Pi boards and 17+ ESP32/Picos/PSOC5,Arduinos and such on my desk for testing or encased in a chassis doing real work. It is good to be retired! I spend most of my time playing with radio and readio-related embedded cpu dev.
>>
>> For the last 8 months I have not been able to do much else due to severe Trigeminal Neuralgia but 2 weeks ago I finally got surgery done and I am now pain free. In another month I will be "normal" again and resume getting outside and spend more time using this stuff on mountaintops and resume motorcycle riding on forest roads and camping again.
>>
>> Getting TCI to work well, paired with client server modes make the SDR apps more useful when you can run the various pieces on more than 1 machine so simply.
>>
>> For the July CQ VHF digital portion contest I will be sitting under the shade of a tree on a 8,000ft crater rim enjoying the view while operating WSJT-X and/or piHPSDR client on my tablet over WiFi to a Pi5 server in the truck in the nearby parking lot. My buddy who will be with me will be tethered to the truck sitting at a table operating his radio of choice and answering questions from visitors all day 😊. I am bench testing the setup I plan to use.
>>
>> I am very happy to see the progress wit TCI among the various apps lately. I hear hamlib will have similar capability coming eventually.
>>
>>
>> - Mike
>>
>> -----Original Message-----
>> From: "Christoph v. Wüllen" <DL1...@darc.de>
>> Sent: Wednesday, June 10, 2026 12:10 AM
>> To: Mike Lewis <k7...@hotmail.com>
>> Subject: pihpsdr v3 update
>>
>> Well, this branch is not yet finished, many things work as expected but perhaps not in all situations. This also involves the proper shutdown/restart.
>>
>> However, discovery really *should* work without a "directed UDP" packet.
>> If "normal discovery" fails, it is in most cases a network setup problem (broadcast packets not delivered). Since your setup often involves virtual machines, the problem may be there.
>>
>> Today I have no time, but it seems I should try first
>>
>> - WSJTX tci operation: band changes initiated by wsjtx and pihpsdr
>> are properly executed on the other side
>>
>> - TCI audio: operation across restarts of the TCI server and of the
>> client
>>
>> Note you are the first one I am telling about this, I know it is not yet perfect, but it is already a big step forward.
>>
>> At the moment most tests are running everything on a single machine (my Macintosh), the next step is to have two machines, namely a Macintosh and a Raspi. But still, the HL2, the Mac and the Pi are connected to the same switch.
>>
>>
>>
>>> Am 09.06.2026 um 21:58 schrieb Mike Lewis <k7...@hotmail.com>:
>>>
>>> More testing. I see you made updates a short bit ago on Modern branch so I pulled and compiled everything here.
>>> It seems as possibly a general case that discovery now only works if enter a specific IP address for my HL2. It comes up empty at startup, I enter and address, then hit discover again and it appears.
>>> I am running piHPSDR client on Linux Mint over WiFI to piHPSDR server on a Pi5 to an HL2.
>>>
>>> • I can connect WSJT-X direct to the server over TCI and it works. The client side lost track of a band change.
>>> • Shutdown WSJT-X and restarted the client. Started WSJT-X but now TCI to the client on a different port just in case. CAT works OK but Audio is Not Working.
>>> • Changed WSJT-X audio to use the loopback audio devices and audio works there.
>>> -Mike
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 4:28 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
>>> Update – I had switched branches, did a git status, said up to date. The below tests were using image built at that point. I then went to each machine and did a git pull and several files came down including TCI.c. So I rebuilt and checked some of the ”Not Working” combos below. I also built and ran on the Linux Mint tablet. I updated the content below adding the new Linux Mint box.
>>> The only combo not working right now is WSJT-X on Windows WSL2(Ubuntu) talking to piHPSDR on any machine. Seems something going on the the WSWJT-X inside WSL2 even though it is running on the same VM that piHPSDR runs on and everyone can talk to it over TCI. Firewall is open both directions and both UDP/TCP. Will use some tools to look at it more, likely a config issue here.
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 3:03 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT I
>>> switched to the MODERN branch on a Pi5 with Bookworm and Ubuntu in Windows 11 WSL2. Ran libinstall.sh to pick up any changes since the last 2.7 builds a week ago. Running WSJT-X 3.0.1 on both Linux and Windows. piHPSDR reports as V3.
>>> At first, I had trouble with the TCI connections and audio was broken or not working. After several restarts of both ends it finally started working, something shook loose. I initially was using port 4005 as I have several instances running here. After all the restarts and changing back to 4002 it is now working. All the below are on 40002. I plan to try other ports later.
>>> On the Pi5 I ran WSJT-X locally over TCI (CAT and Audio) and it works. Good news.
>>> If I run WSJT-X on a remote machine, The WSJT-X green vertical audio RX level bar in WSJT-X bottoms out at 20 and jumps up to the current level (about 40 right now) about every 1 second. It decodes fine using the audio loopbacks. As mentioned after pots changes and restarts it finally started working also.
>>> piHPSDR on Pi5 using TCI
>>> • WSJT-X on my Win11 using TCI to the Pi5 running over LAN - works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) to the Pi5 over LAN – Not working - No connection – have to investigate firewall ports and such. I have ufw installed and port 40002 is opened.
>>> • WSJT-X on Pi5 using TCI using loopback – Works.
>>> • WSJT-X on Linux Mint tablet over WiFi – Works.
>>> piHPSDR on Win11 WSL2 (Ubuntu) using TCI
>>> • WSJT-X on my Win11 using TCI running over loopback - Works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) using TCI over loopback - Not working - Port loopback:19092 and audio loopbacks work fine though.
>>> • WSJT-X on Pi5 using TCI over LAN – Works. Took several WSJT-X restarts, tried different IP addresses to get the WSL machine. but now it works. No idea why it was not before.
>>> • WSJT-X on Linux Mint tablet over WiFi – Works.
>>> piHPSDR on Linux Mint tablet (WiFi) using TCI
>>> • WSJT-X on my Win11 using TCI running over WiFi - Works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) using TCI over WiFi – Not Working
>>> • WSJT-X on Pi5 using TCI over LAN – Works. Took several WSJT-X restarts, tried different IP addresses to get the WSL machine. but now it works. No idea why it was not before.
>>> • WSJT-X on Linux Mint tablet over loopback – Works.
>>> Since the Pi5 WSJT-X to WSL-Ubuntuover a LAN works, you would think
>>> the other cases would work too, shows port 40002 is open. Mystery… I notice that on the Pi5 every time I start up piHPSDR the spectrum draws and is frozen. I use the menu restart button and it then works normal. It did this on 2.7 but seemed to go away magically.
>>> I will rerun the server mode combos tests and diffednt TCI ports tomorrow. 3am here, enough fun for the day.
>>> 73,
>>> Mike K7MDL
>>> -----Original Message-----
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 1:09 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
>>> I will check it out. Thanks!
>>> I have been adding the Teensy4 to my fork of K3NG keyer which has TFT graphics, touch, and BT keyboard. It runs on the ESP32 and Pico2W, but getting MIDI to work on these along with serial on the USB is tough. The Teensy does MIDI+Serial easily as you know, but I lose the BT keyboard code. The graphics lib for my RA887x displays on the Teensy (from my own Teensy4 based SDR which has a custom PCB for 4.3" and 7" displays) are not supported by TFT_eSPI lib I have been using so I am forced to make wrapper functions to get the same functions. Got the MIDI and serial working good, the graphics are displaying now but the text is in the wrong areas at times.
>>> Preparing for our trip to an 8,000ft crater rim in central Oregon state for the CQ VHF contest on July 18. I have been testing an old idle Surface Pro 3 now loaded with Linux Mint running Quisk, piHPSDR, and WSJT-X in various configuration including WiFi with client-server mode. Hardware will be and HL2->transverter->150W Amp-> stacked 6M loops.
>>> I have yet to try TCI with voice modes, seems like it should work...
>>> Mike
>>> -----Original Message-----
>>> From: "Christoph v. Wüllen" <DL1...@darc.de>
>>> Sent: Tuesday, June 9, 2026 12:56 AM
>>> To: Mike Lewis <k7...@hotmail.com>
>>> Subject: Re: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT The TCI
>>> in pihpsdr was very primitive, now I have a complete overhaul that still needs some testing, but I can use it with wsjtx including Audio transport.
>>>> To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/SN6PR12MB26408AD967AC62824793F7A3F6112%40SN6PR12MB2640.namprd12.prod.outlook.com.
>>
>>
>
you reported about TCI problems with wsjtx, when the rig starts e.g. in CW mode
and then you make a band change where wsjtx switches the rig to the preferred
(USB or DIGU) mode.
I can confirm this problem with piHPSDR, but also with other programs, and it is
a bug in wsjtx. Basically in TCITransceiver.hpp timer#7 is used twice: for the
frequency change AND the mode change. One must use the (otherwise un-used timer8
for the mode change, and should also handle this properly on the next incoming
"CMD_MODE" from the SDR Program.
If you know wsjx people, please forward.
The following diff lets it work for me (do not care about the new mylog function, this
I included for debugging)
diff -Naur TCITransceiver.cpp.orig TCITransceiver.cpp
--- TCITransceiver.cpp.orig 2026-06-11 12:13:30
+++ TCITransceiver.cpp 2026-06-11 15:19:11
@@ -706,12 +706,17 @@
break;
case Cmd_Mode:
printf("%s Cmd_Mode : %s\n",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),args.join("|").toStdString().c_str());
+ printf("mode change:%d busy_mode_:%d timer1_remaining:%d timer2_remaining:%d",band_change,busy_other_frequency_,tci_timer8_->remainingTime(),tci_timer2_->remainingTime()); //was timer1 and timer2
if(args.at(0)==rx_) {
if (ESDR3 || HPSDR) {
if (args.at(1) == "0" ) mode_ = args.at(2).toLower(); else mode_ = args.at(1).toLower();
} else mode_ = args.at(1);
+ CAT_TRACE("Rx VFO Mode from SDR is :");
+ CAT_TRACE(mode_);
if (started_mode_.isEmpty()) started_mode_ = mode_;
- if (busy_mode_) return; // was tci_done1();
+ if (busy_mode_ && tci_timer8_->isActive()) { //return; // was tci_done1();
+ tci_done8();
+ }
else if (!requested_mode_.isEmpty() && requested_mode_ != mode_ && !band_change) {
sendTextMessage(mode_to_command(requested_mode_));
}
@@ -832,6 +837,13 @@
break;
}
}
+}
+
+void TCITransceiver::mylog(int line, const QString &msg) {
+ std::string str = msg.toStdString();
+ const char *c = str.c_str();
+ printf("%s:%05d:%s\n",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),
+ line,c);
}
void TCITransceiver::sendTextMessage(const QString &message)
@@ -1153,7 +1165,7 @@
if (!requested_mode_.isEmpty() && requested_mode_ != mode_ && !busy_mode_) {
busy_mode_ = true;
sendTextMessage(mode_to_command(requested_mode_));
- mysleep7(1000);
+ mysleep8(1000);
if (requested_mode_.isEmpty() || requested_mode_ == mode_) update_mode (m);
else {
printf("%s TCI failed set mode %s->%s",QDateTime::QDateTime::currentDateTimeUtc().toString("hh:mm:ss.zzz").toStdString().c_str(),mode_.toStdString().c_str(),requested_mode_.toStdString().c_str());
> Am 10.06.2026 um 23:19 schrieb Mike Lewis <k7...@hotmail.com>:
>
> I pulled down your changes as of this morning and rebuilt.
>
> 1. I noticed that with TCI and WSJT-X, you cannot leave DIGU mode like you can with any other CAT protocol, to work a voice contact, Turning off WSJT-X Monitor solves that problem and you can tune the VFO from WSJT-X still. Quisk acts the same.
>
> That is advisable in any case when leaving WSJT-X running during non-digital contacts. I bounce around between modes a lot during contests and leaving Monitor on in voice mode cause updates to the logger overriding the mode and other parameters causing me to have to edit the contact after I log it to make it SSB.
>
>
> 2. The Discovery issue. It works on Windows (SparkSDR, Zues, Thetis). For all 3 of my Linux machines, as suspected this was due to firewall rules. Turning off the firewall it works. I added these firewall rules.
> sudo ufw allow from 192.168.2.240 proto udp
> sudo ufw allow from 192.168.2.241 proto udp
> where .240 and .241 are my HL2 rigs
>
> I have more rules added for 40002 range TCI ports and 50000 range control ports.
>
>
> 3. The band+mode change (ie in USB mode then use WSJT-X to switch bands, putting it into DigU) acts the same on Quisk. So likely WSJT-X side issue as you suspect. I turned on extended CAT logging in WSJT-X (place a wsjtx_log_config.ini file in the log directory) to look for timing.
> a. I set up several bands to be USB mode.
> b. Set piHPSDR to 7MHz USB.
> c. Started WSJT-X and changed bands to 20M where it popped up the retry dialog.
>
> I attached the resulting WSJT-X CAT control log. It looks like it wants to set a rxfreq and it is failing so it times out and restarts TCI.
>
> [2026-06-10 21:13:32.558183][00:00:12.297111][RIGCTRL:trace] 7143300
> [2026-06-10 21:13:32.558185][00:00:12.297113][RIGCTRL:trace] TCI failed set rxfreq. Requested Rx freq is:
> [2026-06-10 21:13:32.558187][00:00:12.297114][RIGCTRL:trace] 14074000
> [2026-06-10 21:13:32.558269][00:00:12.297196][RIGCTRL:trace] force signal: true
> [2026-06-10 21:13:32.558278][00:00:12.297204][RIGCTRL:trace] #: 11 what: TCI failed set rxfreq
> [2026-06-10 21:13:32.558285][00:00:12.297211][RIGCTRL:trace] reason: TCI failed set rxfreq
> [2026-06-10 21:13:32.558299][00:00:12.297224][RIGCTRL:trace] shutdown
> [2026-06-10 21:13:32.558304][00:00:12.297229][RIGCTRL:trace] state: false
> [2026-06-10 21:13:32.558306][00:00:12.297231][RIGCTRL:trace] TCITransceiver TCI close
> [2026-06-10 21:13:32.558394][00:00:12.297319][RIGCTRL:trace] TCITransceiver entered TCI onDisonnected and inConnected==false
> [2026-06-10 21:13:32.558428][00:00:12.297352][RIGCTRL:trace] deleted commander & closed websocket & deleted:
> [2026-06-10 21:13:32.558433][00:00:12.297357][RIGCTRL:trace] timer1
> [2026-06-10 21:13:32.558441][00:00:12.297364][RIGCTRL:trace] loop1
> [2026-06-10 21:13:32.558443][00:00:12.297366][RIGCTRL:trace] timer2
> [2026-06-10 21:13:32.558445][00:00:12.297368][RIGCTRL:trace] loop2
> [2026-06-10 21:13:32.558447][00:00:12.297369][RIGCTRL:trace] timer3
> [2026-06-10 21:13:32.558450][00:00:12.297371][RIGCTRL:trace] loop3
> [2026-06-10 21:13:32.558452][00:00:12.297373][RIGCTRL:trace] timer4
> [2026-06-10 21:13:32.558454][00:00:12.297375][RIGCTRL:trace] loop4
> [2026-06-10 21:13:32.558456][00:00:12.297377][RIGCTRL:trace] timer5
> [2026-06-10 21:13:32.558458][00:00:12.297378][RIGCTRL:trace] loop5
> [2026-06-10 21:13:32.558461][00:00:12.297380][RIGCTRL:trace] timer6
> [2026-06-10 21:13:32.558462][00:00:12.297381][RIGCTRL:trace] loop6
> [2026-06-10 21:13:32.558465][00:00:12.297383][RIGCTRL:trace] timer7
> [2026-06-10 21:13:32.558468][00:00:12.297386][RIGCTRL:trace] loop7
> [2026-06-10 21:13:32.558470][00:00:12.297388][RIGCTRL:trace] timer8
> [2026-06-10 21:13:32.558472][00:00:12.297390][RIGCTRL:trace] loop8
> [2026-06-10 21:13:32.558481][00:00:12.297399][RIGCTRL:trace] & closed TCITransceiver
> [2026-06-10 21:13:32.558491][00:00:12.297408][RIGCTRL:trace] force signal: false
> [2026-06-10 21:13:32.558497][00:00:12.297414][RIGCTRL:trace] #: Transceiver::TransceiverState(online: yes Frequency {14074000Hz, 0Hz} Mode: DIG_U; SPLIT: off; PTT: off; POWER: 0mWatts; SWR: 0; TUNE: false)
> [2026-06-10 21:13:32.558502][00:00:12.297418][RIGCTRL:trace] shutdown
> [2026-06-10 21:13:32.558504][00:00:12.297420][RIGCTRL:trace] TCITransceiver TCI close
> [2026-06-10 21:13:32.558506][00:00:12.297422][RIGCTRL:trace] force signal: false
> [2026-06-10 21:13:32.558508][00:00:12.297423][RIGCTRL:trace] startup
>
>
> 4. I retested the Not Working cases below. All working now for both Quisk and piHPSDR. Looks like it was firewall rules.
>
>
> 5. The piHPSDR dark them is growing on me as long as the background is not also dark. Need to find a way to have visible light color borders to tell where the window is vs. other dark window apps or desktop background.
>
>
> 6. I note that several times when changing TCI target addresses in WSJT-X (3.0.1) I do not get decodes and audio looks choppy. Restarting WSJT-X fixes that.
>
> 7. If you have not seen N2ADRs TCI implementation paper and related comments from the last few days, check out this thread.
> https://groups.io/g/n2adr-sdr/message/3824
>
>
> So in summary, things are looking very good. The band change mystery in WSJT-X is likely WSJT-X issue or perhaps the SDR app can respond to the rxfreq set request and make it happy.
>
> -----Original Message-----
> From: "Christoph v. Wüllen" <DL1...@darc.de>
> Sent: Wednesday, June 10, 2026 10:41 AM
> To: Mike Lewis <k7...@hotmail.com>
> Subject: Re: pihpsdr v3 update
>
> I can confirm that if you do a band change with wsjtx staying DIGU, then everything is OK.
>
> But when I start from a radio running CW on 20m and then switch to 40m, the TCI hangs, it gets a "Close" from the client. BTW I have tested deskhpsdr and it does the same.
>
> Such a "mode change" lasts very long (about 21 msec) since all sorts of operations may be involved, so I wonder what is the time-out for wsjtx when giving up.
>
> I just compile the wsjtx-3.0.1 from the sources to be able to insert some diagnostics there as well.
>
>
>
>> Am 10.06.2026 um 10:58 schrieb Mike Lewis <k7...@hotmail.com>:
>>
>> Abut the VMs, while I have worked with them on Windows since the first Hypervisor (aka Hyper-V) and the many incarnations that followed, WSLv2 on my Intel Corei7 NUC12 Win11 Pro compiles and run really snappy and looks and feels pretty much like any other app.
>>
>> Since the 90s I worked on designing, building, installing and supporting Telecom datacenter products worldwide, using fault-tolerant Stratus and AIX, then Solaris and Windows Server and clients. In '99 I moved to Microsoft Telecom/Internet and helped them moved into the Unix datacenter space with things like SQL Server and Hosted Exchange. Then came virtualization and modularization instead of hand building servers in a rack.
>>
>> I created and owned the Microsoft Deployment Toolkit program for 9 years and leveraged VMs in various ways as one tool to help with mass automated desktop and server migrations. I have little use for VMs since those days.
>>
>> I am retired since 2023 and run mostly on my Win11 desktop. piHPSDR is perhaps my favorite SDR app so it is nice to have it run so well in WSL now. The other machines are a Pi5, Pi4 and even a Pi3 still (ethernet band decoder for the IC-905 POE RF link), Linux Mint on a tablet and on an old NUC4. That is ignoring the other 6 Pi boards and 17+ ESP32/Picos/PSOC5,Arduinos and such on my desk for testing or encased in a chassis doing real work. It is good to be retired! I spend most of my time playing with radio and readio-related embedded cpu dev.
>>
>> For the last 8 months I have not been able to do much else due to severe Trigeminal Neuralgia but 2 weeks ago I finally got surgery done and I am now pain free. In another month I will be "normal" again and resume getting outside and spend more time using this stuff on mountaintops and resume motorcycle riding on forest roads and camping again.
>>
>> Getting TCI to work well, paired with client server modes make the SDR apps more useful when you can run the various pieces on more than 1 machine so simply.
>>
>> For the July CQ VHF digital portion contest I will be sitting under the shade of a tree on a 8,000ft crater rim enjoying the view while operating WSJT-X and/or piHPSDR client on my tablet over WiFi to a Pi5 server in the truck in the nearby parking lot. My buddy who will be with me will be tethered to the truck sitting at a table operating his radio of choice and answering questions from visitors all day 😊. I am bench testing the setup I plan to use.
>>
>> I am very happy to see the progress wit TCI among the various apps lately. I hear hamlib will have similar capability coming eventually.
>>
>>
>> - Mike
>>
>> -----Original Message-----
>> From: "Christoph v. Wüllen" <DL1...@darc.de>
>> Sent: Wednesday, June 10, 2026 12:10 AM
>> To: Mike Lewis <k7...@hotmail.com>
>> Subject: pihpsdr v3 update
>>
>> Well, this branch is not yet finished, many things work as expected but perhaps not in all situations. This also involves the proper shutdown/restart.
>>
>> However, discovery really *should* work without a "directed UDP" packet.
>> If "normal discovery" fails, it is in most cases a network setup problem (broadcast packets not delivered). Since your setup often involves virtual machines, the problem may be there.
>>
>> Today I have no time, but it seems I should try first
>>
>> - WSJTX tci operation: band changes initiated by wsjtx and pihpsdr
>> are properly executed on the other side
>>
>> - TCI audio: operation across restarts of the TCI server and of the
>> client
>>
>> Note you are the first one I am telling about this, I know it is not yet perfect, but it is already a big step forward.
>>
>> At the moment most tests are running everything on a single machine (my Macintosh), the next step is to have two machines, namely a Macintosh and a Raspi. But still, the HL2, the Mac and the Pi are connected to the same switch.
>>
>>
>>
>>> Am 09.06.2026 um 21:58 schrieb Mike Lewis <k7...@hotmail.com>:
>>>
>>> More testing. I see you made updates a short bit ago on Modern branch so I pulled and compiled everything here.
>>> It seems as possibly a general case that discovery now only works if enter a specific IP address for my HL2. It comes up empty at startup, I enter and address, then hit discover again and it appears.
>>> I am running piHPSDR client on Linux Mint over WiFI to piHPSDR server on a Pi5 to an HL2.
>>>
>>> • I can connect WSJT-X direct to the server over TCI and it works. The client side lost track of a band change.
>>> • Shutdown WSJT-X and restarted the client. Started WSJT-X but now TCI to the client on a different port just in case. CAT works OK but Audio is Not Working.
>>> • Changed WSJT-X audio to use the loopback audio devices and audio works there.
>>> -Mike
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 4:28 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
>>> Update – I had switched branches, did a git status, said up to date. The below tests were using image built at that point. I then went to each machine and did a git pull and several files came down including TCI.c. So I rebuilt and checked some of the ”Not Working” combos below. I also built and ran on the Linux Mint tablet. I updated the content below adding the new Linux Mint box.
>>> The only combo not working right now is WSJT-X on Windows WSL2(Ubuntu) talking to piHPSDR on any machine. Seems something going on the the WSWJT-X inside WSL2 even though it is running on the same VM that piHPSDR runs on and everyone can talk to it over TCI. Firewall is open both directions and both UDP/TCP. Will use some tools to look at it more, likely a config issue here.
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 3:03 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT I
>>> switched to the MODERN branch on a Pi5 with Bookworm and Ubuntu in Windows 11 WSL2. Ran libinstall.sh to pick up any changes since the last 2.7 builds a week ago. Running WSJT-X 3.0.1 on both Linux and Windows. piHPSDR reports as V3.
>>> At first, I had trouble with the TCI connections and audio was broken or not working. After several restarts of both ends it finally started working, something shook loose. I initially was using port 4005 as I have several instances running here. After all the restarts and changing back to 4002 it is now working. All the below are on 40002. I plan to try other ports later.
>>> On the Pi5 I ran WSJT-X locally over TCI (CAT and Audio) and it works. Good news.
>>> If I run WSJT-X on a remote machine, The WSJT-X green vertical audio RX level bar in WSJT-X bottoms out at 20 and jumps up to the current level (about 40 right now) about every 1 second. It decodes fine using the audio loopbacks. As mentioned after pots changes and restarts it finally started working also.
>>> piHPSDR on Pi5 using TCI
>>> • WSJT-X on my Win11 using TCI to the Pi5 running over LAN - works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) to the Pi5 over LAN – Not working - No connection – have to investigate firewall ports and such. I have ufw installed and port 40002 is opened.
>>> • WSJT-X on Pi5 using TCI using loopback – Works.
>>> • WSJT-X on Linux Mint tablet over WiFi – Works.
>>> piHPSDR on Win11 WSL2 (Ubuntu) using TCI
>>> • WSJT-X on my Win11 using TCI running over loopback - Works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) using TCI over loopback - Not working - Port loopback:19092 and audio loopbacks work fine though.
>>> • WSJT-X on Pi5 using TCI over LAN – Works. Took several WSJT-X restarts, tried different IP addresses to get the WSL machine. but now it works. No idea why it was not before.
>>> • WSJT-X on Linux Mint tablet over WiFi – Works.
>>> piHPSDR on Linux Mint tablet (WiFi) using TCI
>>> • WSJT-X on my Win11 using TCI running over WiFi - Works.
>>> • WSJT-X on W11 WSL2 (Ubuntu) using TCI over WiFi – Not Working
>>> • WSJT-X on Pi5 using TCI over LAN – Works. Took several WSJT-X restarts, tried different IP addresses to get the WSL machine. but now it works. No idea why it was not before.
>>> • WSJT-X on Linux Mint tablet over loopback – Works.
>>> Since the Pi5 WSJT-X to WSL-Ubuntuover a LAN works, you would think
>>> the other cases would work too, shows port 40002 is open. Mystery… I notice that on the Pi5 every time I start up piHPSDR the spectrum draws and is frozen. I use the menu restart button and it then works normal. It did this on 2.7 but seemed to go away magically.
>>> I will rerun the server mode combos tests and diffednt TCI ports tomorrow. 3am here, enough fun for the day.
>>> 73,
>>> Mike K7MDL
>>> -----Original Message-----
>>> From: Mike Lewis
>>> Sent: Tuesday, June 9, 2026 1:09 AM
>>> To: '"Christoph v. Wüllen"' <DL1...@darc.de>
>>> Subject: RE: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT
>>> I will check it out. Thanks!
>>> I have been adding the Teensy4 to my fork of K3NG keyer which has TFT graphics, touch, and BT keyboard. It runs on the ESP32 and Pico2W, but getting MIDI to work on these along with serial on the USB is tough. The Teensy does MIDI+Serial easily as you know, but I lose the BT keyboard code. The graphics lib for my RA887x displays on the Teensy (from my own Teensy4 based SDR which has a custom PCB for 4.3" and 7" displays) are not supported by TFT_eSPI lib I have been using so I am forced to make wrapper functions to get the same functions. Got the MIDI and serial working good, the graphics are displaying now but the text is in the wrong areas at times.
>>> Preparing for our trip to an 8,000ft crater rim in central Oregon state for the CQ VHF contest on July 18. I have been testing an old idle Surface Pro 3 now loaded with Linux Mint running Quisk, piHPSDR, and WSJT-X in various configuration including WiFi with client-server mode. Hardware will be and HL2->transverter->150W Amp-> stacked 6M loops.
>>> I have yet to try TCI with voice modes, seems like it should work...
>>> Mike
>>> -----Original Message-----
>>> From: "Christoph v. Wüllen" <DL1...@darc.de>
>>> Sent: Tuesday, June 9, 2026 12:56 AM
>>> To: Mike Lewis <k7...@hotmail.com>
>>> Subject: Re: SSTV with HL2+ & Thetis v2.10.14 HL2 by MI0BOT The TCI
>>> in pihpsdr was very primitive, now I have a complete overhaul that still needs some testing, but I can use it with wsjtx including Audio transport.
>>
>>
>
Reply all
Reply to author
Forward
0 new messages