Re: [wsjt-devel] WSJT-X Bug Report

[Black Michael via wsjt-devel]

First let's install a new Hamlib -- then if that doesn't fix things we'll go to 
the debug stage...

New hamlib for installation directions

#1 Shut down WSJTX 

#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- 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 the appropriate WSJTX 
directory
C:\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
Note: If compiling on Unix-like systems please uninstall any Hamlib package you 
have before installing the new build

#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

Once installed on Linux do "ldconfig".

rigctl --version should then show a relatively recent date of the download

Mike W9MDB








On Thursday, June 13, 2024 at 04:17:00 PM CDT, James Hocut via wsjt-devel 
 wrote: 






I've been annoyed by this for a while and believe I've finally made sense of 
what's going on.  

Rig - Yaesu FTDX10
Windows 10
WSJT-X v 2.6.1  6b6d74

When the IF bandwidth on the FTDX10 is set to anything above 3000 HZ the 
problem will show up after switching modes (from FT8 to FT4 for instance) and 
then selecting either "Tune" or "Enable Tx" (with "Enable Tx" the issue is 
delayed until the rig tries to transmit). At this point a "Rig Control Error" 
message pops up with the following details:

Hamlib error:    11:newcat.c(16):newcat_get_rx_bandwidth returning (-1) 
Invalid parameter

10:newcat.c(1609):newcat_get_mode returning(-1) Invalid parameter


Hopefully this information will be of some help.

Thanks,

Jim Hocut
Wt4W





___
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 ver 2.6.1 Spurious Hound TX after band change

[Andy Durbin via wsjt-devel]

This continues to be a problem at my station and it has the potential to damage 
my equipment as the spurious TX starts before my SteppIR has changed to the new 
band.

Shouldn't WSJT-X clear out all generated messages on band change or, at a 
minimum, flag that F/H QSO attempt has ended.

73,
Andy, k3wyc


From: Andy Durbin 
Sent: Friday, February 16, 2024 8:19 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: WSJT-X ver 2.6.1 Spurious Hound TX after band change

Several times I have completed an FT8 F/H QSO on one band then changed to 
another band with Hound mode still active.  "Enable TX" is not active and no 
intended transmissions have yet been made on the newly selected band.  However, 
WSJT-X starts a new transmission to the fox that had been worked on the 
previous band.

e.g.

240216_14361524.911 Rx FT8-17  0.1  280 TO4A 4Z5KU KM71
240216_14363024.911 Rx FT8-16  0.1  665 HK4GSO 5X7O -07
240216_14363024.911 Rx FT8-17  0.1  785 I1YTO 5X7O -04
240216_14364524.912 Tx FT8  0  0.0 2262 5X7O K3WYC DM33  << QSO start 
12 m
240216_14370024.911 Rx FT8-14  0.1  665 I1YTO 5X7O -04
240216_14370024.911 Rx FT8-14  0.1  726 K3WYC 5X7O -02   << In QSO 12 m
240216_14370024.911 Rx FT8-15  0.1  785 N9LEO 5X7O +00
240216_14371524.912 Tx FT8  0  0.0  726 5X7O K3WYC R-14  << In QSO 12 m
240216_14373024.911 Rx FT8-14  0.2  666 I1YTO 5X7O -06
240216_14373024.911 Rx FT8-14  0.2  725 K3WYC 5X7O RR73  << end QSO 12 m
240216_14373024.911 Rx FT8-16  0.2  785 N9LEO 5X7O +00
240216_14374524.911 Rx FT8 22 -0.3  239 TO4A OH1MM KP01
240216_14374524.911 Rx FT8 11  0.2  593 TO4A W4EU EM55
240216_14374524.911 Rx FT8 -7  0.5  916 TO4A EA3IGU JN11
240216_14374524.911 Rx FT8 -6  0.2  543 5X7O IW4APB JN45
240216_14374524.911 Rx FT8-13  0.1  408 TO4A UT2AA KO70
240216_14374524.911 Rx FT8 11  0.2  605 5X7O K4ZYU EM84
240216_14374524.911 Rx FT8 -8  0.2  893 TO4A DB7VX JN39
240216_14374524.911 Rx FT8-13  0.1  521 TO4A DF7XE JO31
240216_14374524.911 Rx FT8-22  0.1  838 TO4A R7FG LN04
240216_14374524.911 Rx FT8-15  0.2  280 TO4A 4Z5KU KM71
240216_14380024.911 Rx FT8-17  0.2  665 I1YTO 5X7O RR73
240216_14380024.911 Rx FT8-16  0.2  725 N9LEO 5X7O RR73
240216_14380024.911 Rx FT8-16  0.2  786 IW4APB 5X7O +07
240216_14381524.911 Rx FT8 13  0.1  666 5X7O KA5ZHG EL49
240216_14381524.911 Rx FT8  3  0.2  553 5X7O K4ZYU EM84
240216_14381524.911 Rx FT8 20 -0.3  238 TO4A OH1MM KP01
240216_14381524.911 Rx FT8-11  0.2  375 TO4A DD2MON JO41
240216_14381524.911 Rx FT8 -9  0.2  893 TO4A DB7VX JN39
240216_14381524.911 Rx FT8 -9  0.2  584 TO4A YO2LBV KN05
240216_14381524.911 Rx FT8-11  0.2  543 5X7O IW4APB R-12
240216_14381524.911 Rx FT8-15  0.2  408 TO4A UT2AA KO70
240216_14381524.911 Rx FT8-10  0.5  913 TO4A EA3IGU JN11
240216_14381524.911 Rx FT8-19  0.1  837 TO4A R7FG LN04
240216_14381524.911 Rx FT8-10  0.1  521 TO4A DF7XE JO31
240216_14381524.911 Rx FT8-20  0.2  479 TO4A 4Z5KU KM71
240216_14383024.911 Rx FT8-14  0.2  665 IW4APB 5X7O +07
240216_14383024.911 Rx FT8-14  0.2  725 HI3I 5X7O RR73
240216_14383024.911 Rx FT8-14  0.2  785 OH3LMN 5X7O -05
240216_14384524.911 Rx FT8 18 -0.3  238 TO4A OH1MM KP01
240216_14384524.911 Rx FT8  3  0.2  553 5X7O K4ZYU EM84
240216_14384524.911 Rx FT8-13  0.2  374 TO4A DD2MON JO41
240216_14384524.911 Rx FT8-10  0.2  893 TO4A DB7VX JN39
240216_14384524.911 Rx FT8 -6  0.2  585 TO4A YO2LBV KN05
240216_14384524.911 Rx FT8 -7  0.2  543 5X7O IW4APB R-12
240216_14384524.911 Rx FT8-18  0.2  408 TO4A UT2AA KO70
240216_14391528.080 Tx FT8  0  0.0  426 5X7O K3WYC R-14   <<< 
uncommanded TX on 10 m
240216_14393028.080 Rx FT8  5  0.4  393 WB8FVB 5X7O -17
240216_14400028.080 Rx FT8 -5  0.4  453 N4RJ 5X7O +08
240216_14400028.080 Rx FT8 -5  0.4  393 WB8FVB 5X7O RR73

Has anyone else seen this issue?

Andy, k3wyc




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

Re: [wsjt-devel] WSJT-X v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Black Michael via wsjt-devel]

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
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


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 Wednesday, March 20, 2024 at 06:59:10 PM CDT, Scott Armstrong via wsjt-devel 
 wrote: 





Hi All,
I have encountered a problem running  2.7.0-rc4 with Hamlib version
 
This impacts an Icom IC-756ProII and IC-746. The issue is not observed when 
running a IC-9700
The problem is also observed running 2.7.0-rc3 with the new Hamlib version

The workaround is to roll back to the previous version of Hamlib





See below for the problem details. If more information/data is required I'd be 
glad to provide it.

Thanks,
Scott AA5AM

PROBLEM: 
CAT failure causes v2.7.0-rc4 to hang, requiring the process to be killed.



WSJT:



Hamlib:


Windows/PC:



Rigs impacted:

Icom IC-756ProII
Icom IC-746


PROBLEM DESCRIPTION

If CAT becomes disabled by turning the radio off or other problem that causes a 
disconnect, the WSJT CAT connection indicator remains green. It never 
transitions to amber or red.



The Rig Control Error pop-up message is not raised.



When CAT is restored by turning on the radio or resolving other errors, there 
is still no connection between the SW and the radio even though the indicator 
is still green.
WSJT-X v2.7.0-rc4 is then closed and relaunched. 

The pop-up indicating that another instance may be running is observed. 


Then it becomes necessary to go into Task Manager and kill the wsjt.exe process 
that is hung from the previous instance of the SW running.






___
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 v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Black Michael via wsjt-devel]

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
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


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 Wednesday, March 20, 2024 at 06:59:10 PM CDT, Scott Armstrong via wsjt-devel 
 wrote: 





Hi All,
I have encountered a problem running  2.7.0-rc4 with Hamlib version
 
This impacts an Icom IC-756ProII and IC-746. The issue is not observed when 
running a IC-9700
The problem is also observed running 2.7.0-rc3 with the new Hamlib version

The workaround is to roll back to the previous version of Hamlib





See below for the problem details. If more information/data is required I'd be 
glad to provide it.

Thanks,
Scott AA5AM

PROBLEM: 
CAT failure causes v2.7.0-rc4 to hang, requiring the process to be killed.



WSJT:



Hamlib:


Windows/PC:



Rigs impacted:

Icom IC-756ProII
Icom IC-746


PROBLEM DESCRIPTION

If CAT becomes disabled by turning the radio off or other problem that causes a 
disconnect, the WSJT CAT connection indicator remains green. It never 
transitions to amber or red.



The Rig Control Error pop-up message is not raised.



When CAT is restored by turning on the radio or resolving other errors, there 
is still no connection between the SW and the radio even though the indicator 
is still green.
WSJT-X v2.7.0-rc4 is then closed and relaunched. 

The pop-up indicating that another instance may be running is observed. 


Then it becomes necessary to go into Task Manager and kill the wsjt.exe process 
that is hung from the previous instance of the SW running.






___
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 v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Adrian via wsjt-devel]

Usually on click ok, the Config pane pops up on radio tab so you can 
reconfigure , so you don't see that then, ok ?


It would be interesting to confirm a program interface like FLrig, 
Commander or HRD works,


or rigctld/Hamlib interface , rather than actual radio choice.

73


vk4tux

On 21/3/24 10:25, Scott Armstrong wrote:

The Rig Control Error window is never displayed.

But to answer your question... going into the settings and doing a 
'Test CAT' does not restore the connection.


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

Re: [wsjt-devel] WSJT-X v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Scott Armstrong via wsjt-devel]

The Rig Control Error window is never displayed.

But to answer your question... going into the settings and doing a 'Test
CAT' does not restore the connection.

-Scott AA5AM

On Wed, Mar 20, 2024 at 7:11 PM Adrian  wrote:

> Re below ; If you click 'ok', and then are shown the wsjtx radio settings
> tab, does 'Test CAT' restore the cat connection ?
>
>
> 73
>
>
> vk4tux
> On 21/3/24 09:52, Scott Armstrong via wsjt-devel wrote:
>
> The Rig Control Error pop-up message is not raised.
> [image: image.png]
>
>
> When CAT is restored by turning on the radio or resolving other errors,
> there is still no connection between the SW and the radio even though the
> indicator is still green.
> WSJT-X v2.7.0-rc4 is then closed and relaunched.
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Adrian via wsjt-devel]

Re below ; If you click 'ok', and then are shown the wsjtx radio 
settings tab, does 'Test CAT' restore the cat connection ?



73


vk4tux

On 21/3/24 09:52, Scott Armstrong via wsjt-devel wrote:

The Rig Control Error pop-up message is not raised.
image.png


When CAT is restored by turning on the radio or resolving other 
errors, there is still no connection between the SW and the radio even 
though the indicator is still green.

WSJT-X v2.7.0-rc4 is then closed and relaunched.___
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-rc4

[Adrian via wsjt-devel]

It did show that many differrent linux as well as main Debian advanced 
flavours were affected.


Some source code errors may only affect a limited number of branches, 
this showed it as widespread.



73


vk4tux

On 13/3/24 00:43, Joe Taylor via wsjt-devel wrote:

Hi all,

On 3/11/2024 11:02 PM, Jim Shorney NU0C via wsjt-devel wrote:


Confirmed same error, Kubuntu 22.04 up to date as of today.

Error: Symbol ‘ncand‘ at (1) is USE associated from module ‘q65‘ and 
cannot occur in COMMON
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3: 



Multiple reports of the same issue are not really necessary, 
especially after one of us in the development group has already 
responded.


Anyway, thanks to all for your reports.

A new tarball has been posted on the WSJT web site here:
https://wsjt.sourceforge.io/wsjtx.html

... and corrected source code (tagged 'wsjtx-2.7.0-rc4a') is available 
at the SourceForge git repository for WSJT-X.


-- 73, Joe, K1JT


___
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-rc4

[Jim Shorney via wsjt-devel]

Thank you sir! Compiled and installed successfully.

73

-Jim
NU0C

On Tue, 12 Mar 2024 10:43:05 -0400
Joe Taylor via wsjt-devel  wrote:

> Multiple reports of the same issue are not really necessary, especially 
> after one of us in the development group has already responded.
> 
> Anyway, thanks to all for your reports.
> 
> A new tarball has been posted on the WSJT web site here:
> https://wsjt.sourceforge.io/wsjtx.html
> 
> ... and corrected source code (tagged 'wsjtx-2.7.0-rc4a') is available 
> at the SourceForge git repository for WSJT-X.
> 
>   -- 73, Joe, K1JT


___
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-rc4

[Joe Taylor via wsjt-devel]

Hi all,

On 3/11/2024 11:02 PM, Jim Shorney NU0C via wsjt-devel wrote:


Confirmed same error, Kubuntu 22.04 up to date as of today.

Error: Symbol ‘ncand‘ at (1) is USE associated from module ‘q65‘ and cannot 
occur in COMMON
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:


Multiple reports of the same issue are not really necessary, especially 
after one of us in the development group has already responded.


Anyway, thanks to all for your reports.

A new tarball has been posted on the WSJT web site here:
https://wsjt.sourceforge.io/wsjtx.html

... and corrected source code (tagged 'wsjtx-2.7.0-rc4a') is available 
at the SourceForge git repository for WSJT-X.


-- 73, Joe, K1JT


___
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-rc4

[Jim Shorney via wsjt-devel]

Confirmed same error, Kubuntu 22.04 up to date as of today.

Error: Symbol ‘ncand‘ at (1) is USE associated from module ‘q65‘ and cannot 
occur in COMMON
/home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:

73

-Jim
NU0C



On Tue, 12 Mar 2024 00:59:57 +
Stan Gammons via wsjt-devel  wrote:

