Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc3

[Marco Calistri via wsjt-devel]

Good evening/afternoon!

I've tried to get the GIT version but is not available yet, when I hit 
"git pull" the system returned "already updated", then I'll download the 
source archive.



Happy new year 2024!

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


Il 01/01/24 13:00, Joe Taylor via wsjt-devel ha scritto:

Dear WSJT-X Users,

We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc3 is 
ready for download by beta testers.


WSJT-X 2.7.0 Release Candidate 3 includes new features as well as bug 
fixes.  A full list of enhancements can be found in the Release Notes:


https://wsjt.sourceforge.io/wsjtx-doc/Release_Notes_2.7.0-rc3.txt

See also Section 1.1 of the WSJT-X User Guide for this candidate release:

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc3.html#NEW_FEATURES 



Release Candidates are intended for beta testers.  If you download and 
use WSJT-X 2.7.0-rc3, please remember to provide feedback to us on the 
new features in version 2.7, and on anything that does not seem to 
work properly for you.


Direct links to installation packages for Windows, Linux, and macOS 
can be found on the WSJT-X page https://wsjt.sourceforge.io/wsjtx.html 
Scroll down to the heading "Candidate release:  WSJT-X 2.7.0-rc3".


For those who like to compile from source, a complete source-code 
tarball is available at the WSJT-X page. Public access to the git 
repository for the WSJT project is also available on the "Git" tab 
here: https://sourceforge.net/projects/wsjt/

It may take a short time for the code to be updated on SourceForge.


WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If 
you use our code, please have the courtesy to let us know about it.  
If you find bugs or make improvements to the code, please report them 
to us in a timely fashion.


The authors and Copyright holders of WSJT-X request that derivative 
works should not publish programs based on features in WSJT-X before 
those features are made available in a General Availability (GA) 
release of WSJT-X.  We will cease making public Release Candidate (RC) 
pre-releases for testing and user early access purposes if this 
request is ignored.


Feedback should be sent to this email list or one of the of the others 
mentioned here in the User Guide:


https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc3.html#SUPPORT

We hope you will enjoy using WSJT-X 2.7.0-rc3, and that you will help 
us to create a new General Availability (GA) release soon.


    -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB;
 Brian, N9ADG; and John, G4KLA


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Error compiling WSJT-X on OpenSuse Tumbleweed

[Marco Calistri via wsjt-devel]

Hello!

After a recent system update I had to recompile WSJT-X source due some 
libboost get updated, but this time I get an error related to Fortran 
and C compilers, see below.


I would like somebody kindly point me on the right route to resolve this 
issue.



marco@linux-turion64:~/WSJT-X_build/git/src> /usr/bin/cmake 
-Dhamlib_INCLUDE_DIRS=/usr/local/include  
-Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so  
-Dhamlib_LIBRARY_DIRS=/usr/local/lib64  -DWSJT_GENERATE_DOCS=OFF  
-DWSJT_SKIP_MANPAGES=ON  -Werror=deprecated-declarations  -Wno-error  -D 
CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/git/.wsjtx .

-- **

-- Building for for: Linux-x86_64

-- **

-- Building wsjtx v2.7.0.0-rc2

-- Found Usb

-- Found Hamlib 4.6~git

CMake Error at /usr/share/cmake/Modules/FortranCInterface.cmake:398 (message):

  The Fortran compiler:

    /usr/bin/gfortran

  and the CXX compiler:

    /usr/bin/c++

  failed to compile a simple test project using both languages.  The output

  was:

    Change Dir: 
'/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX'




    Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f 
Makefile VerifyFortranC

    /usr/bin/cmake -S/usr/share/cmake/Modules/FortranCInterface/Verify 
-B/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX 
--check-build-system CMakeFiles/Makefile.cmake 0

    /usr/bin/gmake  -f CMakeFiles/Makefile2 VerifyFortranC

    gmake[1]: ingresso nella directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    /usr/bin/cmake -S/usr/share/cmake/Modules/FortranCInterface/Verify 
-B/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX 
--check-build-system CMakeFiles/Makefile.cmake 0

    /usr/bin/cmake -E cmake_progress_start 
/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles
 6

    /usr/bin/gmake  -f CMakeFiles/Makefile2 CMakeFiles/VerifyFortranC.dir/all

    gmake[2]: ingresso nella directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    /usr/bin/gmake  -f CMakeFiles/VerifyFortran.dir/build.make 
CMakeFiles/VerifyFortran.dir/depend

    gmake[3]: ingresso nella directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    cd /home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX && 
/usr/bin/cmake -E cmake_depends "Unix Makefiles" 
/usr/share/cmake/Modules/FortranCInterface/Verify 
/usr/share/cmake/Modules/FortranCInterface/Verify 
/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX 
/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX 
/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/DependInfo.cmake

    Dependee 
"/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/DependInfo.cmake"
 is newer than depender 
"/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/depend.internal".

    Dependee 
"/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/CMakeDirectoryInformation.cmake"
 is newer than depender 
"/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/depend.internal".

    Scanning dependencies of target VerifyFortran

    gmake[3]: uscita dalla directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    /usr/bin/gmake  -f CMakeFiles/VerifyFortran.dir/build.make 
CMakeFiles/VerifyFortran.dir/build

    gmake[3]: ingresso nella directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    [ 16%] Building Fortran object 
CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o

    /usr/bin/gfortran -DVERIFY_CXX 
-I/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX -O3 
-DNDEBUG -O3 -fbounds-check -funroll-all-loops -fno-f2c 
-ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion 
-fno-second-underscore -c 
/usr/share/cmake/Modules/FortranCInterface/Verify/VerifyFortran.f -o 
CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o

    [ 33%] Linking Fortran static library libVerifyFortran.a

    /usr/bin/cmake -P CMakeFiles/VerifyFortran.dir/cmake_clean_target.cmake

    /usr/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortran.dir/link.txt 
--verbose=1

    /usr/bin/ar qc libVerifyFortran.a 
CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o

    /usr/bin/ranlib libVerifyFortran.a

    gmake[3]: uscita dalla directory 
«/home/marco/WSJT-X_build/git/src/CMakeFiles/FortranCInterface/VerifyCXX»

    [ 33%] Built target VerifyFortran

    /usr/bin/gmake  -f CMakeFiles/VerifyFortranC.dir/build.make 
CMakeFiles/VerifyFortranC.dir/depend

    gmake[3]: ingresso nella directory 

[wsjt-devel] /home/marco/.local/share/WSJT-X/hamlib_settings

[Marco Calistri via wsjt-devel]

Can somebody provide me a file example for the file in the subject?

*hamlib_settings* and kindly tell me from what source this file is being 
generated?


Many Thanks!


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Solar Eclipse participation #general

[Marco Calistri via wsjt-devel]

Hi Mike,

Are there studies confirming that a solar eclipse can affect HF propagation?

FWIK, but I'm not an expert on the matter, the most affected frequencies are 
the ones falling into the SHF and microwave bands, in particular the satellite 
bands, which are being affected by solar flares too.

My PSKREPORTER in WSJTX is enabled since the very beginning I started to use 
FT8.

Best regards,

PY1ZRJ

Inviato da Outlook per Android

From: Black Michael via wsjt-devel 
Sent: Friday, September 15, 2023 2:04:19 PM
To: wsjtgr...@groups.io ; WSJT Software Development 
; Wsjt Improved 

Cc: Black Michael 
Subject: [wsjt-devel] Solar Eclipse participation #general

If you have a recent version of WSJTX (like RC2) we would appreciate you 
turning on PSKReporter to support the upcoming solar eclipse Oct 14th.  If you 
can turn on PSKReporter now and keep it on until at least Oct  16th it would be 
appreciated.

We implemented special PSKReporter ability in WSJT-X during solar eclipses.  
All spots will go through where normally duplicates are  ignored.  Phillip 
Gladstone at PSKReporter has implemented special collection recording to 
support this.

This is  to support the HamSCI community solar eclipse analysis.

Mike W9MDB

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Marco Calistri via wsjt-devel]

In order to provide the deserved public acknowledgments to Mike,
I would like to confirm that his latest /rig/ft100.c commit into Hamlib, 
has resolved definitely my issue.


Thanks to Mike W9MDB!

Regards,

Marco, PY1ZRJ

Il 20/07/23 11:45, Marco Calistri via wsjt-devel ha scritto:
I face a similar behavior which last for two or three transmissions 
sequences at the beginning of my FT8 session.


This phenomenal started since some months then if it is due Hamlib, it 
is something that is being dragged along the new releases.


In my case (using an Yaesu FT-100, mode rig split) starting for 
example the transmission on 28074 Mhz, on RX vfo, during the 15 
seconds TX displays 28073, at RX switch the RX vfo shifts to 28073, 
then TX vfo during the second transmission, shifts to 28072 Mhz. At 
third sequence the behavior repeats, so RX is now at 28072 and TX 
shifts to 28071.


To correct it, I need to switch the frequency bands selector of WSJTX 
back to 28074.


Then the next sequences of RX/TX, after my manual intervention, keeps 
stably within the 1 Khz shift: 28074 RX and 28073 TX.


This is not a blocking issue to me but it is a bit annoying having to 
correct manually.


Regards,

Marco, PY1ZRJ

Inviato da Outlook per Android <https://aka.ms/AAb9ysg>

*From:* Black Michael via wsjt-devel 
*Sent:* Thursday, July 20, 2023 10:42:39 AM
*To:* wsjt-devel@lists.sourceforge.net 
*Cc:* Black Michael 
*Subject:* Re: [wsjt-devel] VFO readout on FT8 shutdown
That's what you get when you start smooshing buttons.

Here's what happened.

You swap VFOs -- WSJT-X doesn't care.
You exit -- WSJT-X saves the VFOB frequency as the "last frequency" used.
You start again -- if you have "Monitor returns to last used 
frequency" it  will then load VFOB's frequency into VFOA.

Of course rig split will set VFOB based on VFOA's frequency.

So...

#1 Don't smoosh buttons unless you know what you are doing
#2 Turn off "Monitor returns"

Mike W9MDB





On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via 
wsjt-devel  wrote:



Hello,
Comment: The following Human Induced confusion of VFO frequency occurs
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO
B is in the main position, VFO A on the side, no frequency changes have
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1
kHz higher, which is now 2 kHz from the original. Examples follow.

TX  = 2800 Hz
  PC          rig        rig
FT8 Display  VFO A      VFO B
24915.00    24915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.00    24915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.00    24916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--73, Glenn, AF8C



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Marco Calistri via wsjt-devel]

Il 20/07/23 16:07, Christoph Berg ha scritto:


Check if CIV Transceive is off.

Christoph DF7CB


What is it? CIV...

Are you sure that Yaesu FT-100 has this feature available?


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Marco Calistri via wsjt-devel]

Do you have the link for the source hamlib?

I'm using Linux (mainly).

If this newer version is on GitHub,  I can try compiling from it.

Regards,

Marco, PY1ZRJ

Inviato da Outlook per Android

From: Black Michael 
Sent: Thursday, July 20, 2023 12:28:54 PM
To: WSJT software development ; Marco 
Calistri 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown

Please test the latest hamlib.

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Some rigs cannot change frequency while transmitting.  Are you using VOX?  
SignaLink?

Some fixes were put in for these Yaeus rigs with this problem so hopefully this 
works now for the FT-100 too.

If not
Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences

Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB








On Thursday, July 20, 2023 at 09:45:37 AM CDT, Marco Calistri 
 wrote:


I face a similar behavior which last for two or three transmissions sequences 
at the beginning of my FT8 session.

This phenomenal started since some months then if it is due Hamlib, it is 
something that is being dragged along the new releases.

In my case (using an Yaesu FT-100, mode rig split) starting for example the 
transmission on 28074 Mhz, on RX vfo, during the 15 seconds TX displays 28073, 
at RX switch the RX vfo shifts to 28073, then TX vfo during the second 
transmission, shifts to 28072 Mhz. At third sequence the behavior repeats, so 
RX is now at 28072 and TX shifts to 28071.

To correct it, I need to switch the frequency bands selector of WSJTX back to 
28074.

Then the next sequences of RX/TX, after my manual intervention, keeps stably 
within the 1 Khz shift: 28074 RX and 28073 TX.

This is not a blocking issue to me but it is a bit annoying having to correct 
manually.

Regards,

Marco, PY1ZRJ

Inviato da Outlook per Android

From: Black Michael via wsjt-devel 
Sent: Thursday, July 20, 2023 10:42:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Black Michael 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown

That's what you get when you start smooshing buttons.

Here's what happened.

You swap VFOs -- WSJT-X doesn't care.
You exit -- WSJT-X saves the VFOB frequency as the "last frequency" used.
You start again -- if you have "Monitor returns to last used frequency" it  
will then load VFOB's frequency into VFOA.
Of course rig split will set VFOB based on VFOA's frequency.

So...

#1 Don't smoosh buttons unless you know what you are doing
#2 Turn off "Monitor returns"

Mike W9MDB





On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via wsjt-devel 
 wrote:


Hello,
Comment: The following Human Induced confusion of VFO frequency occurs
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO
B is in the main position, VFO A on the side, no frequency changes have
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1
kHz higher, which is now 2 kHz from the original.  Examples follow.

TX  = 2800 Hz
  PC  rigrig
FT8 Display  VFO A  VFO B
24915.0024915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.0024915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.0024916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--73, Glenn, AF8C



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Marco Calistri via wsjt-devel]

I face a similar behavior which last for two or three transmissions sequences 
at the beginning of my FT8 session.

This phenomenal started since some months then if it is due Hamlib, it is 
something that is being dragged along the new releases.

In my case (using an Yaesu FT-100, mode rig split) starting for example the 
transmission on 28074 Mhz, on RX vfo, during the 15 seconds TX displays 28073, 
at RX switch the RX vfo shifts to 28073, then TX vfo during the second 
transmission, shifts to 28072 Mhz. At third sequence the behavior repeats, so 
RX is now at 28072 and TX shifts to 28071.

To correct it, I need to switch the frequency bands selector of WSJTX back to 
28074.

Then the next sequences of RX/TX, after my manual intervention, keeps stably 
within the 1 Khz shift: 28074 RX and 28073 TX.

This is not a blocking issue to me but it is a bit annoying having to correct 
manually.

Regards,

Marco, PY1ZRJ

Inviato da Outlook per Android

From: Black Michael via wsjt-devel 
Sent: Thursday, July 20, 2023 10:42:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Black Michael 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown

That's what you get when you start smooshing buttons.

Here's what happened.

You swap VFOs -- WSJT-X doesn't care.
You exit -- WSJT-X saves the VFOB frequency as the "last frequency" used.
You start again -- if you have "Monitor returns to last used frequency" it  
will then load VFOB's frequency into VFOA.
Of course rig split will set VFOB based on VFOA's frequency.

So...

#1 Don't smoosh buttons unless you know what you are doing
#2 Turn off "Monitor returns"

Mike W9MDB





On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via wsjt-devel 
 wrote:


Hello,
Comment: The following Human Induced confusion of VFO frequency occurs
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO
B is in the main position, VFO A on the side, no frequency changes have
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1
kHz higher, which is now 2 kHz from the original.  Examples follow.

TX  = 2800 Hz
  PC  rigrig
FT8 Display  VFO A  VFO B
24915.0024915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.0024915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.0024916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--73, Glenn, AF8C



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] High CPU load with 2.7.0-rc2

[Marco Calistri via wsjt-devel]

I confirm that I'm using Linux openSUSE Tumbleweed and this high CPU 
load is not present at all.


Regards,


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

Il 12/07/23 08:51, Black Michael via wsjt-devel ha scritto:

This is a problem on Windows with the async routine enabled.   With async 
enabled Windows uses 100% of 1 core.  Async disabled runs at 1.6% of 1 core.  
It really should be closer to zero than the 1.6% but Windows has a problem with 
timing.

Linux doesn't have this problem.

I'm working on a solution for Windows.

Mike W9MDB









On Wednesday, July 12, 2023 at 05:22:46 AM CDT, Brian Morrison via 
wsjt-devel  wrote:





On Tue, 11 Jul 2023 15:53:25 -0500
Andrew White via wsjt-devel  wrote:


On my Win10 PC, this new version idles at 32% usage which is
essentially the same as the earlier "4.6~git Jun 28" version.  The
older libhamlib-4.dll v4.5.4 idles at less than 2%.

This new pull request may be relevant:

https://github.com/Hamlib/Hamlib/pull/1336

I have not tried it, I will if Mike decides to merge it.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc2

[Marco Calistri via wsjt-devel]

Il 08/07/23 12:16, Black Michael via wsjt-devel ha scritto:

I guess you must be compiling the latest hamlib from github.

Please pull the latest and try again.  It  should be fixed.

Mike W9MDB




Hello,

Are there any oddities in my thoughts regarding Hamlib release included 
into the WSJT-X source archive, which I suppose is not the latter available.


It could be possible to modify the installer wsjt-x compiler script, in 
order to use always the latest Hamlib release from Github, instead to 
rely on a static ( at least I suppose it being so) hamlib release?


Sorry if my thoughts are nonsense.

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc2

[Marco Calistri via wsjt-devel]

No more compiler error on openSUSe Tumbleweed!

Thanks for the new release!

Inviato da Outlook per Android

From: Joe Taylor via wsjt-devel 
Sent: Friday, July 7, 2023 12:50:06 PM
To: WSJT software development 
Cc: Joe Taylor 
Subject: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc2

Dear WSJT-X Users,

We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc2 is
ready for download by beta testers.

WSJT-X 2.7.0 Release Candidate 2 is mostly a bug-fix release.  A full
list of enhancements can be found in the Release Notes:

https://wsjt.sourceforge.io/wsjtx-doc/Release_Notes_2.7.0-rc2.txt

Release Candidates are intended for eta testers.  If you download and
use WSJT-X 2.7.0-rc2, please remember to provide feedback to us on the
new features in version 2.7, and on anything that does not seem to work
properly.

Direct links to installation packages for Windows, Linux, and macOS can
be found on the WSJT-X page https://wsjt.sourceforge.io/wsjtx.html
Scroll down to the heading "Candidate release:  WSJT-X 2.7.0-rc2".

For those who like to compile from source, a complete source-code
tarball is available at the WSJT-X page. Public access to the git
repository for the WSJT project is also available on the "Git" tab here:
https://sourceforge.net/projects/wsjt/
It may take a short time for the code to be updated on SourceForge.


WSJT-X is licensed under the terms of Version 3 of the GNU General
Public License (GPL).  Development of this software is a cooperative
project to which many amateur radio operators have contributed.  If you
use our code, please have the courtesy to let us know about it.  If you
find bugs or make improvements to the code, please report them to us in
a timely fashion.

The authors and Copyright holders of WSJT-X request that derivative
works should not publish programs based on features in WSJT-X before
those features are made available in a General Availability (GA) release
of WSJT-X.  We will cease making public Release Candidate (RC)
pre-releases for testing and user early access purposes if this request
is ignored.

Feedback should be sent to this email list or one of the of the others
mentioned here in the User Guide:

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc2.html#SUPPORT

We hope you will enjoy using WSJT-X 2.7.0-rc2, and that you will help us
to create a GA release of this version very soon.

 -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG3YCB;
  Brian, N9ADG; and John, G4KLA


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.7.0-rc2

[Marco Calistri via wsjt-devel]

Il 07/07/23 13:48, Björn Ekelund via wsjt-devel ha scritto:
Hamlib is broken. Again. Rc2 crashes when I select IC-7610. IC-7300 
and IC-7851 however seem to work.


