Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

Not completely fixed yet
Turns out that was just one part...working now with an IC706 user and we got 
the mode change working now but rigctld isn't working with wsjtx.
But I also need to test this change on another Icom rig tomorrow (IC-7300) to 
ensure it works correctly before committing it,.
Mike W9MDB
 

On Thursday, January 7, 2021, 05:24:51 PM CST, Bill Somerville 
 wrote:  
 
  On 07/01/2021 20:13, Christoph Berg wrote:
  
  Re: Patrick 9A5CW
 
 have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.
 
 I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph
  
 
Hi Christoph,
 
this is a known issue with Hamlib 4.0, it is not able to set the rig mode for 
some of the older Icom rigs. You can work around it in WSJT-X by checking 
"Settings->Radio->Mode->None". The issue is fixed in the Hamlib master branch 
by commit 02c08544.
 
73
 Bill
 G4WJS.

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

On 07/01/2021 20:13, Christoph Berg wrote:

Re: Patrick 9A5CW

have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph


Hi Christoph,

this is a known issue with Hamlib 4.0, it is not able to set the rig 
mode for some of the older Icom rigs. You can work around it in WSJT-X 
by checking "Settings->Radio->Mode->None". The issue is fixed in the 
Hamlib master branch by commit 02c08544.


73
Bill
G4WJS.

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

Re: [wsjt-devel] wsjtx_syslog.log

[Alan]

Thanks!

Alan G0TLK, sent from my mobile device
On 7 January 2021 22:42:59 Bill Somerville  wrote:

Alan,

as I said to Uwe, he should remove the logging configuration file I gave 
him to temporarily diagnose an issue. The default logging is not verbose at 
all and absolutely trivial compared to other file writes by WSJT-X in 
normal operation, like ALL.TXT and the ADIF log file. There is a 
configuration that can be written to disable all logging but you can forget 
any support from us if you do that as even errors and warnings will not be 
logged.


73
Bill
G4WJS.
On 07/01/2021 22:22, Alan wrote:
Hi, I don't care about the file size from a capacity point of view but I 
agree the number of SSD writes involved does maybe seem a little bit 
wasteful of SSD write life?


Even if the number of these writes are small in the overall scheme of 
things, over an entire machine they can mount up to something more significant.


Are there any others?

If so could there perhaps be a diagnostic mode where such files get 
written, but otherwise they don't?  Would also cut resource use, always a 
good thing in my view, even if relatively minimal.


Alan G0TLK, sent from my mobile device

On 7 January 2021 20:59:16 Bill Somerville  wrote:

On 07/01/2021 20:49, DG2YCB, Uwe wrote:

Hello Bill,
I just noticed that WSJT-X v2.3.0-rc3 (64-bit) creates a file 
wsjtx_syslog.log in the log directory, which increases in size very 
quickly. An example: Just a single start of the program with my RX (Rig = 
none) generates a file with 4973 lines after about 2 minutes! (see file 
attached)
What is this for? Does that really make sense? Why are there so many lines 
with [RIGCTRL] although Rig is “none”?
How can I turn off these many unnecessary SSD writes? Will that also be the 
case in the GA? The wsjtx_log_config.ini file that you sent me a few weeks 
ago doesn't seem to have any effect on this.


73 de Uwe, DG2YCB

Hi Uwe,
delete the wsjtx_log_config.ini file, then the logging reverts to default 
verbosity which is very low. The log file is rotated so its size is limited.

73
Bill
G4WJS.


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

Re: [wsjt-devel] wsjtx_syslog.log

[Bill Somerville]

Alan,

as I said to Uwe, he should remove the logging configuration file I gave 
him to temporarily diagnose an issue. The default logging is not verbose 
at all and absolutely trivial compared to other file writes by WSJT-X in 
normal operation, like ALL.TXT and the ADIF log file. There is a 
configuration that can be written to disable all logging but you can 
forget any support from us if you do that as even errors and warnings 
will not be logged.


73
Bill
G4WJS.

On 07/01/2021 22:22, Alan wrote:
Hi, I don't care about the file size from a capacity point of view but 
I agree the number of SSD writes involved does maybe seem a little bit 
wasteful of SSD write life?


Even if the number of these writes are small in the overall scheme of 
things, over an entire machine they can mount up to something more 
significant.


Are there any others?

If so could there perhaps be a diagnostic mode where such files get 
written, but otherwise they don't?  Would also cut resource use, 
always a good thing in my view, even if relatively minimal.


Alan G0TLK, sent from my mobile device

On 7 January 2021 20:59:16 Bill Somerville  wrote:


On 07/01/2021 20:49, DG2YCB, Uwe wrote:


Hello Bill,

