Tnx for the new Build 137.
I have a Glitch, it's not really a Bug. And this exists since some Time. Not sure, if it is cqrlog, wsjtx, hamlib or the remote Mode.
My Setup:
Linux Mint 21.3 Cinnemon
CQRLog 137 Alpha
WSJTX 2.7.0 - Split Setting: Fake it. None or RIG didn't make a Difference.
Hamlib 4.6.2
WSJTX, build from Source, uses Hamlib 4.6.1 internal. Using 4.6.1 System wide makes no Difference.
RIG - Yaesu FT-DX10
I use the Remote Connection for WSJTX via Hamlib NET rigctl as RIG in WSJTX.
This Combination did work very well with a little Glitch, that appears only in this Configuration and not, if WSJTX is connected direct to the RIG without CQRLog.
It's with the RX and TX Audio Settings in the WSJTX Main Window and Band or Mode Switching (with a Frequency Change).
Example:
In WSJTX, RX and TX Audio are set to 800 Hz.
Now switching to another Band. TX and RX Audio Settings should not change, only the Band Frequency.
But always on Band Switching, the RX Audio Settings jumps to 5000 Hz. But only in Remote Mode with CQRLog, not with direct Connection to the RIG.
Same happens on Mode Switching in the same Band, if a Frequency change for the Mode happens.
FT8 to FT4 - RX jumps to 5000 Hz.
Set RX back to 800 Hz and switching back to FT8 - no RX Audio change.
Now back to FT4 - RX jumps again to 5000 Hz.
In Short: Band change - RX Audio switches always to 5000 Hz. Mode change FT8/FT4 - one change for Free :-)
RIG and WSJTX direct Connection - no RX Audio changes.
It's not a Bug, a little (Cosmetic) Glitch and a interesting Behavior. It's not a big Deal and only one more Click to equalize TX and RX Audio in WSJTX. And it's only needed if you want to Monitor your TX Audio for other Users on the same TX Audio.
Heinz-Juergen DO1YHJ
HI!
Sounds like WSJT-X "property".
I had to test this and started Cqrlog. It starts by script that first checks if rigctld is running. If not it starts it leaving it running on background. Settings for it are for my IC7300.
After rigctld is checked/started it starts Cqrlog that uses RIG #2 "Hamlib net rigctld".
Then I started (manually) WSJTX. It uses also RIG #2 "Hamlib net rigctld". At that point the Cqrlog WSJT remote is not yet running.
Suddenly I noticed that WSJT-X RX audio on waterfall was set to 5000Hz that I never use as max audio bandwidth for IC7300 is 3600Hz.
When switched to WSJTX-remote on and made some band and mode changes it did not affect to RX audio setting.
It kept on same frequency I changed for it by clicking on waterfall.
Now when I remembering backwards I have seen RX on 5000Hz some times before.
But that does not matter and needs no attention as it will jump to right frequency when you select a station from Band activity window, or Cqrlog's Cq-monitor/Map to work with.
WSJT-X will receive the whole bandwidth not depending on where the RX audio is spotted.
I could not make this happen again with band change or WSJT mode change. And not ever when I closed Cqrlog, WSJT-X and killed rigctld and started all over again.
It seems to be more or less random with Icom IC7300/Fedora 41/Hamlib 4.7~git 2025-06-09T09:26:07Z SHA=93434b 64-bit
How ever it seems to be a problem with WSJT-X itself when using rigctld started from elsewhere than via WSJT-X itself.
WSJT-X has it's own rigctld called rigctld-wsjtx that it uses.
Note that I did not have Cqrlog remote even opened when getting same 5000Hz RX setting.
Looks like the "key" is that rigctld is "pre started" with rig parameters and then WSJT-X uses it with RIG #2 "Hamlib net rigctld".
I use "WSJT-X v2.8.0 improved PLUS edition" by Uwe, DG2YCB. It seems to have same "property".
You could try that version too to see if it works same way with FT-DX10 when band or mode changes.
If it works same way then perhaps contact to Uwe for this. You both are talking same language (I assume) that makes the conversation easier.
--
Saku
OH1KH
Tnx for the response. You are absolutely right, it's only a little glitch and didn't affect Operations in any way. I will give the improved Version a try.
73 de Heinz-Juergen DO1YHJ