> I'm seeing the same error on Kubuntu 22.04
> 
> uname -a
> Linux radio2 5.15.0-100-generic #110-Ubuntu SMP Wed Feb 7 13:27:48 UTC 2024 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> [ 95%] Building Fortran object 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/moon2.f90.o
> [ 95%] Building Fortran object 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/moondop.f90.o
> [ 95%] Building Fortran object 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65b.f90.o
> /home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:1:60:
> 
> 1 | subroutine q65b(nutc,nqd,fcenter,nfcal,nfsample,ikhz,mousedf,ntol, &
> | 1
> Warning: Unused dummy argument ‘mousedf’ at (1) [-Wunused-dummy-argument]
> /home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:3:70:
> 
> 3 | newdat,nagain,bClickDecode,max_drift,offset,ndepth,datetime,nCFOM, &
> | 1
> Warning: Unused dummy argument ‘ncfom’ at (1) [-Wunused-dummy-argument]
> /home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:1:47:
> 
> 1 | subroutine q65b(nutc,nqd,fcenter,nfcal,nfsample,ikhz,mousedf,ntol, &
> | 1
> Warning: Unused dummy argument ‘nfsample’ at (1) [-Wunused-dummy-argument]
> [ 96%] Building Fortran object 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o
> /home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:
> 
> 24 | common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy, &
> | 1
> Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and cannot 
> occur in COMMON
> /home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:
> 
> 93 | 999 return
> | 1
> Warning: Label 999 at (1) defined but not used [-Wunused-label]
> make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
> make[4]: *** [CMakeFiles/Makefile2:2157: 
> qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
> make[3]: *** [Makefile:156: all] Error 2
> make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
> wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
> make[1]: *** [CMakeFiles/Makefile2:279: CMakeFiles/wsjtx-build.dir/all] Error 
> 2
> make: *** [Makefile:91: all] Error 2
> 
> 73
> 
> Stan
> KM4HQE
> 
> On 3/11/24 13:24, Kari Sillanmäki via wsjt-devel wrote:
> 
> > Hi Josh,
> >
> > I got the same error on my Linux Mint 21,1
> > ( Linux abc 5.15.0-97-generic #107-Ubuntu SMP Wed Feb 7 13:26:48 UTC 2024 
> > x86_64 x86_64 x86_64 GNU/Linux )
> >
> > but on my Raspberry 5 running Debian GNU/Linux 12 (bookworm)
> > ( Linux cde 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 
> > (2024-01-25) aarch64 GNU/Linux )
> >
> > the build succeeded.
> >
> > Something different between Fortran compilers, I guess.
> >
> > 73's de Kari, oh2gqc
> >
> > On 3/11/24 19:26, Josh Rovero via wsjt-devel wrote:
> >  
> >> On Fedora Core 39, 64 bit, (uname -a
> >> Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 
> >> 16:53:59 UTC 2024 x86_64 GNU/Linux, gcc version 13.2.1 20231205 (Red Hat 
> >> 13.2.1-6) (GCC))
> >> I get the following errors building RC4:
> >>
> >> [ 94%] Building Fortran object 
> >> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o
> >> /home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:
> >>
> >> 24 | common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy, &
> >> | 1
> >> Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and 
> >> cannot occur in COMMON
> >> /home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:
> >>
> >> 93 | 999 return
> >> | 1
> >> Warning: Label 999 at (1) defined but not used [-Wunused-label]
> >> make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
> >> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
> >> make[4]: *** [CMakeFiles/Makefile2:2157: 
> >> qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
> >> make[3]: *** [Makefile:156: all] Error 2
> >> make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
> >> wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
> >> make[1]: *** [CMakeFiles/Makefile2:279: CMakeFiles/wsjtx-build.dir/all] 
> >> Error 2
> >> make: *** [Makefile:91: all] Error 2
> >>
> >> --
> >>
> >> P.J. "Josh" Rovero http://www.roveroresearch.org
> >> Ham Radio: KK1D
> >>
> >> ___
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >>
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-deve  



-- 

73

-Jim
NU0C


___
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-rc4

[Stan Gammons via wsjt-devel]

I'm seeing the same error on Kubuntu 22.04

uname -a
Linux radio2 5.15.0-100-generic #110-Ubuntu SMP Wed Feb 7 13:27:48 UTC 2024 
x86_64 x86_64 x86_64 GNU/Linux

[ 95%] Building Fortran object qmap/libqmap/CMakeFiles/qmap_impl.dir/moon2.f90.o
[ 95%] Building Fortran object 
qmap/libqmap/CMakeFiles/qmap_impl.dir/moondop.f90.o
[ 95%] Building Fortran object qmap/libqmap/CMakeFiles/qmap_impl.dir/q65b.f90.o
/home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:1:60:

1 | subroutine q65b(nutc,nqd,fcenter,nfcal,nfsample,ikhz,mousedf,ntol, &
| 1
Warning: Unused dummy argument ‘mousedf’ at (1) [-Wunused-dummy-argument]
/home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:3:70:

3 | newdat,nagain,bClickDecode,max_drift,offset,ndepth,datetime,nCFOM, &
| 1
Warning: Unused dummy argument ‘ncfom’ at (1) [-Wunused-dummy-argument]
/home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65b.f90:1:47:

1 | subroutine q65b(nutc,nqd,fcenter,nfcal,nfsample,ikhz,mousedf,ntol, &
| 1
Warning: Unused dummy argument ‘nfsample’ at (1) [-Wunused-dummy-argument]
[ 96%] Building Fortran object qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o
/home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:

24 | common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy, &
| 1
Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and cannot 
occur in COMMON
/home/stan/wsjtx274/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:

93 | 999 return
| 1
Warning: Label 999 at (1) defined but not used [-Wunused-label]
make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
make[4]: *** [CMakeFiles/Makefile2:2157: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
make[3]: *** [Makefile:156: all] Error 2
make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:279: CMakeFiles/wsjtx-build.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

73

Stan
KM4HQE

On 3/11/24 13:24, Kari Sillanmäki via wsjt-devel wrote:

> Hi Josh,
>
> I got the same error on my Linux Mint 21,1
> ( Linux abc 5.15.0-97-generic #107-Ubuntu SMP Wed Feb 7 13:26:48 UTC 2024 
> x86_64 x86_64 x86_64 GNU/Linux )
>
> but on my Raspberry 5 running Debian GNU/Linux 12 (bookworm)
> ( Linux cde 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 
> (2024-01-25) aarch64 GNU/Linux )
>
> the build succeeded.
>
> Something different between Fortran compilers, I guess.
>
> 73's de Kari, oh2gqc
>
> On 3/11/24 19:26, Josh Rovero via wsjt-devel wrote:
>
>> On Fedora Core 39, 64 bit, (uname -a
>> Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 16:53:59 
>> UTC 2024 x86_64 GNU/Linux, gcc version 13.2.1 20231205 (Red Hat 13.2.1-6) 
>> (GCC))
>> I get the following errors building RC4:
>>
>> [ 94%] Building Fortran object 
>> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o
>> /home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:
>>
>> 24 | common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy, &
>> | 1
>> Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and cannot 
>> occur in COMMON
>> /home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:
>>
>> 93 | 999 return
>> | 1
>> Warning: Label 999 at (1) defined but not used [-Wunused-label]
>> make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
>> qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
>> make[4]: *** [CMakeFiles/Makefile2:2157: 
>> qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2
>> make[3]: *** [Makefile:156: all] Error 2
>> make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
>> wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
>> make[1]: *** [CMakeFiles/Makefile2:279: CMakeFiles/wsjtx-build.dir/all] 
>> Error 2
>> make: *** [Makefile:91: all] Error 2
>>
>> --
>>
>> P.J. "Josh" Rovero http://www.roveroresearch.org
>> Ham Radio: KK1D
>>
>> ___
>> 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-rc4

[Joe Taylor via wsjt-devel]

Hi Josh,

We're aware of the problem you report, but haven't yet got around to 
correcting it.  It does not affect builds on any of the systems we're 
using for development.  Compiler revisions are getting increasingly 
fussy about such things.


You can do one of the following:

1. Wait for the next release.

2. Let me know that you'd like a source-code patch, and I'll make it 
available after making the necessary changes.


3. Make the necessary changes yourself, to satisfy your compiler.

-- Joe, K1JT

On 3/11/2024 1:26 PM, Josh Rovero via wsjt-devel wrote:

On Fedora Core 39, 64 bit, (uname -a
Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar  1 
16:53:59 UTC 2024 x86_64 GNU/Linux, gcc version 13.2.1 20231205 (Red Hat 
13.2.1-6) (GCC))

I get the following errors building RC4:

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

/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:

    24 |   common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy,   
            &

       |                                1
Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and 
cannot occur in COMMON

/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:

    93 | 999 return
       |   1
Warning: Label 999 at (1) defined but not used [-Wunused-label]
make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
make[4]: *** [CMakeFiles/Makefile2:2157: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2

make[3]: *** [Makefile:156: all] Error 2
make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:279: CMakeFiles/wsjtx-build.dir/all] 
Error 2

make: *** [Makefile:91: all] Error 2

--
P.J. "Josh" Rovero http://www.roveroresearch.org 


Ham Radio: KK1D


___
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-rc4

[Kari Sillanmäki via wsjt-devel]

Hi Josh,

I got the same error on my Linux Mint 21,1
( Linux abc 5.15.0-97-generic #107-Ubuntu SMP Wed Feb 7 13:26:48 UTC 2024 
x86_64 x86_64 x86_64 GNU/Linux )

but on my Raspberry 5 running Debian GNU/Linux 12 (bookworm)
( Linux cde 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 
(2024-01-25) aarch64 GNU/Linux )

the build succeeded.

Something different between Fortran compilers, I guess.

73's de Kari, oh2gqc

On 3/11/24 19:26, Josh Rovero via wsjt-devel wrote:

On Fedora Core 39, 64 bit, (uname -a
Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar  1 
16:53:59 UTC 2024 x86_64 GNU/Linux, gcc version 13.2.1 20231205 (Red 
Hat 13.2.1-6) (GCC))

I get the following errors building RC4:

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

/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:24:32:

   24 | common/decodes/ndecodes,ncand,nQDecoderDone,nWDecoderBusy,     
     &

      |                                1
Error: Symbol ‘ncand’ at (1) is USE associated from module ‘q65’ and 
cannot occur in COMMON

/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:93:3:

   93 | 999 return
      |   1
Warning: Label 999 at (1) defined but not used [-Wunused-label]
make[5]: *** [qmap/libqmap/CMakeFiles/qmap_impl.dir/build.make:323: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/q65c.f90.o] Error 1
make[4]: *** [CMakeFiles/Makefile2:2157: 
qmap/libqmap/CMakeFiles/qmap_impl.dir/all] Error 2

make[3]: *** [Makefile:156: all] Error 2
make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:279: 
CMakeFiles/wsjtx-build.dir/all] Error 2

make: *** [Makefile:91: all] Error 2

--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D


___
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 2.7.0 rc3 apparent holes in transmission

[Nic Sears via wsjt-devel]

I will have a look at that later on. Thank you Morris, 73’s Nic

On 30 Jan 2024, at 15:52, Morris Wideman via wsjt-devel 
 wrote:

Hi Nick
Another thing you could check is USB Power management this is found under each 
USB service in Device manager open properties and
uncheck the high lighted line. This has been know to cause USB issues. You may 
find more than one of these to check. 
73 Morris WA4MIT
On Tuesday, January 30, 2024 at 06:28:22 AM CST, Nic Sears via wsjt-devel 
 wrote:


Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 

This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.

Be grateful if you could consider my observation and advise if there is a real 
problem.

Thank you, Nic 





___
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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[Nic Sears via wsjt-devel]

Hi Willie,

Yes the 9700 has that function but when I did that the problem didn’t happen. 
It does seem quite random and intermittent. I suspected it might have been rfi  
as when I moved the 432 MHz ant in the roof the problem seemed to go away. But 
i have seen it back again and I haven’t altered anything.

I suspect something to do with the usb as another has reply has suggested.

Thanks, Nic 

On 30 Jan 2024, at 12:32, William Smith via wsjt-devel 
 wrote:

Is there a monitor function on your rig that you can use to listen to the Tx 
audio?  Then you’d at least know which side of the audio/RF divide to look at…

73, Willie N1JBJ


> On Jan 30, 2024, at 7:25 AM, Nic Sears via wsjt-devel 
>  wrote:
> 
> Hi there, Nic G3YEG here.
> 
> I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
> q65-60b on 432 eme and have never consciously notice the power output of any 
> of my previous rigs varying during ft8 or q65 tx cycles.
> 
> Recently I Started using a new laptop with much higher spec than old machine  
> and also changed over to rc3. I then noted that the alc on my ic9700 had 
> started spiking on the tx cycle.
> 
> This seems to be completely random and does not appear to effect the decoding 
> of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
> set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
> occurs on the ts2000 i use for hf.
> 
> I have investigated and it seems that the transmission does have “holes” in 
> it when you actually listen to it.
> 
> It is not consistent as sometimes the tx cycle is completely clean and 
> sometimes has a number of holes.
> 
> I have reverted back to 2.6.1 and that also exhibits the same problem but it 
> does seem to be to a lesser extent. However Not done that many tests on 2.6.1
> 
> I always run with nil or very low alc on both my rigs so the recent spiking 
> has been quite obvious. The tx power output on both the rigs doesn’t seem to 
> dip that but the 9700 current drain certainly drops on the rig metering.
> 
> The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb 
> memory driving the 9700 via a single usb interface. The new machine is an 
> intel i7 running Windows 11 with 32Gb memory again driving the 9700 via a 
> single usb interface. The ts2000 is driven from the new machine via a usb to 
> rs232 dongle for cat control and a usb to analogue dongle for the audio 
> interface. The icom Ic-9700 usb driver was in use on both old and new 
> machines.
> 
> I mentioned this observation to another local eme operator who has also noted 
> these “holes” but also observed that it doesn’t seem to cause any remote 
> station decoding problems.
> 
> Be grateful if you could consider my observation and advise if there is a 
> real problem.
> 
> Thank you, Nic
> 
> 
> 
> 
> 
> ___
> 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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[Nic Sears via wsjt-devel]

Hi David,

Interesting that you have seen this for a long time.

My old Lenovo laptop didn’t show any signs of this happening driving the 9700 
via usb and my old Sony laptop using just audio from the speaker also did not 
show any signs of this happening when driving the ts2000.

This was on 2.6.1 and previous versions.

Nic



On 30 Jan 2024, at 15:34, David Hilton-Jones via wsjt-devel 
 wrote:

I don’t think that it is always a USB problem.
 
I have been aware of very brief “holes” in the audio output for many 
years/versions. In fact, more often than not I see a brief dropout – shown by 
the RF output power dropping (with ALC glitch) and drop out of audio on monitor.
 
But my audio in/out is not via USB, but through the mic/phones connections on 
the computer.
 
I’ve always assumed that it’s due to a problem with audio “streaming” in the 
computer/soundcard – and ignored it!

David, G4YTL
 
From: Nic Sears via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 January 2024 14:11
To: WSJT software development
Cc: Nic Sears
Subject: Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission
 
Thanks Neil, suspected that but audio stream on other output seemed ok. Cannot 
check usb stream, will try and find an update. Amazed an eme QSO works ok with 
holes!!
 
Nic
 
On 30 Jan 2024 13:03, Neil via wsjt-devel  
wrote:
Hi Nic, I had this problem with random gaps of about 2 seconds in transmission 
audio with an earlier release.  It was nothing to do with wsjt-x, the root 
problem was a buggy USB 3.0 driver for the internal card in the machine 
(i7/32GB/Win10).  I updated the driver and that fixed it.  It took a long time 
to diagnose!
-- 
Neil G4DBN
https://youtube.com/MachiningandMicrowaves
 
On 30/01/2024 12:20, Nic Sears via wsjt-devel wrote:
Hi there, Nic G3YEG here.
 
I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.
 
Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 
 
This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.
 
I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.
 
It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.
 
I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1
 
I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.
 
The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.
 
I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.
 
Be grateful if you could consider my observation and advise if there is a real 
problem.
 
Thank you, Nic 
 
 
 
 
___
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 2.7.0 rc3 apparent holes in transmission

[Morris Wideman via wsjt-devel]

 Hi Nick
Another thing you could check is USB Power management this is found under each 
USB service in Device manager open properties and
uncheck the high lighted line. This has been know to cause USB issues. You may 
find more than one of these to check. 
73 Morris WA4MIT On Tuesday, January 30, 2024 at 06:28:22 AM CST, Nic Sears 
via wsjt-devel  wrote:  
 
 Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 

This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.

Be grateful if you could consider my observation and advise if there is a real 
problem.

Thank you, Nic 





___
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 2.7.0 rc3 apparent holes in transmission

[David Hilton-Jones via wsjt-devel]

I don’t think that it is always a USB problem.

 

I have been aware of very brief “holes” in the audio output for many 
years/versions. In fact, more often than not I see a brief dropout – shown by 
the RF output power dropping (with ALC glitch) and drop out of audio on monitor.

 

But my audio in/out is not via USB, but through the mic/phones connections on 
the computer.

 

I’ve always assumed that it’s due to a problem with audio “streaming” in the 
computer/soundcard – and ignored it!

David, G4YTL

 

From: Nic Sears via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 January 2024 14:11
To: WSJT software development
Cc: Nic Sears
Subject: Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

 

Thanks Neil, suspected that but audio stream on other output seemed ok. Cannot 
check usb stream, will try and find an update. Amazed an eme QSO works ok with 
holes!!

 

Nic

 

On 30 Jan 2024 13:03, Neil via wsjt-devel  
wrote:

Hi Nic, I had this problem with random gaps of about 2 seconds in transmission 
audio with an earlier release.  It was nothing to do with wsjt-x, the root 
problem was a buggy USB 3.0 driver for the internal card in the machine 
(i7/32GB/Win10).  I updated the driver and that fixed it.  It took a long time 
to diagnose!

-- 
Neil G4DBN
https://youtube.com/MachiningandMicrowaves

 

On 30/01/2024 12:20, Nic Sears via wsjt-devel wrote:

Hi there, Nic G3YEG here.
 
I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.
 
Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 
 
This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.
 
I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.
 
It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.
 
I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1
 
I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.
 
The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.
 
I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.
 
Be grateful if you could consider my observation and advise if there is a real 
problem.
 
Thank you, Nic 
 

 

 

 

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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[William Smith via wsjt-devel]

Is there a monitor function on your rig that you can use to listen to the Tx 
audio?  Then you’d at least know which side of the audio/RF divide to look at…

73, Willie N1JBJ


> On Jan 30, 2024, at 7:25 AM, Nic Sears via wsjt-devel 
>  wrote:
> 
> Hi there, Nic G3YEG here.
> 
> I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
> q65-60b on 432 eme and have never consciously notice the power output of any 
> of my previous rigs varying during ft8 or q65 tx cycles.
> 
> Recently I Started using a new laptop with much higher spec than old machine  
> and also changed over to rc3. I then noted that the alc on my ic9700 had 
> started spiking on the tx cycle.
> 
> This seems to be completely random and does not appear to effect the decoding 
> of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
> set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
> occurs on the ts2000 i use for hf.
> 
> I have investigated and it seems that the transmission does have “holes” in 
> it when you actually listen to it.
> 
> It is not consistent as sometimes the tx cycle is completely clean and 
> sometimes has a number of holes.
> 
> I have reverted back to 2.6.1 and that also exhibits the same problem but it 
> does seem to be to a lesser extent. However Not done that many tests on 2.6.1
> 
> I always run with nil or very low alc on both my rigs so the recent spiking 
> has been quite obvious. The tx power output on both the rigs doesn’t seem to 
> dip that but the 9700 current drain certainly drops on the rig metering.
> 
> The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb 
> memory driving the 9700 via a single usb interface. The new machine is an 
> intel i7 running Windows 11 with 32Gb memory again driving the 9700 via a 
> single usb interface. The ts2000 is driven from the new machine via a usb to 
> rs232 dongle for cat control and a usb to analogue dongle for the audio 
> interface. The icom Ic-9700 usb driver was in use on both old and new 
> machines.
> 
> I mentioned this observation to another local eme operator who has also noted 
> these “holes” but also observed that it doesn’t seem to cause any remote 
> station decoding problems.
> 
> Be grateful if you could consider my observation and advise if there is a 
> real problem.
> 
> Thank you, Nic
> 
> 
> 
> 
> 
> ___
> 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 2.7.0 rc3 apparent holes in transmission

[Nic Sears via wsjt-devel]

Thanks Neil, suspected that but audio stream on other output seemed ok. Cannot check usb stream, will try and find an update. Amazed an eme QSO works ok with holes!!NicOn 30 Jan 2024 13:03, Neil via wsjt-devel  wrote:

Hi Nic, I had this problem with random
  gaps of about 2 seconds in transmission audio with an earlier
  release.  It was nothing to do with wsjt-x, the root problem was a
  buggy USB 3.0 driver for the internal card in the machine
  (i7/32GB/Win10).  I updated the driver and that fixed it.  It took
  a long time to diagnose!

-- 
  Neil G4DBN
  https://youtube.com/MachiningandMicrowaves


On 30/01/2024 12:20, Nic Sears via
  wsjt-devel wrote:


  Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and q65-60b on 432 eme and have never consciously notice the power output of any of my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  and also changed over to rc3. I then noted that the alc on my ic9700 had started spiking on the tx cycle. 

This seems to be completely random and does not appear to effect the decoding of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has been quite obvious. The tx power output on both the rigs doesn’t seem to dip that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory driving the 9700 via a single usb interface. The new machine is an intel i7 running Windows 11 with 32Gb memory again driving the 9700 via a single usb interface. The ts2000 is driven from the new machine via a usb to rs232 dongle for cat control and a usb to analogue dongle for the audio interface. The icom Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted these “holes” but also observed that it doesn’t seem to cause any remote station decoding problems.

Be grateful if you could consider my observation and advise if there is a real problem.

Thank you, Nic 






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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[Neil via wsjt-devel]

Hi Nic, I had this problem with random gaps of about 2 seconds in 
transmission audio with an earlier release.  It was nothing to do with 
wsjt-x, the root problem was a buggy USB 3.0 driver for the internal 
card in the machine (i7/32GB/Win10).  I updated the driver and that 
fixed it.  It took a long time to diagnose!

--
Neil G4DBN
https://youtube.com/MachiningandMicrowaves

On 30/01/2024 12:20, Nic Sears via wsjt-devel wrote:

Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle.

This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.

Be grateful if you could consider my observation and advise if there is a real 
problem.

Thank you, Nic



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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[Black Michael via wsjt-devel]

If the new machine is a Dell look for "WAV" services in the services manager 
and disable them.

Mike W9MDB








On Tuesday, January 30, 2024 at 06:28:24 AM CST, Nic Sears via wsjt-devel 
 wrote: 





Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 

This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.

Be grateful if you could consider my observation and advise if there is a real 
problem.

Thank you, Nic 





___
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-devel Digest, Vol 119, Issue 46

[Uwe, DG2YCB via wsjt-devel]

The "240202" code will be released on February 2, 2024.

73 de DG2YCB,
Uwe

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


Am 27.01.2024 um 14:43 schrieb Black Michael:

I don't see the 240202 update at your "find it here" link.

It points 
tohttps://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/

Mike W9MDB








On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via 
wsjt-devel  wrote:





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, I have now 
added another line of code as a test for my upcoming 'improved' 2.7.1-devel 
"240202" update, which has the effect that if you are in FT8 Hound mode, all 
messages (below 1000 Hz) are really displayed in the right window if they contain your 
own callsign.

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on when you are 
in FT8 Hound mode, because this confuses many OMs and makes little sense, at least from 
my point of view. Tell me if there is any good reason why this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:





"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Black Michael via wsjt-devel]

I don't see the 240202 update at your "find it here" link.

It points to 
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/

Mike W9MDB








On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, 
I have now added another line of code as a test for my upcoming 'improved' 
2.7.1-devel "240202" update, which has the effect that if you are in FT8 Hound 
mode, all messages (below 1000 Hz) are really displayed in the right window if 
they contain your own callsign. 

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on 
when you are in FT8 Hound mode, because this confuses many OMs and makes little 
sense, at least from my point of view. Tell me if there is any good reason why 
this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:


>  

"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.   



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Uwe, DG2YCB via wsjt-devel]

Yes, but then we also have to remove the <> characters, because
otherwise it won't work for compound callsigns. But the following code
should do the job. Will be included in "240202".

...
&().replace("<","").replace(">","").contains(""+m_baseCall+"")
...

73 de DG2YCB,
Uwe

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


Am 27.01.2024 um 14:10 schrieb Black Michael:

Should be able to use this instead.  Your call always has a space before/after.

contains(" " + m_baseCall +" "))

Mike W9MDB






On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via 
wsjt-devel  wrote:





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, I have now 
added another line of code as a test for my upcoming 'improved' 2.7.1-devel 
"240202" update, which has the effect that if you are in FT8 Hound mode, all 
messages (below 1000 Hz) are really displayed in the right window if they contain your 
own callsign.

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on when you are 
in FT8 Hound mode, because this confuses many OMs and makes little sense, at least from 
my point of view. Tell me if there is any good reason why this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:





"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Black Michael via wsjt-devel]

Should be able to use this instead.  Your call always has a space before/after.

contains(" " + m_baseCall +" "))

Mike W9MDB






On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, 
I have now added another line of code as a test for my upcoming 'improved' 
2.7.1-devel "240202" update, which has the effect that if you are in FT8 Hound 
mode, all messages (below 1000 Hz) are really displayed in the right window if 
they contain your own callsign. 

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on 
when you are in FT8 Hound mode, because this confuses many OMs and makes little 
sense, at least from my point of view. Tell me if there is any good reason why 
this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:


>  

"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.   



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

Actually CW operators use apriori operation all the time.

When you're in a poor signal CW QSO with a dxepedition or such all you listen 
for is your call sign -- not theirs.  You assume (apriori) that they are the 
ones responding and you have a sequence you follow so you just continue.

Mike W9MDB








On Saturday, January 27, 2024 at 12:50:50 AM CST, Jim Shorney via wsjt-devel 
 wrote: 






I would agree to that. I saw one with a P7 call yesterday that looked quite 
legitimate. My finger wanted badly to click on it but I said "no, wait...". 
Never saw it again. Despite what the nay-sayers claim, FT modes do require some 
human thought to get the best out of them. :)

73

-Jim
NU0C

On Sat, 27 Jan 2024 08:29:56 +0200
Reino Talarmo via wsjt-devel  wrote:

> Perhaps FT8 is too good compared to RTTY and
> CW and operators rely on what's written on screen, hi!


-- 

73

-Jim
NU0C



___
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-devel Digest, Vol 119, Issue 45

[Glenn Williams via wsjt-devel]

Reino,
Many thanks. I like to have all the background. So I cleared the concern
with a fresh TX5S QSO last night. FT8 blasted through all the CW 
contest.  I still got the missing decode in the RX Frequency window, though.


--73, Glenn, AF8C

On 1/27/2024 1:29 AM, Reino Talarmo via wsjt-devel wrote:

Yes, that improves decoding sensitivity quite a lot and
is useful once you have started a QSO. You may study the
a priori principle in the user guide 12.1. AP Decoding
and in more details in the reference 33,
https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf, especially
Figure 7, Table 6 and Figure 8.
Of course you may not use it in FT8, just disable in
Decode menu the Enable AP.
On the other hand also without the AP you still can get
false decodes as the message error detection is not 100
% reliable. There are in the message 77 information bits
and 14 error detection bits and that provides good
enough message error detection after forward error
correction. Perhaps FT8 is too good compared to RTTY and
CW and operators rely on what's written on screen, hi!
I have some 24/7 measurements over two years and I have
collected more than 80 000 callsigns and there are e.g.
108 callsigns starting with '0', 193 callsigns starting
with '1', the latter contains some real ones. That
continues to all figures and numbers, but it is harder
to tell fake ones; say order of 4000 total e.g. 5%. We
should remember that the fake ones are received only
once almost for certain and the real ones 100's of
times. Most of those false decodes are not due to AP,
perhaps half of the recording time I have not used AP as
it takes more processor resources.
It is an operator's fun to use his brains and detect
false decodes although those may be with red background!

73, Reino OH3mA


-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Saturday, January 27, 2024 1:12 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams 
Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,

Issue

45

So,
Do you mean that a priori information is used to help
decode?  That's a bias.  Shouldn't decodes stand on

their

own?
-73, Glenn, AF8C

On 1/26/2024 12:32 PM, Reino Talarmo via wsjt-devel
wrote:

Hi Glenn, congrats about a nice false decode. The

'a3'

tells that the decoder tried as the known

information

your call, DX

call, and rest is decoded. The '?'
indicates that the probability of correct message is

not

too high.

Also the contents of the decoded part is suspicious

as

the report is

just 'R' and the locator 'RA92' is in the middle of

Antarctica.


73, Reino OH3mA



-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Friday, January 26, 2024 6:43 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams 
Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol

119,

Issue

45

I am reporting here another issue with my TX5S QSO

and the FT8

windows that happened last night.  (Previous report

is under

"Subject:
[wsjt-devel] skips RX frequency window (bug?)

wsjtx-

2.7.0-rc3".)  I am also NOT confirmed in ClubLog!

My screenshots with iPhone are in

https://www.hamfaqs.com/tx5s

and I don't believe it was RFI because I was ONLY

receiving at the

time!

--73, Glenn, AF8C

On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
wrote:

Hi Fred and all,

It's really strange. Seems to be working well

here.

Look

at the Rx

Frequency windows of the three instances. (all

connected via virtual

audio, so nothing went over HF). To the left the

Fox

station, and to

the right the two hounds. I tried to reproduce

your

QSO situation when

the Fox was also in QSO with JH1BAM. Do you see

any

message not being

displayed there?


73 de DG2YCB,
Uwe

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





--
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Hasan N0AN via wsjt-devel]

HI Uwe,
This should be eliminated, it resulted in several unintended transmissions
with the antenna not switched or amp not tuned. I like the fact that you
removed it.

By the way, with the "240202" update I also plan to deactivate this strange
function that pressing the RETURN or ENTER keys switches your transmitter
on when you are in FT8 Hound mode
Hasan


On Sat, Jan 27, 2024 at 4:08 AM Uwe, DG2YCB via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi all,
>
> Short information: Although I could not reproduce this unwanted effect so
> far, I have now added another line of code as a test for my upcoming
> 'improved' 2.7.1-devel "240202" update, which has the effect that if you
> are in FT8 Hound mode, all messages (below 1000 Hz) are really displayed in
> the right window if they contain your own callsign.
>
> This gives us double certainty that every report or whatever will be
> displayed there in the future. However, it also has the side effect that
> messages to A1BCD, for example, are also displayed there if your own
> callsign is A1BC. But since this is only effective in hound mode, this
> should be acceptable, because all messages on your Rx QRG are displayed
> there anyway.
>
> Then we can see whether this really solves the problem or not. Depending
> on this, we can decide whether we also include this additional line in our
> regular WSJT-X.
>
> The mentioned i+ update is planned to be rolled out on February 2. Those
> who are interested in testing will find it here
> .
> As always, I am announcing anything about my so-called 'improved' versions
> via the wsjt-x-improved-community email reflector
> ,
> as this list here is primarily intended for our regular versions of WSJT-X.
>
> By the way, with the "240202" update I also plan to deactivate this
> strange function that pressing the RETURN or ENTER keys switches your
> transmitter on when you are in FT8 Hound mode, because this confuses many
> OMs and makes little sense, at least from my point of view. Tell me if
> there is any good reason why this was/is necessary.
>
> 73 de DG2YCB,
> Uwe
> 
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg2...@gmx.de
> Info: www.qrz.com/db/DG2YCB
>
>
> Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:
>
> "I have noticed the same thing at times while running as Hound in F/H
> where
> the report from the Fox will appear in the Band Activity column but not in
> the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel
> 231031 Improved PLUS" version."
>
> I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.
>
> I think it's rare but not new in the versions later than 2.6.1.
>
> It's a don't care for me as I'd prefer the RX frequency to only include
> decodes at the RX frequency as designated by the RX frequency cursor.  Only
> commenting because I don't think it's a new bug.
>
> Andy, k3wyc
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Uwe, DG2YCB via wsjt-devel]

Hi all,

Short information: Although I could not reproduce this unwanted effect
so far, I have now added another line of code as a test for my upcoming
'improved' 2.7.1-devel "240202" update, which has the effect that if you
are in FT8 Hound mode, all messages (below 1000 Hz) are really displayed
in the right window if they contain your own callsign.

This gives us double certainty that every report or whatever will be
displayed there in the future. However, it also has the side effect that
messages to A1BCD, for example, are also displayed there if your own
callsign is A1BC. But since this is only effective in hound mode, this
should be acceptable, because all messages on your Rx QRG are displayed
there anyway.

Then we can see whether this really solves the problem or not. Depending
on this, we can decide whether we also include this additional line in
our regular WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those
who are interested in testing will find it here
.
As always, I am announcing anything about my so-called 'improved'
versions via the wsjt-x-improved-community email reflector
,
as this list here is primarily intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this
strange function that pressing the RETURN or ENTER keys switches your
transmitter on when you are in FT8 Hound mode, because this confuses
many OMs and makes little sense, at least from my point of view. Tell me
if there is any good reason why this was/is necessary.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:

"I have noticed the same thing at times while running as Hound in F/H
where
the report from the Fox will appear in the Band Activity column but not in
the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel
231031 Improved PLUS" version."

I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.

I think it's rare but not new in the versions later than 2.6.1.

It's a don't care for me as I'd prefer the RX frequency to only
include decodes at the RX frequency as designated by the RX frequency
cursor.  Only commenting because I don't think it's a new bug.

Andy, k3wyc


___
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-devel Digest, Vol 119, Issue 45

[Jim Shorney via wsjt-devel]

I would agree to that. I saw one with a P7 call yesterday that looked quite 
legitimate. My finger wanted badly to click on it but I said "no, wait...". 
Never saw it again. Despite what the nay-sayers claim, FT modes do require some 
human thought to get the best out of them. :)

73

-Jim
NU0C

On Sat, 27 Jan 2024 08:29:56 +0200
Reino Talarmo via wsjt-devel  wrote:

> Perhaps FT8 is too good compared to RTTY and
> CW and operators rely on what's written on screen, hi!


-- 

73

-Jim
NU0C


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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Reino Talarmo via wsjt-devel]