Björn SM7IUN






RC2???

I've not seen any announcements for this RC.



---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.7.0-rc2

[Marco Calistri via wsjt-devel]

Il 07/07/23 13:48, Björn Ekelund via wsjt-devel ha scritto:
Hamlib is broken. Again. Rc2 crashes when I select IC-7610. IC-7300 
and IC-7851 however seem to work.


Björn SM7IUN



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-develSorry!



Sorry!
I received the announcement about RC2 now!


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] OFF-TOPIC: MTA error for Domain NIC.FI

[Marco Calistri via wsjt-devel]

Hello,

My apologies for this off-topic but I would like to send an e-mail to 
Saku OH1KH and I get an MTA error reporting a failure (see below).


Are there here some OH hams which have a secondary e-mail address of Saku?

Many thanks and again sorry for my request on this list!

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  sakari.nyl...@nic.fi
(generated fromoh...@sral.fi)
all hosts for 'nic.fi' have been failing for a long time (and retry time 
not reached)

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] PSE Fixed patch for CMakeFiles/qmap_impl.dir/q65c.f90.o

[Marco Calistri via wsjt-devel]

Il 13/06/23 12:19, Joe Taylor via wsjt-devel ha scritto:

Marco,

As far as I'm aware your problem involves only an attempt to build 
program QMAP.  Almost certainly you have no current use for QMAP, and 
no real interest in building it for Linux.


I suggest the simple expedient of moving the statement "endif ()", 
line 1435 of the top-level CMakeFiles.txt down by two lines so that it 
comes after the statement "add_subdirectory (qmap)".  Then you will 
not run into the fussy compiler warnings that are currently bothering 
you.


-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



Hello Joe, you are right, I don't use QMAP at all!

Many thanks for this easy workaround, I will follow your directions in 
case I need to recompile the WSJTX source!


Best regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] PSE Fixed patch for CMakeFiles/qmap_impl.dir/q65c.f90.o

[Marco Calistri via wsjt-devel]

I understood Manfred,

And it can be reproduced as well on Linux I suppose, but I think is 
better to have the solution already into WSJTX code, because it could be 
used by every users, also by who has not practice with the code.


Regards,

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



**Il 12/06/23 18:18, Manfred Antar {KN6KBS} via wsjt-devel ha scritto:

I get the same error on Mac OSX Mojave

Have manually edit qmap/libqmap/q65c.f90 and remove:

nfa
nfb
max_drift

references to get it to compile

Using gfortran-mp-11 which is the macports version of gcc11 same error on gcc12 
gfortran



On Jun 12, 2023, at 12:59 PM, Marco Calistri via 
wsjt-devel  wrote:

Hi,

Tried also to build WSJTX from git repository and faced same error I faced by 
using the tgz archive.

In my distro OpenSUSE Tumbleweed applying the standard WSJT-X single patch 
"wsjtx.patch" do not works and I need to apply it to all the files involved in 
the error.

I supposed that at least in the git this issue were resolved.

In my opinion (maybe I'm wrong) it looks that the major code attention being 
reserved to Windows more than on Linux O.S. with this software.

In any case the behavior between OpenSUSE, Fedora, Ubuntu is certainly 
different on some aspects and for this specific issue of apply the patch it 
looks to really be different.

[ 94%] Automatic MOC for target qmap_impl
[ 94%] Built target qmap_impl_autogen
[ 94%] Building Fortran object qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o
/home/marco/WSJT-X_build/git/src/qmap/libqmap/q65c.f90:23:39:

   23 |ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, 
&
  |   1
Error: Symbol ‘nfa’ at (1) is USE associated from module ‘q65’ and cannot occur 
in COMMON
gmake[2]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:336: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2109: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
gmake: *** [Makefile:156: all] Error 2
---
73 de Marco, PY1ZRJ (former IK5BCU)

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib testing

[Marco Calistri via wsjt-devel]

Will do it Mike,

I will do it when radio is still cold, in order to avoid to have the 
thermal drift as a possible cause, since I think the reason is another.


Regards,

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



**
Il 12/06/23 17:27, Black Michael ha scritto:

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


 C:\Users\[username]\AppData\Local\WSJT-X
 The WSJT-X_Rigcontrol.log file will be in the same location


For Linux put it in
 ~/.config
 The WSJT-X_Rigcontrol.log file will be here:
 ~/.local/share/WSJT-X


For MacOS put it in
 /Users/[username]/Library/Preferences
  
Restart WSJT-X and duplicate the problem.

Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib testing

[Marco Calistri via wsjt-devel]

Tested new version compiled from git repository and on my old YAESU 
FT-100 I see same behavior I saw with previous Hamlib versions.


I use WSJT-X 2.7.0 RC1 with settings Split=RIG and Mode= Data Packet and 
at the very beginning of the operation, the VFO A (Transmitter) and VFO 
B (Receiver) behave in this way:


I make the first CQ, VFO A transmit 1 KHz below, so VFO B then moves 1 
KHz below its original frequency, at second CQ VFO B is then 2 KHz below 
the starting frequency.


I have to correct manually this behavior by clicking again on the band 
frequency I was using and have to do it two or three times, until the 
radio finally stabilize and then the shift keeps constant among VFO A 
and B of the value which depends by the TX audio I selected, I.E. if I 
use 777 Hz, the SPLIT shift between VFO's is 1 KHz and it remains stable.


This is not a major issue for me but I would like to report it here.

Best regards,

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

Il 11/06/23 00:18, Black Michael via wsjt-devel ha scritto:

Need people to test the latest Hamlib please

https://n0nb.users.sourceforge.net/

#1 Backwards compatibility with WSJT-X has been fixed.
#2 Notable speedups for Windows operations
Here's an FT-991 comparison
Old:
  1:rig_get_freq: elapsed=16ms
  1:rig_get_freq: elapsed=17ms
  1:rig_get_split_vfo: elapsed=30ms
  1:rig_get_mode: elapsed=47ms
  1:rig_get_ptt: elapsed=17ms
New:
  1:rig_get_freq: elapsed=6ms
  1:rig_get_freq: elapsed=6ms
  1:rig_get_split_vfo: elapsed=14ms
  1:rig_get_mode: elapsed=13ms
  1:rig_get_ptt: elapsed=4ms

Mike W9MDB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] PSE Fixed patch for CMakeFiles/qmap_impl.dir/q65c.f90.o

[Marco Calistri via wsjt-devel]

Hi,

Tried also to build WSJTX from git repository and faced same error I 
faced by using the tgz archive.


In my distro OpenSUSE Tumbleweed applying the standard WSJT-X single 
patch "wsjtx.patch" do not works and I need to apply it to all the files 
involved in the error.


I supposed that at least in the git this issue were resolved.