I just noticed that WSJT-X v2.3.0-rc3 (64-bit) creates a file 
wsjtx_syslog.log in the log directory, which increases in size very 
quickly.An example: Just a single start of the program with my RX 
(Rig = none) generates a file with 4973 lines after about 2 
minutes!(see file attached)


What is this for?Does that really make sense?Why are there so many 
lines with [RIGCTRL] although Rig is “none”?


How can I turn off these many unnecessary SSD writes?Will that also 
be the case in the GA?The wsjtx_log_config.ini file that you sent me 
a few weeks ago doesn't seem to have any effect on this.


73 de Uwe, DG2YCB


Hi Uwe,

delete the wsjtx_log_config.ini file, then the logging reverts to 
default verbosity which is very low. The log file is rotated so its 
size is limited.


73
Bill
G4WJS.



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

Re: [wsjt-devel] wsjtx_syslog.log

[Alan]

Hi, I don't care about the file size from a capacity point of view but I 
agree the number of SSD writes involved does maybe seem a little bit 
wasteful of SSD write life?


Even if the number of these writes are small in the overall scheme of 
things, over an entire machine they can mount up to something more significant.


Are there any others?

If so could there perhaps be a diagnostic mode where such files get 
written, but otherwise they don't?  Would also cut resource use, always a 
good thing in my view, even if relatively minimal.


Alan G0TLK, sent from my mobile device
On 7 January 2021 20:59:16 Bill Somerville  wrote:

On 07/01/2021 20:49, DG2YCB, Uwe wrote:

Hello Bill,
I just noticed that WSJT-X v2.3.0-rc3 (64-bit) creates a file 
wsjtx_syslog.log in the log directory, which increases in size very 
quickly. An example: Just a single start of the program with my RX (Rig = 
none) generates a file with 4973 lines after about 2 minutes! (see file 
attached)
What is this for? Does that really make sense? Why are there so many lines 
with [RIGCTRL] although Rig is “none”?
How can I turn off these many unnecessary SSD writes? Will that also be the 
case in the GA? The wsjtx_log_config.ini file that you sent me a few weeks 
ago doesn't seem to have any effect on this.


73 de Uwe, DG2YCB

Hi Uwe,
delete the wsjtx_log_config.ini file, then the logging reverts to default 
verbosity which is very low. The log file is rotated so its size is limited.

73
Bill
G4WJS.
___
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] Feature request down the road

[WB5JJJ]

I used FT4 over the RU weekend contest when RTTY dropped down and found it
fun -- EXCEPT for one thing.  It kept calling a station that was only
calling CQ and very seldom answering any calls when Best S+P was
activated.  I had no way to ignore this station (and others) except to turn
off Best S+P for a while.

Could a feature like what JTAlert has, be added to temporarily ignore
selected calls until a restart of the program.  It would solve a lot
of Best S+P attempts that are really unwanted?  I find that JTA feature
most useful to stop announcing over and over a wanted whatever that I'm not
interested in at the moment.  But that does not effect WSJTx and FT4 Best
S+P operations.

Along the same line, could a lower signal limit be added to keep Best S+P
from calling a station that is -24 and probably is not hearing me at all?
Also very helpful.

Thanks for a great program.

73's
George - WB5JJJ


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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Black Michael via wsjt-devel
> I'd like to hook up with you and debug this.
> Do you do Skype?  We can use "Quick Assist" if you are on Windows 10.

I apparently haven't mentioned Debian often enough ;)

Jitsi works quite well, but unfortunately I have a Bridge sked in a
few minutes. Some time tomorrow or on the weekend?

Christoph


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

Re: [wsjt-devel] wsjtx_syslog.log

[Bill Somerville]

On 07/01/2021 20:49, DG2YCB, Uwe wrote:


Hello Bill,

I just noticed that WSJT-X v2.3.0-rc3 (64-bit) creates a file 
wsjtx_syslog.log in the log directory, which increases in size very 
quickly.An example: Just a single start of the program with my RX (Rig 
= none) generates a file with 4973 lines after about 2 minutes!(see 
file attached)


What is this for?Does that really make sense?Why are there so many 
lines with [RIGCTRL] although Rig is “none”?


How can I turn off these many unnecessary SSD writes?Will that also be 
the case in the GA?The wsjtx_log_config.ini file that you sent me a 
few weeks ago doesn't seem to have any effect on this.


73 de Uwe, DG2YCB


Hi Uwe,

delete the wsjtx_log_config.ini file, then the logging reverts to 
default verbosity which is very low. The log file is rotated so its size 
is limited.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

I'd like to hook up with you and debug this.
Do you do Skype?  We can use "Quick Assist" if you are on Windows 10.
Mike

 