Yes, that improves decoding sensitivity quite a lot and
is useful once you have started a QSO. You may study the
a priori principle in the user guide 12.1. AP Decoding
and in more details in the reference 33,
https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf, especially
Figure 7, Table 6 and Figure 8. 
Of course you may not use it in FT8, just disable in
Decode menu the Enable AP.
On the other hand also without the AP you still can get
false decodes as the message error detection is not 100
% reliable. There are in the message 77 information bits
and 14 error detection bits and that provides good
enough message error detection after forward error
correction. Perhaps FT8 is too good compared to RTTY and
CW and operators rely on what's written on screen, hi!
I have some 24/7 measurements over two years and I have
collected more than 80 000 callsigns and there are e.g.
108 callsigns starting with '0', 193 callsigns starting
with '1', the latter contains some real ones. That
continues to all figures and numbers, but it is harder
to tell fake ones; say order of 4000 total e.g. 5%. We
should remember that the fake ones are received only
once almost for certain and the real ones 100's of
times. Most of those false decodes are not due to AP,
perhaps half of the recording time I have not used AP as
it takes more processor resources.
It is an operator's fun to use his brains and detect
false decodes although those may be with red background!

73, Reino OH3mA

> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Saturday, January 27, 2024 1:12 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,
Issue
> 45
> 
> So,
> Do you mean that a priori information is used to help
> decode?  That's a bias.  Shouldn't decodes stand on
their
> own?
> -73, Glenn, AF8C
> 
> On 1/26/2024 12:32 PM, Reino Talarmo via wsjt-devel
> wrote:
> > Hi Glenn, congrats about a nice false decode. The
'a3'
> > tells that the decoder tried as the known
information
> your call, DX
> > call, and rest is decoded. The '?'
> > indicates that the probability of correct message is
not
> too high.
> > Also the contents of the decoded part is suspicious
as
> the report is
> > just 'R' and the locator 'RA92' is in the middle of
> Antarctica.
> >
> > 73, Reino OH3mA
> >
> >
> >> -Original Message-
> >> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> >> de...@lists.sourceforge.net]
> >> Sent: Friday, January 26, 2024 6:43 PM
> >> To: wsjt-devel@lists.sourceforge.net
> >> Cc: Glenn Williams 
> >> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol
119,
> > Issue
> >> 45
> >>
> >> I am reporting here another issue with my TX5S QSO
> and the FT8
> >> windows that happened last night.  (Previous report
> is under
> >> "Subject:
> >> [wsjt-devel] skips RX frequency window (bug?)
wsjtx-
> >> 2.7.0-rc3".)  I am also NOT confirmed in ClubLog!
> >>
> >> My screenshots with iPhone are in
> >>
> >> https://www.hamfaqs.com/tx5s
> >>
> >> and I don't believe it was RFI because I was ONLY
> receiving at the
> >> time!
> >>
> >> --73, Glenn, AF8C
> >>
> >> On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
> >> wrote:
> >>> Hi Fred and all,
> >>>
> >>> It's really strange. Seems to be working well
here.
> > Look
> >> at the Rx
> >>> Frequency windows of the three instances. (all
> >> connected via virtual
> >>> audio, so nothing went over HF). To the left the
Fox
> >> station, and to
> >>> the right the two hounds. I tried to reproduce
your
> >> QSO situation when
> >>> the Fox was also in QSO with JH1BAM. Do you see
> any
> >> message not being
> >>> displayed there?
> >>>
> >>>
> >>> 73 de DG2YCB,
> >>> Uwe
> >>> 
> >>> German Amateur Radio Station DG2YCB
> >>> Dr. Uwe Risse
> >>> eMail: dg2...@gmx.de
> >>> Info: www.qrz.com/db/DG2YCB
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> __
> >> _
> >>> wsjt-devel mailing list
> >>> wsjt-devel@lists.sourceforge.net
> >>>
> >
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>
> >> --
> >> This email has been checked for viruses by Ava

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Glenn Williams via wsjt-devel]

So,
Do you mean that a priori information is used to help decode?  That's a 
bias.  Shouldn't decodes stand on their own?

-73, Glenn, AF8C

On 1/26/2024 12:32 PM, Reino Talarmo via wsjt-devel wrote:

Hi Glenn, congrats about a nice false decode. The 'a3'
tells that the decoder tried as the known information
your call, DX call, and rest is decoded. The '?'
indicates that the probability of correct message is not
too high.
Also the contents of the decoded part is suspicious as
the report is just 'R' and the locator 'RA92' is in the
middle of Antarctica.

73, Reino OH3mA



-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Friday, January 26, 2024 6:43 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams 
Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,

Issue

45

I am reporting here another issue with my TX5S QSO and
the FT8 windows that happened last night.  (Previous
report is under "Subject:
[wsjt-devel] skips RX frequency window (bug?) wsjtx-
2.7.0-rc3".)  I am also NOT confirmed in ClubLog!

My screenshots with iPhone are in

https://www.hamfaqs.com/tx5s

and I don't believe it was RFI because I was ONLY
receiving at the time!

--73, Glenn, AF8C

On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
wrote:

Hi Fred and all,

It's really strange. Seems to be working well here.

Look

at the Rx

Frequency windows of the three instances. (all

connected via virtual

audio, so nothing went over HF). To the left the Fox

station, and to

the right the two hounds. I tried to reproduce your

QSO situation when

the Fox was also in QSO with JH1BAM. Do you see any

message not being

displayed there?


73 de DG2YCB,
Uwe

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






__
_

wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net


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


--
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


--
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

[Andy Durbin via wsjt-devel]

"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in
the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel
231031 Improved PLUS" version."

I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.

I think it's rare but not new in the versions later than 2.6.1.

It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.

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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Adrian via wsjt-devel]

I saw a call from North Korea from the same locator tonight. Someone 
playing silly games perhaps with MW DXCC.



73


vk4tux

On 27/1/24 03:32, Reino Talarmo via wsjt-devel wrote:

Hi Glenn, congrats about a nice false decode. The 'a3'
tells that the decoder tried as the known information
your call, DX call, and rest is decoded. The '?'
indicates that the probability of correct message is not
too high.
Also the contents of the decoded part is suspicious as
the report is just 'R' and the locator 'RA92' is in the
middle of Antarctica.

73, Reino OH3mA



-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Friday, January 26, 2024 6:43 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams 
Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,

Issue

45

I am reporting here another issue with my TX5S QSO and
the FT8 windows that happened last night.  (Previous
report is under "Subject:
[wsjt-devel] skips RX frequency window (bug?) wsjtx-
2.7.0-rc3".)  I am also NOT confirmed in ClubLog!

My screenshots with iPhone are in

https://www.hamfaqs.com/tx5s

and I don't believe it was RFI because I was ONLY
receiving at the time!

--73, Glenn, AF8C

On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
wrote:

Hi Fred and all,

It's really strange. Seems to be working well here.

Look

at the Rx

Frequency windows of the three instances. (all

connected via virtual

audio, so nothing went over HF). To the left the Fox

station, and to

the right the two hounds. I tried to reproduce your

QSO situation when

the Fox was also in QSO with JH1BAM. Do you see any

message not being

displayed there?


73 de DG2YCB,
Uwe

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






__
_

wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net


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

--
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



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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Uwe, DG2YCB via wsjt-devel]

Okay, then let's continue to observe whether we can find a pattern under
which exact conditions the unwanted effect occurs. As said, the
F/H-related part of the code in v2.7.0-rc3 (regular version) is
identical to the i+ version. This should therefore make no difference.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 18:26 schrieb Scott Armstrong via wsjt-devel:

I saw the same behavior over the past few days while working TX5S.

I am running 2.7.0-rc3 (regular version) not the improved version.

My first thoughts were that it was due to the Rx green goalpost in the
waterfall being over a different stream than the one sending the response.

I have no means of testing this scenario. So at this point, it is only
an observation.

-Scott AA5AM

On Fri, Jan 26, 2024, 10:12 AM Gary Rogers via wsjt-devel
 wrote:

I had the same thing happen as with Fred.

Improved rc3 for Mac M1

Sent from my iPhone


On Jan 26, 2024, at 11:00 AM, Fred Price via wsjt-devel
 wrote:


Screenshot of it happening to me with TX5S.




On Jan 26, 2024, at 10:51 AM, Uwe, DG2YCB via wsjt-devel
 wrote:

 But it worked also when I set my Rx QRG manually 275 Hz next
to the Fox offset.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 16:44 schrieb Black Michael:

Perhaps when the fox offset for your callsign changes?
I think I've seen that.









On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via 
wsjt-devel  
  wrote:





Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code) 
using three instances all connected via virtual audio.  One in FT8 Fox mode and 
the other two in FT8 Hound mode. Then I simulated just such QSO situations, but 
each time the reports appeared in the right-hand window of the two Hound 
stations. Not a single issue, even if I set the Rx frequency next to the Fox's 
audio signal. So, at the moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several updates in the meantime. 
Test it again with the current "240106" code, or with the soon-to-be released "240202" 
code. With the latter I will repeat the same test from last night.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:





I have noticed the same thing at times while running as Hound in F/H where the report 
from the Fox will appear in the Band Activity column but not in the Rx Frequency column.I 
am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version.




Also, when the "Start new period decodes at top" checkbox is checked, many 
times a day the background color will change from white to another background color. When 
this occurs it is not always the same color.




Also, at times when using  the  "Start new period decodes at top" option, 
the Band activity columns display will revert back to the earliest decodes, often many 
tens of minutes earlier.




73,

Rich - K1HTV







On Fri, Jan 26, 2024 at 7:55 AM  
  wrote:



Send wsjt-devel mailing list submissions to
 wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
 wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
 wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

    1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)



-- Forwarded message --
From: Glenn Williams  

To:wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
has happened once or twice before.)  His S/N report on me popped up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L 

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Reino Talarmo via wsjt-devel]

Hi Glenn, congrats about a nice false decode. The 'a3'
tells that the decoder tried as the known information
your call, DX call, and rest is decoded. The '?'
indicates that the probability of correct message is not
too high. 
Also the contents of the decoded part is suspicious as
the report is just 'R' and the locator 'RA92' is in the
middle of Antarctica. 

73, Reino OH3mA


> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Friday, January 26, 2024 6:43 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,
Issue
> 45
> 
> I am reporting here another issue with my TX5S QSO and
> the FT8 windows that happened last night.  (Previous
> report is under "Subject:
> [wsjt-devel] skips RX frequency window (bug?) wsjtx-
> 2.7.0-rc3".)  I am also NOT confirmed in ClubLog!
> 
> My screenshots with iPhone are in
> 
> https://www.hamfaqs.com/tx5s
> 
> and I don't believe it was RFI because I was ONLY
> receiving at the time!
> 
> --73, Glenn, AF8C
> 
> On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
> wrote:
> > Hi Fred and all,
> >
> > It's really strange. Seems to be working well here.
Look
> at the Rx
> > Frequency windows of the three instances. (all
> connected via virtual
> > audio, so nothing went over HF). To the left the Fox
> station, and to
> > the right the two hounds. I tried to reproduce your
> QSO situation when
> > the Fox was also in QSO with JH1BAM. Do you see any
> message not being
> > displayed there?
> >
> >
> > 73 de DG2YCB,
> > Uwe
> > 
> > German Amateur Radio Station DG2YCB
> > Dr. Uwe Risse
> > eMail: dg2...@gmx.de
> > Info: www.qrz.com/db/DG2YCB
> >
> >
> >
> >
> >
> __
> _
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> >
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> --
> 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] wsjt-devel Digest, Vol 119, Issue 45

[Scott Armstrong via wsjt-devel]

I saw the same behavior over the past few days while working TX5S.

I am running 2.7.0-rc3 (regular version) not the improved version.

My first thoughts were that it was due to the Rx green goalpost in the
waterfall being over a different stream than the one sending the response.

I have no means of testing this scenario. So at this point, it is only an
observation.

-Scott AA5AM

On Fri, Jan 26, 2024, 10:12 AM Gary Rogers via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I had the same thing happen as with Fred.
>
> Improved rc3 for Mac M1
>
> Sent from my iPhone
>
> On Jan 26, 2024, at 11:00 AM, Fred Price via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> 
> Screenshot of it happening to me with TX5S.
> 
>
>
> On Jan 26, 2024, at 10:51 AM, Uwe, DG2YCB via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>  But it worked also when I set my Rx QRG manually 275 Hz next to the Fox
> offset.
>
> 73 de DG2YCB,
> Uwe
> 
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg2...@gmx.de
> Info: www.qrz.com/db/DG2YCB
>
>
> Am 26.01.2024 um 16:44 schrieb Black Michael:
>
> Perhaps when the fox offset for your callsign changes?
> I think I've seen that.
>
>
>
>
>
>
>
>
>
> On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via wsjt-devel 
>   wrote:
>
>
>
>
>
> Hi Rich,
>
> Last night I ran some tests with our good old standard WSJT-X (latest code) 
> using three instances all connected via virtual audio.  One in FT8 Fox mode 
> and the other two in FT8 Hound mode. Then I simulated just such QSO 
> situations, but each time the reports appeared in the right-hand window of 
> the two Hound stations. Not a single issue, even if I set the Rx frequency 
> next to the Fox's audio signal. So, at the moment I can't reproduce this 
> unwanted effect.
>
> Please note that the "231031" code of 2.7.1-devel has received several 
> updates in the meantime. Test it again with the current "240106" code, or 
> with the soon-to-be released "240202" code. With the latter I will repeat the 
> same test from last night.
>
>
> 73 de DG2YCB,
> Uwe
> 
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg2...@gmx.de
> Info: www.qrz.com/db/DG2YCB
>
>
>
>
> Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:
>
>
>
>
>
> I have noticed the same thing at times while running as Hound in F/H where 
> the report from the Fox will appear in the Band Activity column but not in 
> the Rx Frequency column.I am presently running the "WSJT-X V2.7.1 devel 
> 231031 Improved PLUS" version.
>
>
>
>
> Also, when the "Start new period decodes at top" checkbox is checked, many 
> times a day the background color will change from white to another background 
> color. When this occurs it is not always the same color.
>
>
>
>
> Also, at times when using  the  "Start new period decodes at top" option, the 
> Band activity columns display will revert back to the earliest decodes, often 
> many tens of minutes earlier.
>
>
>
>
> 73,
>
> Rich - K1HTV
>
>
>
>
>
>
>
> On Fri, Jan 26, 2024 at 7:55 AM  
>  wrote:
>
>
>
> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
>
>1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)
>
>
>
> -- Forwarded message --
> From: Glenn Williams  
> To: wsjt-devel@lists.sourceforge.net
> Cc:
> Bcc:
> Date: Thu, 25 Jan 2024 08:12:51 -0500
> Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
> V 2.7.0-rc3
> Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
> has happened once or twice before.)  His S/N report on me popped up in
> Band Act window after my TX1, but no report in RX Freq window. TX3
> completed OK in both Windows.  I use COLORS and so red was instantly
> obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order
> of 450 watts with tuner. Not thinking RFI because no other times ever I
> see any.
>
> -73, Glenn, AF8C
> --
>
> --
> This email has been checked for viruses by Avast antivirus 
> software.www.avast.com
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> 

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

#1 That's a false decode (detectable as a funky message)
#2 Not on the Fox offsets.  Fox never transmitted at 474