In my opinion (maybe I'm wrong) it looks that the major code attention 
being reserved to Windows more than on Linux O.S. with this software.


In any case the behavior between OpenSUSE, Fedora, Ubuntu is certainly 
different on some aspects and for this specific issue of apply the patch 
it looks to really be different.


[ 94%] Automatic MOC for target qmap_impl
[ 94%] Built target qmap_impl_autogen
[ 94%] Building Fortran object 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o

/home/marco/WSJT-X_build/git/src/qmap/libqmap/q65c.f90:23:39:

   23 | ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, &
  |   1
Error: Symbol ‘nfa’ at (1) is USE associated from module ‘q65’ and 
cannot occur in COMMON
gmake[2]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:336: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2109: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2

gmake: *** [Makefile:156: all] Error 2
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [wsjtgroup] Memory leak in 2.7.0 rc1?

[Marco Calistri via wsjt-devel]

Il 26/05/23 14:12, Sam W2JDB via wsjt-devel ha scritto:

Hi,

Just guessing, but for the worked before, depending on what is in the 
ADI file, they might be allocating memory
space for a bit or byte matrix for all possible combination of DX 
entities, Callsigns by mode and band.

That is just a wild ass guess.

73,

Sam W2JDB



-Original Message-
From: Sam Birnbaum via groups.io 
To: wsjt-devel@lists.sourceforge.net 
; wsjtgr...@groups.io 


Sent: Fri, May 26, 2023 1:07 pm
Subject: Re: [wsjtgroup] [wsjt-devel] Memory leak in 2.7.0 rc1?

Hi All,

It is the ADI file - WSJTX_Log.adi. Rename the file and watch the 
memory footprint shrink.


It went from 600MB to 110MB.

73,

Sam W2JDB



-Original Message-
From: alan2--- via wsjt-devel 
To: wsjt-devel@lists.sourceforge.net
Cc: al...@alangroups.plus.com
Sent: Fri, May 26, 2023 9:28 am
Subject: Re: [wsjt-devel] Memory leak in 2.7.0 rc1?

Quick test on a W10 Intel laptop with no rig connected shows 94MB used.
Alan G0TLK
On 26/05/2023 14:22, Fred Price via wsjt-devel wrote:

I started 2.7.0-rc1 Windows 11 Ryzen 5 task manager shows 473mb for WSJT.exe.
I then closed 2.7.0-Tx1 and opened 2.6.1 task manger shows 147mb for WSJT.exe.
Both were opened on a pretty quiet 6M band.
I let 2.7.0-rc1 run for around 4 hours this morning with no memory leaks. My 
settings for save menu are:
None
Disable writing of ALL.TXT.


On May 25, 2023, at 3:54 PM, Brian Moran via 
wsjt-devel  
  wrote:

Greetings; can you describe what mode you are using? If you left it going for 
a few days without deciding any signals (e.g. with no antenna) same behavior? 
What radio and interface to the radio? Any other information you could share 
would be most appreciated.

Thanks!
-Brian N9ADG


Sent via iPhone


On May 25, 2023, at 12:11 PM, Björn Ekelund via 
wsjt-devel  
  wrote:


My RAM (8 Gbyte) fills up if I let rc1 run for a few days. It does not happen 
with 2.6.1.

Interestingly enough the task manager does not show WSJT-X to be the culprit 
but when
I stop it, up to 5Gbyte are freed up.

Also, sometimes rc1 allocates 630Mbyte of RAM when started. Other times 
90Mbyte. It seems random.

2.6.1 is always around 90Mbyte.

I am running Swedish Windows.

Does anyone else experience the same anomalies?

Björn SM7IUN



Hello,

I want to check on my WSJTX Linux opensuse and I noticed a very high CPU 
Load from rigctld (*with radio switched off*) as follows:


marco@linux-turion64:~> top|grep rigctldt

op - 09:00:32 up 1 day, 48 min,  1 user,  load average: 1,33, 1,53, 2,31
Tasks: 239 total,   3 running, 236 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11,5 us, 16,1 sy,  0,0 ni, 65,0 id,  7,4 wa,  0,0 hi,  0,1 si,  
0,0 st

MiB Mem : 3811,676 total,  718,457 free, 2312,383 used, 1235,734 buff/cache
MiB Swap: 16382,99+total, 13892,30+free, 2490,688 used. 1499,293 avail Mem

PID USER    PR  NI    VIRT    RES    SHR S  %*CPU* %MEM 
TIME+ COMMAND


22565 marco 20   0  239676   2808    472 S *100,0* 0,072 62:55.70 
rigctld
22565 marco 20   0  239676   2808    472 S *99,67* 0,072 62:58.70 
rigctld
22565 marco 20   0  239676   2808    472 S *100,3* 0,072 63:01.72 
rigctld
22565 marco 20   0  239676   2808    472 S *100**,0* 0,072  63:04.73 
rigctld
22565 marco 20   0  239676   2808    472 S *99*,*67* 0,072  63:07.73 
rigctld
22565 marco 20   0  239676   2808    472 S *100*,*3* 0,072  63:10.75 
rigctld
22565 marco 20   0  239676   2808    472 S *99,67* 0,072 63:13.75 
rigctld


It could be possibly related to hamlib more than to WSJTX may be, but I 
think abnormal load.


Cheers,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compile fails

[Marco Calistri via wsjt-devel]

Yes,

I faced similar issue on my openSuse, then I had to apply the patch by hand a 
file a time.

Probably the WSJTX internal patching script is not fully compliant with all the 
Linux environments.

73's de PY1ZRJ



Inviato da Outlook per Android

From: Richard Shaw via wsjt-devel 
Sent: Monday, May 22, 2023 9:03:57 AM
To: WSJT software development 
Cc: Richard Shaw 
Subject: Re: [wsjt-devel] Compile fails

On Mon, May 22, 2023 at 6:59 AM Brian Morrison via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
On Sun, 21 May 2023 21:31:44 -0500
Richard Shaw via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:

> On Sun, May 21, 2023 at 9:13 PM jarmo via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> 
> wrote:
>
> > Did git pull for wsjtx, tried to compile, failed...
> >
> > /home/oh1mrr/wsjtx/qmap/libqmap/q65c.f90:23:39:
> >
> >23 |ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift,
> >&
> >   |   1
> > Virhe: Symbol ”nfa” at (1) is USE associated from module ”q65” and
> > cannot occur in COMMON
> > gmake[2]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:336:
> > qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
> > gmake[2]: *** Odotetaan keskeneräisiä töitä
> > gmake[1]: *** [CMakeFiles/Makefile2:2109:
> > qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
> > gmake[1]: *** Odotetaan keskeneräisiä töitä
> > [ 79%] Linking CXX static library libqcp.a
> > [ 79%] Built target qcp
> > gmake: *** [Makefile:156: all] Error 2
> >
>
> Getting the same error trying to build 2.7.0-rc1 for Fedora.
>
> Thanks,
> Richard
> KF5OIM

Patch provided by K7FU that fixes this:

I found the previous email, unfortunately patch didn't like the line endings as 
copied out of said email. I ended up creating a fresh patch using quilt with 
the email as a guide and that got me going.

Thanks,
Richard
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compile fails

[Marco Calistri via wsjt-devel]

Jarmo,

Just look in the last recent messages, there is a patch that corrects this 
issue for Linux.
Sorry, I'm on cellphone and in this moment can't provide you the indicated 
mail/patch.

Also you can look for my callsign here, in order to get such solution.

Good job!

73 de PY1ZRJ

Inviato da Outlook per Android

From: jarmo via wsjt-devel 
Sent: Sunday, May 21, 2023 11:08:00 PM
To: wsjt-devel@lists.sourceforge.net 
Cc: jarmo 
Subject: [wsjt-devel] Compile fails

Did git pull for wsjtx, tried to compile, failed...

/home/oh1mrr/wsjtx/qmap/libqmap/q65c.f90:23:39:

   23 |ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift,   
  &
  |   1
Virhe: Symbol ”nfa” at (1) is USE associated from module ”q65” and cannot occur 
in COMMON
gmake[2]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:336: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
gmake[2]: *** Odotetaan keskeneräisiä töitä
gmake[1]: *** [CMakeFiles/Makefile2:2109: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
gmake[1]: *** Odotetaan keskeneräisiä töitä
[ 79%] Linking CXX static library libqcp.a
[ 79%] Built target qcp
gmake: *** [Makefile:156: all] Error 2

Just for info.

Jarmo, oh1mrr


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Patch for 2.7.0rc1 for newer Linux distros/compilers (was Candidate Release WSJT-X 2.7.0-rc1 Linux compile)

[Marco Calistri via wsjt-devel]

Il 18/05/23 14:12, Brian Morrison via wsjt-devel ha scritto:

On Thu, 18 May 2023 11:53:36 -0300
Marco Calistri via wsjt-devel  wrote:


I got this error, I know it is related to the patch file format
(LF,CR,Tabs...) but I've not been to resolve it:

*73 de Marco, PY1ZRJ (former IK5BCU)*

For future reference Marco, you can change the line endings using:

dos2unix 

Not sure if you have that command, but on Fedora it comes in the
dos2unix rpm package.


Yes Brian,

I do have such command in my openSUSE TW and I attempted in several 
ways, in order to avoid the "hunk error" but,
as I wrote, only by applying the patch by hand, a file at time, I have 
been able to resolve the problem.


Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Patch for 2.7.0rc1 for newer Linux distros/compilers (was Candidate Release WSJT-X 2.7.0-rc1 Linux compile)

[Marco Calistri via wsjt-devel]

Il 18/05/23 11:53, Marco Calistri via wsjt-devel ha scritto:

Il 18/05/23 11:42, Marco Calistri via wsjt-devel ha scritto:

Il 18/05/23 07:52, Brian Morrison via wsjt-devel ha scritto:

diff -Naur wsjtx.orig/qmap/astro.cpp wsjtx/qmap/astro.cpp
--- wsjtx.orig/qmap/astro.cpp   2023-05-12 13:55:48
+++ wsjtx/qmap/astro.cpp2023-05-12 13:57:23
@@ -72,7 +72,7 @@
  
datcom_.ndop00=ndop00;   //Send self Doppler to decoder, via datcom

  //  qDebug() << "aa" << isec << datcom_.fcenter << nfreq << ndop00;
-  sprintf(cc,
+  snprintf(cc, sizeof(cc),
"Az:%6.1f\n"
"El:%6.1f\n"
"MyDop: %6d\n"
@@ -140,7 +140,7 @@
if(f.open(QIODevice::WriteOnly | QIODevice::Append)) {
  QTextStream out();
  out << t.toString("-MMM-dd hh:mm:ss");
-sprintf(cc,"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
+snprintf(cc,sizeof(cc),"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
  azsun,elsun,iCycle,azOffset,elOffset,xavg,10.0*log10(xavg));
  out << cc;
  f.close();
@@ -168,7 +168,7 @@
if(ntxFreq != ntxFreq0) ndiff=1;
ntxFreq0=ntxFreq;
QTextStream out();
-  sprintf(cc,"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
+  snprintf(cc,sizeof(cc),"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Sun\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Source\n"
"%4d,%6d,%6d,Doppler\n"
diff -Naur wsjtx.orig/qmap/libqmap/q65c.f90 wsjtx/qmap/libqmap/q65c.f90
--- wsjtx.orig/qmap/libqmap/q65c.f902023-05-12 13:55:48
+++ wsjtx/qmap/libqmap/q65c.f90 2023-05-12 13:56:41
@@ -20,9 +20,9 @@
  
  !### REMEMBER that/npar/  is not updated until nparams=nparams0 is executed. ###

common/npar/fcenter,nutc,fselected,mousedf,mousefqso,nagain,
&
-   ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, &
+   ndepth,ndiskdat,neme,newdat,nfcal,nfshift, &
 mcall3,nkeep,ntol,nxant,nrxlog,nfsample,nxpol,nmode,   &
-   ndop00,nsave,max_drift,nhsym,mycall,mygrid,hiscall,hisgrid,&
+   ndop00,nsave,nhsym,mycall,mygrid,hiscall,hisgrid,&
 datetime,junk1,junk2
equivalence (nparams,fcenter)
data first/.true./
diff -Naur wsjtx.orig/qmap/soundin.cpp wsjtx/qmap/soundin.cpp
--- wsjtx.orig/qmap/soundin.cpp 2023-05-12 13:55:48
+++ wsjtx/qmap/soundin.cpp  2023-05-12 13:57:57
@@ -173,7 +173,7 @@
int ntr;
int nhsym0=0;
int iz=174;
-  int nBusy=0;
+//  int nBusy=0;
  
// Main loop for input of UDP packets over the network:

while (!qe) {
@@ -217,7 +217,7 @@
  m_hsym=(k-2048)*11025.0/(2048.0*m_rate);
  if(m_hsym != nhsym0) {
if(m_dataSinkBusy) {
-nBusy++;
+ //   nBusy++;
} else {
  m_dataSinkBusy=true;
  emit readyForFFT(k); //Signal to compute new FFTs


Thanks a lot Brian!

I'm goind to test it.

Best regards!

I got this error, I know it is related to the patch file format 
(LF,CR,Tabs...) but I've not been to resolve it:



[ 78%] Performing patch step for 'wsjtx'
patching file qmap/astro.cpp
Hunk #1 FAILED at 72 (different line endings).
Hunk #2 FAILED at 140 (different line endings).
Hunk #3 FAILED at 168 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file qmap/astro.cpp.rej
patching file qmap/libqmap/q65c.f90
Hunk #1 FAILED at 20 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file qmap/libqmap/q65c.f90.rej
patching file qmap/soundin.cpp
Hunk #1 FAILED at 173 (different line endings).
Hunk #2 FAILED at 217 (different line endings).
2 out of 2 hunks FAILED -- saving rejects to file qmap/soundin.cpp.rej
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:89: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-patch] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:305: 
CMakeFiles/wsjtx-install.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:390: CMakeFiles/install.dir/rule] 
Error 2

gmake: *** [Makefile:267: install] Error 2

Sorry.

Regards,


I succeeded to built the code now, but I had to apply the patch by hand 
on each single file, by using this commands:


patch  --binary < wsjtx.patch and selecting: 
wsjtx-prefix/src/wsjtx/qmap/astro.cpp, q65c.f90 and soundin.cpp.


Thanks a lot to (in order of received support):

1. Hitashi T Fujinaka
2. Brian Morrison, G8SEZ
3. K7FU


Cheers!
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Patch for 2.7.0rc1 for newer Linux distros/compilers (was Candidate Release WSJT-X 2.7.0-rc1 Linux compile)

[Marco Calistri via wsjt-devel]

Il 18/05/23 11:42, Marco Calistri via wsjt-devel ha scritto:

Il 18/05/23 07:52, Brian Morrison via wsjt-devel ha scritto:

diff -Naur wsjtx.orig/qmap/astro.cpp wsjtx/qmap/astro.cpp
--- wsjtx.orig/qmap/astro.cpp   2023-05-12 13:55:48
+++ wsjtx/qmap/astro.cpp2023-05-12 13:57:23
@@ -72,7 +72,7 @@
  
datcom_.ndop00=ndop00;   //Send self Doppler to decoder, via datcom

  //  qDebug() << "aa" << isec << datcom_.fcenter << nfreq << ndop00;
-  sprintf(cc,
+  snprintf(cc, sizeof(cc),
"Az:%6.1f\n"
"El:%6.1f\n"
"MyDop: %6d\n"
@@ -140,7 +140,7 @@
if(f.open(QIODevice::WriteOnly | QIODevice::Append)) {
  QTextStream out();
  out << t.toString("-MMM-dd hh:mm:ss");
-sprintf(cc,"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
+snprintf(cc,sizeof(cc),"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
  azsun,elsun,iCycle,azOffset,elOffset,xavg,10.0*log10(xavg));
  out << cc;
  f.close();
@@ -168,7 +168,7 @@
if(ntxFreq != ntxFreq0) ndiff=1;
ntxFreq0=ntxFreq;
QTextStream out();
-  sprintf(cc,"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
+  snprintf(cc,sizeof(cc),"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Sun\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Source\n"
"%4d,%6d,%6d,Doppler\n"
diff -Naur wsjtx.orig/qmap/libqmap/q65c.f90 wsjtx/qmap/libqmap/q65c.f90
--- wsjtx.orig/qmap/libqmap/q65c.f902023-05-12 13:55:48
+++ wsjtx/qmap/libqmap/q65c.f90 2023-05-12 13:56:41
@@ -20,9 +20,9 @@
  
  !### REMEMBER that/npar/  is not updated until nparams=nparams0 is executed. ###

common/npar/fcenter,nutc,fselected,mousedf,mousefqso,nagain,
&
-   ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, &
+   ndepth,ndiskdat,neme,newdat,nfcal,nfshift, &
 mcall3,nkeep,ntol,nxant,nrxlog,nfsample,nxpol,nmode,   &
-   ndop00,nsave,max_drift,nhsym,mycall,mygrid,hiscall,hisgrid,&
+   ndop00,nsave,nhsym,mycall,mygrid,hiscall,hisgrid,&
 datetime,junk1,junk2
equivalence (nparams,fcenter)
data first/.true./
diff -Naur wsjtx.orig/qmap/soundin.cpp wsjtx/qmap/soundin.cpp
--- wsjtx.orig/qmap/soundin.cpp 2023-05-12 13:55:48
+++ wsjtx/qmap/soundin.cpp  2023-05-12 13:57:57
@@ -173,7 +173,7 @@
int ntr;
int nhsym0=0;
int iz=174;
-  int nBusy=0;
+//  int nBusy=0;
  
// Main loop for input of UDP packets over the network:

while (!qe) {
@@ -217,7 +217,7 @@
  m_hsym=(k-2048)*11025.0/(2048.0*m_rate);
  if(m_hsym != nhsym0) {
if(m_dataSinkBusy) {
-nBusy++;
+ //   nBusy++;
} else {
  m_dataSinkBusy=true;
  emit readyForFFT(k); //Signal to compute new FFTs


Thanks a lot Brian!

I'm goind to test it.

Best regards!

I got this error, I know it is related to the patch file format 
(LF,CR,Tabs...) but I've not been to resolve it:



[ 78%] Performing patch step for 'wsjtx'
patching file qmap/astro.cpp
Hunk #1 FAILED at 72 (different line endings).
Hunk #2 FAILED at 140 (different line endings).
Hunk #3 FAILED at 168 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file qmap/astro.cpp.rej
patching file qmap/libqmap/q65c.f90
Hunk #1 FAILED at 20 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file qmap/libqmap/q65c.f90.rej
patching file qmap/soundin.cpp
Hunk #1 FAILED at 173 (different line endings).
Hunk #2 FAILED at 217 (different line endings).
2 out of 2 hunks FAILED -- saving rejects to file qmap/soundin.cpp.rej
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:89: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-patch] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:305: 
CMakeFiles/wsjtx-install.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:390: CMakeFiles/install.dir/rule] 
Error 2

gmake: *** [Makefile:267: install] Error 2

Sorry.

Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Patch for 2.7.0rc1 for newer Linux distros/compilers (was Candidate Release WSJT-X 2.7.0-rc1 Linux compile)

[Marco Calistri via wsjt-devel]

Il 18/05/23 07:52, Brian Morrison via wsjt-devel ha scritto:

diff -Naur wsjtx.orig/qmap/astro.cpp wsjtx/qmap/astro.cpp
--- wsjtx.orig/qmap/astro.cpp   2023-05-12 13:55:48
+++ wsjtx/qmap/astro.cpp2023-05-12 13:57:23
@@ -72,7 +72,7 @@
  
datcom_.ndop00=ndop00;   //Send self Doppler to decoder, via datcom

  //  qDebug() << "aa" << isec << datcom_.fcenter << nfreq << ndop00;
-  sprintf(cc,
+  snprintf(cc, sizeof(cc),
"Az:%6.1f\n"
"El:%6.1f\n"
"MyDop: %6d\n"
@@ -140,7 +140,7 @@
if(f.open(QIODevice::WriteOnly | QIODevice::Append)) {
  QTextStream out();
  out << t.toString("-MMM-dd hh:mm:ss");
-sprintf(cc,"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
+snprintf(cc,sizeof(cc),"%7.1f %7.1f   %d %7.1f %7.1f %10.1f %7.2f\n",
  azsun,elsun,iCycle,azOffset,elOffset,xavg,10.0*log10(xavg));
  out << cc;
  f.close();
@@ -168,7 +168,7 @@
if(ntxFreq != ntxFreq0) ndiff=1;
ntxFreq0=ntxFreq;
QTextStream out();
-  sprintf(cc,"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
+  snprintf(cc,sizeof(cc),"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Moon\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Sun\n"
"%2.2d:%2.2d:%2.2d,%5.1f,%5.1f,Source\n"
"%4d,%6d,%6d,Doppler\n"
diff -Naur wsjtx.orig/qmap/libqmap/q65c.f90 wsjtx/qmap/libqmap/q65c.f90
--- wsjtx.orig/qmap/libqmap/q65c.f902023-05-12 13:55:48
+++ wsjtx/qmap/libqmap/q65c.f90 2023-05-12 13:56:41
@@ -20,9 +20,9 @@
  
  !### REMEMBER that/npar/  is not updated until nparams=nparams0 is executed. ###

common/npar/fcenter,nutc,fselected,mousedf,mousefqso,nagain,
&
-   ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, &
+   ndepth,ndiskdat,neme,newdat,nfcal,nfshift, &
 mcall3,nkeep,ntol,nxant,nrxlog,nfsample,nxpol,nmode,   &
-   ndop00,nsave,max_drift,nhsym,mycall,mygrid,hiscall,hisgrid,&
+   ndop00,nsave,nhsym,mycall,mygrid,hiscall,hisgrid,&
 datetime,junk1,junk2
equivalence (nparams,fcenter)
data first/.true./
diff -Naur wsjtx.orig/qmap/soundin.cpp wsjtx/qmap/soundin.cpp
--- wsjtx.orig/qmap/soundin.cpp 2023-05-12 13:55:48
+++ wsjtx/qmap/soundin.cpp  2023-05-12 13:57:57
@@ -173,7 +173,7 @@
int ntr;
int nhsym0=0;
int iz=174;
-  int nBusy=0;
+//  int nBusy=0;
  
// Main loop for input of UDP packets over the network:

while (!qe) {
@@ -217,7 +217,7 @@
  m_hsym=(k-2048)*11025.0/(2048.0*m_rate);
  if(m_hsym != nhsym0) {
if(m_dataSinkBusy) {
-nBusy++;
+ //   nBusy++;
} else {
  m_dataSinkBusy=true;
  emit readyForFFT(k); //Signal to compute new FFTs


Thanks a lot Brian!

I'm goind to test it.

Best regards!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate Release WSJT-X 2.7.0-rc1 Linux compile

[Marco Calistri via wsjt-devel]

Il 14/05/23 06:29, Kari Sillanmäki via wsjt-devel ha scritto:

On 14.5.2023 4.42, Jim Shorney via wsjt-devel wrote:
That's not trivial either. But with 18.04 going end of support it is 
inevitable. I'm just looking for an easy fix, as usual. I did find a 
qt515 ppa for Bionic but I have no clue how to make it work.


Going to try asking Mr. Google again Then maybe off to the Ubuntu 
forums.



73

-Jim
NU0C


Hi Jim,

I encountered the same problem in my Ubuntu 18.04 system.

Since it's only the new "qmap" program that causes this issue, I 
compiled WSJT-X without qmap.


I don't have any use for qmap anyway.

This way I can postpone the inevitable OS upgrade to some later time...

73's de Kari, oh2gqc



Good night!

I faced the following error on my Linux openSUSE Tumbleweed:


[ 94%] Building Fortran object 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o

/home/marco/WSJT-X_build/build/wsjtx-2.7.0/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:23:39:

   23 | ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift, &
  |   1
Error: Symbol ‘nfa’ at (1) is USE associated from module ‘q65’ and 
cannot occur in COMMON
gmake[6]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:336: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
gmake[5]: *** [CMakeFiles/Makefile2:2065: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2

gmake[4]: *** [Makefile:156: all] Error 2
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:78: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
gmake[2]: *** [CMakeFiles/Makefile2:305: 
CMakeFiles/wsjtx-install.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:390: CMakeFiles/install.dir/rule] 
Error 2

gmake: *** [Makefile:267: install] Error 2



And, if anything else is available to get rid of it, I would be very 
glad to know which cmake option I have to use, in order to disable qmap.


Even better to have the full list of the specific WSJT cmake option as: 
-Dhamlib_LIBRARIES, etc, etc.


I'm not a software programming expert and despite to have attempted to 
find something related to WSJTX cmake variable options, I hadn't found any.




Many thanks!
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Off-Topic: please reply by privare message.

[Marco Calistri via wsjt-devel]

Hello and apologies to use this mailing list to ask an off-topic, but I think 
that probably someone among the many hams here, could provide me some 
suggestions to attempt a solution.

The problem is that, after last usage of my pretty old YAESU FT-100, using 
malfunctioning switching power supply (unstable output voltage) during some QSO 
on FT8, I noticed that now my rig is transmitting with just half of its nominal 
power: 50W instead of 100W.

The good news, at least for my understanding, is that this issue occurs only on 
some HF bands and not on all of these. For example on 20 and 17 meters, the 
output power is the expected.

I suspect that a possible section to be verified could be the low pass filter, 
between the PA and the output antenna connector.

I would be very grateful to receive some technical opinion regarding this 
matter.

Thanks for your kindest attention and once again my apologies to write about 
this here.

Regards,

PY1ZRJ Marco

Inviato da Outlook per Android
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations

[Marco Calistri via wsjt-devel]

Yeah!

Undoubtedly he is one of (if not the the) most active contributor for the 
CQRLOG development code.

On Wndows platform I use Log4Om, jointly with WSJT-X and I think that if CQRLOG 
would have a Microsoft Windows version too, probably could get a more frequent 
updates since I think there are more Windows than Linux users around the world.

But this is just my personal point of view.

Regards,

Marco, PY1ZRJ

(Off-Topic terminated here)


Inviato da Outlook per Android<https://aka.ms/AAb9ysg>

From: Brian Morrison via wsjt-devel 
Sent: Wednesday, February 15, 2023 1:36:37 PM
To: wsjt-devel@lists.sourceforge.net 
Cc: Brian Morrison 
Subject: Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations

On Wed, 15 Feb 2023 14:26:07 +
Marco Calistri via wsjt-devel  wrote:

> Hi Brian,
>
> Yes, i know Saku, he helped me in many occasions.
>
> Since this is not a blocking issue for me but just a random and not
> important one, occuring only under particular usage of the FT8 QSO
> (trying to complete 2 QSO almost at the same time) I don't feel me
> comfortable to asking Saku to resolve it.
>
> In any case him is participating on the present list as user, so
> supposedly he has read this topic already.
>
> I'm quite sure that such behavior it being easily reproducible if you
> try to do same actions I've described on my first email.

I see that there are 17 pull requests on the CQRLog git page, many by
Saku so perhaps we will see a 2.6.1 version before long.

--

Brian  G8SEZ



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations

[Marco Calistri via wsjt-devel]

Hi Brian,

Yes, i know Saku, he helped me in many occasions.

Since this is not a blocking issue for me but just a random and not important 
one, occuring only under particular usage of the FT8 QSO (trying to complete 2 
QSO almost at the same time) I don't feel me comfortable to asking Saku to 
resolve it.

In any case him is participating on the present list as user, so supposedly he 
has read this topic already.

I'm quite sure that such behavior it being easily reproducible if you try to do 
same actions I've described on my first email.

Best regards,

Marco, PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>


Da: Brian Morrison via wsjt-devel 
Inviato: mercoledì 15 febbraio 2023, 11:12
A: wsjt-devel@lists.sourceforge.net 
Cc: Brian Morrison 
Oggetto: Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations

On Tue, 14 Feb 2023 23:17:19 -0300
Marco Calistri via wsjt-devel  wrote:

> Il 14/02/23 11:44, Brian Morrison via wsjt-devel ha scritto:
> > On Tue, 14 Feb 2023 08:39:54 -0300
> > Marco Calistri via wsjt-devel
> > wrote:
> >
> >> Hello,
> >>
> >> I'm using CQRLOG as the default QSO logging software with WSJT-X
> > What version of CQRLOG are you using?
> >
>
> Hello!
>
> CQRLOG 2.6.0 (2022-07-05)
>
> But, as I wrote, this occurred with previous versions as well.

I can only suggest contacting Saku OH1KH and asking him if he can help,
he's made quite a few changes to the CQRLog code and maybe can help fix
your problem.

--

Brian  G8SEZ


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations

[Marco Calistri via wsjt-devel]

Il 14/02/23 11:44, Brian Morrison via wsjt-devel ha scritto:

On Tue, 14 Feb 2023 08:39:54 -0300
Marco Calistri via wsjt-devel  wrote:


Hello,

I'm using CQRLOG as the default QSO logging software with WSJT-X

What version of CQRLOG are you using?



Hello!

CQRLOG 2.6.0 (2022-07-05)

But, as I wrote, this occurred with previous versions as well.
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Logging of mixed data if you do QSO with two stations

[Marco Calistri via wsjt-devel]

Hello,

I'm using CQRLOG as the default QSO logging software with WSJT-X, the 
two programs works jointly through the internal UDP ports 2337/2333.


The following issue is occurring since several time, it is not related 
to a specific WSJT-X or CQRLOG version.


It happened and it still happens from time to time:

If you start to call a certain station (or even you are being called by) 
and you start exchanging the RST, if in the meanwhile you wish to 
provide an acknowledgement to an additional station which has came later 
(as you were doing chat with both the two stations at an half-duplex 
similar QSO), then in almost all cases the first QSO being logged will 
get mixed data from the two stations!


When I say "mixed data" I mean that in the log it could get wrote: mixed 
RST exchange, or mixed name and QTH, or even mixed CQ and WAZ zone!


Now that I'm writing this last detail, I think that this issue being 
more related to CQRLOG then, since it does a lookup on QRZ.com or even 
QTH.com.


Well, I don't know who is the root cause, I suppose that other users are 
facing the same issue.


Thanks for reading!
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.6.1 triggering AV software

[Marco Calistri via wsjt-devel]

Il 27/01/23 18:37, Alan via wsjt-devel ha scritto:
Hi, version 2.6.1-win64.exe from the new home page is triggering my AV 
software, which then promptly deletes it.


My AV has never done this before on WSJT-X

Alan G0TLK, sent from my mobile device



I think you should be able to instruct your AV to not consider WSJT-X as 
a Malware.
The AV's are often to much sensible and use to trigger false positive 
actions, without any reason.



Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Missing Translation Issue (was) Re: WSJT-X 2.6.0 GA Release

[Marco Calistri via wsjt-devel]

Il 22/01/23 15:15, Daniele Forsi ha scritto:

Hello Marco,

the issue is due to the .ts file not up to date with the source code:
the source code has the string "Max Dist", but the English string in
the translations/wsjtx_it.ts has "Max Pts" and the translation can't
be found if the English strings don't match.

I don't know what is the command to update the .ts files.


Hello Daniele!

Thanks for your feedback!

Yes, I've noticed the same mismatch when I was doing the translation, 
but I was not so sure that it could be the cause of the missing 
translation into the program UI!


In my translation I have used the *Max Dist *as it is reported on the 
related button**and into the mouse-over tool-tips, and not th*e Max Pts*.


As I told before, I'm not a developer but I think you are right!

Grazie mille!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.6.0 GA Release

[Marco Calistri via wsjt-devel]

No problem Joe!

I'm glad that now the topic has been clarified.

Best regards,

Marco, PY1ZRJ

Il 07/01/23 11:52, Joe Taylor ha scritto:
Sorry, Marco, I misunderstood your question.  We are not yet 
up-to-date with incorporating UI translations for the new release.  We 
will do so as time allows.


-- Joe, K1JT

On 1/6/2023 11:01 PM, Marco Calistri wrote:

Il 06/01/23 19:58, Joe Taylor ha scritto:

On 1/6/2023 5:14 PM, Marco Calistri PY1ZRJ via wsjt-devel wrote:

I1ve successfully compiled and started WSJT-X 2.6.0, but I notice 
now that the updated Italian translations have not been included 
into the current release!


It should be obvious that updated translations cannot be posted 
until translators have sufficient time after receiving the new 
English version.  The new English User Guide was posted today. 
Further updates are possible.


Translations for the WSJT-X 2.6.0 User Guuide will be posted when 
they become available.


-- Joe, K1JT


Dear and respectable Joe,

I mean the translations of the program UI itself, that once time ago 
were managed by the good Bill Somerville, G4WJS.


I was contributing to the Italian translations for Linux, it was 
coming as a Qt Linguist *.TS file.


The last file I've translated has been for the WSJT-X 2.6.0-RC2 release.

The button on Main Window to select CQ None, CQ First, CQ Max Dist, 
has not been translated in current 2.6.0 GA release, but I did sent 
the TS file containing the corresponding translation for the Italian.



Apologies in case I'm doing confusion on this topic.


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




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.6.0 GA Release

[Marco Calistri via wsjt-devel]

Il 06/01/23 19:58, Joe Taylor ha scritto:

On 1/6/2023 5:14 PM, Marco Calistri PY1ZRJ via wsjt-devel wrote:

I1ve successfully compiled and started WSJT-X 2.6.0, but I notice now 
that the updated Italian translations have not been included into the 
current release!


It should be obvious that updated translations cannot be posted until 
translators have sufficient time after receiving the new English 
version.  The new English User Guide was posted today. Further updates 
are possible.


Translations for the WSJT-X 2.6.0 User Guuide will be posted when they 
become available.


-- Joe, K1JT


Dear and respectable Joe,

I mean the translations of the program UI itself, that once time ago 
were managed by the good Bill Somerville, G4WJS.


I was contributing to the Italian translations for Linux, it was coming 
as a Qt Linguist *.TS file.


The last file I've translated has been for the WSJT-X 2.6.0-RC2 release.

The button on Main Window to select CQ None, CQ First, CQ Max Dist, has 
not been translated in current 2.6.0 GA release, but I did sent the TS 
file containing the corresponding translation for the Italian.



Apologies in case I'm doing confusion on this topic.


Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.6.0 GA Release

[Marco Calistri via wsjt-devel]

Il 06/01/23 12:00, Joe Taylor via wsjt-devel ha scritto:
The WSJT Development Team is pleased to announce the WSJT-X 2.6.0 
General Availability (GA) release.  Program changes from version 
2.5.4, released one year ago, are described in the Release Notes:

https://wsjt.sourceforge.io/wsjtx-doc/Release_Notes_2.6.0.txt

Be sure to read the full Release Notes entry for today's date, January 
6 2023.  Program enhancements since program version 2.5.4 and extensive.


We call to your attention, once again, that the WSJT Home Page has 
moved to a new URL:

https://wsjt.sourceforge.io/

Direct links for downloading pre-built installation packages for 
Windows, Linux, and macOS, can be found on the WSJT-X page:

https://wsjt.sourceforge.io/wsjtx.html

For those who like to compile from source, a complete source-code 
tarball is available at the WSJT-X page. Public access to the git 
repository for the WSJT project is available on the "Git" tab here:

https://sourceforge.net/projects/wsjt/

WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If 
you use our code, please have the courtesy to let us know about it.  
If you find bugs or make improvements to the code, please report them 
to us in a timely fashion.


The authors and Copyright holders of WSJT-X request that derivative 
works should not publish programs based on features in WSJT-X before 
those features are made available in a General Availability (GA) 
release of WSJT-X.  We will cease making public Release Candidate (RC) 
pre-releases for testing and user early access purposes if this 
request is ignored.


Bugs should be reported by following instructions found here in the 
User Guide:


https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.4.html#_bug_reports 



We hope you will enjoy using WSJT-X 2.6.0.

   -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG3YCB;
    Brian, N9ADG; and John, G4KLA


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




Thanks a lot for this new release!

I'm goind to compile it for my openSUSE Tumbleweed system!


Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Some comments for WSJT-X 2.6.0-RC4

[Marco Calistri via wsjt-devel]

Hello,

Today I've been able to see an important warning message that most 
likely is the alarm for the cause of the audio issue in my WSJT-X for Linux:


*ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred**
*
I've installed pipewire on place of the default pulseaudio and I don't 
know if I should adjust something in the settings for this new sound 
environment.


Any thought is very appreciated.

Thanks and regards,


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

l 11/11/22 10:37, Marco Calistri via wsjt-devel ha scritto:

Il 11/11/22 09:26, Uwe, DG2YCB ha scritto:


Hello Marco,

FYI. The second issue should be fixed with v2.6.0-rc5. We have 
fine-tuned some GUI settings so that it now works better with 
different font sizes and on different operating systems.


And issue #1 can also be RFI. Does it also happen on all bands or 
only on some? Check whether the error is still there when TX PWR is 
very low.


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB



Hi Uwe and thanks for your reply!

Regarding issue 1 it is not RFI related since it doesn't occur under 
WSJT-X for Windows using same rig and computer, it is an isolated 
behavior between computer's sound system and WSJT-X under Linux, 
because as I wrote, by using any other apps to play sounds, it is 
working perfectly.



Il 11/11/22 08:35, leo bistmans via wsjt-devel ha scritto:

1)
Does pavucontrol show a difference at fail time?
Does dmesg -w show some lines at fail time?
I had something like this when hdmi screen came out of power save 
modem the Linux thought there was a new audio default: the non 
existing speakers in the screen via the hdmi out ...


2)
I just do Dark on gnome desktop:
wsjtx -r ft-891 --stylesheet :/qdarkstyle/style.qss

73 de on1aad Leo


Hi Leo!

1) To be honest I've not checked the logs but as I wrote if I play a 
video on same environment, without touching nothing on sound system, 
the sound works perfectly. I'm suspecting after some guessing, that 
this sound interruption under WSJT-X could be related to my tests 
using the "*ondemand*" cpu-governor kernel option.
I roll back to "*schedutil*" now and I will keep monitoring if such 
issue occurs again.


2) I use XFCE as desktop environment and I start WSJT-X program from 
within CQRLOG, which as far as I tested, is not accepting "composed 
commands on same string" as the one you mention above.


BTW I would like to ask from where you take the *qss* styles?

Il 11/11/22 08:21, Kari Sillanmäki via wsjt-devel ha scritto:

Hi Marco,

Never had this problem.  What Linux version and radio are you using?

Why not just set environment variable QT_STYLE_OVERRIDE="Fusion" ?

73's de Kari, oh2gqc


Hi Kari!

I'm using openSUSE Tumbleweed 64 bits and my radio is the YAESU FT-100.
Your suggestion is interesting but it will force the style globally 
for any user's application so, IMHO is not the best solution because 
it could not be ideal for different apps (maybe...).


*Thanks everybody for your feedback!*

Best regards!

Am 10.11.2022 um 21:40 schrieb Marco Calistri via wsjt-devel:

Hello,

I'm using latest release of WSJT-X (2.6.0-RC4) and I faced two 
issues so far related to my Linux installation:


1 - Suddenly the audio IN/OUT communication with the default sound 
system get lost and WSJT-X stop to receive and to send audio. 
*Please note that it happens just within WSJT-X and the default 
sound system,* I verified this by opening a YouTube video whose 
audio plays perfectly. To resolve this issue I have to 
"*pkill*"wsjtx, eventually delete its lock file in /tmp and restart 
the app.


2 - With my desktop environment (XFCE), I need to start WSJT-X with 
a specific *"style"* option, otherwise the band frequencies and 
other graphical details (buttons, menus) of the program window are 
resulting not perfectly adjusted for the window itself. More in 
detail, I use a script to start my WSJT-X which executes the 
following command:


*/home/marco/WSJT-X_build/.wsjtx/bin/wsjtx -style Fusion*

Would like to know if is there an option, during the program source 
compiling of WSJT-X, to *force* a specific starting window 
environment style.


3 - Please note that the issue at point 1 is *not present with 
WSJT-X for Windows as I could verify under Windows 11.**


*
Many thanks for your kindest attention!

Best regards,




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] How to set a specific Hamlib version when compiling WSJT-X source

[Marco Calistri via wsjt-devel]

Hello,

Due my latest sound interruption issues I'm trying to rebuilt WSJT-X 
2.5.4 from source but now I get an error related to Hamlib:


[ 88%] Linking CXX executable wsjtx
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 
/home/marco/WSJT-X_build/build/wsjtx-2.5.4/hamlib-prefix/lib64/libhamlib.a(usb_port.o): 
in function `find_and_open_device':
(.text.find_and_open_device+0xc8): undefined reference to 
`libusb_get_device_list'
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 
(.text.find_and_open_device+0x125): undefined reference to 
`libusb_get_device_descriptor'


.SNIP.
gmake[6]: *** [CMakeFiles/wsjtx.dir/build.make:874: wsjtx] Error 1
gmake[5]: *** [CMakeFiles/Makefile2:1343: CMakeFiles/wsjtx.dir/all] Error 2
gmake[4]: *** [Makefile:156: all] Error 2
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:78: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
gmake[2]: *** [CMakeFiles/Makefile2:305: 
CMakeFiles/wsjtx-install.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:390: CMakeFiles/install.dir/rule] 
Error 2

gmake: *** [Makefile:267: install] Error 2

If I try to built the 2.6.0 source this error is not present and 
compiling succeed.


To build the source I use these commands:

/usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/local/include \
 -Dhamlib_LIBRARIES=/usr/local/lib64/libhamlib.so \
 -Dhamlib_LIBRARY_DIRS=/usr/local/lib64 \
 -DWSJT_GENERATE_DOCS=OFF \
 -DWSJT_SKIP_MANPAGES=ON \
 -Werror=deprecated-declarations \
 -Wno-error \
 -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx .

 /usr/bin/cmake --build .  --target install

*Please note*: I have installed latest available Hamlib from github.

marco@linux-turion64:~/WSJT-X_build> rigctl --version
rigctl Hamlib 4.6~git gio nov 10 14:03:43 2022 + SHA=09d7ed

How can I "force" the compiler to not use the 
/home/marco/WSJT-X_build/build/wsjtx-2.5.4/hamlib-prefix/ from the 
source and take the one I installed from github?


Thanks for your suggestions!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Some comments for WSJT-X 2.6.0-RC4

[Marco Calistri via wsjt-devel]

Il 11/11/22 09:26, Uwe, DG2YCB ha scritto:


Hello Marco,

FYI. The second issue should be fixed with v2.6.0-rc5. We have 
fine-tuned some GUI settings so that it now works better with 
different font sizes and on different operating systems.


And issue #1 can also be RFI. Does it also happen on all bands or only 
on some? Check whether the error is still there when TX PWR is very low.


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB



Hi Uwe and thanks for your reply!

Regarding issue 1 it is not RFI related since it doesn't occur under 
WSJT-X for Windows using same rig and computer, it is an isolated 
behavior between computer's sound system and WSJT-X under Linux, because 
as I wrote, by using any other apps to play sounds, it is working perfectly.



Il 11/11/22 08:35, leo bistmans via wsjt-devel ha scritto:

1)
Does pavucontrol show a difference at fail time?
Does dmesg -w show some lines at fail time?
I had something like this when hdmi screen came out of power save 
modem the Linux thought there was a new audio default: the non 
existing speakers in the screen via the hdmi out ...


2)
I just do Dark on gnome desktop:
wsjtx -r ft-891 --stylesheet :/qdarkstyle/style.qss

73 de on1aad Leo


Hi Leo!

1) To be honest I've not checked the logs but as I wrote if I play a 
video on same environment, without touching nothing on sound system, the 
sound works perfectly. I'm suspecting after some guessing, that this 
sound interruption under WSJT-X could be related to my tests using the 
"*ondemand*" cpu-governor kernel option.
I roll back to "*schedutil*" now and I will keep monitoring if such 
issue occurs again.


2) I use XFCE as desktop environment and I start WSJT-X program from 
within CQRLOG, which as far as I tested, is not accepting "composed 
commands on same string" as the one you mention above.


BTW I would like to ask from where you take the *qss* styles?

Il 11/11/22 08:21, Kari Sillanmäki via wsjt-devel ha scritto:

Hi Marco,

Never had this problem.  What Linux version and radio are you using?

Why not just set environment variable QT_STYLE_OVERRIDE="Fusion" ?

73's de Kari, oh2gqc


Hi Kari!

I'm using openSUSE Tumbleweed 64 bits and my radio is the YAESU FT-100.
Your suggestion is interesting but it will force the style globally for 
any user's application so, IMHO is not the best solution because it 
could not be ideal for different apps (maybe...).


*Thanks everybody for your feedback!*

Best regards!

Am 10.11.2022 um 21:40 schrieb Marco Calistri via wsjt-devel:

Hello,

I'm using latest release of WSJT-X (2.6.0-RC4) and I faced two issues 
so far related to my Linux installation:


1 - Suddenly the audio IN/OUT communication with the default sound 
system get lost and WSJT-X stop to receive and to send audio. *Please 
note that it happens just within WSJT-X and the default sound 
system,* I verified this by opening a YouTube video whose audio plays 
perfectly. To resolve this issue I have to "*pkill*"wsjtx, eventually 
delete its lock file in /tmp and restart the app.


2 - With my desktop environment (XFCE), I need to start WSJT-X with a 
specific *"style"* option, otherwise the band frequencies and other 
graphical details (buttons, menus) of the program window are 
resulting not perfectly adjusted for the window itself. More in 
detail, I use a script to start my WSJT-X which executes the 
following command:


*/home/marco/WSJT-X_build/.wsjtx/bin/wsjtx -style Fusion*

Would like to know if is there an option, during the program source 
compiling of WSJT-X, to *force* a specific starting window 
environment style.


3 - Please note that the issue at point 1 is *not present with WSJT-X 
for Windows as I could verify under Windows 11.**


*
Many thanks for your kindest attention!

Best regards,




---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Some comments for WSJT-X 2.6.0-RC4

[Marco Calistri via wsjt-devel]

Hello,

I'm using latest release of WSJT-X (2.6.0-RC4) and I faced two issues so 
far related to my Linux installation:


1 - Suddenly the audio IN/OUT communication with the default sound 
system get lost and WSJT-X stop to receive and to send audio. *Please 
note that it happens just within WSJT-X and the default sound system,* I 
verified this by opening a YouTube video whose audio plays perfectly. To 
resolve this issue I have to "*pkill*"wsjtx, eventually delete its lock 
file in /tmp and restart the app.


2 - With my desktop environment (XFCE), I need to start WSJT-X with a 
specific *"style"* option, otherwise the band frequencies and other 
graphical details (buttons, menus) of the program window are resulting 
not perfectly adjusted for the window itself. More in detail, I use a 
script to start my WSJT-X which executes the following command:


*/home/marco/WSJT-X_build/.wsjtx/bin/wsjtx -style Fusion*


Would like to know if is there an option, during the program source 
compiling of WSJT-X, to *force* a specific starting window environment 
style.


3 - Please note that the issue at point 1 is *not present with WSJT-X 
for Windows as I could verify under Windows 11.**


*
Many thanks for your kindest attention!

Best regards,


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4

[Marco Calistri via wsjt-devel]

Well,

IMHO this issue is pretty annoying also because from the lock stale 
warning window we cannot remove the file and as I told in other 
occasions, the same problem is present in every WSJT-X release I used 
from the very beginning.


Beside this, more precisely with 2.6.0 RC4, I noticed an increase of 
occurrences of the processes hanging in the background (I think it being 
the JT9 process...) and a manual intervention is necessary to kill them 
in order to restart the main program.


In addition from time to time, I noticed with RC4 a sudden lost of audio 
communication (both in TX and RX) between WSJT-X and the default 
computer sound system and again to get it sorted out, I need to delete 
the WSJT-X.lock file by hand and restart the main program.


Regards,

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

Il 05/11/22 10:06, Adrian via wsjt-devel ha scritto:

I see this from time to time, rectified with 'sudo pkill wsjtx' and

then no problem to start a new session.. If linux > wsjtx ran a 
startup script killing first,


then there would never be an issue.


73


Adrian Fewster

On 5/11/22 22:56, leo bistmans via wsjt-devel wrote:
Via strace I saw the lock file that is not there is /tmp/WSJT-X ... 
.lock



openat(AT_FDCWD, "/tmp/WSJT-X - ft-891.lock", 
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 13

flock(13, LOCK_EX|LOCK_NB)              = 0

If I create it myself with touch,  the switch code below is used 
instead of throwing the fatal error.


      The code in main.cpp:

  // disallow multiple instances with same instance key
      QLockFile instance_lock {temp_dir.absoluteFilePath 
(a.applicationName () + ".lock")};

      instance_lock.setStaleLockTime (0);
      while (!instance_lock.tryLock ())
        {
          if (QLockFile::LockFailedError == instance_lock.error ())
            {
              auto button = MessageBox::query_message (nullptr
                                                       , "Another 
instance may be running"
                                                       , "try to 
remove stale lock file?"

                                                       , QString {}
                                                       , 
MessageBox::Yes | MessageBox::Retry | MessageBox::No
                                                       , 
MessageBox::Yes);

              switch (button)
                {
                case MessageBox::Yes:
                  instance_lock.removeStaleLockFile ();
                  break;

                case MessageBox::Retry:
                  break;

                default:
                  throw std::runtime_error {"Multiple instances must 
have unique rig names"};

                }
            }
          else
            {
              throw std::runtime_error {"Failed to access lock file"};
            }
        }

The reason that I do not have the .lock file in /tmp is an open 
question to me ( possibly a disk full condition? ).
However I think it is fairly safe for wsjt-x to just start instead of 
forcing me to reboot my PC.


73 de on1aad



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Annoying Stale Lock File Window

[Marco Calistri via wsjt-devel]

Hello Dev-Team!

I would like to avoid seeing the same annoying warning window in the 
next 2.6.0 GA, as far it being humanely possible.


This issue is present from the very first WSJT-X I ever installed on my 
Linux box and apparently is inexplicable since I have "RW" rights on the 
/tmp dir despite this the lock file doesn't went removed by clicking on 
the button.


Stale Lock File

Thanks for your kindest attention!
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X Crashes if switching from F/H to WW-DIGI Contest

[Marco Calistri via wsjt-devel]

Hello,

As per the subject: I was trying to contact 4U1UN on F/H, then I went to 
advanced options and selected WW DIGI contest and program has closed.


Running WSJT-X 2.6.0-RC4 on a Linux Opensuse-Tumbleweed 64 bits
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] /tmp/WSJT-X.lock

[Marco Calistri via wsjt-devel]

Il 08/10/22 19:07, Black Michael ha scritto:

touch /tmp/test.txt

ls -ld /tmp
drwxrwxrwt 20 root root 520  8 ott 19.29 /tmp

marco@linux-turion64:~> touch /tmp/test.txt

marco@linux-turion64:~> ls -ltr /tmp

-rw-r--r-- 1 marco users  0  8 ott 19.29 test.txt
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] /tmp/WSJT-X.lock

[Marco Calistri via wsjt-devel]

From the very first install of WSJT-X on my Linux laptop, I always 
noticed the impossibility to remove the lock file created into the 
system /tmp directory by the program itself. In order to be able to 
remove it, I have to use the Linux "rm" command from the console prompt.


marco@linux-turion64:~> rm /tmp/WSJT-X.lock

Why this removing feature apparently available in WSJT-X program is not 
yet working?


Thanks!
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] pskreporter.de

[Marco Calistri via wsjt-devel]

Il 20/09/22 00:59, Adrian via wsjt-devel ha scritto:
I noticed pskreporter.de was down for a long time with a database 
issue. Now it requires a login ?


Is it now a subscriber service, I see no info on that site, as any 
associated url needs auth access ?



Thankyou for any info.


73


vk4tux



Hi!

I'm in contact with pskreporter.de owner and webmaster and he is working 
for updating the website in order to comply with the requirements 
established by the source engine which is running on pskreporter.info 
owned by Mr. Gladstone.


Currently the host management of pswkreporter.de has configured a 
private access protected by login/password just for the website owner, 
in order to reduce the high load during the upgrading process.


I used to use such site much more than pskreporter.info because I prefer 
its graphics and its usability.


I hope it will be back soon!


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib errors please for RC4 #hamlib

[Marco Calistri via wsjt-devel]

Il 14/09/22 19:04, Black Michael via wsjt-devel ha scritto:
If everyone running RC4 would please check their wsjtx_syslog.log file 
and see if there are any hamlib errors I would appreciate it.  If 
errors/warning are seen please send the log to me


Getting ready to release Hamlib 4.5 and would like to ensure all is 
working well.


For Windows
C:\Users\[username]\AppData\Local\WSJT-X\wsjtx_syslog.dat
For Linux
/home/[username]\.local\share\WSJT-X\wsjtx_syslog.dat

And RC4 version is not available for MacOS so no testing for Macs is 
needed.


Mike W9MDB


Hi Mike!

I've collected some errors into my log and warnings about the dropped 
audio issue.


I've tried before to send the log as zip archive but then Outlook.com 
has blocked the sending of the message:


Total retry attempts: 1

wsjt-devel@lists.sourceforge.net
Remote Server returned '550 5.0.350 Remote server returned an error -> 
550 Blacklisted file extension detected'




So I'm copying below the relevant parts of the syslog, I'm using an 
Yaesu FT-100 trasceiver with two serial cables one for PTT and the other 
for the CAT control:


[SYSLOG][2022-09-15 12:25:03.936377][00:00:00.088548][info] Log Start
[SYSLOG][2022-09-15 12:25:03.936524][00:00:00.088690][info] WSJT-X 
v2.6.0-rc4   by K1JT et al. - Program startup
[SYSLOG][2022-09-15 12:25:03.955409][00:00:00.107577][info] locale: 
language: Italian script: Latin country: Italy ui-languages: it-IT
[SYSLOG][2022-09-15 12:25:03.982102][00:00:00.134273][info] Loaded Qt 
translations for current locale from resources
[SYSLOG][2022-09-15 12:25:03.986233][00:00:00.138400][info] Loaded 
WSJT-X base translation file from :/Translations based on language it
[SYSLOG][2022-09-15 12:25:03.990635][00:00:00.142801][info] Loaded 
WSJT-X translations for current locale from resources
[SYSLOG][2022-09-15 12:25:04.255149][00:00:00.407316][info] shmem size: 
48275260
[RIGCTRL][2022-09-15 12:25:04.442125][00:00:00.594292][info] Hamlib 
version: Hamlib 4.5~git Sun Sep 04 16:38:41 2022 + SHA=6c746c
[RIGCTRL][2022-09-15 12:25:11.445276][00:00:07.597441][warning] 
network_flush: network data clear d: ret=0, len=7, ''
[RIGCTRL][2022-09-15 12:25:11.445337][00:00:07.597502][warning] 
network_flush: network data cleared: ret=0, len_read=7/0x7
[RIGCTRL][2022-09-15 12:25:11.497850][00:00:07.650015][warning] 
network_flush: network data clear d: ret=0, len=7, ''
[RIGCTRL][2022-09-15 12:25:11.497936][00:00:07.650102][warning] 
network_flush: network data cleared: ret=0, len_read=7/0x7
[SYSLOG][2022-09-15 13:18:14.328497][00:53:10.480667][warning] Detected 
dropped audio source samples: 73296 (1.527 S)
[SYSLOG][2022-09-15 13:18:29.434296][00:53:25.586467][warning] Detected 
dropped audio source samples: 2688 (0.056 S)
[SYSLOG][2022-09-15 13:18:44.368816][00:53:40.520983][warning] Detected 
dropped audio source samples: -768 (-0.016 S)
[SYSLOG][2022-09-15 13:19:59.380873][00:54:55.533042][warning] Detected 
dropped audio source samples: 576 (0.012 S)
[SYSLOG][2022-09-15 13:20:29.317394][00:55:25.469561][warning] Detected 
dropped audio source samples: -672 (-0.014 S)
[SYSLOG][2022-09-15 13:20:44.434271][00:55:40.586441][warning] Detected 
dropped audio source samples: 816 (0.017 S)
[SYSLOG][2022-09-15 13:20:59.319241][00:55:55.471409][warning] Detected 
dropped audio source samples: -720 (-0.015 S)
[SYSLOG][2022-09-15 13:21:14.431544][00:56:10.583715][warning] Detected 
dropped audio source samples: 576 (0.012 S)
[SYSLOG][2022-09-15 13:21:59.381365][00:56:55.533534][warning] Detected 
dropped audio source samples: 3504 (0.073 S)
[RIGCTRL][2022-09-15 13:22:00.208182][00:56:56.360346][warning] 
network_flush: network data clear d: ret=0, len=7, ''
[RIGCTRL][2022-09-15 13:22:00.208220][00:56:56.360392][warning] 
network_flush: network data cleared: ret=0, len_read=7/0x7
[RIGCTRL][2022-09-15 13:22:00.346274][00:56:56.498438][warning] 
network_flush: network data clear d: ret=0, len=7, ''
[RIGCTRL][2022-09-15 13:22:00.346312][00:56:56.498477][warning] 
network_flush: network data cleared: ret=0, len_read=7/0x7
[RIGCTRL][2022-09-15 13:22:00.372103][00:56:56.524268][warning] 
network_flush: network data clear d: ret=0, len=7, ''
[RIGCTRL][2022-09-15 13:22:00.372142][00:56:56.524307][warning] 
network_flush: network data cleared: ret=0, len_read=7/0x7
[RIGCTRL][2022-09-15 13:22:01.516165][00:56:57.668330][error] error: 
rig_set_split_mode: mode PKTUSB is different from A=LSB and B=PKTUSB
/home/marco/WSJT-X_build/build/wsjtx-2.6.0/hamlib-prefix/src/hamlib/src/rig.c(4226) 
trace

netrigctl_set_split_mode called
netrigctl_vfostr: called vfo=VFOA
netrigctl_vfostr: vfo_opt=0
netrigctl_transaction: called len=12
rig_flush: called for network device
network_flush called
write_block(): TX 12 bytes, method=2
    58 20 50 4b 54 55 53 42 20 2d 31 0a X PKTUSB -1.
read_string_generic called, rxmax=1024 direct=1
read_string_generic(): RX 8 characters, direct=1
    52 50 52 54 20 2d 31 0a 

Re: [wsjt-devel] WSJT-X 2.6.0 RC2 - Strange little bug using the newest Hamlib

[Marco Calistri via wsjt-devel]

Hello and thanks to the development's team for the new WSJT-X release!

Would like to inform that the little issue below I faced using RC2 is 
not anymore present on RC4!




Best regards!

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

Il 22/07/22 11:14, Marco Calistri via wsjt-devel ha scritto:

Hello,

I noticed a new undesired behavior here using the new WSJT-X 2.6.0-RC 
2 with the latest Hamlib available by Github:


When I switch *FROM* any band *TO* 21MHz band, the rig begins making a 
sort of band switching from previous band to the 21MHz one, without stop.


This happens *ONLY* when I switch over 21MHz and the only way to stop 
it is by manual pressing the SPLIT and the VFO A=B on my Yaesu FT-100 
front panel.


I start rigctld with the command /usr/local/bin/rgctld and the 
additional parameters I pass to it are:


/usr/local/bin/rigctld -m 1 *-r /dev/FT-100_USB1 -t 4532 -m 1021 --vfo 
--set-conf=post_write_delay=40 -s 4800*


This is the first time so far I see this behavior which I consider of 
very low severity, BTW I would like to share it here.


Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-2.6.0-rc2

[Marco Calistri via wsjt-devel]

  
I downloaded the source by the website
  and I got the right one.
  
  I read a note by Saku here on this list regarding differences
  among the source availables in Github and in the Website.
  
  
  
  Best regards!
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 23/07/22 04:15, jarmo via wsjt-devel ha scritto:


  Don't know, if anyone else have this, but compiled wsjtx
from wsjtx-2.6.0-rc2.tgz.
Still, when starting wsjtx I get wsjtx-2.6.0-rc1???
What I'm missing???

Jarmo, oh1mrr


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.6.0 RC2 - Strange little bug using the newest Hamlib

[Marco Calistri via wsjt-devel]

  
Hello,

I noticed a new undesired behavior here using the new WSJT-X
2.6.0-RC 2 with the latest Hamlib available by Github:

When I switch FROM any band TO 21MHz band, the rig
begins making a sort of band switching from previous band to the
21MHz one, without stop.

This happens ONLY when I switch over 21MHz and the only way
to stop it is by manual pressing the SPLIT and the VFO A=B on my
Yaesu FT-100 front panel.

I start rigctld with the command /usr/local/bin/rgctld
and the additional parameters I pass to it are:

/usr/local/bin/rigctld -m 1 -r
/dev/FT-100_USB1 -t 4532 -m 1021 --vfo
--set-conf=post_write_delay=40 -s 4800
  
This is the first time so far I see this behavior which I
consider of very low severity, BTW I would like to share it here.

Regards,

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Release Candidate WSJT-X 2.6.0-rc2

[Marco Calistri via wsjt-devel]

  
Many thanks to all the WSJT-X
  Developement Team for their effort by providing us more and more
  features and delighting usage of this nice program!
  
  I'm gonna to download, compile and test the version RC2 for Linux
  today!
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  
  Il 21/07/22 09:58, Joe Taylor via wsjt-devel ha scritto:

Dear
  WSJT-X Users,
  
  
  We are pleased to announce that Release Candidate WSJT-X 2.6.0-rc2
  is ready for download by beta testers. A list of its essential
  changes from previous releases can be found in the Release Notes:
  
  https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt
  
  
  Links for downloading WSJT-X 2.6.0-rc2 can be found on the WSJT-X
  Home Page, https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
  
  Scroll down to find "Candidate release:  WSJT-X 2.6.0-rc2".
  
  
  We hope you will enjoy using this beta release of WSJT-X 2.6.0. 
  As a beta tester you should report on your experiences with its
  new features, successful and otherwise, on one of the relevant
  WSJT forums.  Bugs should be reported by following instructions
  found here in the User Guide:
  
  
https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.6.0-rc2.html#_bug_reports
  
  
  WSJT-X and MAP65 are licensed under the terms of Version 3 of the
  GNU General Public License (GPLv3).  Development of this software
  is a cooperative project to which many amateur radio operators
  have contributed.  If you use our code, please have the courtesy
  to let us know about it.  If you find bugs or make improvements to
  the code, please report them to us in a timely fashion. 
  Additional licensing details can be found here:
  
  https://physics.princeton.edu//pulsar/k1jt/devel.html
  
  
   73 from the WSJT Core Development Team
  
   Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Chet, KG4IYS; Uwe,
  DG2YCB;
  
   Brian, N9ADG; and John, G4KLA
  
  
  
  ___
  
  wsjt-devel mailing list
  
  wsjt-devel@lists.sourceforge.net
  
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  



  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

  
I received several eQSL QSL rejections
  too for same reason.
  
  Regards,
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 15/07/22 10:29, Adrian via wsjt-devel ha scritto:


  
  They should do, the ones i queried via eqsl rejections said
they did not receive my RR73, and then moved on to another
station.
  Bad op practice by them , I agree, instead of trying or perhaps
they did with no luck on RX,
   but sometimes a cheap txcr with poor blocking gets smothered
by closed in strong signals and they 
  
  lose the contact. 
  
  In the meantime i have them in my log, but I am not in theirs.
If theirs logged when they send the 73 and mine logs when i
receive it,
  then we both have each other in the log or have enough to
confirm the qso in ALL.txt via confirm sig reports on both
sides.
  
  
  
  73
  
  
  vk4tux
  
  On 15/7/22 23:14, Larry Banks via
wsjt-devel wrote:
  
   If they don't get your RR73,
then they will send back their R-#.  IF you get nothing back
they got your R73 and are playing by the rules.

Larry / W1DYJ



  
  
  
  
  
  
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

  
Il 15/07/22 05:03, Fred Price via
  wsjt-devel ha scritto:


  
  
When sending RR73 the other station doesn't have to reply
  with a 73. The reason is that the QSO is over at RR73. A lot
  of stations take as much and move on.
If you'd like your 73 just change the RR73 to
  RRR by double clicking Tx 4. Doing it this way it will not log
  until you receive the 73. This also might be a good idea as
  you stated you have a little station. Another thing you could
  do is to check Prompt me to log QSO on the Reporting tab. This
  pops up a box and it stays there until you feel the QSO is
  sufficient to log even if you send RR73. Of course this
  doesn't work if you are in a contest mode and you have Log
  automatically checked.


Fred
N2XK 
  
  

  

Very good point Fred! I will switch my Tx4 to defaulting in RRR
instead of RR73, may be in this way I will collect less QSO dupes.

As well your second hint regarding when to click on log QSO, is very
useful.

Best regards,

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



  

  
On Jul 14, 2022 11:24 PM, Adrian
  via wsjt-devel 
  wrote:
  

  It is a good point, wsjtx should not auto log until
the 73 is received, not RR73 sent.
  Case in point is the rejected eqsl's from stations
in my log, but I am not in theirs.
  This would save that problem.
  In the meantime, in those situation's, my TX is set
free to change, and I click a
   vacant column on pan to better my chances of
finishing the qso.
  Many stations don't bother with the 73 because of
this shortfall.
  
  
  
  73
  
  
  vk4tux
  
  On 15/7/22 13:10, Marco Calistri via wsjt-devel
wrote:
  
  
Il 14/07/22 23:18, jarmo ha scritto:


  Thu, 14 Jul 2022 23:02:32 -0300
Marco Calistri via wsjt-devel 
kirjoitti:


  
Hello,

  
  
This occurrence causes that WSJT-X logging the QSO then I go to hit
"OK" and QSO is getting saved on my CQRLOG app.

 (I'm using Linux).

  
  I'm using also, now question, why you hit OK, if qso is not complete?
I hit again opposite stations report to give again RR73, some cases
move couple Hz TX and hit again RR73. Normally I do this max 5 times and
then hit CANCEL. Can't log unfinished qso.


Good point! 

Yes probably I just have to discard the logged QSO
offered by WSJT-X in cases like this one and click
OK only when QSO get really completed.

The fact is that as soon as WSJT-X sends the RR73 to
the partner then from a WSJT-X point of view the QSO
is complete!


  Normally this means, that someone qrm'ing so much, that opposite
station can't hear anymore me.
 

  
But I would like to know if I could adjust something into WSJT-X
settings, to avoid closing QSO's "unilaterally".

  
  This could ba, as sending that RR73 so long yuo get /# or if not
you cancel qso..


Jarmo, oh1mrr


Thanks Jarmo for your comments. I believed that this
process (logging QSO) would be totally managed by
WSJT-X,  without any human intervention.

Hopefully, in an ideal world, it should be that
WSJT-X  waits for a second RR73 (hypothetical answer
confirmation sequence I mean) from the remote
station, before to definitely close and log the QSO.

Regards,

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




___
wsjt-devel mailing list
wsjt-devel@lists.s

Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

Hi Adrian,

Yes your suggestion I think that will resolve once for all this QSO 
logging issue.


But may be its easy to tell about and less easy to add the feature in 
the code, I don't know.


Best regards,


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



**Il 15/07/22 02:29, Adrian ha scritto:


When you send a RR73 and get nothing back, then wsjtx has logged the 
call, but you don't know if your RR73 was received,


or if the other party logged you.

Making the log work only on 73 sent or received instead of RR73, 
confirms the sig report both ways and the qso both ways.


if the program worked this way the everyone would send the 73 to get 
in and be logged.


Why is using 73 to trigger a log entry sent/received a problem ?

Send RR73 and program logs on received 73.

Receive RR73 and program logs on sent 73.


vk4tux

On 15/7/22 15:12, Reino Talarmo via wsjt-devel wrote:


>Hopefully, in an ideal world, it should be that WSJT-X  waits for a 
second RR73 (hypothetical answer confirmation sequence I mean) from 
the remote station, before to definitely close and log the QSO.


Hi Marco,
I am not sure what you mean by the “second RR73”. There seems to be a 
generic misunderstanding how the protocol is assumed to work. User 
Guide sections 7.1. and 7.4. provide a nice advice. For a minimum 
QSO, where locator information is exchanged:


CQ K1ABC FN42  #K1ABC calls CQ

  K1ABC G0XYZ IO91 #G0XYZ answers

G0XYZ K1ABC –19    #K1ABC sends report

  K1ABC G0XYZ R-22 #G0XYZ sends R+report

G0XYZ K1ABC RR73   #K1ABC sends RR73

  K1ABC G0XYZ 73   #G0XYZ sends 73

The last message (73) is optional.

Relevant issue is that in none of the examples a station that 
receives RR73 is sending back RR73, but 73 or nothing more for that call.


73, Reino OH3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

Il 15/07/22 02:12, Reino Talarmo ha scritto:


>Hopefully, in an ideal world, it should be that WSJT-X  waits for a 
second RR73 (hypothetical answer confirmation sequence I mean) from 
the remote station, before to definitely close and log the QSO.


Hi Marco,
I am not sure what you mean by the “second RR73”. There seems to be a 
generic misunderstanding how the protocol is assumed to work. User 
Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, 
where locator information is exchanged:


CQ K1ABC FN42  #K1ABC calls CQ

  K1ABC G0XYZ IO91 #G0XYZ answers

G0XYZ K1ABC –19    #K1ABC sends report

  K1ABC G0XYZ R-22 #G0XYZ sends R+report

G0XYZ K1ABC RR73   #K1ABC sends RR73

  K1ABC G0XYZ 73   #G0XYZ sends 73

The last message (73) is optional.

Relevant issue is that in none of the examples a station that receives 
RR73 is sending back RR73, but 73 or nothing more for that call.


73, Reino OH3mA



Yes Reino,

WSJT-X dialog sequence is clear and it performs like you explained here, 
however often my WSJT-X sends RR73 to the remote station and opens up 
the LOG QSO window for me to click on its OK label.


Unluckily due a series of reasons, if the remote station has not 
received back my RR73 then it sends again the latest sequence to me and 
in this case some times I manually hit again on my RR73 sequence to 
confirm the QSO to the remote station.


This scenario is causing from time to time I collecting dupes QSOs in my 
CQRLOG which I need to delete manually.


Regards,

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

Il 14/07/22 23:18, jarmo ha scritto:

Thu, 14 Jul 2022 23:02:32 -0300
Marco Calistri via wsjt-devel
kirjoitti:


Hello,



This occurrence causes that WSJT-X logging the QSO then I go to hit
"OK" and QSO is getting saved on my CQRLOG app.

  (I'm using Linux).

I'm using also, now question, why you hit OK, if qso is not complete?
I hit again opposite stations report to give again RR73, some cases
move couple Hz TX and hit again RR73. Normally I do this max 5 times and
then hit CANCEL. Can't log unfinished qso.


Good point!

Yes probably I just have to discard the logged QSO offered by WSJT-X in 
cases like this one and click OK only when QSO get really completed.


The fact is that as soon as WSJT-X sends the RR73 to the partner then 
from a WSJT-X point of view the QSO is complete!



Normally this means, that someone qrm'ing so much, that opposite
station can't hear anymore me.
  

But I would like to know if I could adjust something into WSJT-X
settings, to avoid closing QSO's "unilaterally".

This could ba, as sending that RR73 so long yuo get /# or if not
you cancel qso..


Jarmo, oh1mrr
Thanks Jarmo for your comments. I believed that this process (logging 
QSO) would be totally managed by WSJT-X,  without any human intervention.


Hopefully, in an ideal world, it should be that WSJT-X  waits for a 
second RR73 (hypothetical answer confirmation sequence I mean) from the 
remote station, before to definitely close and log the QSO.


Regards,

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X close the QSO unilaterally (?)

[Marco Calistri via wsjt-devel]

  
Hello,

I've collected several use-cases wherein my WSJT-X sends the RR73 to
the other station which keeps to send back the RST to me.

This occurrence causes that WSJT-X logging the QSO then I go to hit
"OK" and QSO is getting saved on my CQRLOG app.

 (I'm using Linux).

Would like to know what could be the issue causing this, I suppose
it could be due my setup not so powerful and due to the partner
unable to decode me completely.

But I would like to know if I could adjust something into WSJT-X
settings, to avoid closing QSO's "unilaterally".


Thanks and best regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC1 UI bug

[Marco Calistri via wsjt-devel]

  
Il 17/06/22 17:00, Joe Taylor via
  wsjt-devel ha scritto:

Marco
  --
  
  
  On 6/17/2022 3:50 PM, Marco Calistri via wsjt-devel wrote:
  
  
  What is that "FT8-D" mode?

  
  
  There is no mode FT8-D.  That label on the K0VM screen shot is a
  name he selected for a Configuration.
  
  
  -- Joe, K1JT
  
  
  


Thanks Joe for your specification!

I will be wait a bit to upgrade to 2.6. 

2.5.4 is working very well here for FT8/FT4 modes.

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC1 UI bug

[Marco Calistri via wsjt-devel]

Il 17/06/22 17:00, Reino Talarmo ha scritto:


Hi Marco.

It is just a title defined for a Configuration by AL.

73, Reino

>What is that "FT8-D" mode?


Thanks Reino!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib testing

[Marco Calistri via wsjt-devel]

  
Il 31/05/22 13:04, Black Michael via
  wsjt-devel ha scritto:


  
  

  I need everyone to test the
latest Hamlib 
  Testing in Rig Split and
Fake It would be appreciated.
  Successes/Failures please
report.
  
  
  

  

  New hamlib for installation directions
  
  
  #1 Shut down WSJTX/JTDX
  
  
  #2 Download either the 32-bit or 64-bit DLL
matching the 32/64-bit version of WSJTX/JTDX --
hopefully your browser doesn't block it but may warn
you multiple times.
  
  
  If you can do a "Save As" you can save it
directly in \WSJT\WSJTX\bin and replace the
libhamlib-4.dll that is there.
  
  
  http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
  
  
  http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
  
  
  Linux/Unix/Mac users need to compile the latest
tar file from http://n0nb.users.sourceforge.net/
  
  
  #3 If you don't save directly you need to open a
file browser and move the file that way.
  
  
  If you're not familiar with that here's a video
on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk
  
  
  Mike W9MDB


  

  

  
  

Hi Mike!

Regarding Linux, after the testing stage passed, the new Hamlib
version will be available on github as usual?

Thanks!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ARRL International Digital Contest

[Marco Calistri via wsjt-devel]

  
Il 28/05/22 19:18, Sam W2JDB via
  wsjt-devel ha scritto:


  
  Hi
Joe, 





  2. Go to "File | Settings | Colors",
check "My Call in message" and "New
  
  Call on Band", and uncheck everything
else.  Check the box "Highlight

  also messages
  with 73 or RR73."  Click OK to dismiss the Settings
dialog.
  
  
  

Not on the color page. Where ?


73, 

  

  Sam W2JDB

  

  
  

Sorry but I haven't get the scope of this "colors settings-->My
Call in message".

Could someone be so kind to try to explain me in few words?

Thanks and regards,


---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Are you building WSJT-X ?

[Marco Calistri via wsjt-devel]

  
Il 25/04/22 12:29, Joe Taylor via
  wsjt-devel ha scritto:

When
  I started work on WSJT some 21 years ago, my principal goal was to
  help bring amateur weak-signal communication techniques into the
  twenty-first century -- and in doing so, to help spread knowledge
  of modern communication theory into the amateur radio community.
  
  
  By 2005 WSJT was well established but mostly used for special
  purposes like meteor scatter and EME ("moonbounce").  A stable
  development path had been established: the program was fully Open
  Source, licensed under the GNU General Public License, and it
  could be built by anyone from source code using freely available
  compilers and development tools.  At this time WSJT was coded in a
  combination of Python, Fortran, and C.  A re-write in 2012 created
  the present program, WSJT-X, using the Qt platform and C++
  language in addition to Fortran and C.
  
  
  To help gauge the extent to which my original educational goals
  are being met, we in the core development team are interested to
  know how many WSJT-X users are currently building the program for
  themselves, from source code.  If you are doing so, we would
  appreciate an email response -- either publicly, to this list, or
  in a private email to me. All responses will be appreciated, but
  particular things you might want to mention in your message
  include these:
  
  

Hello Joe,

Very grateful for being one of the thousands of the enthusiast
people around the globe using this amazing software, which allows
practically to every amateur radio, having a transceiver, a computer
and a small antenna, to be able to communicate worldwide in digital
mode.

I'm going to answer to your little poll point by point:


 -
  Building on what platform?  Windows, Linux, macOS, or other?
  

I always take the WSJT-X source code and compile here on my Linux
  64 bit laptop, running openSUSE Tumbleweed.


  
   - What are your particular programming skills and interests?
  

I'm not a developer at all, my coding skills are very limited to
  just some very basic tasks as using scripts and troubleshooting a
  possible software malfunctions

  
   - Are you making changes to the code?  If so, toward what end?
  

No, I have just contributed in the past for the translation of
  the WSJT-X  menu in Italian, when Bill, G4WJS was the
  maintainer of the WSJT-X localization list


  
   - What portions of the code have you studied well enough to
  understand?
  

As I told previously I'm not a developer, nor I have enough skill
  to analyze the code, but I gave a little more "insights" to the
  serial ports management, in order to control my transceiver
  through WSJT-X

  
  Many thanks -- I look forward to hearing from you!
  
  
  -- 73, Joe, K1JT
  
  
  
  ___
  
  wsjt-devel mailing list
  
  wsjt-devel@lists.sourceforge.net
  
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  



---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Help Debug WSJT-X Core Dump

[Marco Calistri via wsjt-devel]

  
Hello,

I ran WSJT-X on an openSUSE Tumbleweed system, Tumbleweed name
explain the "ever-rolling philosophy" of this distribution which
went updated daily.

Unluckily one of the negative effects of this is represented by
possible breakouts of the application which was running with a
different library, compiler, etc.

After the last system update I cannot start anymore my WSJT-X (I
also tried to re-compile it against latest gcc, libs and so on
without any positive result.

I got these errors in the log:

 wsjtx[7992]: segfault at 7ffc5bd57ff8 ip 7efe93d38e73 sp
7ffc5bd57ff0 error 6 in libc.so.6[7efe93cc4000+182000]

wsjtx[8186]: segfault at 7fffb5dbcff8 ip 7f09fd3f1dce sp
7fffb5dbd000 error 6 in libQt5Core.so.5.15.2
  
Which, despite I'm not a software developer, I understand that
are caused by different libraries or symbolic links to expected
libraries required by WSJT-X.

I would like to receive any suggestion in order to get rid of this
error which is not allowing me to use the WSJT-X program.

Thanks in advance!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Il 20/02/22 09:50, Saku via wsjt-devel
  ha scritto:

Hi Marco!
  
  
  Reason that you could not get it working with my suggestion below,
  and needed "-a" is written here: "il file binario corrisponde".
  
  
  Bash thinks ALL.TXT is a binary file. How ever a clean ALL.TXT is
  pure text file and grep can handle it directly.
  
  
  Maybe your WSJT-X has crashed some day in past during the write of
  ALL.TXT and there are some "hieroglyphs" written to file that
  makes grep think it is a binary file.
  
  
  As seen your ALL.TXT size I suggest you move the file.
  
  
  cd ~/.local/share/WSJT-X
  
  mv ALL.TXT ALLOLD1.TXT
  
  
  WSJT-X then opens a new ALL.TXT on next start.
  
  Then you can make more ALLOLDx files, monthly, or by yearly basis.
  Depending how much you use WSJT-X.
  
  

Hi Saku!

Any news regarding CQRLOG updates? (answer me directly, if you
  prefer!).

Yes, I could do what you suggested since my bash_history is not data
but text type then the issue could be rightly on ALL.TXT file.

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Il 19/02/22 20:06, Jim Brown via
  wsjt-devel ha scritto:

On
  2/19/2022 2:23 PM, Marco Calistri via wsjt-devel wrote:
  
  Amazing explanation of an "historical" and
already well identified issue Grant!

  
  
  Many of the answers to questions asked here are in the manual for
  WSJT-X. To reduce the load on the guys who provide support here,
  everyone should STUDY the manual first.
  
  
  73, Jim K9YC
  
  
  
  

Right!

Regards,

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Amazing explanation of an "historical"
  and already well identified issue Grant!
  
  Most likely I did read that post when Bill wrote it, but as you
  know things are differently digested when they affect you
  directly.
  
  Regarding the "Fox file" you are right! I had found it but it
  contains some text may be I produced myself when I tried to be the
  Fox(?).
  I think it is there just for the Fox usage and not for the Hounds.
  
  -FoxQSO.txt--
  2021-09-24 21:01:50  0.000  0  0  0 NSlots 5
  2021-09-24 21:01:50  0.000  0  0  0 Max_dB 70
  2021-09-24 21:04:30  0.000  0  0  0 NSlots 5
  2021-09-24 21:04:30  0.000  0  0  0 Max_dB 70
  2021-09-25 14:00:09  0.000  0  0  0 NSlots 5
  2021-09-25 14:00:09  0.000  0  0  0 Max_dB 70
  2021-09-26 14:02:01  0.000  0  0  0 NSlots 5
  2021-09-26 14:02:01  0.000  0  0  0 Max_dB 70
  ---
  
  The searched strings (ZV8L, 3X2021) have been collected regularly
  into ALL.TXT, it was just a little mistake on the command issued
  to extract them.
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)



  Il 19/02/22 18:51, Grant VK5GR via wsjt-devel ha scritto:


  
  
  
  
  
Folks,
 
Bill
Somerville (sk) responded to a similar question that came up
during the 3DA0RU expedition in October last year. 
 
In
summary:
 
1.   3X2021
does not fit the standard callsign pattern and so must use
the “Hash Code” call way of processing a callsign and  QSO
sequence  – where the is a coded form of the
callsign that shortens them to fit insite the number of bits
available in the FT8 protocol, and which is then that is
translated back to a full call by the receiving station once
the receiving station sees a particular sequence
transmitted.
 
2.   Back
in October, Bill reported that the developers had identified
a bug with WSJT where  if you use it in FOX mode and are
running a non standard callsign that the sequencing will
fail. I can’t find reference so far that they released a fox
for that issue?
 
So
this leaves the expedition with the problem what software to
use where they want to run multi-stream to improve
efficiency and QSO rate. This leads to the use of
MSHV/WSJT-Z use. 
 
As
for how to ID exactly what mode they are running, you used
to be able to tell when you at least knew the dial frequency
the expedition station was on and could see their
transmissions above 1000Hz on the waterfall – then it isn’t
Fox Mode but MHSV multi-stream. Now however some of the
other WSJT “variants”  appear to place their muti-streams at
the bottom of the channel like WSJT-X fox mode so it makes
the problem harder to identify. The fact that these variants
don’t follow the full FOX protocol leads to more confusion
too.
 
There
are various solutions I suspect – but they require either a
formal agreement between all of the variant developers to
either follow the proper WSJT-X protocol for multi-stream OR
to start broadcasting free text periodically with dial freq
+ software version automatically to give the hounds half a
chance at working out what is going on.
 
Regards,
Grant
VK5GR
 
P.S.
with ALL.TXT – I am not sure in HOUND MODE, but I know in
FOX mode that ALL.TXT does not capture every string. There
is a separate FOX.TXT file I think it was called where the
FOX/Hound QSO data is written – but it doesn’t capture all
details either. (I had this issue when working through log
issues on one of my previous expeditions (A35JT Tonga)).
 
 
 

  
From: Kari Sillanmäki via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, 20 February 2022 1:14 AM
    To: Marco Calistri via wsjt-devel
Cc: Kari Sillanmäki
Subject: Re: [wsjt-devel] QSO 15 meters FT8 F/H
not logged!
  

 

  Hi Marco,

AFAIK WSJT-X records everything it hears and sends to
ALL.TXT file and there is no option to disable that.
So you should see youre QSO in ALL.TXT

P

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Il 19/02/22 18:08, Jim Brown via
  wsjt-devel ha scritto:

On
  2/19/2022 4:45 AM, Marco Calistri via wsjt-devel wrote:
  
  Very interesting! I was not aware of the
MSHV software, IMHO it's not a good behavior to use "not
standard" software expecting same results as it should work as
per the  "standard way".

  
  
  Fox/Hound mode is NOT a "standard way," it is a very special
  system for DXpeditions developed by the WSJT team, and implemented
  ONLY in WSJT-X.
  
  
  There are (at least) two other FT8 implementations, both from EU
  hams, JTDX and MSHV. Each has pluses and minuses. Many of us use
  JTDX for FT8, because it decodes more weak signals than the other
  two, but it doesn't do MS, Q65, FST4, or contest mode, so I use
  WSJT-X for those. MSHV decoding is comparable to WSJT-X, it does
  multi-stream, but without fox/hound frequency switching of the
  hound.
  
  
  I also like the faster "turn-around" after a QSO with JTDX that
  allows me to call CQ or answer/call another station. It works that
  way because it considers my mouse click to log the QSO as human
  intervention, and defaults to calling CQ after receiving RRR or
  RR73 if those are not repeated.
  
  
  73, Jim K9YC
  
  
  
  


Hu Jim,

Good to know! I use only WSJT-X than I was not aware of the working
differences among the other derivates.

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Hi again William!
  
  Please, be so kind to accept my apologies but you are extremely
  right!
  
  Using the -a switch has pemitted grep tp show the pattern
  correctly!
  
  marco@localhost:~/.local/share/WSJT-X> cat ALL.TXT |grep -a
  ZV8L|grep -a PY1ZRJ
  
  220218_150746    24.915 Tx FT8  0  0.0 1964 ZV8L PY1ZRJ GG87
  220218_150815    24.915 Tx FT8  0  0.0 1964 ZV8L PY1ZRJ GG87
  220218_150830    24.915 Rx FT8  5  0.2 1470 PY1ZRJ ZV8L +01
  220218_150845    24.915 Tx FT8  0  0.0 1964 ZV8L PY1ZRJ R+05
  220218_150900    24.915 Rx FT8  8  0.2 1470 PY1ZRJ ZV8L RRR
  220218_150915    24.915 Tx FT8  0  0.0 1964 ZV8L PY1ZRJ 73
  220218_150930    24.915 Rx FT8 10  0.2 1469 PY1ZRJ ZV8L 73
  
  And more important that the above, this one:
  
  marco@localhost:~/.local/share/WSJT-X> cat ALL.TXT |grep -a
  3X2021|grep -a PY1ZRJ|grep RR73
  
  220218_181600    21.080 Rx FT8    -12 
  0.2  754  3X2021 RR73
220218_183200    21.080 Rx FT8    -12  0.2  764
   3X2021 RR73
  
  Probably my bash history is causing that issue but it doesn't
  contains any data inside, just text.
  
  Great suggestion! Thanks again William!!!
  
  Best regards!
  
  Marco
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 19/02/22 14:01, Marco Calistri via wsjt-devel ha scritto:

Hi
  William!
  
  
  This is not a matter of UNIX command syntax, the fact is that such
  string is not present in the file.
  
  
  Thanks and regards,
  
  
  Marco, PY1ZRJ
  
  
  Il 19/02/22 13:42, William Smith ha scritto:
  
  Try -a with grep as per


https://unix.stackexchange.com/questions/335716/grep-returns-binary-file-standard-input-matches-when-trying-to-find-a-string


73, Willie N1JBJ




  
  On Feb 19, 2022, at 11:35 AM, Marco Calistri via wsjt-devel
   wrote:
  
  
  il file binario corrisponde
  

  
  
  
  
  
  ___
  
  wsjt-devel mailing list
  
  wsjt-devel@lists.sourceforge.net
  
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  



  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

Hi William!

This is not a matter of UNIX command syntax, the fact is that such 
string is not present in the file.


Thanks and regards,

Marco, PY1ZRJ

Il 19/02/22 13:42, William Smith ha scritto:

Try -a with grep as per

https://unix.stackexchange.com/questions/335716/grep-returns-binary-file-standard-input-matches-when-trying-to-find-a-string

73, Willie N1JBJ




On Feb 19, 2022, at 11:35 AM, Marco Calistri via wsjt-devel 
 wrote:


il file binario corrisponde





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

Using my default shell (/bin/bash) the suggested grep command doesn't works.

In any case I had opened the ALL.TXT file yesterday using a text editor 
and I've not found any trace of the 3X2021 data inside.


Best regards!

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

Il 19/02/22 11:12, William Smith ha scritto:
If you were using WSJT-x, the QSO and everything ever sent or decoded 
is in ALL.TXT


Logged QSOs are in the .adi(f?) file.

Please note that when using grep, the calls must be ALLCAPS (or use 
grep -i) or you will not get a result.


73, Willie N1JBJ



On Feb 19, 2022, at 7:45 AM, Marco Calistri via wsjt-devel 
 wrote:



Hi Saku!

Good command! But as I wrote, there is not any registry of the QSO in 
the ALL.TXT file simply because WSJT-X has not registered it!


Best regards,

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

**

Il 19/02/22 05:01, Saku via wsjt-devel ha scritto:

Hi I
Think you were using linux. Then open command console and:

cd ~/.local/share/WSJT-X
grep -ni HisCall ALL.TXT | grep -i YourCall

Shows qso in fast and easy way (with line numbers of ALL.TXT).
Just replace the callsigns in command.

Jim Shorney via wsjt-devel kirjoitti 19.2.2022 klo 6.57:

You should be able to find this in your all.txt file.

73

-Jim
NU0C

On Sat, 19 Feb 2022 01:46:13 -0300
Marco Calistri via wsjt-devel  
wrote:


I asked to the DX station's QSL manager if he can send me the 
details of the QSO (Time and RST) registered by the Fox station on 
his ClubLog, so hopefully I could manually include the QSO also 
into my log.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Hi Reino!
  
  Also you sent a very interesting response!...
  Sure the best way to indicate a multislot normal
  operation is the use of the ODD timeslot to indicate that they
  are NOT using FT8 DX mode. BUT, as you said, most users don’t
  know that feature of the FT8 DX mode and even less the Spmsg
  meaning. 
  I confess that I don't know what Spmsg is and I would like to
  understand it.
  
  Regarding the F/H specific management of the frequencies and
  timing, I have a better idea how it works and I know that this
  process is governed internally by the WSJT-X software.
  
  Best regards,
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 19/02/22 07:33, Reino Talarmo via wsjt-devel ha scritto:


  
  
  
  
Hi Michael, Marco and all
I know that this is not a wsjt-x development
issue at all and should not be discussed on this list, but
may I present my observations.
I got the
opportunity to work 3X2021 with my contest call ov9a. And
  as you can see at the picture I worked him in WSJTX Normal
  mode beacuse there not TX'ed any Spmsg from him at any time. And it all worked as surpposedt.
The Spmsg as such may or may  not affect to
wsjt-x normal mode auto sequencer behavior and an operator
may need manually log the QSO. 
By the was way
the TU5PCT Dxpedition was not using WSJT-X but MSHV software
in FOX Look a Like Mode and what I call a Pseudo FOX Mode. 
I would not call it as a “Pseudo FOX Mode” at
all as there is no “Hound” related frequency jumping
behavior assumed or needed. It is simply a multislot
transmission.
The Z22O team
are also using the MSHV software. In the beginning
  of the DXpedition they was TX'ing ODD (15/45) with spmsg ON
  and that made WSJT-X going bananas because people thought it
  was a FOX due to the Spmsg and then put their WSJT-X in Hound
  Mode. But when WSJT-X is in Hound Mode it will only TX ODD
  (15/45). So all the WSJT-X users were TX'ing on the same
  timeslot as Z22O. What a mess. Lately they are only TX'ing
  EVEN (00/30) as a normal FOX but sometimes they don't have
  Spmsg ON and then it ain't a FOX or Pseudo FOX. 
Sure the best way to indicate a multislot
normal operation is the use of the ODD timeslot to indicate
that they are NOT using FT8 DX mode. BUT, as you said, most
users don’t know that feature of the FT8 DX mode and even
less the Spmsg meaning. 
 I wish people
would use 4-5 minuttes looking at their screen B4 hitting
the TX and make a Spot on the DX-Cluster...
Agreed!
There could be another “protocol” for a
multislot operation, where the DX station uses audio
frequencies above say 2000 Hz and listens only below that.
That would also minimize possible intermodulation signal
above their transmission, when a TX filter is used as
normally in most SSB rigs. Even the Spmsg, could be used, if
normal FT8 supports it.
Of course this will be a new mess before
operators learn how the DX station is using split. For sure
that needs clearly stated beforehand, hi! On the other hand
most unintended interference will be above the DX station.
Well, it may not prevent wrong spottings as
spotters will report a 2k higher frequency.
My 2 cents.
73, Reino OH3mA
  
  
  
  
  
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Hi Saku!
  
  Good command! But as I wrote, there is not any registry of the QSO
  in the ALL.TXT file simply because WSJT-X has not registered it!
  
  Best regards,
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 19/02/22 05:01, Saku via wsjt-devel ha scritto:

Hi I
  
  Think you were using linux. Then open command console and:
  
  
  cd ~/.local/share/WSJT-X
  
  grep -ni HisCall ALL.TXT | grep -i YourCall
  
  
  Shows qso in fast and easy way (with line numbers of ALL.TXT).
  
  Just replace the callsigns in command.
  
  
  Jim Shorney via wsjt-devel kirjoitti 19.2.2022 klo 6.57:
  
  You should be able to find this in your
all.txt file.


73


-Jim

NU0C


On Sat, 19 Feb 2022 01:46:13 -0300

Marco Calistri via wsjt-devel
 wrote:


I asked to the DX station's QSL manager
  if he can send me the details of the QSO (Time and RST)
  registered by the Fox station on his ClubLog, so hopefully I
  could manually include the QSO also into my log.
  


___

wsjt-devel mailing list

wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel

  
  





  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Il 19/02/22 01:57, Jim Shorney via
  wsjt-devel ha scritto:
  
  No,
  
  There is not any registry of such QSO in that file!
  
  Best regards!
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  


  
You should be able to find this in your all.txt file.

73

-Jim
NU0C

On Sat, 19 Feb 2022 01:46:13 -0300
Marco Calistri via wsjt-devel  wrote:


  
I asked to the DX station's QSL manager if he can send me the details of the QSO (Time and RST) registered by the Fox station on his ClubLog, so hopefully I could manually include the QSO also into my log.

  
  






  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!

[Marco Calistri via wsjt-devel]

  
Dears,
  
  Very interesting answers, including any eventual "admonitions" 
  
  I was not aware about the fact explained by Michael, 5p1kzx
  regarding the pseudo Fox/Hound mode using a different FT8
  application.
  
  This has been the first time in my experience with WSJT-X wherein
  a QSO in F/H has not been logged!
  
  In any case the observation of Russ, KR6W is exact! 
  
  I tried three times in a row to double-click on the RR73 reply
  from the Fox station but the Tx"n" buttons on the WSJT-X were
  greyed-out and it just was restarting from the first Tx1 "CQ"
  sequence, instead to log the QSO.
  
  I asked to the DX station's QSL manager if he can send me the
  details of the QSO (Time and RST) registered by the Fox station on
  his ClubLog, so hopefully I could manually include the QSO also
  into my log.
  
  Many thanks to all for your really appreciated answers!
  
  Best regards,
  
  ---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
  Il 19/02/22 00:49, Star Light via wsjt-devel ha scritto:


  Hi Jim,

Your admonition isn’t appropriate in this case. WSJT-X actually greyed out the relevant messages so they couldn’t be selected. 

Thanks,
Russ KR6W



  
On Feb 18, 2022, at 8:29 PM, Jim Shorney via wsjt-devel  wrote:


Auto sequencing is not perfect and will fail eveyone sooner or later. In circumstances where the auto sequencing fails it is the responsibility of the operator to manually select the correct message to send, and to manually click the Log QSO button if necessary. 

73

-Jim
NU0C



  On Fri, 18 Feb 2022 22:54:04 -0300
Marco Calistri via wsjt-devel  wrote:

Hello,

Today I tried to make a QSO with the Guinea station: 3X2021 on 15 meters using F/H mode.

Despite the Fox has sent to me the RR73 message for three times, due the fact I repeated my CQ attempts because I was not getting back the log message, my WSJT-X has not logged the QSO!

Despite this weird occurrence, I verified that the Fox station has logged regularly our QSO on Clublog!

For which possible reason this fact has could happen?

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






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

  

  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.4 GA Release

[Marco Calistri via wsjt-devel]

  
Il 04/01/22 20:17, Paul Bramscher via
  wsjt-devel ha scritto:

Thanks
  Joe -- we appreciate the update.  Downloaded the source tarball
  from your Princeton site, compiled without issue on Debian 11.
  
  
  Previously I was running 2.5.3 with a Kenwood TS-590S and it did
  crash a few times.  No such problems seen yet with 2.5.4.
  
  
  73, KD0KZE / Paul
  
  
  On 1/3/22 10:54, Joe Taylor via wsjt-devel wrote:
  
  Please welcome two new members of the core
WSJT Development group: Chet Fennell, KG4IYS, and Uwe Risse,
DG2YCB.  Each brings important skills and experience to the
project, after the loss of Bill Somerville, G4WJS.


The newly constituted group has been working to redefine
standard operating procedures for new releases.  WSJT-X 2.5.4, a
bug-fix release correcting these two flaws in release 2.5.3, is
now available as a General Availability (GA) release.


Changes from v2.5.3 are:


WSJT-X: Repair a defect that caused occasional crashes when in
QSO with

stations using nonstandard callsigns.


MAP65: Correct a bug that prevented "Best-fit Delta phi"
solutions from   being displayed to the user.


Links to WSJT-X 2.5.4 installation packages for Windows and
Linux are available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html


Thanks to John Nelson, G4KLA, the installation package for macOS
will be added soon.


You can also download the packages from our SourceForge site:

https://sourceforge.net/projects/wsjt/files/

It may take a short time for the SourceForge site to be updated.


WSJT-X is licensed under the terms of Version 3 of the GNU
General Public License (GPL).  Development of this software is a
cooperative project to which many amateur radio operators have
contributed.  If you use our code, please have the courtesy to
let us know about it.  If you find bugs or make improvements to
the code, please report them to us in a timely fashion.


The authors and Copyright holders of WSJT-X request that
derivative works should not publish programs based on features
in WSJT-X before those features are made available in a General
Availability (GA) release of WSJT-X.  We will cease making
public Release Candidate (RC) pre-releases for testing and user
early access purposes if this request is ignored.


Bugs should be reported by following instructions found here in
the User Guide:


https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.4.html#_bug_reports


We hope you will enjoy using WSJT-X 2.5.4.


    -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Chet,
KG4IYS; and

    Uwe, DG3YCB.

  

Same here: 2.5.4= NO CRASH SO FAR!

Best regards!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.4 GA Release

[Marco Calistri via wsjt-devel]

  
Il 03/01/22 13:54, Joe Taylor via
  wsjt-devel ha scritto:
  

Please welcome two new members of the core
  WSJT Development group: Chet Fennell, KG4IYS, and Uwe Risse,
  DG2YCB.  Each brings important skills and experience to the
  project, after the loss of Bill Somerville, G4WJS

Thanks for the new release Joe!

A warm welcome to the new core members: Chet Fennell, KG4IYS, and
Uwe Risse, DG2YCB 

I've already compiled the 2.5.4 version for Linux and now the
aesthetic "fcl" detail on the main window is not showed anymore.

Also I'm curious to see if the seldom program crashes would be still
occurring.

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X syslog and the .WAV files issue.

[Marco Calistri via wsjt-devel]

  
Hello and happy new year 2022!

I have two request:

1- What this error I saw in the syslog means: [SYSLOG][2022-01-01
  23:55:44.398661][01:12:40.285677][warning] Detected dropped audio
  source samples: 472 (0.009834 S)

2- Why you, dears developers, do not include the full disabling of
the software save the so large . WAV files?

I think that not everyone is using such audio files and due their
size if you forget to empty the related folder, they tend to fill
the disk space.

IMHO you should include an user option to fully disable such audio
files creation.

Las but not least: from time to time I noticed WSJT-X closes
suddenly without any apparent reason, then I need to restart it.

Many thanks for your kindest attention and good DX!


---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Question about compiling the WSJT-X source for Linux

[Marco Calistri via wsjt-devel]

Il 24/12/21 16:30, Chester Fennell ha scritto:


Short answer is no. Same as before.

73,

Chet

Chet Fennell

KG4IYS

Islandwalk

Venice, FL

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
Windows


*From: *Marco Calistri via wsjt-devel 
<mailto:wsjt-devel@lists.sourceforge.net>

*Sent: *Friday, December 24, 2021 2:28 PM
*To: *'WSJT software development' 
<mailto:wsjt-devel@lists.sourceforge.net>

*Cc: *Marco Calistri <mailto:py1...@outlook.com>
*Subject: *[wsjt-devel] Question about compiling the WSJT-X source for 
Linux


Hello,

Just to clarify one doubt that raised here in my mind: are there any 
differences in the steps/requirements to follow in order to compile 
the WSJT-X tar-ball for Linux in respect to the previous releases, 
from 2.5.2 back?


Thanks and Merry X-Mas to everybody!

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


Hello and Merry Christmas to everyone!

I had to compile WSJT-X from source due a libboost error was impeding 
version 2.5.2 to start.
This could happens since I'm using openSUSE Tumbleweed, which is a 
rolling constantly updating Linux distribution and I see that the new 
2.5.3 source is not the "pure raw" WSJTX source code, whereas it is a 
customized "Linux packager" version which I have used also in the past 
as specific RPM package:




I would like to know if sometime in the future we will get again the 
"raw pure" WSJT-X source code, I'm not worry about the FCL source, I'm 
sure it just a cosmetic detail the "FCL"  but I'd prefer to have the 
genuine previous version without any kind of customization.


I hope to have been clear enough.

Thanks and regards!

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


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Question about compiling the WSJT-X source for Linux

[Marco Calistri via wsjt-devel]

Il 24/12/21 16:30, Chester Fennell ha scritto:


Short answer is no. Same as before.

73,

Chet

Chet Fennell

KG4IYS

Islandwalk

Venice, FL

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
Windows


*From: *Marco Calistri via wsjt-devel 
<mailto:wsjt-devel@lists.sourceforge.net>

*Sent: *Friday, December 24, 2021 2:28 PM
*To: *'WSJT software development' 
<mailto:wsjt-devel@lists.sourceforge.net>

*Cc: *Marco Calistri <mailto:py1...@outlook.com>
*Subject: *[wsjt-devel] Question about compiling the WSJT-X source for 
Linux


Hello,

Just to clarify one doubt that raised here in my mind: are there any 
differences in the steps/requirements to follow in order to compile 
the WSJT-X tar-ball for Linux in respect to the previous releases, 
from 2.5.2 back?


Thanks and Merry X-Mas to everybody!

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


Good to know!

Tks and Season's Greetings!

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


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Question about compiling the WSJT-X source for Linux

[Marco Calistri via wsjt-devel]

  
Hello,

Just to clarify one doubt that raised here in my mind: are there any
differences in the steps/requirements to follow in order to compile
the WSJT-X tar-ball for Linux in respect to the previous releases,
from 2.5.2 back?

Thanks and Merry X-Mas to everybody!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.3 GA Release for Linux

[Marco Calistri via wsjt-devel]

  
Il 15/12/21 15:49, Joe Taylor via
  wsjt-devel ha scritto:

Thanks
  to Chet Fennell, KG4IYS, installation packages for WSJT-X 2.5.3 on
  Debian-based (Debian, Ubuntu 20.04 LTS, ...) and Fedora-based
  (Fedora 34, RedHat, ...) flavors of Linux have been posted on the
  WSJT-X web page:
  
  https://physics.princeton.edu//pulsar/k1jt/wsjtx.html
  
  
  Versions installable with "apt-get" and "yum" will be made
  available when our package maintainers create the packages.
  
  
  Note: these packages are unlikely to install properly on Linux
  distributions with required dependencies at lower versions than
  those on the named distributions.  In such cases building from
  source is the correct way to install WSJT-X.
  
  
  Many thanks to Chet Fennell, KG4IYS, for building the .deb and
  .rpm packages.  We also thank Dave Slotter, W3DJS, for comparable
  parallel effort.
  
  
  For those who like to build their own, we hope to have the
  standard WSJT-X tarball (source code and other required resources)
  available soon.
  
  
    -- 73 from Joe, K1JT; Steve, K9AN; and Nico, IV3NWV
  
  
  
  ___
  
  wsjt-devel mailing list
  
  wsjt-devel@lists.sourceforge.net
  
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  

Hello,

When new release for Linux as source tar.gz will also be available?

Thanks and regards,

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Slower commands execution by Hamlib

[Marco Calistri via wsjt-devel]

  
Hello,

I don't know if it's just a local perception but along time I
noticed that hamlib is getting slower and slower in terms of command
execution sent to to my RIG.

Now, when I switch VFO to other band, the RIG has a pretty
noticeable delay before it sets to the newer frequency.

Also I see glitches on TX switch, especially at the first
transmission attempt after the QSY this normally end up into a TX
failure (NO PTT switch, NO RF out).

These issues were not present at all in the previous (older) Hamlib
versions.

I can see well the differences (BEFORE, NOW) since I have not
changed anything from my setup: same radio, same cabling, same ports
speed.


Thanks and regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.3 GA Release (Win64 only)

[Marco Calistri via wsjt-devel]

  
Il 08/12/21 15:25, Joe Taylor via
  wsjt-devel ha scritto:

Dear
  WSJT-X Users:
  
  
  As most of you know, we are mourning the recent death of our
  friend and colleague Bill Somerville, G4WJS, who since 2013 has
  contributed so much to the WSJT project.
  
  
  One of Bill's many WSJT-related tasks was creating installation
  packages for Win32, Win64, Linux (Debian, Fedora, Raspberry Pi,
  ...), and macOS for each new program release.  At present we have
  a straightforward system for building the Win64 package -- the
  best choice for the majority of WSJT-X users -- but no systems in
  place for building Win32, Linux, and macOS packages.
  
  
  WSJT-X 2.5.3 includes a feature of special interest to users who
  will enter the ARRL January VHF Contest (January 15-17, 2022). 
  For benefit of those users, we have decided to release WSJT-X
  version 2.5.3 for Win64 even though we have not yet made prebuilt
  packages for the other operating systems.
  
  
  Differences between WSJT-X 2.5.2 and 2.5.3 are minimal and
  described in the Release Notes:
  
  https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt
  
  
  The new feature for the ARRL VHF contests is an enhanced macro
  facility for Tx messages, aimed at making it easier to ask another
  station to QSY to a new band.  The feature is described briefly
  here in the User Guide:
  
https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.3.html#TXMACROS
  
  Additional information will likely appear on VHF-contest-related
  forums.
  
  
  A link for the Win64 installation package for WSJT-X 2.5.3 is now
  available on the WSJT-X web page:
  
  https://physics.princeton.edu//pulsar/k1jt/wsjtx.html
  
  
  Pre-built packages for Win32, Linux, and macOS will be added when
  we have created new means for creating them.
  
  
   -- 73 from Joe, K1JT; Steve, K9AN; and Nico, IV3NWV
  
  
  
  ___
  
  wsjt-devel mailing list
  
  wsjt-devel@lists.sourceforge.net
  
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  


As noted previously by other colleagues, for Linux just by having
the source tar ball would be quite enough in order to have the
chance to keep our WSJT-X updated.

Thanks and once again my sincere and friendly "goodbye" to Bill.

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bill Somerville, G4WJS, SK

[Marco Calistri via wsjt-devel]

  
Il 04/12/21 15:24, Joe Taylor via
  wsjt-devel ha scritto:

I am
  very sorry to convey the sad news that Bill Somerville, G4WJS,
  died suddenly and unexpectedly a few days ago.  He was only about
  65 years old.
  
  
  Bill was a dear friend and very close colleague, though (as is
  often the case with worldwide ham radio friendships) we had met in
  person only a few times.  In 2013 he was the first to join me in
  forming a core development group for WSJT-X, which at that time
  was at program version 0.99.  Bill has been closely involved with
  WSJT-X and related software projects ever since.
  
  
  Our free, open-source software could not have achieved its
  extensive worldwide popularity and influence in ham radio without
  Bill's essential contributions.  In addition to writing code for
  important portions of the Qt-based user interface for WSJT-X, Bill
  helped to bring the overall program structure more nearly up to
  professional standards.  Moreover, he devoted countless hours to
  program support, patiently answering user's questions on
  WSJT-related forums.
  
  
  I have only started to think about the many ways in which I will
  miss Bill -- not no mention how we all will miss his immense and
  positive impact on WSJT-X and related projects.  For more than
  eight years Bill and I communicated closely and regularly on ham
  radio topics, sometimes many times per day.  Perhaps I will be
  able to write more about it in the near future.
  
  
  Rest in peace, dear friend G4WJS.
  
  
  -- Joe, K1JT
  
  
  


My God! 

Whats terrible news is this! 

Bill helped me in many occasions with WSJT-X always with a very pure
"ham-spirit" and availability.

My very sincere condolence to all his family and friends, I will
miss him a lot despite I never had the pleasure to meet him.

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Frequent exchanges repeats on some circustances

[Marco Calistri via wsjt-devel]

Il 22/11/21 05:01, Reino Talarmo ha scritto:


Are these parameters possibly being causing this issue of many TX 
retries  or are there influencing only the RX band-pass?


Best regards!

Hi Marco,
The frequency calibration affects only to the carrier frequency i.e. 
the frequency rig is using for radio frequency generation. In effect 
it is the same as you were tuning the frequency of your synthesizer 
crystal oscillator. It has no affect to transmitter or receiver band-pass.
A very minor TX frequency change, 1 Hz, as such should not make a 
radical change into the decoding process on the interference point of 
view. Success of it may as well be due to a QSB change or the 
interfering signal stopped as that contact were luckily completed 
during those three cycles Saku mentioned. You never know! Generally a 
larger TX frequency change should be more effective.


73, Reino OH3mA


Hello Reino!

Thanks for the clarification, I doubted of my new frequency calibration 
settings because looks like the amount of TX retries has augmented after 
I made the changes.


---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Frequent exchanges repeats on some circustances

[Marco Calistri via wsjt-devel]

  
Il 21/11/21 14:57, Saku via wsjt-devel
  ha scritto:


  
  I agree with Reino!
  I have set TX 1Hz up after three retries. It is amazing how
often it helps!
If that does not make effect within few tries then just randomly
jump TX around band during every TX period so long that opponent
station receives your signal.
  Sometimes trying first to jump to opponent's TX frequency may
also help as often he/she transmits on frequency that looks free
during his/her RX period (that is the human mind...). Answering
directly on his/her TX frequency for CQ is not good idea as so
many other stations may do the same.
  
  -- 
Saku
OH1KH
  Reino Talarmo via wsjt-devel
kirjoitti 21.11.2021 klo 12.48:
  
  



  I'm noticing the occurrence depicted by the
  below print wherein you can see many attempts to end the
  QSO which doesn't close and are being repeated many
  retries despite my RST_R (-13) being fair.
  Hi Marco,
  One possible reason is a strong interference
  on your frequency and a change of your TX frequency could
  help.
  73, Reino OH3mA
   



  

Dear Saku,

To be more detailed, this kind of issue started to apperas more
frequently after I set up the frequency calibration.

My current frequency settings in WSJT-X are like these now:



Are these parameters possibly being causing this issue of many TX
retries  or are there influencing only the RX band-pass?

Best regards!


---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Frequent exchanges repeats on some circustances

[Marco Calistri via wsjt-devel]

Il 21/11/21 07:48, Reino Talarmo ha scritto:


I'm noticing the occurrence depicted by the below print wherein you 
can see many attempts to end the QSO which doesn't close and are being 
repeated many retries despite my RST_R (-13) being fair.


Hi Marco,

One possible reason is a strong interference on your frequency and a 
change of your TX frequency could help.


73, Reino OH3mA


Thanks Reino,

Effectively this is not a constant occurrence, sometime happens, 
sometime doesn't.


Regarding changing my tx frequency since I use RIG--> SPLIT, how should 
I proceed with this test?


All the best,

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Yaesu rig split problems

[Marco Calistri via wsjt-devel]

Il 04/11/21 19:49, Black Michael ha scritto:

And what rig is this?

VFOA moves just like VFOB does in split so shouldn't make any 
difference in F/H mode.


Mike W9MDB




On Thursday, November 4, 2021, 05:26:18 PM CDT, Marco Calistri via 
wsjt-devel  wrote:



Hello Mike,

My answers inline.

Il 04/11/21 09:35, Black Michael via wsjt-devel ha scritto:
I'm trying to solve rig split operation problems with Yaesu rigs and 
need some Yaesu operator help...


I need any Yaesu owners to state their rig model and whether or not 
"Rig split" works in WSJT-X or if you see flashing on the rig when 
Rig split is turned on.


So 3 questions
#1 Can you make QSOs? *Yes*
#2 Does rig operation look smooth? Should be a little activity as 
freq & mode get set on both VFOs but it I'd like to know if the 
display goes a little nuts when it's happening with Rx/Tx flickering 
or such. *Yes*



Mike W9MDB


*Additional notes: *Split works well here but lately, in order to be 
able to work some of the latest DX Expeditions, I switched this option 
to "FAKE-IT" due the fact that otherwise, when I'm into F/H mode using 
"SPLIT" my VFO moves too much off from the FOX station frequency.


As you probably may remind, I cannot use USB mode here if use hamlib 
net rigctl, just DIG-MODE in this case otherwise the TX audio mutes.





Oh, sorry Mike, I omitted the rig! It is the *YAESU FT-100*.

What I faced here is that when using F/H and split option set to 
*SPLIT*, my RX VFO was moving too much off from the FOX station TX 
frequency so that I couldn't receive his signal anymore.


It took me some failed attempts to discover this fact and when finally I 
switched split option to *FAKE-IT*, the problem has stopped.




---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Yaesu rig split problems

[Marco Calistri via wsjt-devel]

  
Hello Mike,
  
  My answers inline.
  
  Il 04/11/21 09:35, Black Michael via wsjt-devel ha scritto:


  
  

  I'm trying to solve rig
split operation problems with Yaesu rigs and need some Yaesu
operator help...
  
  
  I need any Yaesu owners to
state their rig model and whether or not "Rig split" works
in WSJT-X or if you see flashing on the rig when Rig split
is turned on.
  
  
  
  So 3 questions
  #1 Can you make QSOs? Yes
  
  #2 Does rig operation look
smooth?  Should be a little activity as freq & mode get
set on both VFOs but it I'd like to know if the display goes
a little nuts when it's happening with Rx/Tx flickering or
such. Yes
  
  
  
  Mike W9MDB
  
  
  

  

Additional notes: Split works well here but lately, in order
to be able to work some of the latest DX Expeditions, I switched
this option to "FAKE-IT" due the fact that otherwise, when I'm into
F/H mode using "SPLIT" my VFO moves too much off from the FOX
station frequency. 

As you probably may remind, I cannot use USB mode here if use hamlib
net rigctl, just DIG-MODE in this case otherwise the TX audio mutes.



---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 15:36, Bill Somerville via
  wsjt-devel ha scritto:


  
  On 20/10/2021 19:12, Marco Calistri
via wsjt-devel wrote:
  
  
Il 20/10/21 14:39, Claude Frantz
  via wsjt-devel ha scritto:

On
  10/20/21 1:09 PM, Kari Sillanmäki via wsjt-devel wrote: 
  
  I'm also using XFCE4 desktop but I get
no errors when using refspec.dat. So I believe XFCE is not
the problem. 
  
  
  The same observation here. 
  
  Best wishes, 
  Claude (DJ0OT) 
  
  

Hello Claude!

I'm using the openSUSE Tumbleweed version which is a "Rolling
Distribution" or better the overall packages are updated almost
daily.

I.E. my installed packages for the Fortran are the following:

gcc11-fortran-11.2.1+git610-1.12.x86_64
gcc10-fortran-10.3.1+git1893-2.12.x86_64
libgfortran5-11.2.1+git610-1.12.x86_64
gcc-fortran-11-4.1.x86_64

For this reason is possible that something has changed as Bill
has noticed and that reflects to have none effects for you and
Kari.

For Bill: Your patch has worked perfectly, now my WSJT-X works
like a charm using Ref Spec. 

Anyway  I have not been able to use the
Menu-->Tools-->Measure the Reference Spectrum: when I
click there nothing happens.

I suppose I should see the graph you attached me showing my
audio response.

Best regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  Hi Marco,
  thanks for the update on the patch.
  You need to stop the reference spectrum capture after a minute
or so by clicking the "Stop" button. That action saves a new
refspec.dat file.
  73
Bill
G4WJS.
  
  

Thanks to you Bill!

I will follow your instructions and I'll create a new refspec.

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 14:39, Claude Frantz via
  wsjt-devel ha scritto:

On
  10/20/21 1:09 PM, Kari Sillanmäki via wsjt-devel wrote:
  
  
  I'm also using XFCE4 desktop but I get no
errors when using refspec.dat. So I believe XFCE is not the
problem.

  
  
  The same observation here.
  
  
  Best wishes,
  
  Claude (DJ0OT)
  
  
  

Hello Claude!

I'm using the openSUSE Tumbleweed version which is a "Rolling
Distribution" or better the overall packages are updated almost
daily.

I.E. my installed packages for the Fortran are the following:

gcc11-fortran-11.2.1+git610-1.12.x86_64
gcc10-fortran-10.3.1+git1893-2.12.x86_64
libgfortran5-11.2.1+git610-1.12.x86_64
gcc-fortran-11-4.1.x86_64

For this reason is possible that something has changed as Bill has
noticed and that reflects to have none effects for you and Kari.

For Bill: Your patch has worked perfectly, now my WSJT-X works like
a charm using Ref Spec. 

Anyway  I have not been able to use the Menu-->Tools-->Measure
the Reference Spectrum: when I click there nothing happens.

I suppose I should see the graph you attached me showing my audio
response.

Best regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 13:48, Bill Somerville via
  wsjt-devel ha scritto:


  
  On 20/10/2021 17:43, Kari Sillanmäki
via wsjt-devel wrote:
  
  Hu
Marco,21 08:09, Kari Sillanmäki via wsjt-devel ha scritto: 
 


I'm using XFCE
  too and I ran WSJT-X on a Lenovo Laptop, I have not external
  screen. 

I'm using Lenovo laptop as well. 
 
  Can you say us if you use a pre-compiled WSJT-X or if you
  compiled it on your machine from source and if is the latter,
  do you set some specific parameter in the .configure command?
  


I compile WSJT-X locally from the source tarball ( not githup )
and I use no special parameters. 

Just saw that Bill has managed to get the dump too, so I believe
there will be a solution soon. 

73's de Kari, oh2gqc 
  Hi Kari and Marco,
  yes, the issue is provoked by using a recent version of the
gcc-fortran compiler. It lays out memory differently from
previous versions and that reveals a defect in our code. I have
a fix, if you want to try it a patch is attached.
  73
Bill
G4WJS.
  
  

Hello Bill,

Yes of course I want to try it and I will do it within today, I
hope.

Many thanks for your prompt solution.

Best regards!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 13:43, Kari Sillanmäki via
  wsjt-devel ha scritto:

Hu
  Marco,21 08:09, Kari Sillanmäki via wsjt-devel ha scritto:
  
  

  
  
  I'm using XFCE too and I ran WSJT-X on a
Lenovo Laptop, I have not external screen.

  
  I'm using Lenovo laptop as well.
  
  

Can you say us if you use a pre-compiled WSJT-X or if you
compiled it on your machine from source and if is the latter, do
you set some specific parameter in the .configure command?

  
  
  I compile WSJT-X locally from the source tarball ( not githup )
  and I use no special parameters.
  
  
  Just saw that Bill has managed to get the dump too, so I believe
  there will be a solution soon.
  
  
  73's de Kari, oh2gqc
  
  

Yes Kari!

I see. Thanks for your feedback!

Regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 12:46, Bill Somerville via
  wsjt-devel ha scritto:


  
  On 20/10/2021 16:39, Marco Calistri
via wsjt-devel wrote:
  
  
Il 20/10/21 01:50, jarmo ha
  scritto:


  Tue, 19 Oct 2021 15:00:21 -0300
Marco Calistri via wsjt-devel 
kirjoitti:


  
WSJT-X crashes, producing a core-dump which neither I noticed where
it saves to.

My doubt now is that same issue could happens to others colleagues
which are using WSJT-X for Linux, for this reason I would like to
have some feedback on this topic.

Because if some Linux users are not facing this issue, may be that
they are using different DE (Desktop Environment) or graphic settings
(Just guessing).

  
  Hi Marco

I have this problem also. Fedora 34 XFCE4 desktop... I have now tried
couple of times and wsjtx crashes, but after renaming or deleting
refspec.dat I can use wsjtx again.
And haven't found that "core-file", what supposed done somewhere.
Searched whole HD.

Jarmo, oh1mrr 


Good morning Jarmo!

Well, so far we are 3 Linux users affected by the same problem.

Let's see if some WSJT-X packagers for Linux would be able to
discover the root cause of this issue.

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  Hi Marco,
  I can report that I have managed to reproduce the crash. I am
working on a repair.
  73
Bill
G4WJS.
  
  

Good afternoon Bill!

Amazing, many thanks for your great support!

Best regards!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Il 20/10/21 08:09, Kari Sillanmäki via
  wsjt-devel ha scritto:

Hi Marco
  & Jarmo
  
  
  On 20.10.2021 7.50, jarmo via wsjt-devel wrote:
  
  Tue, 19 Oct 2021 15:00:21 -0300

Marco Calistri via wsjt-devel


kirjoitti:


WSJT-X crashes, producing a core-dump
  which neither I noticed where
  
  it saves to.
  
  
  My doubt now is that same issue could happens to others
  colleagues
  
  which are using WSJT-X for Linux, for this reason I would like
  to
  
  have some feedback on this topic.
  
  
  Because if some Linux users are not facing this issue, may be
  that
  
  they are using different DE (Desktop Environment) or graphic
  settings
  
  (Just guessing).
  

Hi Marco


I have this problem also. Fedora 34 XFCE4 desktop... I have now
tried

couple of times and wsjtx crashes, but after renaming or
deleting

refspec.dat I can use wsjtx again.

  
  
  I'm also using XFCE4 desktop but I get no errors when using
  refspec.dat. So I believe XFCE is not the problem.
  
  
  And haven't found that "core-file", what
supposed done somewhere.

Searched whole HD.

  
  
  You probably have "ulimit -c" set to 0.
  
  
  Try to temprarely change ulimit to unlimited ( command: ulimit -c
  unlimited ).
  
  
  You should then get the corefile in that terminal session.
  
  
  73's de Kari, oh2gqc
  
  

Hi Kari!

Ok now we are 3 affected against one not affected!

I'm using XFCE too and I ran WSJT-X on a Lenovo Laptop, I have not
external screen.

I will try to set the ulimit parameter just to see if I can get the
core-dump.

Can you say us if you use a pre-compiled WSJT-X or if you compiled
it on your machine from source and if is the latter, do you set some
specific parameter in the .configure command?

Thanks for your feedback!

Best regards!

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

Il 20/10/21 01:50, jarmo ha scritto:

Tue, 19 Oct 2021 15:00:21 -0300
Marco Calistri via wsjt-devel
kirjoitti:


WSJT-X crashes, producing a core-dump which neither I noticed where
it saves to.

My doubt now is that same issue could happens to others colleagues
which are using WSJT-X for Linux, for this reason I would like to
have some feedback on this topic.

Because if some Linux users are not facing this issue, may be that
they are using different DE (Desktop Environment) or graphic settings
(Just guessing).

Hi Marco

I have this problem also. Fedora 34 XFCE4 desktop... I have now tried
couple of times and wsjtx crashes, but after renaming or deleting
refspec.dat I can use wsjtx again.
And haven't found that "core-file", what supposed done somewhere.
Searched whole HD.

Jarmo, oh1mrr

Good morning Jarmo!

Well, so far we are 3 Linux users affected by the same problem.

Let's see if some WSJT-X packagers for Linux would be able to discover 
the root cause of this issue.


Best regards!

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

Hi Stefan,

Your feedback is pretty appreciated because in some way demonstrates that this 
is not a local issue in my environment.

I bet that there are many more cases like these around but supposedly the users 
are ignoring to have it just because they aren't using such ref spec feature.

On the other hand I bet that there are many more Windows than Linux users using 
WSJTX (guessing).

Thanks and best regards!

73's Marco PY1ZRJ

Scarica Outlook per Android<https://aka.ms/AAb9ysg>


Da: Stefan HB9TMC via wsjt-devel 
Inviato: martedì 19 ottobre 2021, 18:23
A: wsjt-devel@lists.sourceforge.net
Cc: Stefan HB9TMC
Oggetto: Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

Hi Marco & group

On 19.10.21 20:00, Marco Calistri via wsjt-devel wrote:
>
> My doubt now is that same issue could happens to others colleagues which
> are using WSJT-X for Linux, for this reason I would like to have some
> feedback on this topic.

I have the same issue and had reported it a few months ago.

There is also a bug report on debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995376


73
Stefan


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Back on the usage of Ref.Spec. for Linux systems

[Marco Calistri via wsjt-devel]

  
Hello,

As reported by previous messages, I'm facing problem whenever I have
the "refspec.dat" file saved into the WSJT-X folder and I select it
in the wide-graph.

If I rename that file or delete it, then I can use the wide-graph
with Ref Spec enabled.

I tried to see if it was a file permission issue, so I gave
"write,read,execute" permission to "refspec.dat" but this has not
changed nothing: 

WSJT-X crashes, producing a core-dump which neither I noticed where
it saves to.

My doubt now is that same issue could happens to others colleagues
which are using WSJT-X for Linux, for this reason I would like to
have some feedback on this topic.

Because if some Linux users are not facing this issue, may be that
they are using different DE (Desktop Environment) or graphic
settings (Just guessing).

I have a Windows 10 VM (Virtual Machine) wherein I installed WSJT-X
and I'm curious to check if there the Rf Spec behaves like in Linux
or not.

Thanks and regards,
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Exaggerated reports given to lower tone freqs

[Marco Calistri via wsjt-devel]

  
Il 17/10/21 19:03, Bill Somerville via
  wsjt-devel ha scritto:


  
  On 17/10/2021 21:38, Marco Calistri
via wsjt-devel wrote:
  
  
Il 17/10/21 17:31, Bill Somerville
  via wsjt-devel ha scritto:


  On 17/10/2021 21:11, Marco
Calistri via wsjt-devel wrote:
  
  
Il 17/10/21 16:52, Kevin
  McQuiggin (SFU) ha scritto:

 Hi
  Marco:
  
  
  Did you follow the steps to record a reference
spectrum first?  You have to record a minute or so of
noise in order for the program to be able to compute
gain figures which are then used to flatten frequency
response.  I am not sure what would happen if you
activated reference spectrum without recording it first.
 
  
  
  Kevin

Sent from my iPad

  On Oct 16, 2021, at 15:11, Marco Calistri via
  wsjt-devel <wsjt-devel@lists.sourceforge.net>
  wrote:
  


  
Il 16/10/21 17:30,
  Kevin McQuiggin via wsjt-devel ha scritto:


  Hi All:
  
  
  There is a pretty good article on
the why and how of reference spectrum use by Bob
KA1GT at http://www.bobatkins.com/radio/WSJTX_flatten.html.
 His site is targeted primarily at EME and
UHF-and-above users, but the information applies
to use of the reference spectrum at HF as well.
  
  
  73,
  
  
  Kevin
  
  
  

Hi Kevin,

I found this topic very interesting.

I've followed the step by step described in the
article by KA1GT but when I click on Ref Spec my
WSJT-X crashes!

I'm using WSJT-X 2.5.0 on Linux openSUSE Tumbleweed.

Regards,
  

  

Yes Kevin!

For this reason I went disappointed:

I followed the step by step from the URL you shared here
regarding how to create a reference spectrum and then I
checked that a new refspec.dat was produced inside the
folder, but it seems that something in such file is not
appreciated by WSJT-X and it keep crashing until I renamed
such file to refspec.old.

marco@localhost:~> find   ~/.local/share/WSJT-X/ -name "refspec*"  -exec ls -la {} \;
-rw-r--r-- 1 marco users 204045 16 ott 19.35 /home/marco/.local/share/WSJT-X/refspec.old


I don't know why, I know that in this way it works!


---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  Hi Marco,
  send me (g4wjs  classdesign  com) your
refspec.dat file that causes a crash please?
  73
Bill
G4WJS.
  
  

Hi Bill!

I'll do it!
---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  Hi Marco,
  your reference spectrum file works FB for me, I don't see any
issues with it. Here is the plot of it from the Equalization
Tools dialog:
  
  73
Bill
G4WJS.
  
  

Thanks Bill!

But if I let it in the folder as refspec.dat my WSJT-X crashes. I
have not the possibility to use this reference spectrum here.

---
  73 de Marco, PY1ZRJ (former IK5BCU)
  
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel