You can subscribe to this list here.
2007 |
Jan
(30) |
Feb
|
Mar
(10) |
Apr
(60) |
May
(62) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(10) |
Oct
(17) |
Nov
(1) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
(21) |
Mar
(4) |
Apr
(15) |
May
(37) |
Jun
(98) |
Jul
(120) |
Aug
(1) |
Sep
(14) |
Oct
|
Nov
(31) |
Dec
(8) |
2009 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(25) |
May
(88) |
Jun
(5) |
Jul
(31) |
Aug
(25) |
Sep
(4) |
Oct
(19) |
Nov
(119) |
Dec
(11) |
2010 |
Jan
(3) |
Feb
(19) |
Mar
(4) |
Apr
|
May
(7) |
Jun
(17) |
Jul
|
Aug
(4) |
Sep
(20) |
Oct
(3) |
Nov
(29) |
Dec
(86) |
2011 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
(8) |
May
(1) |
Jun
(12) |
Jul
(9) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
|
Dec
(1) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
(10) |
Feb
(7) |
Mar
(4) |
Apr
(76) |
May
(66) |
Jun
(101) |
Jul
(210) |
Aug
(255) |
Sep
(83) |
Oct
(18) |
Nov
(3) |
Dec
(3) |
2014 |
Jan
(187) |
Feb
(139) |
Mar
(99) |
Apr
(173) |
May
(106) |
Jun
(61) |
Jul
(50) |
Aug
(66) |
Sep
(342) |
Oct
(238) |
Nov
(251) |
Dec
(189) |
2015 |
Jan
(96) |
Feb
(295) |
Mar
(260) |
Apr
(271) |
May
(358) |
Jun
(531) |
Jul
(311) |
Aug
(231) |
Sep
(267) |
Oct
(219) |
Nov
(452) |
Dec
(390) |
2016 |
Jan
(367) |
Feb
(128) |
Mar
(208) |
Apr
(308) |
May
(237) |
Jun
(272) |
Jul
(90) |
Aug
(289) |
Sep
(153) |
Oct
(214) |
Nov
(167) |
Dec
(282) |
2017 |
Jan
(194) |
Feb
(173) |
Mar
(267) |
Apr
(102) |
May
(39) |
Jun
(201) |
Jul
(1064) |
Aug
(363) |
Sep
(383) |
Oct
(289) |
Nov
(237) |
Dec
(185) |
2018 |
Jan
(175) |
Feb
(198) |
Mar
(489) |
Apr
(222) |
May
(414) |
Jun
(297) |
Jul
(329) |
Aug
(136) |
Sep
(383) |
Oct
(590) |
Nov
(834) |
Dec
(1114) |
2019 |
Jan
(425) |
Feb
(177) |
Mar
(319) |
Apr
(515) |
May
(337) |
Jun
(447) |
Jul
(525) |
Aug
(252) |
Sep
(119) |
Oct
(108) |
Nov
(211) |
Dec
(228) |
2020 |
Jan
(158) |
Feb
(141) |
Mar
(94) |
Apr
(99) |
May
(545) |
Jun
(470) |
Jul
(211) |
Aug
(142) |
Sep
(181) |
Oct
(128) |
Nov
(219) |
Dec
(213) |
2021 |
Jan
(243) |
Feb
(514) |
Mar
(279) |
Apr
(101) |
May
(97) |
Jun
(259) |
Jul
(164) |
Aug
(205) |
Sep
(149) |
Oct
(301) |
Nov
(139) |
Dec
(159) |
2022 |
Jan
(116) |
Feb
(70) |
Mar
(63) |
Apr
(46) |
May
(50) |
Jun
(114) |
Jul
(173) |
Aug
(106) |
Sep
(127) |
Oct
(65) |
Nov
(117) |
Dec
(102) |
2023 |
Jan
(139) |
Feb
(99) |
Mar
(52) |
Apr
(132) |
May
(238) |
Jun
(75) |
Jul
(91) |
Aug
(25) |
Sep
(36) |
Oct
(64) |
Nov
(45) |
Dec
(91) |
2024 |
Jan
(156) |
Feb
(56) |
Mar
(30) |
Apr
(16) |
May
(40) |
Jun
(53) |
Jul
(327) |
Aug
(171) |
Sep
(67) |
Oct
(53) |
Nov
(43) |
Dec
(78) |
2025 |
Jan
(112) |
Feb
(27) |
Mar
(46) |
Apr
(49) |
May
(58) |
Jun
(54) |
Jul
(42) |
Aug
(11) |
Sep
(92) |
Oct
(39) |
Nov
|
Dec
|
From: Dan C. <hot...@ho...> - 2025-10-20 22:31:15
|
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 |
From: Erik I. <run...@gm...> - 2025-10-20 21:49:06
|
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 |
From: Erik I. <run...@gm...> - 2025-10-20 21:46:14
|
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 |
From: Joseph T. <jo...@Pr...> - 2025-10-20 20:53:55
|
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 |
From: Erik I. <run...@gm...> - 2025-10-20 20:39:04
|
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 |
From: Erik I. <run...@gm...> - 2025-10-20 20:27:45
|
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 |
From: Gary R. <cga...@gm...> - 2025-10-19 23:30:56
|
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 |
From: Mike H. <mik...@ma...> - 2025-10-19 19:42:21
|
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 |
From: <gr...@gr...> - 2025-10-19 16:52:39
|
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 |
From: Gary R. <cga...@gm...> - 2025-10-18 18:01:28
|
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 |
From: John S. <jst...@co...> - 2025-10-18 17:49:55
|
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 |
From: Michael M. <cmo...@gm...> - 2025-10-18 17:41:13
|
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 |
From: John K. <joh...@gm...> - 2025-10-13 22:55:55
|
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 > |
From: Andy D. <a.d...@ms...> - 2025-10-13 22:03:53
|
"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 |
From: Marco C. <PY...@ou...> - 2025-10-13 21:22:49
|
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)* ** |
From: John K. <joh...@gm...> - 2025-10-13 21:03:53
|
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 > |
From: Andy D. <a.d...@ms...> - 2025-10-13 20:40:49
|
"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 |
From: John K. <joh...@gm...> - 2025-10-13 20:18:23
|
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 > |
From: Lance C. W. <w7...@bi...> - 2025-10-13 19:39:55
|
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)! |
From: John K. <joh...@gm...> - 2025-10-13 18:50:37
|
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 > |
From: Reino T. <rei...@ko...> - 2025-10-13 18:10:23
|
Hi Andy, Yes, thanks for pointing the real time indication in the case of the Rig split operation. 73, Reino OH3mA From: Andy Durbin via wsjt-devel <wsj...@li...> Sent: Monday, October 13, 2025 5:22 PM To: WSJT software development <wsj...@li...> Cc: Andy Durbin <a.d...@ms...> Subject: Re: [wsjt-devel] Enforcing WSJT-X split mode "In the fake-it operation the X VFO (A) frequency changes and in the rig the transmission uses the TX VFO (B). For an indication both require a rig transmission activation." My TS-590S simultaneously displays VFO A and VFO B. I operate in rig split and there is no transmission required to see the TX VFO frequency change when I move the TX frequency cursor. No all rigs work the same and some are more capable than others. 73, Andy, k3wyc |
From: Jaroslav Š. <jsk...@re...> - 2025-10-13 16:17:10
|
Hi, linux distros are trying to harden with the noexecstack and the execstack in decoder.f90 is causing problems. E.g. [1], [2]. It seems the g++ linker doesn't allow combination of binaries with exec/noexec stacks [1], so the whole binary needs to be compiled with the execstack which may be unacceptable for some distros. The patch proposed in [1] uses mprotect, should something similar be upstreamed? Build failure of wsjtx-2.7.0 with the gcc-c++-15.2.1 in Fedora rawhide: [81%] Building Fortran object qmap/libqmap/CMakeFiles/qmap_impl.dir/f77_wisdom.f.o cd /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap && /usr/bin/gfortran -DBIGSYM=1 -DBOOST_ALL_DYN_LINK -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_LOG_SETUP_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DCMAKE_BUILD -DFOX_OTP -DQT5 -DQT_CORE_LIB -DQT_NO_DEBUG -DUNIX -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap/qmap_impl_autogen/include -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build -I/usr/include -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/lib64/qt5/mkspecs/linux-g++ -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules -DNDEBUG -fbounds-check -funroll-all-loops -fno-f2c -ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion -fno-second-underscore -fvisibility=hidden -fPIC -c /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap/f77_wisdom.f -o CMakeFiles/qmap_impl.dir/f77_wisdom.f.o [ 81%] Linking CXX executable ldpcsim240_74 /usr/bin/cmake -E cmake_link_script CMakeFiles/ldpcsim240_74.dir/link.txt --verbose=1 /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: no error collect2: error: ld returned 1 exit status thanks & regards Jaroslav [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278939 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2385733 |
From: Andy D. <a.d...@ms...> - 2025-10-13 14:21:55
|
"In the fake-it operation the X VFO (A) frequency changes and in the rig the transmission uses the TX VFO (B). For an indication both require a rig transmission activation." My TS-590S simultaneously displays VFO A and VFO B. I operate in rig split and there is no transmission required to see the TX VFO frequency change when I move the TX frequency cursor. No all rigs work the same and some are more capable than others. 73, Andy, k3wyc |
From: Marco C. <PY...@ou...> - 2025-10-13 12:55:43
|
*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)* ** |
From: Marco C. <PY...@ou...> - 2025-10-13 11:19:35
|
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)* > ** |