Mike W9MDB








On Friday, January 26, 2024 at 11:19:40 AM CST, Glenn Williams via wsjt-devel 
 wrote: 





I am reporting here another issue with my TX5S QSO and the FT8 windows 
that happened last night.  (Previous report is under "Subject: 
[wsjt-devel] skips RX frequency window (bug?) wsjtx-2.7.0-rc3".)  I am 
also NOT confirmed in ClubLog!

My screenshots with iPhone are in

https://www.hamfaqs.com/tx5s

and I don't believe it was RFI because I was ONLY receiving at the time!

--73, Glenn, AF8C

On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel wrote:
> Hi Fred and all,
> 
> It's really strange. Seems to be working well here. Look at the Rx 
> Frequency windows of the three instances. (all connected via virtual 
> audio, so nothing went over HF). To the left the Fox station, and to the 
> right the two hounds. I tried to reproduce your QSO situation when the 
> Fox was also in QSO with JH1BAM. Do you see any message not being 
> displayed there?
> 
> 
> 73 de DG2YCB,
> Uwe
> 
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg2...@gmx.de
> Info: www.qrz.com/db/DG2YCB

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

-- 
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] wsjt-devel Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

No...it just appends the file.  Size doesn't matter as the saying goes...

Mike W9MDB








On Friday, January 26, 2024 at 11:10:08 AM CST, Glenn Williams via wsjt-devel 
 wrote: 





So,
Once upon a time I asked a question and the gurus had an answer (V2.2.2 
I think).

My question was about "how does FT8 keep huge files open and still keep 
up with the band activity while updating huge files". Today's question 
is about that.  ALL.TXT has grown really large.  Is there a practical 
limit on how large it can grow before the data flow bogs down and causes 
errors during Decode time?

--73, Glenn, AF8C

On 1/26/2024 9:18 AM, Rich - K1HTV via wsjt-devel wrote:
> I have noticed the same thing at times while running as Hound in F/H 
> where the report from the Fox will appear in the Band Activity column 
> but not in the Rx Frequency column.I am presently running the "WSJT-X 
> V2.7.1 devel 231031 Improved PLUS" version.
> 
> Also, when the "Start new period decodes at top" checkbox is checked, 
> many times a day the background color will change from white to another 
> background color. When this occurs it is not always the same color.
> 
> Also, at times when using  the  "Start new period decodes at top" 
> option, the Band activity columns display will revert back to the 
> earliest decodes, often many tens of minutes earlier.
> 
> 73,
> Rich - K1HTV
> 
> 
> On Fri, Jan 26, 2024 at 7:55 AM 
>  > wrote:
> 
>    Send wsjt-devel mailing list submissions to
>    wsjt-devel@lists.sourceforge.net
>    
> 
>    To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>    
>    or, via email, send a message with subject or body 'help' to
>    wsjt-devel-requ...@lists.sourceforge.net
>    
> 
>    You can reach the person managing the list at
>    wsjt-devel-ow...@lists.sourceforge.net
>    
> 
>    When replying, please edit your Subject line so it is more specific
>    than "Re: Contents of wsjt-devel digest..."
>    Today's Topics:
> 
>         1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
>    Williams)
> 
> 
> 
>    -- Forwarded message --
>    From: Glenn Williams     >
>    To: wsjt-devel@lists.sourceforge.net
>    
>    Cc:
>    Bcc:
>    Date: Thu, 25 Jan 2024 08:12:51 -0500
>    Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
>    V 2.7.0-rc3
>    Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
>    has happened once or twice before.)  His S/N report on me popped up in
>    Band Act window after my TX1, but no report in RX Freq window. TX3
>    completed OK in both Windows.  I use COLORS and so red was instantly
>    obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the
>    order
>    of 450 watts with tuner. Not thinking RFI because no other times ever I
>    see any.
> 
>    -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


___
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-devel Digest, Vol 119, Issue 45

[Glenn Williams via wsjt-devel]

I am reporting here another issue with my TX5S QSO and the FT8 windows 
that happened last night.  (Previous report is under "Subject: 
[wsjt-devel] skips RX frequency window (bug?) wsjtx-2.7.0-rc3".)  I am 
also NOT confirmed in ClubLog!


My screenshots with iPhone are in

https://www.hamfaqs.com/tx5s

and I don't believe it was RFI because I was ONLY receiving at the time!

--73, Glenn, AF8C

On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel wrote:

Hi Fred and all,

It's really strange. Seems to be working well here. Look at the Rx 
Frequency windows of the three instances. (all connected via virtual 
audio, so nothing went over HF). To the left the Fox station, and to the 
right the two hounds. I tried to reproduce your QSO situation when the 
Fox was also in QSO with JH1BAM. Do you see any message not being 
displayed there?



73 de DG2YCB,
Uwe

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




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


--
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Glenn Williams via wsjt-devel]

So,
Once upon a time I asked a question and the gurus had an answer (V2.2.2 
I think).


My question was about "how does FT8 keep huge files open and still keep 
up with the band activity while updating huge files". Today's question 
is about that.  ALL.TXT has grown really large.  Is there a practical 
limit on how large it can grow before the data flow bogs down and causes 
errors during Decode time?


--73, Glenn, AF8C

On 1/26/2024 9:18 AM, Rich - K1HTV via wsjt-devel wrote:
I have noticed the same thing at times while running as Hound in F/H 
where the report from the Fox will appear in the Band Activity column 
but not in the Rx Frequency column.I am presently running the "WSJT-X 
V2.7.1 devel 231031 Improved PLUS" version.


Also, when the "Start new period decodes at top" checkbox is checked, 
many times a day the background color will change from white to another 
background color. When this occurs it is not always the same color.


Also, at times when using  the  "Start new period decodes at top" 
option, the Band activity columns display will revert back to the 
earliest decodes, often many tens of minutes earlier.


73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM 
> wrote:


Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net


To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net


You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net


When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

    1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
Williams)



-- Forwarded message --
From: Glenn Williams mailto:a...@alumni.caltech.edu>>
To: wsjt-devel@lists.sourceforge.net

Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
has happened once or twice before.)  His S/N report on me popped up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the
order
of 450 watts with tuner. Not thinking RFI because no other times ever I
see any.

-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



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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Gary Rogers via wsjt-devel]

I had the same thing happen as with Fred. Improved rc3 for Mac M1Sent from my iPhoneOn Jan 26, 2024, at 11:00 AM, Fred Price via wsjt-devel  wrote:





Screenshot of it happening to me with TX5S. 



On Jan 26, 2024, at 10:51 AM, Uwe, DG2YCB via wsjt-devel  wrote:




 But it worked also when I set my Rx QRG manually 275 Hz next to the Fox offset.

73 de DG2YCB,
Uwe

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



Am 26.01.2024 um 16:44 schrieb Black Michael:


Perhaps when the fox offset for your callsign changes?
I think I've seen that.









On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via wsjt-devel  wrote:





Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code) using three instances all connected via virtual audio.  One in FT8 Fox mode and the other two in FT8 Hound mode. Then I simulated just such QSO situations, but each time the reports appeared in the right-hand window of the two Hound stations. Not a single issue, even if I set the Rx frequency next to the Fox's audio signal. So, at the moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several updates in the meantime. Test it again with the current "240106" code, or with the soon-to-be released "240202" code. With the latter I will repeat the same test from last night.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:




  


I have noticed the same thing at times while running as Hound in F/H where the report from the Fox will appear in the Band Activity column but not in the Rx Frequency column.I am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version.




Also, when the "Start new period decodes at top" checkbox is checked, many times a day the background color will change from white to another background color. When this occurs it is not always the same color.




Also, at times when using  the  "Start new period decodes at top" option, the Band activity columns display will revert back to the earliest decodes, often many tens of minutes earlier.




73,

Rich - K1HTV







On Fri, Jan 26, 2024 at 7:55 AM  wrote:




Send wsjt-devel mailing list submissions to
        wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
        wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
        wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

   1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)



-- Forwarded message --
From: Glenn Williams 
To: wsjt-devel@lists.sourceforge.net
Cc: 
Bcc: 
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
has happened once or twice before.)  His S/N report on me popped up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order
of 450 watts with tuner. Not thinking RFI because no other times ever I
see any.

-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


___
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 listwsjt-devel@lists.sourceforge.nethttps://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-devel Digest, Vol 119, Issue 45

[Uwe, DG2YCB via wsjt-devel]

But it worked also when I set my Rx QRG manually 275 Hz next to the Fox
offset.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 16:44 schrieb Black Michael:

Perhaps when the fox offset for your callsign changes?
I think I've seen that.









On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via 
wsjt-devel  wrote:





Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code) 
using three instances all connected via virtual audio.  One in FT8 Fox mode and 
the other two in FT8 Hound mode. Then I simulated just such QSO situations, but 
each time the reports appeared in the right-hand window of the two Hound 
stations. Not a single issue, even if I set the Rx frequency next to the Fox's 
audio signal. So, at the moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several updates in the meantime. 
Test it again with the current "240106" code, or with the soon-to-be released "240202" 
code. With the latter I will repeat the same test from last night.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:





I have noticed the same thing at times while running as Hound in F/H where the report 
from the Fox will appear in the Band Activity column but not in the Rx Frequency column.I 
am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version.




Also, when the "Start new period decodes at top" checkbox is checked, many 
times a day the background color will change from white to another background color. When 
this occurs it is not always the same color.




Also, at times when using  the  "Start new period decodes at top" option, the 
Band activity columns display will revert back to the earliest decodes, often many tens 
of minutes earlier.




73,

Rich - K1HTV







On Fri, Jan 26, 2024 at 7:55 AM  
wrote:



Send wsjt-devel mailing list submissions to
 wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
 wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
 wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

    1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)



-- Forwarded message --
From: Glenn Williams
To:wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
has happened once or twice before.)  His S/N report on me popped up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order
of 450 watts with tuner. Not thinking RFI because no other times ever I
see any.

-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


___
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-devel Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

Perhaps when the fox offset for your callsign changes?
I think I've seen that.









On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code) 
using three instances all connected via virtual audio.  One in FT8 Fox mode and 
the other two in FT8 Hound mode. Then I simulated just such QSO situations, but 
each time the reports appeared in the right-hand window of the two Hound 
stations. Not a single issue, even if I set the Rx frequency next to the Fox's 
audio signal. So, at the moment I can't reproduce this unwanted effect. 

Please note that the "231031" code of 2.7.1-devel has received several updates 
in the meantime. Test it again with the current "240106" code, or with the 
soon-to-be released "240202" code. With the latter I will repeat the same test 
from last night.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:


>  

I have noticed the same thing at times while running as Hound in F/H where the 
report from the Fox will appear in the Band Activity column but not in the Rx 
Frequency column.I am presently running the "WSJT-X V2.7.1 devel 231031 
Improved PLUS" version.




Also, when the "Start new period decodes at top" checkbox is checked, many 
times a day the background color will change from white to another background 
color. When this occurs it is not always the same color.




Also, at times when using  the  "Start new period decodes at top" option, the 
Band activity columns display will revert back to the earliest decodes, often 
many tens of minutes earlier.




73,

Rich - K1HTV







On Fri, Jan 26, 2024 at 7:55 AM  
wrote:


> Send wsjt-devel mailing list submissions to
>         wsjt-devel@lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
>         wsjt-devel-requ...@lists.sourceforge.net
> 
> You can reach the person managing the list at
>         wsjt-devel-ow...@lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
> 
>    1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)
> 
> 
> 
> -- Forwarded message --
> From: Glenn Williams 
> To: wsjt-devel@lists.sourceforge.net
> Cc: 
> Bcc: 
> Date: Thu, 25 Jan 2024 08:12:51 -0500
> Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
> V 2.7.0-rc3
> Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This 
> has happened once or twice before.)  His S/N report on me popped up in 
> Band Act window after my TX1, but no report in RX Freq window. TX3 
> completed OK in both Windows.  I use COLORS and so red was instantly 
> obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order 
> of 450 watts with tuner. Not thinking RFI because no other times ever I 
> see any.
> 
> -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


___
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-devel Digest, Vol 119, Issue 45

[Uwe, DG2YCB via wsjt-devel]

Rick,

Just completed the same test with the i+ 2.7.1-devel "240202" code.
Identical results as with our standard WSJT-X v2.7.0-rc3 (not
surprising, since this part of the code is identical). Not a single
issue, all messages to the own callsign were displayed correctly in the
right window. So, I can really not reproduce this unwanted effect.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 16:12 schrieb Uwe, DG2YCB via wsjt-devel:

Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest
code) using three instances all connected via virtual audio.  One in
FT8 Fox mode and the other two in FT8 Hound mode. Then I simulated
just such QSO situations, but each time the reports appeared in the
right-hand window of the two Hound stations. Not a single issue, even
if I set the Rx frequency next to the Fox's audio signal. So, at the
moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several
updates in the meantime. Test it again with the current "240106" code,
or with the soon-to-be released "240202" code. With the latter I will
repeat the same test from last night.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

I have noticed the same thing at times while running as Hound in F/H
where the report from the Fox will appear in the Band Activity column
but not in the Rx Frequency column.I am presently running the "WSJT-X
V2.7.1 devel 231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked,
many times a day the background color will change from white to
another background color. When this occurs it is not always the same
color.

Also, at times when using  the  "Start new period decodes at top"
option, the Band activity columns display will revert back to the
earliest decodes, often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM
 wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

   1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
Williams)



-- Forwarded message --
From: Glenn Williams 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?)
wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10.
(This
has happened once or twice before.)  His S/N report on me popped
up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on
the order
of 450 watts with tuner. Not thinking RFI because no other times
ever I
see any.

-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




___
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-devel Digest, Vol 119, Issue 45

[Uwe, DG2YCB via wsjt-devel]

Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest
code) using three instances all connected via virtual audio.  One in FT8
Fox mode and the other two in FT8 Hound mode. Then I simulated just such
QSO situations, but each time the reports appeared in the right-hand
window of the two Hound stations. Not a single issue, even if I set the
Rx frequency next to the Fox's audio signal. So, at the moment I can't
reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several
updates in the meantime. Test it again with the current "240106" code,
or with the soon-to-be released "240202" code. With the latter I will
repeat the same test from last night.

73 de DG2YCB,
Uwe

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


Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

I have noticed the same thing at times while running as Hound in F/H
where the report from the Fox will appear in the Band Activity column
but not in the Rx Frequency column.I am presently running the "WSJT-X
V2.7.1 devel 231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked,
many times a day the background color will change from white to
another background color. When this occurs it is not always the same
color.

Also, at times when using  the  "Start new period decodes at top"
option, the Band activity columns display will revert back to the
earliest decodes, often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM
 wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

   1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
Williams)



-- Forwarded message --
From: Glenn Williams 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?)
wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10.
(This
has happened once or twice before.)  His S/N report on me popped
up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the
order
of 450 watts with tuner. Not thinking RFI because no other times
ever I
see any.

-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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Rich - K1HTV via wsjt-devel]

I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in
the Rx Frequency column.I am presently running the "WSJT-X V2.7.1 devel
231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked, many
times a day the background color will change from white to another
background color. When this occurs it is not always the same color.

Also, at times when using  the  "Start new period decodes at top" option,
the Band activity columns display will revert back to the earliest decodes,
often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
>
>1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)
>
>
>
> -- Forwarded message --
> From: Glenn Williams 
> To: wsjt-devel@lists.sourceforge.net
> Cc:
> Bcc:
> Date: Thu, 25 Jan 2024 08:12:51 -0500
> Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
> V 2.7.0-rc3
> Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
> has happened once or twice before.)  His S/N report on me popped up in
> Band Act window after my TX1, but no report in RX Freq window. TX3
> completed OK in both Windows.  I use COLORS and so red was instantly
> obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order
> of 450 watts with tuner. Not thinking RFI because no other times ever I
> see any.
>
> -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] WSJT-X ver 2.6.1 Failed to start OmniRig COM server

[Carl Moreschi via wsjt-devel]

A lot of monitors have built in sound.  I have seen crazy things where 
these monitor sound devices cause strange problems.  I would disable all 
the sound devices in your monitors.


Carl Moreschi N4PY
127 River Moss Way
Hertford, NC 27944
www.n4py.com

On 12/20/2023 8:24 AM, Christopher Wawak via wsjt-devel wrote:
I have seen this exact scenario with the sound device causing Omnirig to 
fail to initialize. I can reliably reproduce this and repair it. I've 
posted about it before to no avail.


I have also seen a scenario where the sound devices don't seem to 
change, but Omnirig fails to initialize even after a reboot. Eventually 
some sort of gyration (killing the ominrig daemon, resetting the serial 
port, etc etc) allows the system to recover.


I use Log4OM which also uses Omni-Rig.

I've sort of decided to live with it rather than continue to track it 
down, but happy to share any debugging that I might have done in more 
detail if there's interest to address this.


73 KC2IEB

On Wed, Dec 20, 2023 at 7:13 AM Andy Durbin via wsjt-devel 
> wrote:


It turns out that this problem is very easy to reproduce.  First
some background on my configuration.

The TS-590S has both a USB port and a traditional RS-232 COM port. 
The USB port connects to an internal USB hub which, in turn,

connects to a USB UART for CAT and a PCM2903B USB Audio CODEC.  In
my station OmniRig is connected to the RS-232 COM port and does not
use USB CAT.

Starting with WSJT-X connected via OmniRig and connected to rig USB
audio CODEC
I pulled the rig USB cable
I observed WSJ-X report loss of sound interface
I went to Settings/Audio and saw Input TS-590 USB Audio CODEC not found
I went to Settings/Radio and executed Test CAT - Failed with "failed
to start OmniRig server"
I restored the rig USB cable
I went to Settings/Audio and restored the rig CODEC connection
I went to Settings/Radio and Executed Test CAT - it failed.
I terminated and re-started WSJT-X.
It started with no errors.

I see no reason why loss of USB Audio should cause WSJT-X to be
unable to connect to OmniRig and think there may be an unintended
dependency in the code.

73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

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




--
-- Chris


___
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 ver 2.6.1 Failed to start OmniRig COM server

[Christopher Wawak via wsjt-devel]

I have seen this exact scenario with the sound device causing Omnirig to
fail to initialize. I can reliably reproduce this and repair it. I've
posted about it before to no avail.

I have also seen a scenario where the sound devices don't seem to change,
but Omnirig fails to initialize even after a reboot. Eventually some sort
of gyration (killing the ominrig daemon, resetting the serial port, etc
etc) allows the system to recover.

I use Log4OM which also uses Omni-Rig.

I've sort of decided to live with it rather than continue to track it down,
but happy to share any debugging that I might have done in more detail if
there's interest to address this.

73 KC2IEB

On Wed, Dec 20, 2023 at 7:13 AM Andy Durbin via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> It turns out that this problem is very easy to reproduce.  First some
> background on my configuration.
>
> The TS-590S has both a USB port and a traditional RS-232 COM port.  The
> USB port connects to an internal USB hub which, in turn, connects to a USB
> UART for CAT and a PCM2903B USB Audio CODEC.  In my station OmniRig is
> connected to the RS-232 COM port and does not use USB CAT.
>
> Starting with WSJT-X connected via OmniRig and connected to rig USB audio
> CODEC
> I pulled the rig USB cable
> I observed WSJ-X report loss of sound interface
> I went to Settings/Audio and saw Input TS-590 USB Audio CODEC not found
> I went to Settings/Radio and executed Test CAT - Failed with "failed to
> start OmniRig server"
> I restored the rig USB cable
> I went to Settings/Audio and restored the rig CODEC connection
> I went to Settings/Radio and Executed Test CAT - it failed.
> I terminated and re-started WSJT-X.
> It started with no errors.
>
> I see no reason why loss of USB Audio should cause WSJT-X to be unable to
> connect to OmniRig and think there may be an unintended dependency in the
> code.
>
> 73,
> Andy, k3wyc
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


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

Re: [wsjt-devel] WSJT-X ver 2.6.1 Failed to start OmniRig COM server

[Andy Durbin via wsjt-devel]

It turns out that this problem is very easy to reproduce.  First some 
background on my configuration.

The TS-590S has both a USB port and a traditional RS-232 COM port.  The USB 
port connects to an internal USB hub which, in turn, connects to a USB UART for 
CAT and a PCM2903B USB Audio CODEC.  In my station OmniRig is connected to the 
RS-232 COM port and does not use USB CAT.

Starting with WSJT-X connected via OmniRig and connected to rig USB audio CODEC
I pulled the rig USB cable
I observed WSJ-X report loss of sound interface
I went to Settings/Audio and saw Input TS-590 USB Audio CODEC not found
I went to Settings/Radio and executed Test CAT - Failed with "failed to start 
OmniRig server"
I restored the rig USB cable
I went to Settings/Audio and restored the rig CODEC connection
I went to Settings/Radio and Executed Test CAT - it failed.
I terminated and re-started WSJT-X.
It started with no errors.

I see no reason why loss of USB Audio should cause WSJT-X to be unable to 
connect to OmniRig and think there may be an unintended dependency in the code.

73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X ver 2.6.1 Failed to start OmniRig COM server

[Andy Durbin via wsjt-devel]

I have it working again.

I had disconnected all cables from the laptop to access the battery. When I put 
it all back together I had swapped the cables for the TS-590S USB port and a 10 
port USB hub.  I only realized this error when WSJT-X did not see my TS-590S 
USB audio CODEC.

When I put the USB cables back in the usual laptop ports the TS-590S USB audio 
CODEC was available to WSJT-X and, when it was selected for audio in and out, I 
could connect to OmniRig.  I have a feeling there is a bug here but, at least 
for now, I'd rather chase DX than try to reproduce it.