On Thursday, January 7, 2021, 02:17:22 PM CST, Christoph Berg 
 wrote:  
 
 Re: Patrick 9A5CW
> have the same problem.
> If i start the radio in USB mode, manually i change with a button on the
> radio IC706mk2 mode to CW, then i go back into WSJT-X i
> chose a freq from the dropdown menu list, radio is trying to switch to that
> selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Patrick 9A5CW]

Hi Christoph,
Yes the same behaviour noted here, if you disable USB mode in the WSJT-X
radio settings all works ok, except no more USB is automaticaly selected.
Must be something wrong related to USB mode switching or so.
Hope to solve the problem with Mike in next few days.

Best regards,
Patrik 9a5cw

čet, 7. sij 2021. 21:17 Christoph Berg  je napisao:

> Re: Patrick 9A5CW
> > have the same problem.
> > If i start the radio in USB mode, manually i change with a button on the
> > radio IC706mk2 mode to CW, then i go back into WSJT-X i
> > chose a freq from the dropdown menu list, radio is trying to switch to
> that
> > selected frequency but can't do it.
>
> I have the same problem here. If IC706 is in CW mode, wsjtx fails to
> change the mode, and will even refuse to key PTT via the attached
> usb-serial dongle. Changing bands via wsjtx works somewhat, but the
> rig stays on CW, and the dreaded "Rig Control Error" popup appears.
>
> Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
> attached without rigctld.)
>
> Christoph
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Patrick 9A5CW
> have the same problem.
> If i start the radio in USB mode, manually i change with a button on the
> radio IC706mk2 mode to CW, then i go back into WSJT-X i
> chose a freq from the dropdown menu list, radio is trying to switch to that
> selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph


WSJT-X_RigControl-ic706-cw.log.gz
Description: application/gzip
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Bill Somerville
> > ... and the "Hamlib error: Invalid parameter while exchanging VFOs" popup.
> 
> Hi Christoph,
> 
> the rigctld trace doesn't show any errors. Please put the attached file into
> the local configuration directory ~/.config and run the test again then quit
> WSJT-X. It will generate a file ~/Desktop/WSJT-X_RigControl.log which will
> have trace info from the WSJT-X end.

The attached logfiles contain a test with IC706 directly connected,
and then via rigctld with the above error message.

Christoph


WSJT-X_RigControl-ic706.log.gz
Description: application/gzip


WSJT-X_RigControl-rigctld.log.gz
Description: application/gzip
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc3 Antenna Switching

[Bill Somerville]

Hi Josh,

so we can see what is happening please put the attached file into your 
local configuration directory ~/.config and run a minimal test that 
demonstrates the issue, including two transmissions that demonstrate the 
repeated switching to aerial 0. Then quit WSJT-X. It will have created a 
file ~/Desktop/WSJT-X_RigControl.log, send us that for analysis please?


73
Bill
G4WJS.

On 07/01/2021 15:13, Black Michael via wsjt-devel wrote:

It shouldn't be doing that on every transmit though...just on band change.

It should also be skipping that if you are in split mode.

Mike W9MDB




On Thursday, January 7, 2021, 09:07:00 AM CST, Bill Somerville 
 wrote:



On 07/01/2021 14:44, Josh Rovero wrote:

64-bit on Fedora Core 32:

On my FT-950, every tune/transmit cycle switches to Antenna 0, even 
if I have manually selected Antenna 1.  This did not happen in 
previous versions.


FWIW, I use ANT 0 (vertical wire with elevated radials) for 
night-time operation with 160 and 80 meters, and ANT 1 (36 m dipole) 
for daytime 40-10m.  ANT 0 will cover 160-10, so it's not a show 
stopper, but if I had the antennas reversed it would be


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


Ham Radio: KK1D


Hi Josh,

the latest version of Hamlib being used in WSJT-X v2.3.0 RC3 attempts 
to change bands on certain Yaesu rigs in a way that is compatible with 
other manufacturers rigs (and other Yaesu rigs). These Yaesu rigs do 
not select the last "band stack" memory used on the target band when a 
basic CAT QSY to a target frequency command is sent, other 
manufacturers rigs behave better in this respect. The latest Hamlib 
will do the equivalent of selecting the band then the target frequency 
in that band. That should cause the rig to revert to certain settings 
last used on that band as stored in the "band stack" registers, such 
as aerial selection, pre-amp settings (IPO), etc..


If the behaviour you see is not consistent with the above description 
then let us know so we can direct you to gather some diagnostic 
information.


73
bill
G4WJS.



[Sinks.SYSLOG]
Destination=TextFile
Asynchronous=true
AutoFlush=false
FileName="${AppLocalDataLocation}/wsjtx_syslog.log"
TargetFileName="${AppLocalDataLocation}/logs/wsjtx_syslog_%Y-%m.log"
RotationTimePoint="01 00:00:00"
Append=true
EnableFinalRotation=false
MaxSize=41943040
MinFreeSpace=1073741824
MaxFiles=12
Target="${AppLocalDataLocation}/logs"
ScanForFiles="Matching"
Format="[%Channel%][%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Severity%] %Message%"
Filter="%Severity% >= info"

[Sinks.RIGCTRL]
Destination=TextFile
Asynchronous=true
AutoFlush=true
FileName="${DesktopLocation}/WSJT-X_RigControl.log"
Append=true
Format="[%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Channel%:%Severity%] 
%Message%"
Filter="%Channel% matches \"RIGCTRL\" | %Severity% >= info"
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc3 Antenna Switching

[Black Michael via wsjt-devel]

It shouldn't be doing that on every transmit though...just on band change.
It should also be skipping that if you are in split mode.
Mike W9MDB

 

On Thursday, January 7, 2021, 09:07:00 AM CST, Bill Somerville 
 wrote:  
 
  On 07/01/2021 14:44, Josh Rovero wrote:
  
   64-bit on Fedora Core 32: 
  On my FT-950, every tune/transmit cycle switches to Antenna 0, even if I have 
manually selected Antenna 1.  This did not happen in previous versions. 
  FWIW, I use ANT 0 (vertical wire with elevated radials) for night-time 
operation with 160 and 80 meters, and ANT 1 (36 m dipole) for daytime 40-10m.  
ANT 0 will cover 160-10, so it's not a show stopper, but if I had the antennas 
reversed it would be
 
  -- 
  P.J. "Josh" Rovero     http://www.roveroresearch.org                   
Ham Radio: KK1D 
 
Hi Josh,
 
the latest version of Hamlib being used in WSJT-X v2.3.0 RC3 attempts to change 
bands on certain Yaesu rigs in a way that is compatible with other 
manufacturers rigs (and other Yaesu rigs). These Yaesu rigs do not select the 
last "band stack" memory used on the target band when a basic CAT QSY to a 
target frequency command is sent, other manufacturers rigs behave better in 
this respect. The latest Hamlib will do the equivalent of selecting the band 
then the target frequency in that band. That should cause the rig to revert to 
certain settings last used on that band as stored in the "band stack" 
registers, such as aerial selection, pre-amp settings (IPO), etc..
 
If the behaviour you see is not consistent with the above description then let 
us know so we can direct you to gather some diagnostic information.
 
73
 bill
 G4WJS.
 
 ___
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.3.0-rc3 Antenna Switching

[Bill Somerville]

On 07/01/2021 14:44, Josh Rovero wrote:

64-bit on Fedora Core 32:

On my FT-950, every tune/transmit cycle switches to Antenna 0, even if 
I have manually selected Antenna 1.  This did not happen in previous 
versions.


FWIW, I use ANT 0 (vertical wire with elevated radials) for night-time 
operation with 160 and 80 meters, and ANT 1 (36 m dipole) for daytime 
40-10m.  ANT 0 will cover 160-10, so it's not a show stopper, but if I 
had the antennas reversed it would be


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


Ham Radio: KK1D


Hi Josh,

the latest version of Hamlib being used in WSJT-X v2.3.0 RC3 attempts to 
change bands on certain Yaesu rigs in a way that is compatible with 
other manufacturers rigs (and other Yaesu rigs). These Yaesu rigs do not 
select the last "band stack" memory used on the target band when a basic 
CAT QSY to a target frequency command is sent, other manufacturers rigs 
behave better in this respect. The latest Hamlib will do the equivalent 
of selecting the band then the target frequency in that band. That 
should cause the rig to revert to certain settings last used on that 
band as stored in the "band stack" registers, such as aerial selection, 
pre-amp settings (IPO), etc..


If the behaviour you see is not consistent with the above description 
then let us know so we can direct you to gather some diagnostic information.


73
bill
G4WJS.

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

[wsjt-devel] WSJT-X 2.3.0-rc3 Antenna Switching

[Josh Rovero]

64-bit on Fedora Core 32:

On my FT-950, every tune/transmit cycle switches to Antenna 0, even if I
have manually selected Antenna 1.  This did not happen in previous versions.

FWIW, I use ANT 0 (vertical wire with elevated radials) for night-time
operation with 160 and 80 meters, and ANT 1 (36 m dipole) for daytime
40-10m.  ANT 0 will cover 160-10, so it's not a show stopper, but if I had
the antennas reversed it would be

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