wsjt-devel — WSJT software development

Re: [wsjt-devel] Sequencer Did Recognize 73 Because of a3 ?

[Iztok <s5...@s5...>]

Hello,

all OK: after R-13 RR73 or RRR is expected. 73 does not confirm RX of 
-13 raport.

73 gl, cu

Iztok, s52d

On 10/23/25 06:24, Tim Goeppinger via wsjt-devel wrote:
> I am using WSTJ-x 3.0.0 RC1
>
> Today I was working FR4OM on FT4, and I had an issue with the auto sequencing.    FR4OM's 73 message had the AP a3 in it, and was totally ignored by my auto sequencer.   I just continued to send my R-08 message.   Is this the way it should behave?
>
> 251022_150830    28.180 Tx FT4      0  0.0  567 FR4OM N6GP DM13
> 251022_150837    28.180 Rx FT4    -13  0.2 1447 N6GP FR4OM +03
> 251022_150845    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-13
> 251022_150852    28.180 Rx FT4     -8  0.2 1446 N6GP FR4OM 73  a3
> 251022_150900    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
> 251022_150915    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
>
> Tnx & 73,
> Tim N6GP
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Sequencer Did Recognize 73 Because of a3 ?

[Tim G. <ti...@ya...>]

I am using WSTJ-x 3.0.0 RC1

Today I was working FR4OM on FT4, and I had an issue with the auto sequencing.    FR4OM's 73 message had the AP a3 in it, and was totally ignored by my auto sequencer.   I just continued to send my R-08 message.   Is this the way it should behave?

251022_150830    28.180 Tx FT4      0  0.0  567 FR4OM N6GP DM13
251022_150837    28.180 Rx FT4    -13  0.2 1447 N6GP FR4OM +03
251022_150845    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-13
251022_150852    28.180 Rx FT4     -8  0.2 1446 N6GP FR4OM 73  a3
251022_150900    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
251022_150915    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08

Tnx & 73,
Tim N6GP

[wsjt-devel] V3.0.0 rc1 issues

[Richard L. <ric...@gm...>]

Hi
Been using the new rc1 for a while and have a few issues to report.
Using Windows 10. All issues new to this RC1 and not seen in V2.7.0. My
usage is FT8 & FT4.

1. The link to the selected audio device comes up when you load app but
after a few TX cycles it drops out and you have to go to settings, Audio
tab and reselect the same device. Once you've done this once it seems to
hold onto it OK.

2. The log qso window keeps last Comments entered even though this is not
the selected option. Also it shows empty in the new qso comment field but
the previous old comment is logged.

3. In a qso exchange where it is necessary to repeat Tx3 before you get a
Tx4 confirmation the report sent changes each time the caller is decodes
and has a different decode report. This means it's impossible to know which
report the caller has actually received in the sequence. I don't recall
seeing this in V2.7. Example here where my sent report changes from R-11 to
R-10 to R-09 before I see the Tx4:

249 VA3BS G4AHN -01 251021_181822 28.180 Rx FT4 -11 0.5 1385 "on Odd"
250 G4AHN VA3BS R-11 251021_181830 28.180 Tx FT4 0 0.0 2491 "On Even"
251 VA3BS G4AHN -01 251021_181837 28.180 Rx FT4 -10 0.5 1385 "on Odd"
252 G4AHN VA3BS R-10 251021_181845 28.180 Tx FT4 0 0.0 2491 "on Odd"
253 VA3BS G4AHN -01 251021_181852 28.180 Rx FT4 -9 0.4 1385 "on Odd"
254 G4AHN VA3BS R-09 251021_181900 28.180 Tx FT4 0 0.0 2491 "On Even"
255 G4AHN VA3BS R-09 251021_181915 28.180 Tx FT4 0 0.0 2491 "on Odd"
256 G4AHN VA3BS R-09 251021_181930 28.180 Tx FT4 0 0.0 1385 "On Even"
257 G4AHN VA3BS R-09 251021_181945 28.180 Tx FT4 0 0.0 1385 "on Odd"
258 VA3BS G4AHN RR73 251021_181952 28.180 Rx FT4 -4 0.5 1385 "on Odd"

4. When calling CQ it sometimes does not auto select a caller and continues
with another CQ. Doesn't seem to be because of a late decode looking at my
UDP log. see example here at 145730.

145700 Tx 2316 + CQ G4AHN IO91

145715 Tx 2316 + CQ G4AHN IO91

145722 -11 0.4 2313 + G4AHN AB8E FM08  U.S.A. VA-WV

145730 Tx 2316 + CQ G4AHN IO91

145734 Tx 2316 + AB8E G4AHN -11

145745 Tx 2316 + AB8E G4AHN -11

145752 -7 0.3 2314 + G4AHN AB8E R-11  U.S.A.

145800 Tx 2316 + AB8E G4AHN RR73

145830 Tx 2316 + AB8E G4AHN RR73

145845 Tx 2316 + AB8E G4AHN RR73

145900 Tx 2316 + AB8E G4AHN RR73

145915 Tx 2316 + CQ G4AHN IO91

145930 Tx 2316 + CQ G4AHN IO91




Many thanks for all the hard work

73

Rich

G4AHN

Re: [wsjt-devel] Can't Enable Tx in Super Fox mode (WSJT-X version 2.7)

[Larry B. <lar...@ve...>]

Hi Jim,

I don't think it will transmit until he has decoded a superfox 
transmission.   It's designed this way to prevent blind calling.

73 -- Larry - W1DYJ