73,
Andy, k3wyc

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

Re: [wsjt-devel] WSJT noise estimates

[Joe Fleagle via wsjt-devel]

Thanks for the explanation Joe.  I had not seen that before. Signals do not 
affect the noise estimate which was one of the answers I was looking for.

Joe

> On Dec 10, 2023, at 11:21, Joe Taylor via wsjt-devel 
>  wrote:
> 
> Hi Joe,
> 
>> On 12/9/2023 9:56 PM, w0fy--- via wsjt-devel wrote:
>> Been wondering how WSJT-X generates the noise power estimate it uses to 
>> calculate SNR for each FT8 signal.  Does it simply collect all the signals 
>> and noise over the bandwidth selected on the waterfall and call that the 
>> noise power level or does it take a quick snapshot of  the background noise 
>> level during the brief quiet period at the end of each 15 second FT8 
>> sequence? Or is it more complicated than that?
> 
> This question has been asked and answered many times on this and similar 
> forums.  WSJT-X measures noise power by computing the spectrum of the 
> receiver's output, averaged over the reception interval, and fitting a 
> baseline to the regions that have no discernible signal present.  The 
> resulting value -- effectively a noise power density, or power per unit 
> bandwidth -- is then scaled to yield noise power in 2500 Hz bandwidth.
> 
>> I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that 
>> if not AWGN is pretty close to it.  10 meters is even worse. The DSP noise 
>> blanker in my TS590 will reduce it slightly. I estimate this is degrading my 
>> ability to decode FT8 signals on 6 by nearly 20 dB compared to the noise 
>> level generated by a 50 ohm resistor.  I don’t use an LNA ahead of the radio 
>> – would be pointless.  I don’t use the noise reduction feature in the radio 
>> either as it tends to lose very weak signals completely.
> 
> It's OK to use your receiver's noise blanker to remove impulsive noise.
> 
> Do NOT use "noise reduction" features, and do NOT use a receiver bandwidth 
> narrower than about 2.5 kHz.  Wider bandwidths are even better, up to 4 or 5 
> kHz.  WSJT-X does all necessary narrow-band filtering in software.
> 
>-- 73, Joe, K1JT
> 
> 
> ___
> 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 noise estimates

[Joe Taylor via wsjt-devel]

Hi Joe,

On 12/9/2023 9:56 PM, w0fy--- via wsjt-devel wrote:
Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the 
signals and noise over the bandwidth selected on the waterfall and call 
that the noise power level or does it take a quick snapshot of  the 
background noise level during the brief quiet period at the end of each 
15 second FT8 sequence? Or is it more complicated than that?


This question has been asked and answered many times on this and similar 
forums.  WSJT-X measures noise power by computing the spectrum of the 
receiver's output, averaged over the reception interval, and fitting a 
baseline to the regions that have no discernible signal present.  The 
resulting value -- effectively a noise power density, or power per unit 
bandwidth -- is then scaled to yield noise power in 2500 Hz bandwidth.


I am plagued with a S2 -S3 noise level on 6 meters nearly all the time 
that if not AWGN is pretty close to it.  10 meters is even worse. The 
DSP noise blanker in my TS590 will reduce it slightly. I estimate this 
is degrading my ability to decode FT8 signals on 6 by nearly 20 dB 
compared to the noise level generated by a 50 ohm resistor.  I don’t use 
an LNA ahead of the radio – would be pointless.  I don’t use the noise 
reduction feature in the radio either as it tends to lose very weak 
signals completely.


It's OK to use your receiver's noise blanker to remove impulsive noise.

Do NOT use "noise reduction" features, and do NOT use a receiver 
bandwidth narrower than about 2.5 kHz.  Wider bandwidths are even 
better, up to 4 or 5 kHz.  WSJT-X does all necessary narrow-band 
filtering in software.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] WSJT noise estimates

[w0fy--- via wsjt-devel]

Thanks for comments Reino and Andy.  My 20 dB degradation number was based on 
an actual measurement using FM mode on my radio.  Basically  injected a signal 
into the antenna feedline which was terminated with a 50 ohm load. Measured the 
receiver quieting sensitivity, then repeated the measurement with the antenna 
connected in place of the 50 ohm load. Noted the difference in input signal 
level required to produce a given amount of quieting. Although the receiver 
bandwidth is different, if we assume the noise is uniformly distributed over 
frequency the bandwidth difference should not affect the difference 
measurement. 

 

Think I’m going to redo that measurement using an actual locally generated FT8 
signal as soon as I figure out how to get enough attenuation on the FT8 signal 
and keep leakage from spoiling the measurement.   I don’t care about the SNR 
numbers reported, want to see if I can improve decoding sensitivity with 
additional filtering. Suffering from the frustration of others around me 
decoding stuff  I don’t!

 

From: Reino Talarmo via wsjt-devel  
Sent: Sunday, December 10, 2023 10:19 AM
To: 'WSJT software development' 
Cc: Reino Talarmo 
Subject: Re: [wsjt-devel] WSJT noise estimates

 

Hi Andy,

Interesting approach. But how you know that it really enhanced the signal 
detection?
The wanted signal is now close the wanted signal and that may disturb the S/N 
calculation and you will see a better S/N values with your method without a 
real better sensitivity. Possibly the only real comparison could be with two 
radios fed from the same antenna with a power divider (you may need a an 
amplifier before the power divider for compensating attenuation) and two 
instances of wsjt-x. Then a statistical study of success/failure rates could 
tell a real story.

 

Just my two pennies.

 

73, Reino OH3mA

 

From: Andrew Neumeier via wsjt-devel [ 
<mailto:wsjt-devel@lists.sourceforge.net> 
mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, December 10, 2023 3:40 PM
To: w0fy--- via wsjt-devel < <mailto:wsjt-devel@lists.sourceforge.net> 
wsjt-devel@lists.sourceforge.net>
Cc: Andrew Neumeier < <mailto:ka2...@yahoo.com> ka2...@yahoo.com>
Subject: Re: [wsjt-devel] WSJT noise estimates

 

Joe,

 

Just a comment here.  I use FT8 frequently and almost always on 2 meters.  My 
interest is in weak signals.  I use a Omni VII here, with a transverter.  I 
have had some luck using my notch filter on very weak FT8

signals.  Setting the notch width at about 75hz, I have been using the edge of 
the filter to enhance the signals I am looking for.  So, the notch is not 
directly on the desired signal, but set a few hundred hertz from it, usually

below it.  Of course, placing the notch directly on the signal would erase it, 
but I don't use it that way.  I have worked a number of stations this way.  It 
took some playing around to get this to work, and it does not always

work, and one must see the signal first and have a decode failure, before 
turning to this remedy.  

 

Just my two cents.

 

Best of luck,

73,

Andy, ka2uqw

 

 

 

On Saturday, December 9, 2023 at 10:05:26 PM EST, w0fy--- via wsjt-devel < 
<mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net> 
wrote: 

 

 

Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the signals and 
noise over the bandwidth selected on the waterfall and call that the noise 
power level or does it take a quick snapshot of  the background noise level 
during the brief quiet period at the end of each 15 second FT8 sequence? Or is 
it more complicated than that?

 

I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that if 
not AWGN is pretty close to it.  10 meters is even worse. The DSP noise blanker 
in my TS590 will reduce it slightly. I estimate this is degrading my ability to 
decode FT8 signals on 6 by nearly 20 dB compared to the noise level generated 
by a 50 ohm resistor.  I don’t use an LNA ahead of the radio – would be 
pointless.  I don’t use the noise reduction feature in the radio either as it 
tends to lose very weak signals completely. 

 

Wondering if I can use the DSP in my TS590 to narrow the receiver bandwidth to 
perhaps 300 -500 Hz around a known offset to help pick weak signals out of the 
noise? I realize that the WSJT program filters the audio into much narrower BW 
bins so all the receiver filtering can do is reduce the receiver gain reduction 
caused by the noise pumping up the AGC but that might be beneficial.  Likewise, 
would using the DSP notch to suppress a single strong local signal or birdie 
help since strong signals also reduce receiver gain?  Should I deselect the 
flatness option if I use these tools? Would narrowing the waterfall span help 
any since the program ignores anything outside that span? Would appreciat

Re: [wsjt-devel] WSJT noise estimates

[Andrew Neumeier via wsjt-devel]

 Reino,
I really have no data to compare as you suggest, and the results are purely 
annecdotal.  

The way this got started was that on 2 meters I suffer from local rfi, usually 
these are suspected to be chargers in the vicinity.  In engaging filters I 
noticed the rfi become enhanced, by observingnearly imperceptible rfi become 
completely visible.  So, I wondered if I could do the same with a very weak 
signal.  In some cases, a non-decoding ft8 signal which is very light in color, 
often becomesdarker, nearly orange at times and decodes.  Using the method, I 
have worked quite a few stations otherwise impossible to decode.  And yes, the 
signal reading reported by WSJTX will change, sometimesdramatically.  As I 
posted earlier, the method is not foolproof, it doesn't always work.  QSB does 
not help the matter, of course.  

It's important to mention that I do this only on 2 meters.  Often the target 
signal is the only one on the waterfall so I can spend time zeroing in on it.  

I can only suggest that it be tried, maybe I'm wrong, but I use the method 
pretty regularly.
I have noticed the same results on Q65, but generally have not spent much time 
with it there.

73,Andy, ka2uqw


On Sunday, December 10, 2023 at 11:25:32 AM EST, Reino Talarmo via 
wsjt-devel  wrote:  
 
 
Hi Andy,

Interesting approach. But how you know that it really enhanced the signal 
detection?
The wanted signal is now close the wanted signal and that may disturb the S/N 
calculation and you will see a better S/N values with your method without a 
real better sensitivity. Possibly the only real comparison could be with two 
radios fed from the same antenna with a power divider (you may need a an 
amplifier before the power divider for compensating attenuation) and two 
instances of wsjt-x. Then a statistical study of success/failure rates could 
tell a real story.

  

Just my two pennies.

  

73, Reino OH3mA

  

From: Andrew Neumeier via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, December 10, 2023 3:40 PM
To: w0fy--- via wsjt-devel 
Cc: Andrew Neumeier 
Subject: Re: [wsjt-devel] WSJT noise estimates

  

Joe,

  

Just a comment here.  I use FT8 frequently and almost always on 2 meters.  My 
interest is in weak signals.  I use a Omni VII here, with a transverter.  I 
have had some luck using my notch filter on very weak FT8

signals.  Setting the notch width at about 75hz, I have been using the edge of 
the filter to enhance the signals I am looking for.  So, the notch is not 
directly on the desired signal, but set a few hundred hertz from it, usually

below it.  Of course, placing the notch directly on the signal would erase it, 
but I don't use it that way.  I have worked a number of stations this way.  It 
took some playing around to get this to work, and it does not always

work, and one must see the signal first and have a decode failure, before 
turning to this remedy.  

  

Just my two cents.

  

Best of luck,

73,

Andy, ka2uqw

  

  

  

On Saturday, December 9, 2023 at 10:05:26 PM EST, w0fy--- via wsjt-devel 
 wrote: 

  

  

Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the signals and 
noise over the bandwidth selected on the waterfall and call that the noise 
power level or does it take a quick snapshot of  the background noise level 
during the brief quiet period at the end of each 15 second FT8 sequence? Or is 
it more complicated than that?

 

I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that if 
not AWGN is pretty close to it.  10 meters is even worse. The DSP noise blanker 
in my TS590 will reduce it slightly. I estimate this is degrading my ability to 
decode FT8 signals on 6 by nearly 20 dB compared to the noise level generated 
by a 50 ohm resistor.  I don’t use an LNA ahead of the radio – would be 
pointless.  I don’t use the noise reduction feature in the radio either as it 
tends to lose very weak signals completely. 

 

Wondering if I can use the DSP in my TS590 to narrow the receiver bandwidth to 
perhaps 300 -500 Hz around a known offset to help pick weak signals out of the 
noise? I realize that the WSJT program filters the audio into much narrower BW 
bins so all the receiver filtering can do is reduce the receiver gain reduction 
caused by the noise pumping up the AGC but that might be beneficial.  Likewise, 
would using the DSP notch to suppress a single strong local signal or birdie 
help since strong signals also reduce receiver gain?  Should I deselect the 
flatness option if I use these tools? Would narrowing the waterfall span help 
any since the program ignores anything outside that span? Would appreciate any 
insight you can share.

 

Joe W0FY

 

 

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

Re: [wsjt-devel] WSJT noise estimates

[Reino Talarmo via wsjt-devel]

Hi Andy,

Interesting approach. But how you know that it really enhanced the signal 
detection?
The wanted signal is now close the wanted signal and that may disturb the S/N 
calculation and you will see a better S/N values with your method without a 
real better sensitivity. Possibly the only real comparison could be with two 
radios fed from the same antenna with a power divider (you may need a an 
amplifier before the power divider for compensating attenuation) and two 
instances of wsjt-x. Then a statistical study of success/failure rates could 
tell a real story.

 

Just my two pennies.

 

73, Reino OH3mA

 

From: Andrew Neumeier via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, December 10, 2023 3:40 PM
To: w0fy--- via wsjt-devel 
Cc: Andrew Neumeier 
Subject: Re: [wsjt-devel] WSJT noise estimates

 

Joe,

 

Just a comment here.  I use FT8 frequently and almost always on 2 meters.  My 
interest is in weak signals.  I use a Omni VII here, with a transverter.  I 
have had some luck using my notch filter on very weak FT8

signals.  Setting the notch width at about 75hz, I have been using the edge of 
the filter to enhance the signals I am looking for.  So, the notch is not 
directly on the desired signal, but set a few hundred hertz from it, usually

below it.  Of course, placing the notch directly on the signal would erase it, 
but I don't use it that way.  I have worked a number of stations this way.  It 
took some playing around to get this to work, and it does not always

work, and one must see the signal first and have a decode failure, before 
turning to this remedy.  

 

Just my two cents.

 

Best of luck,

73,

Andy, ka2uqw

 

 

 

On Saturday, December 9, 2023 at 10:05:26 PM EST, w0fy--- via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the signals and 
noise over the bandwidth selected on the waterfall and call that the noise 
power level or does it take a quick snapshot of  the background noise level 
during the brief quiet period at the end of each 15 second FT8 sequence? Or is 
it more complicated than that?

 

I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that if 
not AWGN is pretty close to it.  10 meters is even worse. The DSP noise blanker 
in my TS590 will reduce it slightly. I estimate this is degrading my ability to 
decode FT8 signals on 6 by nearly 20 dB compared to the noise level generated 
by a 50 ohm resistor.  I don’t use an LNA ahead of the radio – would be 
pointless.  I don’t use the noise reduction feature in the radio either as it 
tends to lose very weak signals completely. 

 

Wondering if I can use the DSP in my TS590 to narrow the receiver bandwidth to 
perhaps 300 -500 Hz around a known offset to help pick weak signals out of the 
noise? I realize that the WSJT program filters the audio into much narrower BW 
bins so all the receiver filtering can do is reduce the receiver gain reduction 
caused by the noise pumping up the AGC but that might be beneficial.  Likewise, 
would using the DSP notch to suppress a single strong local signal or birdie 
help since strong signals also reduce receiver gain?  Should I deselect the 
flatness option if I use these tools? Would narrowing the waterfall span help 
any since the program ignores anything outside that span? Would appreciate any 
insight you can share.

 

Joe W0FY

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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 noise estimates

[Andrew Neumeier via wsjt-devel]

 Joe,
Just a comment here.  I use FT8 frequently and almost always on 2 meters.  My 
interest is in weak signals.  I use a Omni VII here, with a transverter.  I 
have had some luck using my notch filter on very weak FT8signals.  Setting the 
notch width at about 75hz, I have been using the edge of the filter to enhance 
the signals I am looking for.  So, the notch is not directly on the desired 
signal, but set a few hundred hertz from it, usuallybelow it.  Of course, 
placing the notch directly on the signal would erase it, but I don't use it 
that way.  I have worked a number of stations this way.  It took some playing 
around to get this to work, and it does not alwayswork, and one must see the 
signal first and have a decode failure, before turning to this remedy.  

Just my two cents.
Best of luck,73,Andy, ka2uqw


On Saturday, December 9, 2023 at 10:05:26 PM EST, w0fy--- via wsjt-devel 
 wrote:  
 
 
Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the signals and 
noise over the bandwidth selected on the waterfall and call that the noise 
power level or does it take a quick snapshot of  the background noise level 
during the brief quiet period at the end of each 15 second FT8 sequence? Or is 
it more complicated than that?

  

I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that if 
not AWGN is pretty close to it.  10 meters is even worse. The DSP noise blanker 
in my TS590 will reduce it slightly. I estimate this is degrading my ability to 
decode FT8 signals on 6 by nearly 20 dB compared to the noise level generated 
by a 50 ohm resistor.  I don’t use an LNA ahead of the radio – would be 
pointless.  I don’t use the noise reduction feature in the radio either as it 
tends to lose very weak signals completely. 

  

Wondering if I can use the DSP in my TS590 to narrow the receiver bandwidth to 
perhaps 300 -500 Hz around a known offset to help pick weak signals out of the 
noise? I realize that the WSJT program filters the audio into much narrower BW 
bins so all the receiver filtering can do is reduce the receiver gain reduction 
caused by the noise pumping up the AGC but that might be beneficial.  Likewise, 
would using the DSP notch to suppress a single strong local signal or birdie 
help since strong signals also reduce receiver gain?  Should I deselect the 
flatness option if I use these tools? Would narrowing the waterfall span help 
any since the program ignores anything outside that span? Would appreciate any 
insight you can share.

  

Joe W0FY

  

  
___
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 noise estimates

[Reino Talarmo via wsjt-devel]

Hi Joe, 
Some quick comments in-line.

73, Reino OH3mA

> Sent: Sunday, December 10, 2023 4:56 AM
> Subject: [wsjt-devel] WSJT noise estimates

> Been wondering how WSJT-X generates the noise power
estimate it uses to calculate SNR for each FT8 signal. 
Does it simply collect all the signals and noise over
the bandwidth selected on the waterfall and call that
the noise power level or does it take a quick snapshot
of  the background noise level during the brief quiet
period at the end of each 15 second FT8 sequence? Or is
it more complicated than that?
3mA: The S/N calculation process is pretty complicated.
It estimates noise over the whole receiver bandwidth and
uses 2500 Hz as the reference bandwidth. Some other
implementations try to calculate S/N over the individual
signal bandwidth, 50Hz, and the values are not directly
comparable.

> I am plagued with a S2 -S3 noise level on 6 meters
nearly all the time that if not AWGN is pretty close to
it.  10 meters is even worse. The DSP noise blanker in
my TS590 will reduce it slightly. I estimate this is
degrading my ability to decode FT8 signals on 6 by
nearly 20 dB compared to the noise level generated by a
50 ohm resistor.  I don’t use an LNA ahead of the radio
– would be pointless.  I don’t use the noise reduction
feature in the radio either as it tends to lose very
weak signals completely. 
3mA: Noise blanker may help only, if the noise have high
and short peaks and the noise is cancelled e.g. limited
at a wide bandwidth point of the receiver chain. On AWGN
it does not help. Then the resulting distortion noise is
distributed over a wide frequency range. Your assumption
about the degradation may be a bit pessimistic,
depending on the noise type, S2 - S3 is quite low
compared what is typical on lower HF.

> Wondering if I can use the DSP in my TS590 to narrow
the receiver bandwidth to perhaps 300 -500 Hz around a
known offset to help pick weak signals out of the noise?
I realize that the WSJT program filters the audio into
much narrower BW bins so all the receiver filtering can
do is reduce the receiver gain reduction caused by the
noise pumping up the AGC but that might be beneficial.  
3mA: The additional receiver bandwidth reduction
improves the calculated S/N values as there is less
noise. But the decoding sensitivity does not usually
improve as long as the linearity of the receiver chain
is kept. There is some S/N calculation oddities at the
edges of a narrow bandwidth. I don't know the actual
reason, but I have recorded up to 40 dB additional
variations of S/N values in a comparison of the same
messages between narrow and wide bandwidths. 

> Likewise, would using the DSP notch to suppress a
single strong local signal or birdie help since strong
signals also reduce receiver gain?  
3mA: That seems to help. Especially, when the disturbing
signal is not very close to the wanted signal. 

> Should I deselect the flatness option if I use these
tools? 
3mA: To my knowledge the flatness option is only for
waterfall display, not for the decoding process.
 
Would narrowing the waterfall span help any since the
program ignores anything outside that span? 
3mA: That is about equivalent as usage of a narrow
filter. If signals outside of the waterfall are not
causing distortion noise (overdriving receiver), then
there will be an apparent S/N improvement, but not a
real decoding improvement. There is another possible
decoding improvement as there are less signal candidates
to process, Decoding is only attempted on frequencies
inside the waterfall. Well at least in principle, I have
seem rear instances, where also signal outside the
waterfall has been decoded.

> Would appreciate any insight you can share.

Joe W0FY

PS. 3mA i.e. is 3 milliamps, my local nickname.



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

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Joe Taylor via wsjt-devel]

I agree.  It's good enough as you have it.

-- Joe

On 12/8/2023 2:50 PM, Uwe, DG2YCB via wsjt-devel wrote:

Hi all,

Once again regarding my question about EU / AS Turkey: My commit only 
changes the displayed country name. Theoretically, the distinction 
between continents etc. should therefore remain unaffected. I have just 
looked up how LotW and QRZ.com do it. There is also only one entry 
there, namely "Turkey". So this should not be wrong if this is also the 
case with WSJT-X in the future. If someone wants to differentiate 
between the two, all they have to do is activate the "Include extra WAE 
entites" checkbox. And why should this be treated differently for AF 
Italy than for EU Turkey?


How do you see it?

73 de Uwe, DG2YCB


Am 08.12.2023 um 18:50 schrieb Uwe, DG2YCB via wsjt-devel:
This may all be correct, but at least to me, the decisive factor is 
what the DXCC rules are. And according to the DXCC list 
 available 
to me, there is only one "Turkey", namely DXCC No. 390.


TA-TC* Turkey EU/AS 39 20 390

73 de DG2YCB,
Uwe

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


Am 08.12.2023 um 18:22 schrieb robert evans LAST_NAME via wsjt-devel:
East Thrace or Eastern Thrace, also known as Turkish Thrace or 
European Turkey, is the part of Turkey that is geographically a part 
of Southeast Europe. It accounts for 3.03% of Turkey's land area and 
15% of its population. The largest city is Istanbul, which straddles 
the Bosporus between Europe and Asia.

Asiatic Turkey is east of the Bosporus.
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
Merhaba Arkadaslar. Nasiliniz?
On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel 
 wrote:

Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results: 
There seems to be nowhere specified which countries the WAE entities 
shall be assigned to when the "Include extra WAE entites" checkbox 
is *not* checked, neither in the CTY.DAT file nor in WSJT-X. This 
means, if these entities are not queried, "" appears as a country 
name. Quite logical in my eyes.


Therefore, I reprogrammed it in a way, that the WAE entities are now 
always queried but that these special country names are replaced by 
the correct DXCCs later in case the "Include extra WAE entites" 
checkbox is not checked.


The first tests look already promising. (My setup: Two instances 
connected via virtual audio, meaning that nothing goes over HF, and 
I can simulate almost each QSO situation.)




By the way, what is with "European Turkey"? Must both "Asiatic 
Turkey" and "European Turkey" then be displayed as "Turkey" if the 
"Include extra WAE entites" checkbox is not checked?


Did I forget anything else?

73 de DG2YCB,
Uwe

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


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:
This message is rather long, but I want to address this issue so it 
can be fixed before WSJT-X 2.7 is released.  Also note that this 
message contains a lot of formatting.  If it doesn't pass through 
the mailing list correctly, please contact me and I can send you 
the original copy.

I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej 
 wrote:


I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put
the cty.dat file ( which does show Austria , not Italy.  and
put it the the save folder of each of my wsjt versions..   am I
in the wrong folder, because it still shows Italy still

Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria


He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.

After some back-and-forth with Brett VR2BG today, I think I might 
understand the problem.  I believe that WSJT-X is either parsing or 
using the country file incorrectly.

First some background:
The CQWW DX contest uses two different country lists.  It uses the 
ARRL DXCC lists, plus five (5) entities which are multipliers for 
the WAEDC contest, plus one other:

https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/
Look at the bottom of that page for "WAE Country List".  It lists 
these 

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Uwe, DG2YCB via wsjt-devel]

Hi all,

Once again regarding my question about EU / AS Turkey: My commit only
changes the displayed country name. Theoretically, the distinction
between continents etc. should therefore remain unaffected. I have just
looked up how LotW and QRZ.com do it. There is also only one entry
there, namely "Turkey". So this should not be wrong if this is also the
case with WSJT-X in the future. If someone wants to differentiate
between the two, all they have to do is activate the "Include extra WAE
entites" checkbox. And why should this be treated differently for AF
Italy than for EU Turkey?

How do you see it?

73 de Uwe, DG2YCB


Am 08.12.2023 um 18:50 schrieb Uwe, DG2YCB via wsjt-devel:

This may all be correct, but at least to me, the decisive factor is
what the DXCC rules are. And according to the DXCC list
 available
to me, there is only one "Turkey", namely DXCC No. 390.

TA-TC* Turkey EU/AS 39 20 390

73 de DG2YCB,
Uwe

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


Am 08.12.2023 um 18:22 schrieb robert evans LAST_NAME via wsjt-devel:

East Thrace or Eastern Thrace, also known as Turkish Thrace or
European Turkey, is the part of Turkey that is geographically a part
of Southeast Europe. It accounts for 3.03% of Turkey's land area and
15% of its population. The largest city is Istanbul, which straddles
the Bosporus between Europe and Asia.
Asiatic Turkey is east of the Bosporus.
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
Merhaba Arkadaslar. Nasiliniz?

On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel
 wrote:
Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results:
There seems to be nowhere specified which countries the WAE entities
shall be assigned to when the "Include extra WAE entites" checkbox
is *not* checked, neither in the CTY.DAT file nor in WSJT-X. This
means, if these entities are not queried, "" appears as a country
name. Quite logical in my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by
the correct DXCCs later in case the "Include extra WAE entites"
checkbox is not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and
I can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic
Turkey" and "European Turkey" then be displayed as "Turkey" if the
"Include extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

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


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through
the mailing list correctly, please contact me and I can send you
the original copy.
I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej
 wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put