On 10/21/2025 19:07, Jim Reisert AD1C via wsjt-devel wrote:
> My father W1JR is running WSJT-X version 2.7.
>
> He can transmit in normal mode (and I believe Fox/Hound) mode, but
> when he switches to SF mode, clicking on "Enable Tx" doesn't work --
> the box never enables transmitting.  I just watched him do this
> (virtually), and I'm confused why.
>
> Any idea what could be the problem?
>
> Thanks - Jim AD1C
>
>

[wsjt-devel] Can't Enable Tx in Super Fox mode (WSJT-X version 2.7)

[Jim R. A. <jjr...@al...>]

My father W1JR is running WSJT-X version 2.7.

He can transmit in normal mode (and I believe Fox/Hound) mode, but
when he switches to SF mode, clicking on "Enable Tx" doesn't work --
the box never enables transmitting.  I just watched him do this
(virtually), and I'm confused why.

Any idea what could be the problem?

Thanks - Jim AD1C


-- 
Jim Reisert AD1C, <jjr...@al...>, https://ad1c.us

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Dan C. <hot...@ho...>]

I’ve made a couple of handfuls of contacts with them, the ones that were made using SF all showed the verification with the exception of 1 17m contact on 10/18. Even though I got the RR73 from the station I worked, it never confirmed in Clublog. All others confirmed immediately. I can only assume that I worked a pirated call without having them do a log check. I have since reworked that band slot.
Sent from my iPhone

> On Oct 20, 2025, at 4:42 PM, Erik Icket via wsjt-devel <wsj...@li...> wrote:
> 
> Some more info,
> 
> I did a fallback to 2.7.0, and there as well, there is no OTP message.
> So the OM has a SF key (see ncdxf), but probably has not loaded his key by
> ticking OTP in the Advanced tab, and entering the key.
> 
> What about a hint at the hound side (and the fox side ?), that the fox is
> running without OTP key ?
> 
> 73's Erik
> ON4PB
> 
> -----Original Message-----
> From: Erik Icket <run...@gm...>
> Sent: Monday, 20 October 2025 22:28
> To: wsj...@li...
> Subject: SuperFox - OTP verification in rel 3.0.0-rc1
> 
> Dear developers,
> 
> This evening, I was working PJ6Y in SuperFox mode, but did not observe any
> OTP verification results.
> 
> ------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
> 201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
> 201100 -5 0.4 746 ~ TA2LG PJ6Y -01
> 201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
> ------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
> 201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
> 201130 -7 0.5 746 ~ TA2LG PJ6Y -01
> 201130 -7 0.5 746 ~ ON4PB PJ6Y -04
> 
> Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
> Show OTP messages.
> 
> Should there be a either a $Verify$ or verified or invalid OTP result line
> in the Band Activity ?
> 
> 73's Erik
> ON4PB
> 
> 
> 
> 
> 
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Please read “hound side” and not “fox side” in my last phrase.

 

My apologies.

 

From: Erik Icket <run...@gm...> 
Sent: Monday, 20 October 2025 23:46
To: 'Joseph Taylor' <jo...@Pr...>; wsj...@li...
Subject: RE: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Dear Joe,

 

I may well have been too naïve in believing so.

 

The thing is that on the hound side, in the absence of an OTP, and all OTP checkboxes ticked, you cannot really tell if an OTP verification is done or not.

I believe today, one can observe “$Verify$”, “K1ABC verified”, “K1ABC invalid” in the band activity pane.

What if we add a hint at the fox side that the callsign is “not verified” if all OTP checkboxes (Superfox mode, Hound, OTP, Show OTP messages) are ticked ?

 

73’s Erik

ON4PB

 

From: Joseph Taylor <jo...@Pr... <mailto:jo...@Pr...> > 
Sent: Monday, 20 October 2025 22:54
To: wsj...@li... <mailto:wsj...@li...> 
Cc: Erik Icket <run...@gm... <mailto:run...@gm...> >
Subject: Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Hi Erik,

 

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

 



 

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Dear Joe,

 

I may well have been too naïve in believing so.

 

The thing is that on the hound side, in the absence of an OTP, and all OTP checkboxes ticked, you cannot really tell if an OTP verification is done or not.

I believe today, one can observe “$Verify$”, “K1ABC verified”, “K1ABC invalid” in the band activity pane.

What if we add a hint at the fox side that the callsign is “not verified” if all OTP checkboxes (Superfox mode, Hound, OTP, Show OTP messages) are ticked ?

 

73’s Erik

ON4PB

 

From: Joseph Taylor <jo...@Pr...> 
Sent: Monday, 20 October 2025 22:54
To: wsj...@li...
Cc: Erik Icket <run...@gm...>
Subject: Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Hi Erik,

 

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

 



 

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Joseph T. <jo...@Pr...>]

Hi Erik,

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

[cid:1c518ba7-4742-42f7-8f5e-73b0e5c9f472]

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Some more info,

I did a fallback to 2.7.0, and there as well, there is no OTP message.
So the OM has a SF key (see ncdxf), but probably has not loaded his key by
ticking OTP in the Advanced tab, and entering the key.

What about a hint at the hound side (and the fox side ?), that the fox is
running without OTP key ?

73's Erik
ON4PB

-----Original Message-----
From: Erik Icket <run...@gm...> 
Sent: Monday, 20 October 2025 22:28
To: wsj...@li...
Subject: SuperFox - OTP verification in rel 3.0.0-rc1

Dear developers,