the cty.dat file ( which does show Austria , not Italy.  and
put it the the save folder of each of my wsjt versions..   am I
in the wrong folder, because it still shows Italy still

Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria

He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.

After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.
First some background:
The CQWW DX contest uses two different country lists.  It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for
the WAEDC contest, plus one other:
https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European entities:

  * 4U1V (Vienna Int'l Center)
  * GM/s (Shetland & Faire Islands)
  * IT (without IG9/IH9 Zone 33) (Sicily)
  * JW/b (Bear Island)
  * TA1 

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Uwe, DG2YCB via wsjt-devel]

This may all be correct, but at least to me, the decisive factor is what
the DXCC rules are. And according to the DXCC list
 available
to me, there is only one "Turkey", namely DXCC No. 390.

TA-TC* Turkey EU/AS 39 20 390

73 de DG2YCB,
Uwe

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


Am 08.12.2023 um 18:22 schrieb robert evans LAST_NAME via wsjt-devel:

East Thrace or Eastern Thrace, also known as Turkish Thrace or
European Turkey, is the part of Turkey that is geographically a part
of Southeast Europe. It accounts for 3.03% of Turkey's land area and
15% of its population. The largest city is Istanbul, which straddles
the Bosporus between Europe and Asia.
Asiatic Turkey is east of the Bosporus.
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
Merhaba Arkadaslar. Nasiliniz?

On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel
 wrote:
Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results: There
seems to be nowhere specified which countries the WAE entities shall
be assigned to when the "Include extra WAE entites" checkbox is *not*
checked, neither in the CTY.DAT file nor in WSJT-X. This means, if
these entities are not queried, "" appears as a country name. Quite
logical in my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by
the correct DXCCs later in case the "Include extra WAE entites"
checkbox is not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and I
can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic
Turkey" and "European Turkey" then be displayed as "Turkey" if the
"Include extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

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


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through
the mailing list correctly, please contact me and I can send you the
original copy.
I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej
 wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put the
cty.dat file ( which does show Austria , not Italy.  and put it
the the save folder of each of my wsjt versions..   am I in the
wrong folder, because it still shows Italy still

Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria

He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.

After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.
First some background:
The CQWW DX contest uses two different country lists. It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for
the WAEDC contest, plus one other:
https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European entities:

  * 4U1V (Vienna Int'l Center)
  * GM/s (Shetland & Faire Islands)
  * IT (without IG9/IH9 Zone 33) (Sicily)
  * JW/b (Bear Island)
  * TA1 (European part of Turkey)

Now IG9/IH9 are special.  Normally they would be included as part of
Sicily, but they are in Africa, not Europe.  Therefore they are
counted as a separate multiplier in CQWW DX (but not in WAEDC)
There is another point to take into account.  A "prefix" in the
country file can be either a prefix or a full callsign.  Full
callsigns are prefixed with '='.  You will see some examples in the
next part. *Matching a full callsign should always have priority
over matching a prefix (partial callsign). *
One last point is that the "prefix" at the end of the line in the
country file that contains the entity name is for display purposes
only.  It should never be 

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[robert evans LAST_NAME via wsjt-devel]

East Thrace or Eastern Thrace, also known as Turkish Thrace or European Turkey, 
is the part of Turkey that is geographically a part of Southeast Europe. It 
accounts for 3.03% of Turkey's land area and 15% of its population. The largest 
city is Istanbul, which straddles the Bosporus between Europe and Asia.
 
Asiatic Turkey is east of the Bosporus.
 
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
 
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
 
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
 
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
 
Merhaba Arkadaslar. Nasiliniz?
 
 
 

> On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel 
>  wrote:
>  
>  
> Hi Jim and all,
> 
> I have analyzed our WSJT-X code regarding this aspect. Results: There seems 
> to be nowhere specified which countries the WAE entities shall be assigned to 
> when the "Include extra WAE entites" checkbox is not checked, neither in the 
> CTY.DAT file nor in WSJT-X. This means, if these entities are not queried, "" 
> appears as a country name. Quite logical in my eyes.
> 
> Therefore, I reprogrammed it in a way, that the WAE entities are now always 
> queried but that these special country names are replaced by the correct 
> DXCCs later in case the "Include extra WAE entites" checkbox is not checked.
> 
> The first tests look already promising. (My setup: Two instances connected 
> via virtual audio, meaning that nothing goes over HF, and I can simulate 
> almost each QSO situation.)
> 
> 
> 
> By the way, what is with "European Turkey"? Must both "Asiatic Turkey" and 
> "European Turkey" then be displayed as "Turkey" if the "Include extra WAE 
> entites" checkbox is not checked?
> 
> Did I forget anything else?
> 
> 73 de DG2YCB,
> Uwe
> 
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg2...@gmx.de mailto:dg2...@gmx.de
> Info:http://www.qrz.com/db/DG2YCB
> 
> 
> Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:
> 
> > This message is rather long, but I want to address this issue so it can be 
> > fixed before WSJT-X 2.7 is released.  Also note that this message contains 
> > a lot of formatting.  If it doesn't pass through the mailing list 
> > correctly, please contact me and I can send you the original copy.
> >  
> >  
> > I recently received this message:
> > 
> > On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej  > mailto:ve3...@gmail.com> wrote:
> >  
> > 
> > > I am getting 4u1a on ft4 today, and wsjt-x is showing it as Italy.  I 
> > > have downloaded the updated cty-3388 file, and put the cty.dat file ( 
> > > which does show Austria , not Italy.  and put it the the save folder of 
> > > each of my wsjt versions..   am I in the wrong folder, because it still 
> > > shows Italy still
> > > 
> >  
> > 
> > Ron Whitsel, W3RJW also wrote me:
> > 
> > > 
> > > 4U1A comes up as 'Italy' in WSJT-X Band Activity window.Should be 
> > > Austria
> > > 
> >  
> > He later wrote:
> >  
> > 
> > > 
> > > OK I fixed it:
> > > 
> > > Added:
> > > 
> > > Removed 4U from Italy
> > > 
> > > Now 4U1A comes up as Austria in WSJT-X.
> > > 
> >  
> > After some back-and-forth with Brett VR2BG today, I think I might 
> > understand the problem.  I believe that WSJT-X is either parsing or using 
> > the country file incorrectly.
> >  
> > First some background:
> >  
> > The CQWW DX contest uses two different country lists.  It uses the ARRL 
> > DXCC lists, plus five (5) entities which are multipliers for the WAEDC 
> > contest, plus one other:
> >  
> > https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/
> >  
> > Look at the bottom of that page for "WAE Country List".  It lists these 
> > additional European entities:
> > * 4U1V (Vienna Int'l Center)
> > 
> > * GM/s (Shetland & Faire Islands)
> > 
> > * IT (without IG9/IH9 Zone 33) (Sicily)
> > 
> > * JW/b (Bear Island)
> > 
> > * TA1 (European part of Turkey)
> > 
> > Now IG9/IH9 are special.  Normally they would be included as part of 
> > Sicily, but they are in Africa, not Europe.  Therefore they are counted as 
> > a separate multiplier in CQWW DX (but not in WAEDC)
> >  
> > There is another point to take into account.  A "prefix" in the country 
> > file can be either a prefix or a full callsign.  Full callsigns are 
> > prefixed with '='.  You will see some examples in the next part.  Matching 
> > a full callsign should always have priority over matching a prefix (partial 
> > callsign). 
> >  
> > One last point is that the "prefix" at the end of the line in the country 
> > file that contains the entity name is for display purposes only.  It should 
> > never be included in 

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Uwe, DG2YCB via wsjt-devel]

Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results: There
seems to be nowhere specified which countries the WAE entities shall be
assigned to when the "Include extra WAE entites" checkbox is *not*
checked, neither in the CTY.DAT file nor in WSJT-X. This means, if these
entities are not queried, "" appears as a country name. Quite logical in
my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by the
correct DXCCs later in case the "Include extra WAE entites" checkbox is
not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and I
can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic Turkey"
and "European Turkey" then be displayed as "Turkey" if the "Include
extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

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


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through the
mailing list correctly, please contact me and I can send you the
original copy.


I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej 
wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put the
cty.dat file ( which does show Austria , not Italy.  and put it
the the save folder of each of my wsjt versions..  am I in the
wrong folder, because it still shows Italy still


Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria


He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.


After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.

First some background:

The CQWW DX contest uses two different country lists.  It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for the
WAEDC contest, plus one other:

https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European entities:

  * 4U1V (Vienna Int'l Center)
  * GM/s (Shetland & Faire Islands)
  * IT (without IG9/IH9 Zone 33) (Sicily)
  * JW/b (Bear Island)
  * TA1 (European part of Turkey)

Now IG9/IH9 are special.  Normally they would be included as part of
Sicily, but they are in Africa, not Europe. Therefore they are counted
as a separate multiplier in CQWW DX (but not in WAEDC)

There is another point to take into account.  A "prefix" in the
country file can be either a prefix or a full callsign. Full callsigns
are prefixed with '='.  You will see some examples in the next part.
*Matching a full callsign should always have priority over matching a
prefix (partial callsign). *

One last point is that the "prefix" at the end of the line in the
country file that contains the entity name is for display purposes
only.  It should never be included in the list of prefixes for the
given entity.


Now let's focus specifically on the country file.  I have highlighted
some prefixes/callsigns.

Here is the 4U1/v entity as shown in the country file:

Vienna Intl Ctr:    15:  28:  EU:   48.20:   -16.30:    -1.0:  *4U1V:
    =4U0R,=4U100QO,=4U1A,=4U1VIC,=4U2U,=4Y1A,=C7A;

Here is the Italy entity as shown in the country file:

Italy:    15:  28:  EU:   42.82:   -12.58:    -1.0:  I:
4U,I,=I2DMK/RM,=IT9ELM/0,=IT9PQJ/0;

Here is the Austria entity as shown in the country file;

Austria:    15:  28:  EU:   47.33:   -13.33:    -1.0:  OE:
    OE,=4U0R,=4U100QO,=4U1A,=4U1VIC,=4U2U,=4Y1A,=C7A;

You should notice a few things:

 1. The "prefix" at the end of the line beginning with "Vienna Intl
Ctr" has a '*' in front of it.  That means that this entity is
only used in the CQWW DX and WAEDC contests.  It is not a DXCC entity.
 2. 4U1A (full callsign) is listed twice, once under "Vienna Intl Ctr"
and once under "Austria"
 3. 4U is listed as a prefix for Italy.

Regarding #3, this was done so that "new" (previously unknown) 4U
callsigns that are spotted on the DX cluster will propagate through
the network.  If that prefix mapping were not there, those calls would
be ignored because they could not be associated with any entity in the
country file.  Tis was done at the request of Lee VE7CC.  4U has been
used numerous times from Italy.  4U24OCT is a recent example.  The 

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Jim Reisert AD1C via wsjt-devel]

On Thu, Dec 7, 2023 at 2:46 AM Reino Talarmo wrote:

> From: Jim Reisert AD1C via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> > Sent: Thursday, December 7, 2023 3:51 AM
>
> > 3. 4U is listed as a prefix for Italy.
> Regarding #3, this was done so that "new" (previously unknown) 4U
> callsigns that are spotted on the DX cluster will propagate through the
> network.  If that prefix mapping were not there, those calls would be
> ignored because they could not be associated with any entity in the country
> file.  Tis was done at the request of Lee VE7CC.  4U has been used numerous
> times from Italy.  4U24OCT is a recent example.  The QTH is the Global
> Service Centre ARC in Brindisi, Italy, normally 4U1GSC.  4U could have just
> as easily been listed as a prefix for Austria, but I chose Italy based on
> past experience.
>
> Thanks Jim for clarification,
> Just for educating myself may I ask, is the United Nations 4U the only
> "country code" that is allowed to pop up in any country without a country
> prefix xxx/?
>

Hi Reino,

First, I heard and worked 4U1A this morning on 20m FT8, using WSJT-X 2.7
RC2.  It was identified as "Vienna Intl Ctr" in the program, so I don't
quite understand the problem that people have been having.  I was using the
country file released on November 29, without any edits.  Perhaps the
parsing of the country file was changed from the GA release to the 2.7 RC
release(s).

4U used to be used in the 1970s and 1980s from various locations in the
Middle East by members of various peacekeeping forces.  It was also used
from a few locations in Africa in the 1990s (such as 4U9U in Burundi).I
can send you my entire list if you want, but it's probably not useful.

Currently, the only use of this prefix is by the Vienna Int'l Center
(4U1VIC etc), the United Nations HQ in New York (4U1UN etc) and the Global
Service Centre ARC in Brindisi (4U1VIC etc.)

Second question is how long "visiting" individual callsigns are kept in the
> cty.dat file? Related question is why e.g. 4U24OCT and 4U1GSC are not
> listed under Italy? Perhaps those will be listed, if the 4U movement to
> Austria is implemented.
>

My software "activates" a callsign 45 days before it is scheduled to be
used, through 45 days past the end.  This allows a callsign to remain
active in the country file throughout the two major CQWW DX contests, Phone
at the end of October and CW at the end of November.  Callsigns are
"retired" because some software is unable to deal with very large country
files.  WSJT-X uses the big CTY.DAT file, which is quite large, and does
not have this limitation:

https://www.country-files.com/contest/wsjt-x/

(follow the link to CTY.DAT at the bottom of the web page).

Could it be sensible that 4U will be listed as a separate "country" in
> addition to the United Nations HQ with a line ending e.g. "Location
> currently unknown:"? Of course the new call sign will be listed in the
> proper entity as soon as it is known.
>

I'd rather not do it this way.  It's best if any prefix or callsign has a
valid DXCC entity code associated with it:

https://www.adif.org/314/ADIF_314.htm#DXCC_Entity_Code_Enumeration

The main points I was trying to make about the country file were:

1.  Full callsigns take priority over prefixes.

2.  WSJT-X should probably just be skipping the "WAEDC" entities, those
which have a '*' in front of the prefix at the end of the first line.

3.   Callsigns are duplicated in the file if they are also part of a
"WAEDC" entity.  Software has to make a decision.  If it is using the WAEDC
entities, then a callsign found in that list should be ignored if found
elsewhere in the file.  If the software is not using the WAEDC entities,
then those entities in the country file can be skipped, and the duplicate
callsign problem is avoided.

-- 
Jim Reisert AD1C, , https://ad1c.us
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

[Reino Talarmo via wsjt-devel]

> From: Jim Reisert AD1C via wsjt-devel 
> [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: Thursday, December 7, 2023 3:51 AM

> 3. 4U is listed as a prefix for Italy.
Regarding #3, this was done so that "new" (previously unknown) 4U callsigns 
that are spotted on the DX cluster will propagate through the network.  If that 
prefix mapping were not there, those calls would be ignored because they could 
not be associated with any entity in the country file.  Tis was done at the 
request of Lee VE7CC.  4U has been used numerous times from Italy.  4U24OCT is 
a recent example.  The QTH is the Global Service Centre ARC in Brindisi, Italy, 
normally 4U1GSC.  4U could have just as easily been listed as a prefix for 
Austria, but I chose Italy based on past experience.

Thanks Jim for clarification,
Just for educating myself may I ask, is the United Nations 4U the only "country 
code" that is allowed to pop up in any country without a country prefix xxx/? 
Second question is how long "visiting" individual callsigns are kept in the 
cty.dat file? Related question is why e.g. 4U24OCT and 4U1GSC are not listed 
under Italy? Perhaps those will be listed, if the 4U movement to Austria is 
implemented.
Could it be sensible that 4U will be listed as a separate "country" in addition 
to the United Nations HQ with a line ending e.g. "Location currently unknown:"? 
Of course the new call sign will be listed in the proper entity as soon as it 
is known. 

73, Reino OH3mA



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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[Joe Taylor via wsjt-devel]

Geoff --

I was not trying to justify our code that posts only the first decode of 
duplicates in the same Rx sequence, just to tell you what the code does.


I'm sure you can find many places where we have done something simple 
and straightforward, "just to get it going," even when something 
arguably "better" can be imagined.  The "something better" might be done 
at some later time.


If you would like to submit a patch, please do so.

-- 73, Joe, K1JT

On 12/1/2023 3:53 AM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:

Puzzled by your response.  I agree with not uploading dupes, but I can't 
fathom why you wouldn't compare dupes and pick the strongest one.  In a 
situation like this, clearly the strongest signal is representative of 
the real conditions. I can't think of a use for uploading any other 
decode, besides as punishment for any stations that dare to have their 
spurs strong enough to be heard (ironically the worse their transmitter 
is, the less they get punished).


Anyway, it sounds like a conscious choice, so good luck with it.

Regards,

Geoff VK2WA



On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:

Hi Geoff,

On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
I just had a funny one with a close station, S9+10dB, the 
transmission was +32 SNR but WSJT-X uploaded only the first decode at 
-19dB:


Queried for all spots me + target, unique NOT ticked:

Would have been better to upload the 32dB spot!


Perhaps that would be your choice.  It was not ours.

We don't post duplicate decodes.  Any decode of a message identical to 
one already staged for posting in the same Rx sequence is considered a 
dupe and discarded.


-- Joe


___
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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[William Smith via wsjt-devel]

Absolutely, but this isn’t “The strongest signal over the last n decode 
periods”, its “The strongest signal _this_ decode period”, which might help 
reduce the reporting of spurs.

And yeah, it’s a rathole.

73, Willie N1JBJ

> On Dec 1, 2023, at 7:33 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Actually the strongest is not indicative at all of current conditions.

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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[Stefan HB9TMC via wsjt-devel]

Yes, for WSPR/FST4W signal reports are essential.
For FT8 etc. it probably doesn't matter much, but that was not the topic.

73
Stefan

On 01.12.23 13:33, Black Michael via wsjt-devel wrote:


And does anybody even look at that data anyways?






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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[Black Michael via wsjt-devel]

Actually the strongest is not indicative at all of current conditions.  You can 
have momentary band conditions either way.

What matters is what signal you heard them at.  e.g. "I initially received you 
at XXdB".  If a user wants to see band conditions for their callsign they can 
use PSKReporter or HamSpots.net.
One signal report doesn't tell you much.

And does anybody even look at that data anyways?

Mike W9MDB









On Friday, December 1, 2023 at 06:26:37 AM CST, William Smith via wsjt-devel 
 wrote: 





Well, OK, Joe wrote the program, so he really is the ultimate authority.

But the “decoded a spur and used that number for the SNR” seems to be the real 
issue here.

In an ideal world, signals for a particular call should be sorted _after_ all 
the decodes are done, and the strongest (very probably not the spur) should be 
used.

However, if the program flow is “Decode at a random spot on the waterfall, 
queue the results to upload to PSKreporter, set as number to report to QSO 
partner”, and then another one comes along, you have to do all these gyrations 
to determine if it’s ‘better’ and replace it, and unqueue from PSKreporter and 
all this messy stuff.

73, Willie N1JBJ

> On Dec 1, 2023, at 3:53 AM, Geoff Van der Wagen via wsjt-devel 
>  wrote:
> 
> Hi Joe,
> 
> Puzzled by your response.  I agree with not uploading dupes, but I can't 
> fathom why you wouldn't compare dupes and pick the strongest one.  In a 
> situation like this, clearly the strongest signal is representative of the 
> real conditions. I can't think of a use for uploading any other decode, 
> besides as punishment for any stations that dare to have their spurs strong 
> enough to be heard (ironically the worse their transmitter is, the less they 
> get punished).
> 
> Anyway, it sounds like a conscious choice, so good luck with it.
> 
> Regards,
> 
> Geoff VK2WA
> 
> 
> 
> On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:
>> Hi Geoff,
>> 
>> On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
>>> I just had a funny one with a close station, S9+10dB, the transmission was 
>>> +32 SNR but WSJT-X uploaded only the first decode at -19dB:
>>> 
>>> Queried for all spots me + target, unique NOT ticked:
>>> 
>>> Would have been better to upload the 32dB spot!
>> 
>> Perhaps that would be your choice.  It was not ours.
>> 
>> We don't post duplicate decodes.  Any decode of a message identical to one 
>> already staged for posting in the same Rx sequence is considered a dupe and 
>> discarded.
>> 
>>    -- Joe
>> 
>> 
>> ___
>> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[William Smith via wsjt-devel]

Well, OK, Joe wrote the program, so he really is the ultimate authority.

But the “decoded a spur and used that number for the SNR” seems to be the real 
issue here.

In an ideal world, signals for a particular call should be sorted _after_ all 
the decodes are done, and the strongest (very probably not the spur) should be 
used.

However, if the program flow is “Decode at a random spot on the waterfall, 
queue the results to upload to PSKreporter, set as number to report to QSO 
partner”, and then another one comes along, you have to do all these gyrations 
to determine if it’s ‘better’ and replace it, and unqueue from PSKreporter and 
all this messy stuff.

73, Willie N1JBJ

> On Dec 1, 2023, at 3:53 AM, Geoff Van der Wagen via wsjt-devel 
>  wrote:
> 
> Hi Joe,
> 
> Puzzled by your response.  I agree with not uploading dupes, but I can't 
> fathom why you wouldn't compare dupes and pick the strongest one.  In a 
> situation like this, clearly the strongest signal is representative of the 
> real conditions. I can't think of a use for uploading any other decode, 
> besides as punishment for any stations that dare to have their spurs strong 
> enough to be heard (ironically the worse their transmitter is, the less they 
> get punished).
> 
> Anyway, it sounds like a conscious choice, so good luck with it.
> 
> Regards,
> 
> Geoff VK2WA
> 
> 
> 
> On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:
>> Hi Geoff,
>> 
>> On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
>>> I just had a funny one with a close station, S9+10dB, the transmission was 
>>> +32 SNR but WSJT-X uploaded only the first decode at -19dB:
>>> 
>>> Queried for all spots me + target, unique NOT ticked:
>>> 
>>> Would have been better to upload the 32dB spot!
>> 
>> Perhaps that would be your choice.  It was not ours.
>> 
>> We don't post duplicate decodes.  Any decode of a message identical to one 
>> already staged for posting in the same Rx sequence is considered a dupe and 
>> discarded.
>> 
>> -- Joe
>> 
>> 
>> ___
>> 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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead ofmain decode for strong signals

[OG55W via wsjt-devel]

Geoff!
Do You mean that somebody is really looking FT8 or FT4 reports???
If You can see the call sign on Your screen, it is possible to have a QSO. You 
just have to find clear transmitting frequency.
I have worked many DX QSOs and after the QSO have noticed that I was using only 
5 W:

73 Keijo OG5O

Lähetetty Windowsin Sähköpostiista

Lähettäjä: Geoff Van der Wagen via wsjt-devel
Lähetetty: perjantai 1. joulukuuta 2023 10.56
Vastaanottaja: wsjt-devel@lists.sourceforge.net
Kopio: Geoff Van der Wagen
Aihe: Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead ofmain 
decode for strong signals

Hi Joe,

Puzzled by your response.  I agree with not uploading dupes, but I can't 
fathom why you wouldn't compare dupes and pick the strongest one.  In a 
situation like this, clearly the strongest signal is representative of 
the real conditions. I can't think of a use for uploading any other 
decode, besides as punishment for any stations that dare to have their 
spurs strong enough to be heard (ironically the worse their transmitter 
is, the less they get punished).

Anyway, it sounds like a conscious choice, so good luck with it.

Regards,

Geoff VK2WA



On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:
> Hi Geoff,
>
> On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
>> I just had a funny one with a close station, S9+10dB, the 
>> transmission was +32 SNR but WSJT-X uploaded only the first decode at 
>> -19dB:
>>
>> Queried for all spots me + target, unique NOT ticked:
>>
>> Would have been better to upload the 32dB spot!
>
> Perhaps that would be your choice.  It was not ours.
>
> We don't post duplicate decodes.  Any decode of a message identical to 
> one already staged for posting in the same Rx sequence is considered a 
> dupe and discarded.
>
> -- Joe
>
>
> ___
> 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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[Stefan HB9TMC via wsjt-devel]

I would also prefer if the strongest signal would be uploaded.

73
Stefan


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

Re: [wsjt-devel] WSJT-X WSPR decoder uploads spur decode instead of main decode for strong signals

[Geoff Van der Wagen via wsjt-devel]

Hi Joe,

Puzzled by your response.  I agree with not uploading dupes, but I can't 
fathom why you wouldn't compare dupes and pick the strongest one.  In a 
situation like this, clearly the strongest signal is representative of 
the real conditions. I can't think of a use for uploading any other 
decode, besides as punishment for any stations that dare to have their 
spurs strong enough to be heard (ironically the worse their transmitter 
is, the less they get punished).


Anyway, it sounds like a conscious choice, so good luck with it.

Regards,

Geoff VK2WA



On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:

Hi Geoff,

On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
I just had a funny one with a close station, S9+10dB, the 
transmission was +32 SNR but WSJT-X uploaded only the first decode at 
-19dB:


Queried for all spots me + target, unique NOT ticked:

Would have been better to upload the 32dB spot!


Perhaps that would be your choice.  It was not ours.

We don't post duplicate decodes.  Any decode of a message identical to 
one already staged for posting in the same Rx sequence is considered a 
dupe and discarded.


-- Joe


___
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 WSPR decoder uploads spur decode instead of main decode for strong signals

[Joe Taylor via wsjt-devel]

Hi Geoff,

On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
I just had a funny one with a close station, S9+10dB, the transmission 
was +32 SNR but WSJT-X uploaded only the first decode at -19dB:


Queried for all spots me + target, unique NOT ticked:

Would have been better to upload the 32dB spot!


Perhaps that would be your choice.  It was not ours.

We don't post duplicate decodes.  Any decode of a message identical to 
one already staged for posting in the same Rx sequence is considered a 
dupe and discarded.


-- Joe


___
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 flagged as malware

[August Treubig via wsjt-devel]

You have met a “false Positive”. Most anti virus programs don’t recognize ham 
radio software.

Aug
AG5AT 
Sent from my iPad

> On Oct 27, 2023, at 3:40 PM, F4FPR Benjamin via wsjt-devel 
>  wrote:
> 
> Dear wsjt-x devel list,
> I’ve just tried to download the last update of WSJT-X version and it looks 
> like that the last version is flagged as the malware onto Sourceforge as such 
> as into VirusTotal, what is going on ?
> Best regards & 73
> Benjamin L / F4FPR / K5AW
> ___
> 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 flagged as malware

[Reino Talarmo via wsjt-devel]

It is only a false positive malware indication.  

73, Reino OH3mA


> -Original Message-
> From: F4FPR Benjamin via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Friday, October 27, 2023 11:36 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: F4FPR Benjamin 
> Subject: [wsjt-devel] WSJT-X 2.7.0 rc2 flagged as
> malware
> 
> Dear wsjt-x devel list,
> I’ve just tried to download the last update of WSJT-X
> version and it looks like that the last version is flagged as
> the malware onto Sourceforge as such as into
> VirusTotal, what is going on ?
> Best regards & 73
> Benjamin L / F4FPR / K5AW
> __
> _
> 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-devel Digest, Vol 116, Issue 10

[Erik Icket via wsjt-devel]

Hi Michael,

This was with MAP65.exe (version 3.0.1) packaged within WSJTX 2.7.0-rc2.
So, MAP65.exe is launched, and when that error occurs, it terminates.

73's Erik
ON4PB

-Original Message-
From: wsjt-devel-requ...@lists.sourceforge.net
 
Sent: Tuesday, 17 October 2023 15:16
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 116, Issue 10

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific than
"Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Fortran runtime error in MAP65 3.0.1 (Erik Icket)
   2. Re: Fortran runtime error in MAP65 3.0.1 (Black Michael)


--

Message: 1
Date: Tue, 17 Oct 2023 13:17:31 +0200
From: "Erik Icket" 
To: 
Subject: [wsjt-devel] Fortran runtime error in MAP65 3.0.1
Message-ID: <009101da00eb$85bea7b0$913bf710$@gmail.com>
Content-Type: text/plain;   charset="us-ascii"

Dear developers,

The following Fortran runtime error occurred a number of times in MAP65.exe
:

Running: C:\WSJT\wsjtx\bin\m65 -s
At line 13 of file C:\JTSDK64-Tools\WSJTX\BBdevelop\lib\pctile.f90
Fortran runtime error: Index '-240641' of dimension 1 of array 'tmp' below
lower bound of 1

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x
#1 0x
#2 0x
#3 0x
#4 0x
#5 0x
#6 0x
#7 0x
#8 0x
#9 0x
#10 0x
#11 0x
#12 0x
#13 0x
#14 0x
#15 0x
#16 0x


I have the impression this error occurs more frequently in the presence of
strong interference signals in the passband of MAP65.
Also, MAP65 runs with selected mode Q65A and JT65B.

For information, MAP65 (and QMAP) received its baseband feed from the new
MAP65/QMAP interface built into SDRConsole 3.3

73's Erik
ON4PB





--

Message: 2
Date: Tue, 17 Oct 2023 12:11:58 + (UTC)
From: Black Michael 
To: Erik Icket via wsjt-devel 
Subject: Re: [wsjt-devel] Fortran runtime error in MAP65 3.0.1
Message-ID: <1878016149.8854474.1697544718...@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

What version of WSJT-X?

Mike W9MDB








On Tuesday, October 17, 2023 at 06:23:56 AM CDT, Erik Icket via wsjt-devel
 wrote: 





Dear developers,

The following Fortran runtime error occurred a number of times in MAP65.exe
:

Running: C:\WSJT\wsjtx\bin\m65 -s
At line 13 of file C:\JTSDK64-Tools\WSJTX\BBdevelop\lib\pctile.f90
Fortran runtime error: Index '-240641' of dimension 1 of array 'tmp' below
lower bound of 1

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x
#1 0x
#2 0x
#3 0x
#4 0x
#5 0x
#6 0x
#7 0x
#8 0x
#9 0x
#10 0x
#11 0x
#12 0x
#13 0x
#14 0x
#15 0x
#16 0x


I have the impression this error occurs more frequently in the presence of
strong interference signals in the passband of MAP65.
Also, MAP65 runs with selected mode Q65A and JT65B.

For information, MAP65 (and QMAP) received its baseband feed from the new
MAP65/QMAP interface built into SDRConsole 3.3

73's Erik
ON4PB




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



--



--

Subject: Digest Footer

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


--

End of wsjt-devel Digest, Vol 116, Issue 10
***



___
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 Switching caller in TX1 message

[Joe Taylor via wsjt-devel]

On 10/10/2023 8:25 PM, Clay Couger N5YJZ via wsjt-devel wrote:

There is another bug in both 2.6.1 and 2.7.0 RC2 where the first call is 
always picked to respond to even if max dist is slected.


This behavior is not a bug.  "CQ Max Dist" is effective only when the 
Active Stations window is displayed, which apparently you have not done.


-- 73, Joe, K1JT


___
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 Switching caller in TX1 message

[Uwe, DG2YCB via wsjt-devel]

Hi Clay,

Thanks for this issue report. With WSJT-X, CQ: Max Dist only works with
certain contest messages, and when you have the Active Stations window
open. I have changed this with my wsjt-x_improved
 program. There it works also
for normal messages. This program also contains a number of bug fixes
that might also fix the first problem. Feel free to try it out, and then
please be so kind and report if the mentioned issues are gone with it.

Wsjt-x_improved is an extended version of WSJT-X. It has the same source
code core. I use it to try out new features and fixes that sometimes
become part of WSJT-X later. Examples were the mode buttons and numerous
detail improvements to the WSJT-X source code.

The main reason for offering two programs, WSJT-X and wsjt-x_improved,
is that there are two groups of users. One group has been using WSJT-X
for a long time and doesn't really want any changes or new features.
Just look at how few of the v2.6.1 users have tried v2.7.0-rc so far.
According to PSK Reporter statistics, that's only 9.7%. And then
remember the numerous protests just because we had introduced a new Tune
watchdog function.
The second group of users, on the other hand, would like to have exactly
such new features. They eagerly await every new improvement and
immediately test or use them intensively. This second group is currently
served with wsjt-x_improved. There are a lot of useful additional
features, bug fixes as well as new program versions as soon as it is
worthwhile (about three to four times as often as with WSJT-X).


73 de DG2YCB,
Uwe

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


Am 11.10.2023 um 02:25 schrieb Clay Couger via wsjt-devel:

After transmitting RR73 or 73 to WB0OQV, but before the next
transmission cycle I select 'I4RHP N5YJZ -11' message to send. WSJT-X
2.7.0 RS2 replaces my request with 'W8NGA N5YJZ -03' This issue is not
seen in WSJT-X 2.6.1

There is another bug in both 2.6.1 and 2.7.0 RC2 where the first call
is always picked to respond to even if max dist is slected.

Capture2.PNG


___
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-improved-community] [wsjtgroup] Solar Eclipse participation #general

[Black Michael via wsjt-devel]

I got some more info from the HamSCI group.  So if you could maintain one band 
for the duration of the  SEQP that would be best.
>From W2NAF
The SEQP is going to run for 10 hours from 1200-2200 UTC. See 
https://hamsci.org/seqp-rules
 

What we actually analyze will depend on the quality of the data we receive. We 
will likely be building off of the analysis published in 
https://doi.org/10.1029/2018GL077324, which focused on 1.8, 3.5, 7, and 14 MHz. 
We are also now at a higher point in the solar cycle, so hopefully the higher 
bands will also be useful.

 

TNX es 73 Nathaniel W2NAF



> 
> On 9/15/2023 1:04 PM, Mike Black W9MDB via groups.io wrote:
>> 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
>>
>> _._,_._,_
>> 
>> Groups.io Links:
>>
>> You receive all messages sent to this group.
>>
>> View/Reply Online (#1104)  
>> | Reply To Group 
>> 
>>  | Reply To Sender 
>> 
>>  | Mute This Topic  | New Topic 
>> 
>> Mute #general 
>> Your Subscription  | 
>> Contact Group Owner  | Unsubscribe 
>>  
>> [a...@alumni.caltech.edu]
>>
>> _._,_._,_
> 


___
Wsjt-x-improved-community mailing list
wsjt-x-improved-commun...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X as an AppImage

[Jeff Stillinger via wsjt-devel]

While this always seems to be a good idea on the surface, it really ties 
the hands of the software's flexibility and portability.  For example, I 
have run into Appimage issues with GQRX on various platforms.   Usually 
various library versions out of sync with the Appimage.   To the point 
where it's easier to just build GQRX from source and it just works.    
The same holds true for WSJT-X.   A end user such as myself operating at 
Enterprise Linux level (paid for) vs. someone with a rolling release 
that gets built daily.   My Appimage will run for 10 years, but the 
person on a rolling release may run fine today, but break after 
tomorrows update.  With the fix being a simple recompile.    It seems 
like the vast majority of the WSJT Linux user base is on a rolling 
release.   When a person is using a rolling release, rebuilding various 
packages is considered a normal daily task.


For me personally, an appimage would offer a nice alternative.   I could 
see myself giving up the various compile optimizations (higher 
speed/better memory usage) in favor of a simple copy/past, chmod 755, 
and go...




On 7/22/23 09:31, Daniel Uppström via wsjt-devel wrote:

Hi all,

I recently wrote about building and running WSJT-X in a Docker 
container ( 
https://sm6vfz.wordpress.com/2023/07/10/building-and-running-wsjt-x-in-a-docker-container/ 
). This works great for me and I no longer plan to run any of the 
built binaries.


But another option I have become aware of, would be to build the 
program as an AppImage ( https://appimage.org/ ).

Is there any experience here with that concept?
If it is living up to its promises it seems to be a nice way of 
distributing a program like WSJT-X in a format that runs on most 
linux/unix distros, instead of building packages for each and everyone 
of these.


/SM6VFZ




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


--
Jeff Stillinger - KB6IBB
KB6IBB Laboratories, Wylie Tx
http://kb6ibb-15.ham-radio-op.net/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X published to WinGet

[Chris Keller via wsjt-devel]

Fair point, Neal. The pull request process means there is human review and
approval, plus a set of automated malware checks, but it's certainly not
foolproof. If security is a top concern, building from source is probably
the best bet.

On Tue, Jul 18, 2023 at 9:49 AM Neal Pollack via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Regarding the winget repository for installs, and your statement:
> "
>
> *This is great for automated system installs! I'll attempt to keep the
> version here up-to-date, but any developer can submit manifest updates via
> GitHub pull request.*";
> Am I misunderstanding that this is a terrible security risk, since
> apparently anyone
> can alter the installation manifest, and therefore future installs could
> be installing
> malware rather than WSJT-X?Or do I misunderstand?
>
> Neal
>
> On Tue, Jul 18, 2023 at 5:59 AM 
> wrote:
>
>> Send wsjt-devel mailing list submissions to
>> wsjt-devel@lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> or, via email, send a message with subject or body 'help' to
>> wsjt-devel-requ...@lists.sourceforge.net
>>
>> You can reach the person managing the list at
>> wsjt-devel-ow...@lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of wsjt-devel digest..."
>>
>>
>> Today's Topics:
>>
>>1. WSJT-X published to WinGet (Chris Keller)
>>2. Transverter Offset (tom)
>>
>>
>> --
>>
>> Message: 1
>> Date: Mon, 17 Jul 2023 11:58:16 -0600
>> From: Chris Keller 
>> To: wsjt-devel@lists.sourceforge.net
>> Subject: [wsjt-devel] WSJT-X published to WinGet
>> Message-ID:
>> > kp...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello folks,
>>
>> I wanted to let you know that I've published a manifest
>>  for WSJT-X in
>> Microsoft's official Windows Package Manager, a.k.a. WinGet. Users
>> comfortable with the command line can now install WSJT-X with the command:
>>
>> winget install -e --id K1JT.wsjtx
>>
>> This is great for automated system installs! I'll attempt to keep the
>> version here up-to-date, but any developer can submit manifest updates via
>> GitHub pull request.
>>
>> 73,
>> Chris K0SWE
>> -- next part --
>> An HTML attachment was scrubbed...
>>
>> --
>>
>> Message: 2
>> Date: Tue, 18 Jul 2023 11:30:16 +0100
>> From: tom 
>> To: WSJT software development 
>> Subject: [wsjt-devel] Transverter Offset
>> Message-ID: <2d867620-9fa1-4cfc-a25d-e204f3d5c...@tkrh.co.uk>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi - posted on main list but no final solution.
>>
>> Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2
>>
>> Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue.
>> Used an offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to
>> 1.065 MHz.
>>
>>
>> Tried the example given on archive for 2m offset -116 and all worked
>> fine, cat kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed
>> 144 MHz.
>>
>> Could it be the , in offset freq -1268 is entered and software formats it
>> to -1,268.000 000 MHz.
>>
>> Tried the same setup with MSHV and WSJT-X-Improved and worked as expected
>> with -1268 offset. Cat and freq both ok.
>>
>> Thanks in advance for any suggestions but it does look like a bug rather
>> than user error.
>>
>> Tom GM8MJV
>> t...@tkrh.co.uk
>>
>>
>>
>>
>>
>> -- next part --
>> An HTML attachment was scrubbed...
>>
>> --
>>
>>
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> --
>>
>> End of wsjt-devel Digest, Vol 113, Issue 23
>> ***
>>
> ___
> 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 published to WinGet

[Neal Pollack via wsjt-devel]

Regarding the winget repository for installs, and your statement:
"

*This is great for automated system installs! I'll attempt to keep the
version here up-to-date, but any developer can submit manifest updates via
GitHub pull request.*";
Am I misunderstanding that this is a terrible security risk, since
apparently anyone
can alter the installation manifest, and therefore future installs could be
installing
malware rather than WSJT-X?Or do I misunderstand?

Neal

On Tue, Jul 18, 2023 at 5:59 AM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
>
>
> Today's Topics:
>
>1. WSJT-X published to WinGet (Chris Keller)
>2. Transverter Offset (tom)
>
>
> --
>
> Message: 1
> Date: Mon, 17 Jul 2023 11:58:16 -0600
> From: Chris Keller 
> To: wsjt-devel@lists.sourceforge.net
> Subject: [wsjt-devel] WSJT-X published to WinGet
> Message-ID:
>  kp...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello folks,
>
> I wanted to let you know that I've published a manifest
>  for WSJT-X in
> Microsoft's official Windows Package Manager, a.k.a. WinGet. Users
> comfortable with the command line can now install WSJT-X with the command:
>
> winget install -e --id K1JT.wsjtx
>
> This is great for automated system installs! I'll attempt to keep the
> version here up-to-date, but any developer can submit manifest updates via
> GitHub pull request.
>
> 73,
> Chris K0SWE
> -- next part --
> An HTML attachment was scrubbed...
>
> --
>
> Message: 2
> Date: Tue, 18 Jul 2023 11:30:16 +0100
> From: tom 
> To: WSJT software development 
> Subject: [wsjt-devel] Transverter Offset
> Message-ID: <2d867620-9fa1-4cfc-a25d-e204f3d5c...@tkrh.co.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi - posted on main list but no final solution.
>
> Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2
>
> Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue.
> Used an offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to
> 1.065 MHz.
>
>
> Tried the example given on archive for 2m offset -116 and all worked fine,
> cat kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed 144
> MHz.
>
> Could it be the , in offset freq -1268 is entered and software formats it
> to -1,268.000 000 MHz.
>
> Tried the same setup with MSHV and WSJT-X-Improved and worked as expected
> with -1268 offset. Cat and freq both ok.
>
> Thanks in advance for any suggestions but it does look like a bug rather
> than user error.
>
> Tom GM8MJV
> t...@tkrh.co.uk
>
>
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
>
> --
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
>
> End of wsjt-devel Digest, Vol 113, Issue 23
> ***
>
___
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

[Steven Franke via wsjt-devel]

Hi Josh, 

So far, I’m not able to reproduce that behavior here. WSPR band hopping is 
working fine and Enable Tx stays enabled once it is set.

Steve k9an

> On Jul 8, 2023, at 5:49 AM, Josh Rovero via wsjt-devel 
>  wrote:
> 
> Builds and runs well on Fedora Core 38 64-bit.
> 
> While WSPR band hopping, the first band change cycle "unsets" Enable Tx, but 
> after resetting Enable TX, subsequent band changes keep it set.
> 
> -- 
> P.J. "Josh" Rovero http://www.roveroresearch.org 
>   
> Ham Radio: KK1D
> ___
> 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

Re: [wsjt-devel] wsjt-devel Digest, Vol 112, Issue 11

[Al via wsjt-devel]

Since you were asking about the IC705, I loaded the new dll and tried it with 
my X6100. It worked as it should from 6m > 160m and back with no problems. It 
also worked fine with my ANAN running Thetis. I will leave the new dll 
installed and let you know if something shows later.

BTW, I did notice the X6100 saves ATT, PRE, and ATU settings by VFO. So, if 
using ATI in split operation, you do need to  tune the ATU while in each VFO. I 
suspect most other transceivers save preamp/attenuation and ATU tuning by band 
therefor avoiding this. I will post it to the Xiegu suggestion/bug site.


Al Pawlowski
Los Osos, CA USA



> On Jun 11, 2023, at 11:26, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Send wsjt-devel mailing list submissions to
>   wsjt-devel@lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
>   wsjt-devel-requ...@lists.sourceforge.net
> 
> You can reach the person managing the list at
>   wsjt-devel-ow...@lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results
>  (Gene Hinkle)
>   2. Re: Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results
>  (Black Michael)
>   3. Re: Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results
>  (Gene Hinkle)
> 
> 
> --
> 
> Message: 1
> Date: Sun, 11 Jun 2023 09:04:53 -0500
> From: Gene Hinkle 
> To: Black Michael via wsjt-devel 
> Subject: Re: [wsjt-devel] Hamlib testing -Testing IC-7300/IC-705,
>   IC-7610 Results
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> *_Testing IC-7300/IC-705, IC-7610 Results_*
> 
> Mike, on the IC-7610 so far the new *libhamlib-4.dll* seems to work.
> 
> On the IC-705 and the IC-7300 however:
> 
> The WSJT-X program /*crashes */if I start either radio from 7.074 MHz or 
> higher and THEN change the band setting drop down to 80m e.g., 3.573 MHz 
> or lower and do a TUNE transmit. It works OK at on 7.074 MHz and above 
> frequencies but when I then drop to 3.573 MHz or the 1.840 MHz band and 
> TUNE for Transmit it will crash and I have to then restart the program 
> which then immediately crashes and a second restart operates correctly 
> works unless I repeat the sequence I state above.
> 
> I should note that in both radio test cases, they are being operated 
> from different computers, in fact all radios have their own computers.
> 
> I will be out most of the morning to church but back in the afternoon CDST.
> 
> 73, Gene, K5PA
> 
> 
> 
> 
> 
> 
> On 6/10/2023 10:18 PM, Black Michael via wsjt-devel wrote:
>> 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
> 
> -- 
> -- Gene
> -- next part --
> An HTML attachment was scrubbed...
> 
> --
> 
> Message: 2
> Date: Sun, 11 Jun 2023 15:03:46 + (UTC)
> From: Black Michael 
> To: Gene Hinkle via wsjt-devel 
> Subject: Re: [wsjt-devel] Hamlib testing -Testing IC-7300/IC-705,
>   IC-7610 Results
> Message-ID: <715399477.1421189.1686495826...@mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Sounds like RFI Problems due to noise on the USB cable
> 
> 
> Tests
> If problems are occurring only during transmit:
> #1 Reduce power to zero and see if the problem stops -- if it does stop 
> than it is definitely RFI.? You will see certain higher power levels on 
> certain bands that cause problems.
> Then, if problems are occurring during non-transmit periods it indicates a 
> system problem with USB devices so...
> #1 Check USB Power Management option is turned off on all USB devices
> Device Manager for Windows.
> For Linux set autosuspend=-1 
> https://docs.kernel.org/driver-api/usb/power-management.html
> 
> 
> RFI Fixes:
> #1 Free - Move USB cables to another port -- some ports are more 
> susceptible than others.
> #2 Free -- Check your grounding system.? rod-outside-the-shack is a 
> common problem 

Re: [wsjt-devel] wsjt-x Hungarian localization

[Uwe, DG2YCB via wsjt-devel]

Hi Janos,

Thank you for your Hungarian translation file. I have added it to our
source code. I will send you a WSJT-X test version with your file by
private email soon.

73 de DG2YCB,
Uwe

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


Am 21.05.2023 um 22:42 schrieb János Isgum via wsjt-devel:

Dear wsjt program-developer OM!

I apologize for the impersonal address, but I don't know who in the
wsjt development team is responsible for the localization part of the
program.
The wsjt-x is the most popular digital amateur radio program also
among the Hungarian hams.

I have created the Hungarian localization of the wsjt program (based
on the wsjtx_en_GB.ts file of the source code).
Here I am sending the Hungarian wsjt_hu.ts file as an attachment.
Dear OM, my request is that you include this file in the program and
send me the executable wsjtx.exe file for testing.
After testing the Hungarian localization, I will send you the final
wsjtx_hu.ts file.

I have also translated and prepared the Hungarian User Manual for wsjt-x.
In it, some pictures still need to be replaced to have Hungarian
subtitles where necessary.
I will send this as well.

Thanks in advance for your patience and help!
I wish you good programming, good health, and I hope my next letter
can be personal!
73,  Janos, HA5GG

Postscript:
Some programs for which I have already done the Hungarian localization:
LogHX3 Logger > Hungarian localization
N1MM+ Logger > Hungarian localization, and Hungarian User Manual
DXLog Logger > Hungarian User Manual


___
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-rc1 Mac build changes

[Hisashi T Fujinaka via wsjt-devel]

Yes, I did the same. I sent the diffs to Uwe.

So far, there are a few quirks in the rc. Mostly with jt-bridge
integration not working the same as before. Double clicking on a
non-CQing station doesn't seem to populate the DX call but can put your
station into "Enable TX" so instead of calling DX after clicking on
their "RR73", it put me into CQ mode.

Oh, and sometimes TX1 was greyed out so the only thing I could send was
TX2.

Both sound like they could be part of the "improved" code. I didn't go
poking around in that code yet.

On Fri, 12 May 2023, Alex Lelievre via wsjt-devel wrote:


If the team would be willing to accept some diffs for the Mac build under MacOS 
SDK 13-

The main issue on Mac is that sprintf is deprecated and treated as an error. 
The second issue are a few variables that are declared and incremented but not used anywhere.


In qmap/astro.cpp there are several calls to sprintf that I updated to snprintf.

qmap/soundin.cpp:   in SoundInThread::inputUDP() there is a variable ?nBusy' 
that is not used (I just commented it out).

Same with models/FrequencyList.cpp:  in FrequencyList_v2_101::from_json_file(), 
there?s ?valid_entry_count' and ?skipped_entry_count? variables which are not 
used.  Also commented out.

These all cause build errors and it would be great if the code base could 
include these changes.

Thanks again for a new version.  So far so good!
alex K6LOT

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


--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


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

Re: [wsjt-devel] WSJT-X Not Responding on UDP Messages

[John via wsjt-devel]

Hi Laurie,

I'm sorry, I didn't see your note. I see it now. I'll respond there.

John

On Mon, Mar 20, 2023 at 9:15 PM Laurie, VK3AMA via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

>
>
> On 21/03/2023 11:53 am, John via wsjt-devel wrote:
> >
> > I'm running the latest production version of WSJT-X.
> >
> > I use WSJT-X with GridTracker and I am able to click on a station in
> > the GridTracker roster and WSJT-X automatically initiates a QSO. This
> > works perfectly.
> >
> > I have written code in Java that is attempting to send UDP messages to
> > WSJT-X, but the messages do not seem to have any effect on WSJT-X.
> >
> > I have run Wireshark and I can see the UDP messages received and the
> > bytes look exactly as they should. They are similar to the UDP
> > messages that GridTrackers emits which do properly initiate a QSO in
> > WSJT-X.
> >
> > Here are the bytes from a 'free text' message that I sent to WSJT-X:
> > 2023-03-20T07:19:00,326 DEBUG [WsjtUdp] (WsjtUdp:86)> position=33
> > dump=byte[33]: [ad bc cb da 00 00 00 02 00 00 00 09 00 00 00 06 W S J
> > T 2d X 00 00 00 06 M Y T E X T 01 ]
> > You can see the magic value, the schema(2), message type (9), the UTF8
> > encoded string for ID, UTF8 encoded free text, and the 'send' byte (1).
> >
> > Do you know any reason why WSJT-X seems to be ignoring this message?
> >
> > Is there a log/debug message in WSJT-X that might help me track this
> down?
> >
> > It's certainly something I'm doing wrong since GridTracker works
> > perfectly. I am struggling to think of what to check and how to debug.
> >
> > Thanks,
> > John
>
> Did you not see my reply to your other message (posted over 3 hours ago)
> on the same topic posted to the WSJTX support group?
> https://wsjtx.groups.io/g/main/message/43351
>
> de Laurie VK3AMA
> (JTAlert author)
>
>
> ___
> 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 Not Responding on UDP Messages

[Laurie, VK3AMA via wsjt-devel]

On 21/03/2023 11:53 am, John via wsjt-devel wrote:


I'm running the latest production version of WSJT-X.

I use WSJT-X with GridTracker and I am able to click on a station in 
the GridTracker roster and WSJT-X automatically initiates a QSO. This 
works perfectly.


I have written code in Java that is attempting to send UDP messages to 
WSJT-X, but the messages do not seem to have any effect on WSJT-X.


I have run Wireshark and I can see the UDP messages received and the 
bytes look exactly as they should. They are similar to the UDP 
messages that GridTrackers emits which do properly initiate a QSO in 
WSJT-X.


Here are the bytes from a 'free text' message that I sent to WSJT-X:
2023-03-20T07:19:00,326 DEBUG [WsjtUdp] (WsjtUdp:86)> position=33 
dump=byte[33]: [ad bc cb da 00 00 00 02 00 00 00 09 00 00 00 06 W S J 
T 2d X 00 00 00 06 M Y T E X T 01 ]
You can see the magic value, the schema(2), message type (9), the UTF8 
encoded string for ID, UTF8 encoded free text, and the 'send' byte (1).


Do you know any reason why WSJT-X seems to be ignoring this message?

Is there a log/debug message in WSJT-X that might help me track this down?

It's certainly something I'm doing wrong since GridTracker works 
perfectly. I am struggling to think of what to check and how to debug.


Thanks,
John


Did you not see my reply to your other message (posted over 3 hours ago) 
on the same topic posted to the WSJTX support group?

https://wsjtx.groups.io/g/main/message/43351

de Laurie VK3AMA
(JTAlert author)


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

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

[Chris Keller via wsjt-devel]

This appears to be resolved,
https://sourceforge.net/p/wsjt/wsjtx/ci/wsjtx-2.6.1/tree/. Thanks to the
dev team!

Chris, K0SWE

On Tue, Feb 14, 2023 at 10:59 AM Brian Morrison via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On Tue, 14 Feb 2023 16:44:07 +
> Barry Jackson via wsjt-devel  wrote:
>
> > Further to my last and after a good search of the git log it seems
> > that since 2.5.4 nobody has tagged the releases.
> >
> > There are commits with references to making preparations for the
> > releases of 2.6.0 and 2.6.1 but neither were tagged at release!
>
> I suspect that this is due to the untimely demise of Bill G4WJS in
> late 2021, perhaps the rest of the team are less familiar with the
> details of git development.
>
> Let's hope that this thread is noticed by the current dev team and they
> sort out tags for the 3 releases that are missing them.
>
> --
>
> 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] WSJT-X 2.6.1 GA Release

[Bill Barrett via wsjt-devel]

The error was due to an instance of WSJT-X running while trying to update.
Sri;
Bill W2PKY

On Tue, Feb 14, 2023 at 7:49 PM Bill Barrett 
wrote:

> Stuck on this error, Am I doing something wrong?
>
>
> Bill W2PKY
>
> On Tue, Feb 14, 2023 at 6:28 PM Joe Taylor via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Hi Barry,
>>
>> There have been *many* announcements in a variety of places about our
>> switch from the Princeton University site to SourceForge.  The tarfile
>> you want is now linked at the bottom of this web page:
>>
>> https://wsjt.sourceforge.io/wsjtx.html
>>
>> The direct link to the tarfile is:
>>
>> https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.1/wsjtx-2.6.1.tgz
>>
>> -- Joe, K1JT
>>
>> On 2/13/2023 5:35 PM, Barry Jackson via wsjt-devel wrote:
>> > On 16/01/2023 14:22, Joe Taylor via wsjt-devel wrote:
>> >> The WSJT Development Team is pleased to announce that today the Solar
>> >> Flux Index is 234 and Sunspot Number is 195.
>> >>
>> >> Oh, yes: and the WSJT-X 2.6.1 General Availability (GA) release is now
>> >> available for free download from SourceForge.
>> >>
>> >
>> > Hi Joe,
>> >
>> > error: Could not download file
>> > https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-2.6.1.tgz
>> >
>> > I maintain wsjtx for Mageia and we have always used the above URL path
>> > for downloading the official sources.
>> >
>> > Has this changed permanently, or is this an oversight, or a server
>> issue?
>> >
>> > Barry
>> >
>> >
>> >
>> > ___
>> > 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

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

[Bill Barrett via wsjt-devel]

Stuck on this error, Am I doing something wrong?


Bill W2PKY

On Tue, Feb 14, 2023 at 6:28 PM Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Barry,
>
> There have been *many* announcements in a variety of places about our
> switch from the Princeton University site to SourceForge.  The tarfile
> you want is now linked at the bottom of this web page:
>
> https://wsjt.sourceforge.io/wsjtx.html
>
> The direct link to the tarfile is:
>
> https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.1/wsjtx-2.6.1.tgz
>
> -- Joe, K1JT
>
> On 2/13/2023 5:35 PM, Barry Jackson via wsjt-devel wrote:
> > On 16/01/2023 14:22, Joe Taylor via wsjt-devel wrote:
> >> The WSJT Development Team is pleased to announce that today the Solar
> >> Flux Index is 234 and Sunspot Number is 195.
> >>
> >> Oh, yes: and the WSJT-X 2.6.1 General Availability (GA) release is now
> >> available for free download from SourceForge.
> >>
> >
> > Hi Joe,
> >
> > error: Could not download file
> > https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-2.6.1.tgz
> >
> > I maintain wsjtx for Mageia and we have always used the above URL path
> > for downloading the official sources.
> >
> > Has this changed permanently, or is this an oversight, or a server issue?
> >
> > Barry
> >
> >
> >
> > ___
> > 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

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

[Joe Taylor via wsjt-devel]

Hi Barry,

There have been *many* announcements in a variety of places about our 
switch from the Princeton University site to SourceForge.  The tarfile 
you want is now linked at the bottom of this web page:


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

The direct link to the tarfile is:

https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.1/wsjtx-2.6.1.tgz

-- Joe, K1JT

On 2/13/2023 5:35 PM, Barry Jackson via wsjt-devel wrote:

On 16/01/2023 14:22, Joe Taylor via wsjt-devel wrote:
The WSJT Development Team is pleased to announce that today the Solar 
Flux Index is 234 and Sunspot Number is 195.


Oh, yes: and the WSJT-X 2.6.1 General Availability (GA) release is now 
available for free download from SourceForge.




Hi Joe,

error: Could not download file 
https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-2.6.1.tgz


I maintain wsjtx for Mageia and we have always used the above URL path 
for downloading the official sources.


Has this changed permanently, or is this an oversight, or a server issue?

Barry



___
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.6.1 GA Release

[Brian Morrison via wsjt-devel]

On Tue, 14 Feb 2023 16:44:07 +
Barry Jackson via wsjt-devel  wrote:

> Further to my last and after a good search of the git log it seems
> that since 2.5.4 nobody has tagged the releases.
> 
> There are commits with references to making preparations for the 
> releases of 2.6.0 and 2.6.1 but neither were tagged at release!

I suspect that this is due to the untimely demise of Bill G4WJS in
late 2021, perhaps the rest of the team are less familiar with the
details of git development.

Let's hope that this thread is noticed by the current dev team and they
sort out tags for the 3 releases that are missing them.

-- 

Brian  G8SEZ


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

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

[Barry Jackson via wsjt-devel]

Further to my last and after a good search of the git log it seems that 
since 2.5.4 nobody has tagged the releases.


There are commits with references to making preparations for the 
releases of 2.6.0 and 2.6.1 but neither were tagged at release!


So this has broken my script which was checking the tags for new 
releases. :(


Barry
G4MKT




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

Re: [wsjt-devel] WSJT-X 2.6.X CAT bug

[Black Michael via wsjt-devel]

Do you perhaps have an offset for that band in the Frequencies tab?

Mike W9MDB








On Tuesday, February 14, 2023 at 06:03:40 AM CST, CT1EKD via wsjt-devel 
 wrote: 







At version 2.4.x and version 2.6.x

When we select 14.074mhz (FT8 mode) the radio goes to 28mhz, (28,128) also if 
you add a new QRG at the frequencies list it goes to 28mhz band 

I tested it with the ICOM radios 706mkg2 and Icom 746, all the other bands QSY 
to the correct Freq/band.

It worked fine with previous versions



Pedro - CT1EKD

___
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