This evening, I was working PJ6Y in SuperFox mode, but did not observe any
OTP verification results.

------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
201100 -5 0.4 746 ~ TA2LG PJ6Y -01
201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
201130 -7 0.5 746 ~ TA2LG PJ6Y -01
201130 -7 0.5 746 ~ ON4PB PJ6Y -04

Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
Show OTP messages.

Should there be a either a $Verify$ or verified or invalid OTP result line
in the Band Activity ?

73's Erik
ON4PB

[wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Dear developers,

This evening, I was working PJ6Y in SuperFox mode, but did not observe any
OTP verification results.

------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
201100 -5 0.4 746 ~ TA2LG PJ6Y -01
201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
201130 -7 0.5 746 ~ TA2LG PJ6Y -01
201130 -7 0.5 746 ~ ON4PB PJ6Y -04

Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
Show OTP messages.

Should there be a either a $Verify$ or verified or invalid OTP result line
in the Band Activity ?

73's Erik
ON4PB

Re: [wsjt-devel] WSJTX build issue on Windows

[Gary R. <cga...@gm...>]

You might want to look over in the JTSDK reflector for Windows build assistance:

https://groups.io/g/JTSDK/topics
> On Oct 19, 2025, at 3:41 PM, Mike Hornsby via wsjt-devel <wsj...@li...> wrote:
> 
> I also attempted to do a windows 11 build of wsjtx. Ran into same issues and did not get any further. 
> 
> Was able to build easily on various raspberry pi’s and older pcs. PCs using Linux mint thanks to instructions from:
> http://www.kk5jy.net/wsjtx-build/
> 
> Much evidence exists on this list for not using windows to run wsjtx. Issues with Com ports, constant updates, Microsoft withdrawal of support for versions … windows has always been problematic as any new application install can update libraries and configurations that can impact other applications.
> 
> Added to this, for handicap types of uses I would build a WSJTx raspberry pi like appliance that is stand alone and plug and play. 
> 
> To keep it as simple an and low cost as possible, I would start with a 20 meter only version that operates on the radio VOX interface. Anyone have any stats on FT8 traffic by band? 
> 
> Also, I know from experience, with a 20 watts and a 20 meter ham stick, or if you have an attic or yard, a speaker wire dipole, you can work the globe.
> 
> GL ES 73 
> Mike KC8yom
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Oct 19, 2025, at 12:54 PM, grday--- via wsjt-devel <wsj...@li... <mailto:wsj...@li...>> wrote:
>> 
>> 
>> Hello WSJTX developers:
>>  
>>     I am trying to build WSJTX from the tarball wsjtx-3.0.0_improved_PLUS_250924.tgz
>> as recommended by dg2ycb several weeks ago, but have encountered
>> a barrier for which I am looking for a suggestion.
>>  
>>     I need to build WSJTX on a Windows 11 system.
>>     I think I have made pretty good progress in the sense that I have
>> gotten what I believe to be all of the dependant packages to build and
>> install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw
>> compilers, etc.
>>  
>>    I think I am close to getting wsjtx to build, but right now I am
>> pretty much stimied.
>>  
>>     I began by installing Qt 5.15.2 and jtsdk64-tools. Within the
>> jtsdk64-tools directory framework and from the mingw64 shell I installed
>> the various dependencies via the package manager.
>>  
>>     The wsjtx source is setup to be built via the CMake build utility
>> with which I am currently a novice. I have tried to build wsjtx from a
>> build directory  via the following commands:
>>  
>> cmake -G "MinGW Makefiles" \
>>   -DWSJT_GENERATE_DOCS=OFF \
>>   -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \
>>   -DCMAKE_BUILD_TYPE=Release \
>>   -DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/mingw64" \
>>   ..
>>  
>> cmake --build . --parallel
>>  
>>     The diagnostic that I get is:
>>  
>> [ 38%] Performing configure step for 'hamlib'
>> 'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not recognized as an internal or external command,
>> operable program or batch file.
>>  
>>     I tried building and installing hamlib separately which appeared
>> to work ok but then I found that the building of wsjtx is very tightly
>> coupled to the building of hamlib in the CMake build scripts. I tried
>> tweaking the top level CMakeLists.txt file, specificly the call to
>> ExternalProject_Add(hamlib to use the bash shell to execute configure
>> but that did not work.
>>  
>>    I also tried setting the CONFIG_SHELL environment variable, i.e.,
>>  
>> export CONFIG_SHELL=/usr/bin/sh
>>  
>> but it had no effect.
>>  
>>   Any suggestions will be much appreciated.
>>  
>>     As further background, I myself am a blind developer who has
>> volunteered to make some modifications to the UDP daemon for the
>> purpose of extending the current API so that more of the WSJTX functionality
>> is available via an external accessibility agent. I myself am not a
>> radio operator and have no call sign but my goal is to make more WSJTX
>> functions available to the WSJTX blind user group.
>>  
>> Thanks in advance,
>>  
>> Gary R. Day
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li... <mailto:wsj...@li...>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li... <mailto:wsj...@li...>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX build issue on Windows

[Mike H. <mik...@ma...>]

I also attempted to do a windows 11 build of wsjtx. Ran into same issues and did not get any further. 

Was able to build easily on various raspberry pi’s and older pcs. PCs using Linux mint thanks to instructions from:
http://www.kk5jy.net/wsjtx-build/

Much evidence exists on this list for not using windows to run wsjtx. Issues with Com ports, constant updates, Microsoft withdrawal of support for versions … windows has always been problematic as any new application install can update libraries and configurations that can impact other applications.

Added to this, for handicap types of uses I would build a WSJTx raspberry pi like appliance that is stand alone and plug and play. 

To keep it as simple an and low cost as possible, I would start with a 20 meter only version that operates on the radio VOX interface. Anyone have any stats on FT8 traffic by band? 

Also, I know from experience, with a 20 watts and a 20 meter ham stick, or if you have an attic or yard, a speaker wire dipole, you can work the globe.

GL ES 73 
Mike KC8yom









> On Oct 19, 2025, at 12:54 PM, grday--- via wsjt-devel <wsj...@li...> wrote:
> 
> 
> Hello WSJTX developers:
>  
>     I am trying to build WSJTX from the tarball wsjtx-3.0.0_improved_PLUS_250924.tgz
> as recommended by dg2ycb several weeks ago, but have encountered
> a barrier for which I am looking for a suggestion.
>  
>     I need to build WSJTX on a Windows 11 system.
>     I think I have made pretty good progress in the sense that I have
> gotten what I believe to be all of the dependant packages to build and
> install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw
> compilers, etc.
>  
>    I think I am close to getting wsjtx to build, but right now I am
> pretty much stimied.
>  
>     I began by installing Qt 5.15.2 and jtsdk64-tools. Within the
> jtsdk64-tools directory framework and from the mingw64 shell I installed
> the various dependencies via the package manager.
>  
>     The wsjtx source is setup to be built via the CMake build utility
> with which I am currently a novice. I have tried to build wsjtx from a
> build directory  via the following commands:
>  
> cmake -G "MinGW Makefiles" \
>   -DWSJT_GENERATE_DOCS=OFF \
>   -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \
>   -DCMAKE_BUILD_TYPE=Release \
>   -DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/mingw64" \
>   ..
>  
> cmake --build . --parallel
>  
>     The diagnostic that I get is:
>  
> [ 38%] Performing configure step for 'hamlib'
> 'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not recognized as an internal or external command,
> operable program or batch file.
>  
>     I tried building and installing hamlib separately which appeared
> to work ok but then I found that the building of wsjtx is very tightly
> coupled to the building of hamlib in the CMake build scripts. I tried
> tweaking the top level CMakeLists.txt file, specificly the call to
> ExternalProject_Add(hamlib to use the bash shell to execute configure
> but that did not work.
>  
>    I also tried setting the CONFIG_SHELL environment variable, i.e.,
>  
> export CONFIG_SHELL=/usr/bin/sh
>  
> but it had no effect.
>  
>   Any suggestions will be much appreciated.
>  
>     As further background, I myself am a blind developer who has
> volunteered to make some modifications to the UDP daemon for the
> purpose of extending the current API so that more of the WSJTX functionality
> is available via an external accessibility agent. I myself am not a
> radio operator and have no call sign but my goal is to make more WSJTX
> functions available to the WSJTX blind user group.
>  
> Thanks in advance,
>  
> Gary R. Day
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJTX build issue on Windows

[<gr...@gr...>]

Hello WSJTX developers:

 

    I am trying to build WSJTX from the tarball
wsjtx-3.0.0_improved_PLUS_250924.tgz

as recommended by dg2ycb several weeks ago, but have encountered

a barrier for which I am looking for a suggestion.

 

    I need to build WSJTX on a Windows 11 system.

    I think I have made pretty good progress in the sense that I have

gotten what I believe to be all of the dependant packages to build and

install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw

compilers, etc.

 

   I think I am close to getting wsjtx to build, but right now I am

pretty much stimied.

 

    I began by installing Qt 5.15.2 and jtsdk64-tools. Within the

jtsdk64-tools directory framework and from the mingw64 shell I installed

the various dependencies via the package manager.

 

    The wsjtx source is setup to be built via the CMake build utility

with which I am currently a novice. I have tried to build wsjtx from a

build directory  via the following commands:

 

cmake -G "MinGW Makefiles" \

  -DWSJT_GENERATE_DOCS=OFF \

  -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \

  -DCMAKE_BUILD_TYPE=Release \

 
-DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/m
ingw64" \

  ..

 

cmake --build . --parallel

 

    The diagnostic that I get is:

 

[ 38%] Performing configure step for 'hamlib'

'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not
recognized as an internal or external command,

operable program or batch file.

 

    I tried building and installing hamlib separately which appeared

to work ok but then I found that the building of wsjtx is very tightly

coupled to the building of hamlib in the CMake build scripts. I tried

tweaking the top level CMakeLists.txt file, specificly the call to

ExternalProject_Add(hamlib to use the bash shell to execute configure

but that did not work.

 

   I also tried setting the CONFIG_SHELL environment variable, i.e.,

 

export CONFIG_SHELL=/usr/bin/sh

 

but it had no effect.

 

  Any suggestions will be much appreciated.

 

    As further background, I myself am a blind developer who has

volunteered to make some modifications to the UDP daemon for the

purpose of extending the current API so that more of the WSJTX functionality

is available via an external accessibility agent. I myself am not a

radio operator and have no call sign but my goal is to make more WSJTX

functions available to the WSJTX blind user group.

 

Thanks in advance,

 

Gary R. Day

Re: [wsjt-devel] Superfox MacOS

[Gary R. <cga...@gm...>]

I am decoding them on 10 right now with Mac M2 and OS 15.7.1 WSJT-X improved AL plus

> On Oct 18, 2025, at 1:49 PM, John Stengrevics via wsjt-devel <wsj...@li...> wrote:
> 
> Probably something specific to your situation.  I worked PJ6Y on 10m super fox this morning.  Running a MacBook Pro with M3 Max chip and Tahoe 26.0.1 operating system.
> 
> 73,
> 
> John
> WA1EAZ
> 
>> On Oct 18, 2025, at 1:40 PM, Michael Morgan via wsjt-devel <wsj...@li...> wrote:
>> 
>> I was just trying to decode and work 5K0UA on 10M using super fox and on my Mac it would never decode them.  I switched to my windows pc and it decoded fine and I was able to work them.  My time was good on my Mac.  I don’t typically use my windows machine but one I got the time synced on it, the decodes started working right away.  I am using WSJ-X Improved 250924 on both.  On my Mac I am using the M1 build.  I did also try the standard WSJT build as as well.  Not sure if it is just my situation or something may be up with the Mac builds of super fox.  All other functions work fine.  Here’s a screenshot showing both running.  I did grab an audio file but not sure that is necessary since it works fine on the Windows side.  
>> 
>> 73’s
>> 
>> Michael, AA5SH
>> 
>> https://www.aa5sh.com/pics/wsjt-sf.png_______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Superfox MacOS

[John S. <jst...@co...>]

Probably something specific to your situation.  I worked PJ6Y on 10m super fox this morning.  Running a MacBook Pro with M3 Max chip and Tahoe 26.0.1 operating system.

73,

John
WA1EAZ

> On Oct 18, 2025, at 1:40 PM, Michael Morgan via wsjt-devel <wsj...@li...> wrote:
> 
> I was just trying to decode and work 5K0UA on 10M using super fox and on my Mac it would never decode them.  I switched to my windows pc and it decoded fine and I was able to work them.  My time was good on my Mac.  I don’t typically use my windows machine but one I got the time synced on it, the decodes started working right away.  I am using WSJ-X Improved 250924 on both.  On my Mac I am using the M1 build.  I did also try the standard WSJT build as as well.  Not sure if it is just my situation or something may be up with the Mac builds of super fox.  All other functions work fine.  Here’s a screenshot showing both running.  I did grab an audio file but not sure that is necessary since it works fine on the Windows side.  
> 
> 73’s
> 
> Michael, AA5SH
> 
> https://www.aa5sh.com/pics/wsjt-sf.png_______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Superfox MacOS

[Michael M. <cmo...@gm...>]

I was just trying to decode and work 5K0UA on 10M using super fox and on my Mac it would never decode them.  I switched to my windows pc and it decoded fine and I was able to work them.  My time was good on my Mac.  I don’t typically use my windows machine but one I got the time synced on it, the decodes started working right away.  I am using WSJ-X Improved 250924 on both.  On my Mac I am using the M1 build.  I did also try the standard WSJT build as as well.  Not sure if it is just my situation or something may be up with the Mac builds of super fox.  All other functions work fine.  Here’s a screenshot showing both running.  I did grab an audio file but not sure that is necessary since it works fine on the Windows side.  

73’s

Michael, AA5SH

https://www.aa5sh.com/pics/wsjt-sf.png
wsjt-sf
PNG Image · 4.5 MB

Re: [wsjt-devel] Enforcing WSJT-X split mode

[John K. <joh...@gm...>]

Andy,

You know, I spent a fair amount of time as junior faculty working with
medical students and first year residents.  Things that were well known to
me were brand new to them and so at the start of every rotation I had to
lay out the basics all over again.  It wasn't a case of  stupidity or  bad
intent on their part.  There were just things they didn't know.  The good
news is the WSJT-X suite is a very popular application that gains more and
more users every week.  It isn't that they are not intelligent, it was just
that they didn't know or understand. In a different setting, a friend not
too long ago got chided for not doing something quite right.  Her
supervisor noted, "Well it was in a memo I sent around in 2023."
Problem was my friends started in 2024.. My point is some of the basics
need to be repeated over and over again.  So, yes, you could make rig split
or fake it mandatory.  But users might not know why it is mandatory.  Maybe
more importantly they understand the importance of a clean signal and the
role that rig  split/fake it plays  as a backup in case they get it wrong.

I am going to sign off for now.  Andy, it's a hobby and I think we should
always assume positive intent.

Peace,

John

On Mon, Oct 13, 2025 at 3:07 PM Andy Durbin via wsjt-devel <
wsj...@li...> wrote:

> "And unless I have a really good reason, I never go below 1500 Hz."
>
> Well, since you use split, you are imposing a meaningless and unnecessary
> restriction on your operating.  The requirement is not to never operate
> below DF 1500 Hz.  The requirement is not to use a modulation frequency
> below 1,500 Hz.
>
> If WSJT-X is controlling the rig correctly you cannot have a modulation
> frequency less that 1.500 Hz at any TX DF when split is in use.
>
> Andy, k3wyc
>
>
>
>
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Enforcing WSJT-X split mode

[Andy D. <a.d...@ms...>]

"And unless I have a really good reason, I never go below 1500 Hz."

Well, since you use split, you are imposing a meaningless and unnecessary restriction on your operating.  The requirement is not to never operate below DF 1500 Hz.  The requirement is not to use a modulation frequency below 1,500 Hz.

If WSJT-X is controlling the rig correctly you cannot have a modulation frequency less that 1.500 Hz at any TX DF when split is in use.

Andy, k3wyc

Re: [wsjt-devel] Hamlib new version fails on YAESU FT-100 VFO handling

[Marco C. <PY...@ou...>]

Well,

Since my issue persists and apparently nobody provided answers, I 
abandoned Hamlib NET option and I switched to Rig=YAESU FT-100: this is 
working under every situation!

73 de Marco, PY1ZRJ



Il 13/10/25 09:55, Marco Calistri via wsjt-devel ha scritto:
> *WRONG!
> *
> The issue is till present also in the new Hamlib!
>
> I need to manually switch off  the split operation in my FT-100, then 
> click again on the new band, otherwise VFOB keeps using the previous band!
>
> I use mode Rig in my WSJTX Radio Settings.
>
> Very dumb issue which was not present on the older Hamlib!
>
> Sorry for the wrong announcement!
>
> Regards!
>
> Marco, PY1ZRJ
>
> Il 13/10/25 08:19, Marco Calistri ha scritto:
>> Hello!
>>
>> Updating to
>>
>> *rigctld Hamlib 4.7~git 2025-10-10T14:52:54Z SHA=23710cf2d 64-bit*
>>
>> Has resolved the issue I spoken about in my previous message.
>>
>> So far, so good!
>>
>> Thanks,
>>
>>
>> ---
>> *73 de Marco, PY1ZRJ (former IK5BCU)*
>> **
>>
>>
>>
>> Il 30/09/25 11:57, Marco Calistri ha scritto:
>>> Hello,
>>>
>>> Hope someone of the Hamlib group being sneaking here.
>>>
>>> So far my rigctld command to drive my YAESU FT-100 CAT port has 
>>> worked flawlessly:
>>>
>>> /usr/local/bin/rigctld -m 1021 -r /dev/FT-100_USB1 -t 4532 -s 4800 
>>> *--vfo* &
>>>
>>> This by using older Hamlib version:
>>> rigctld --version: rigctld Hamlib 4.6~git 2023-07-20T21:59:57Z 
>>> SHA=aacf06 64-bit
>>>
>>> Now, using the new Hamlib version:
>>>
>>> rigctld --version: rigctld Hamlib 4.7~git 2025-09-27T16:16:32Z 
>>> SHA=0d122f6b1 64-bit
>>>
>>> One of the VFO stays on previous frequency when I switch band.
>>>
>>> For example: I start working on 10 meters band then VFOA tunes on 
>>> 28.074 and VFOB tunes on the same frequency minus or plus the audio 
>>> shift.
>>>
>>> When I switch band, for example to 17 meters, VFOA sets on 18.100, 
>>> whereas VFOB stays on 28.074!
>>>
>>> This is a really annoying behavior!
>>>
>>> I tried also without adding the *--vfo* parameter at rigctld without 
>>> success and obtaining a worst and slower switching from TX to RX.
>>>
>>> Thanks for any inputs you could provide.
>>>
>>> Marco, PY1ZRJ
>>> ---
>>> *73 de Marco, PY1ZRJ (former IK5BCU)*
>>> **
>>
>>
>
>
> ---
> *73 de Marco, PY1ZRJ (former IK5BCU)*
> **
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**

Re: [wsjt-devel] Enforcing WSJT-X split mode

[John K. <joh...@gm...>]

Andy,

Yes , indeed.  As we dig to the weeds on Rig Split versus Fake It and how
you know my only point was it is worth remembering why we got into this
discussion.   I must have read your paper or heard the talk because I have
from day one I have used Fake It.   And unless I have a really good reason,
I never go below 1500 Hz.

Point taken......"When you are up to your rear end in alligators it is
worth remembering why you got into the swamp!"

Cheers!

John

On Mon, Oct 13, 2025 at 1:46 PM Andy Durbin via wsjt-devel <
wsj...@li...> wrote:

> "I thought this all started with an observation that some people hit it
> way too hard and generate unwanted harmonics.  I have always thought the
> "cure" for that was to turn down the audio feed.  It is not clear to me how
> using rig split or Fake It solves that problem."
>
> When WSJT-X split mode is used the modulation frequency is always in the
> range 1,500 - 2,000 Hz.  The lowest frequency of the second harmonic is
> 3,000 Hz which is outside the TX passband of most transceivers.
>
> When WSJT-X split mode is not used the lowest modulating frequency is 200
> Hz. The harmonics of 200 Hz contaminate the normal WSJT-X operating
> frequency range.
>
> It is simply not possible to foul up the band with audio harmonics if
> split mode is used.  There is no protection against fouling the band if
> split mode is not used and transmission are made at the low end of the DF
> range.
>
> This is not new knowledge.  Long before WSJT-X was popular JT65 HF
> operating instructions cautioned against transmitting in the low DF range.
>
> Sure, if every operator set up their station to be free of audio
> harmonics, there would be no need for split mode.  You only have to look at
> the FT8 frequencies on any day of the week to know that isn't going to
> happen.
>
> I wrote a paper on this topic years ago.  It was intended for club use but
> I'll share it here - https://tinyurl.com/2err7nsz
>
> 73,
> Andy, k3wyc
>
>
>
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Enforcing WSJT-X split mode

[Andy D. <a.d...@ms...>]

"I thought this all started with an observation that some people hit it way too hard and generate unwanted harmonics.  I have always thought the "cure" for that was to turn down the audio feed.  It is not clear to me how using rig split or Fake It solves that problem."

When WSJT-X split mode is used the modulation frequency is always in the range 1,500 - 2,000 Hz.  The lowest frequency of the second harmonic is 3,000 Hz which is outside the TX passband of most transceivers.

When WSJT-X split mode is not used the lowest modulating frequency is 200 Hz. The harmonics of 200 Hz contaminate the normal WSJT-X operating frequency range.

It is simply not possible to foul up the band with audio harmonics if split mode is used.  There is no protection against fouling the band if split mode is not used and transmission are made at the low end of the DF range.

This is not new knowledge.  Long before WSJT-X was popular JT65 HF operating instructions cautioned against transmitting in the low DF range.

Sure, if every operator set up their station to be free of audio harmonics, there would be no need for split mode.  You only have to look at the FT8 frequencies on any day of the week to know that isn't going to happen.

I wrote a paper on this topic years ago.  It was intended for club use but I'll share it here - https://tinyurl.com/2err7nsz

73,
Andy, k3wyc

Re: [wsjt-devel] Enforcing WSJT-X split mode

[John K. <joh...@gm...>]

Lance,

Yes, as I said I recall that as the reason to stay above 1500 Hz.  I just
don't see how rig split or fake it solves the problem.  Or is it that
regardless of your DF, either of those modes *always* places you above 1500
Hz?

John

On Mon, Oct 13, 2025 at 12:45 PM Lance Collister, W7GJ via wsjt-devel <
wsj...@li...> wrote:

> Hi John,
>
> It IS important not to overdrive your audio stage, but that is not the
> biggest issue.
> The problem arises if the audio signals actually transmitted by the
> computer are
> under 1500 Hz...in that case, the audio harmonics can be passed through
> the filter in
> the transmitter and broadcast all across the spectrum.
>
> Before he passed away, W9MDB explained this on his website:
>
>
> https://www.dropbox.com/scl/fi/avq8nt3higd3evutjssv4/FT8Noise8.pdf?rlkey=xgfxw0bmtdik23h1psu7khz38&e=1&dl=0
>
> GL and VY 73, Lance
>
> On 10/13/2025 18:50:14, John Kludt via wsjt-devel wrote:
> > Guys,
> >
> > I thought this all started with an observation that some people hit it
> way too hard
> > and generate unwanted harmonics.  I have always thought the "cure" for
> that was to
> > turn down the audio feed.  It is not clear to me how using rig split or
> Fake It
> > solves that problem.  I always use Fake it - have for literally years.
> I thought
> > either method ,Rig Split or Fake It, was about keeping your signal more
> or less in
> > the center of the bandpass.   I do recall advice somewhere to run higher
> in the
> > bandpass rather than lower in the bandpass to move unwanted signals out
> of the
> > bandpass - is that why you all are discussing Fake It versus Rig Split?
> Isn't the
> > better answer to make sure you have a clean signal and in some cases
> maybe turn
> > down the power just a little bit?
> >
> > Just curious what I am missing.
> >
> > John K7SYS
> >
> > On Sun, Oct 12, 2025 at 11:57 PM Reino Talarmo via wsjt-devel
> > <wsj...@li...> wrote:
> >
> >     Hi Andy,
> >
> >     Your statement ‘Testing fake-it requires a transmission but rig
> split does
> >     not.’ without additional information makes no sense to me. Do you
> mean how an
> >     operator can see that he is transmitting at correct radio frequency?
> Most
> >     radios indicate the used VFO frequency, when commanded for
> transmission. In the
> >     fake-it operation the RX VFO (A) frequency changes and in the rig the
> >     transmission uses the TX VFO (B). For an indication both require a
> rig
> >     transmission activation.
> >
> >     If the Tune button is used for the activation, then there is output
> power in
> >     both cases. If the Test Cat button or the Test PTT button is used,
> then no
> >     audio will be transmitted, and no RF output will be sent. (If PTT
> method VOX is
> >     used, then the Test PTT don’t work and only the Tune button can be
> used.)
> >
> >     The change of the audio frequency is not presented to the user.
> >
> >     It would be much easier to help in the rig split operation, if at
> least you
> >     tell us the rig type and how CAT control is arranged.
> >
> >     73, Reino OH3mA
> >
> >     *From:*Andy Durbin via wsjt-devel <wsj...@li...>
> >     *Sent:* Monday, October 13, 2025 12:24 AM
> >     *To:* WSJT software development <wsj...@li...>
> >     *Cc:* Andy Durbin <a.d...@ms...>
> >     *Subject:* Re: [wsjt-devel] Enforcing WSJT-X split mode
> >
> >     "I provided a signal report with screen shots to one offending
> station and he
> >     improved his signal with audio drive adjustment.  He stated he was
> using rig
> >     split."
> >
> >     Correction - He stated he was using fake-it.  Testing fake-it
> requires a
> >     transmission but rig split does not.
> >
> >     Andy, k3wyc
> >
> >     _______________________________________________
> >     wsjt-devel mailing list
> >     wsj...@li...
> >     https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> >
> >
> > _______________________________________________
> > wsjt-devel mailing list
> > wsj...@li...
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
> Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, FO/W7GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11 - 6m DXCC #815 - FFMA #7
>
> Interested in 6m EME?  Ask me about subscribing to the new Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Enforcing WSJT-X split mode

[Lance C. W. <w7...@bi...>]

Hi John,

It IS important not to overdrive your audio stage, but that is not the biggest issue. 
The problem arises if the audio signals actually transmitted by the computer are 
under 1500 Hz...in that case, the audio harmonics can be passed through the filter in 
the transmitter and broadcast all across the spectrum.

Before he passed away, W9MDB explained this on his website:

https://www.dropbox.com/scl/fi/avq8nt3higd3evutjssv4/FT8Noise8.pdf?rlkey=xgfxw0bmtdik23h1psu7khz38&e=1&dl=0

GL and VY 73, Lance

On 10/13/2025 18:50:14, John Kludt via wsjt-devel wrote:
> Guys,
>
> I thought this all started with an observation that some people hit it way too hard 
> and generate unwanted harmonics.  I have always thought the "cure" for that was to 
> turn down the audio feed.  It is not clear to me how using rig split or Fake It 
> solves that problem.  I always use Fake it - have for literally years.  I thought 
> either method ,Rig Split or Fake It, was about keeping your signal more or less in 
> the center of the bandpass.   I do recall advice somewhere to run higher in the 
> bandpass rather than lower in the bandpass to move unwanted signals out of the 
> bandpass - is that why you all are discussing Fake It versus Rig Split?  Isn't the 
> better answer to make sure you have a clean signal and in some cases maybe turn 
> down the power just a little bit?
>
> Just curious what I am missing.
>
> John K7SYS
>
> On Sun, Oct 12, 2025 at 11:57 PM Reino Talarmo via wsjt-devel 
> <wsj...@li...> wrote:
>
>     Hi Andy,
>
>     Your statement ‘Testing fake-it requires a transmission but rig split does
>     not.’ without additional information makes no sense to me. Do you mean how an
>     operator can see that he is transmitting at correct radio frequency? Most
>     radios indicate the used VFO frequency, when commanded for transmission. In the
>     fake-it operation the RX VFO (A) frequency changes and in the rig the
>     transmission uses the TX VFO (B). For an indication both require a rig
>     transmission activation.
>
>     If the Tune button is used for the activation, then there is output power in
>     both cases. If the Test Cat button or the Test PTT button is used, then no
>     audio will be transmitted, and no RF output will be sent. (If PTT method VOX is
>     used, then the Test PTT don’t work and only the Tune button can be used.)
>
>     The change of the audio frequency is not presented to the user.
>
>     It would be much easier to help in the rig split operation, if at least you
>     tell us the rig type and how CAT control is arranged.
>
>     73, Reino OH3mA
>
>     *From:*Andy Durbin via wsjt-devel <wsj...@li...>
>     *Sent:* Monday, October 13, 2025 12:24 AM
>     *To:* WSJT software development <wsj...@li...>
>     *Cc:* Andy Durbin <a.d...@ms...>
>     *Subject:* Re: [wsjt-devel] Enforcing WSJT-X split mode
>
>     "I provided a signal report with screen shots to one offending station and he
>     improved his signal with audio drive adjustment.  He stated he was using rig
>     split."
>
>     Correction - He stated he was using fake-it.  Testing fake-it requires a
>     transmission but rig split does not.
>
>     Andy, k3wyc
>
>     _______________________________________________
>     wsjt-devel mailing list
>     wsj...@li...
>     https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, FO/W7GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME?  Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!

Re: [wsjt-devel] Enforcing WSJT-X split mode

[John K. <joh...@gm...>]

Guys,

I thought this all started with an observation that some people hit it way
too hard and generate unwanted harmonics.  I have always thought the "cure"
for that was to turn down the audio feed.  It is not clear to me how using
rig split or Fake It solves that problem.  I always use Fake it - have for
literally years.  I thought either method ,Rig Split or Fake It, was about
keeping your signal more or less in the center of the bandpass.   I do
recall advice somewhere to run higher in the bandpass rather than lower in
the bandpass to move unwanted signals out of the bandpass - is that why you
all are discussing Fake It versus Rig Split?  Isn't the better answer to
make sure you have a clean signal and in some cases maybe turn down the
power just a little bit?

Just curious what I am missing.

John K7SYS

On Sun, Oct 12, 2025 at 11:57 PM Reino Talarmo via wsjt-devel <
wsj...@li...> wrote:

> Hi Andy,
>
> Your statement ‘Testing fake-it requires a transmission but rig split does
> not.’ without additional information makes no sense to me. Do you mean how
> an operator can see that he is transmitting at correct radio frequency?
> Most radios indicate the used VFO frequency, when commanded for
> transmission. In the fake-it operation the RX VFO (A) frequency changes and
> in the rig the transmission uses the TX VFO (B). For an indication both
> require a rig transmission activation.
>
> If the Tune button is used for the activation, then there is output power
> in both cases. If the Test Cat button or the Test PTT button is used, then
> no audio will be transmitted, and no RF output will be sent. (If PTT method
> VOX is used, then the Test PTT don’t work and only the Tune button can be
> used.)
>
>
>
> The change of the audio frequency is not presented to the user.
>
>
>
> It would be much easier to help in the rig split operation, if at least
> you tell us the rig type and how CAT control is arranged.
>
>
>
> 73, Reino OH3mA
>
>
>
> *From:* Andy Durbin via wsjt-devel <wsj...@li...>
> *Sent:* Monday, October 13, 2025 12:24 AM
> *To:* WSJT software development <wsj...@li...>
> *Cc:* Andy Durbin <a.d...@ms...>
> *Subject:* Re: [wsjt-devel] Enforcing WSJT-X split mode
>
>
>
> "I provided a signal report with screen shots to one offending station and
> he improved his signal with audio drive adjustment.  He stated he was using
> rig split."
>
>
>
> Correction - He stated he was using fake-it.  Testing fake-it requires a
> transmission but rig split does not.
>
>
>
> Andy, k3wyc
>
>
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>