Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[Bill Somerville]

Hi Dave,

what steps did you take to install WSJT-X?

73
Bill
G4WJS.

On 17/02/2021 00:44, David Schmocker wrote:

Bill,
Thank you so much for your patience.
Here's bottom section of my finder in which I have left just single instance of 
WSJTX v2.4.0rc1 (named wsjtx).

And what I get when I try to run it in terminal window with or without 
"Untitled" up front.I appreciate any inputs/suggestions.  Thank you   very 
73,
Dave


On 2/16/21, 5:05 PM, "Bill Somerville"  wrote:

 Hi David,

 to uninstall an application bundle like WSJT-X simply drag and drop it
 into the trash can.

 73
 Bill
 G4WJS.

 On 16/02/2021 22:39, David Schmocker wrote:
 > Gents
 > Thank you; I believe I foolishly (and contrary to User-Guide 
instruction)  installed WSJTX v2.4.0rc1 and v2.3.0 over the top of  formerly 
working v2.2.2 because I don't understand how you create a separate install folder 
in OS.
 > After doing the terminal window set-up commands for Mac, I dragged all 
(2.3.0 and 2.4.0rc1) installer shortcuts into the same Mac Applications folder).
 >
 > Next thinking I could somehow get the computer to separate these three 
WSJT shortcuts all same name in Applications folder (viewed in Finder), I went 
into finder and renamed two of the three instances with the version number.
 >
 > Now I think I need to learn how to uninstall all of the parts in OS 
10.14.6, I think I need to start over with a clean install of just 2.4.0rc1.
 >
 > I would highly prefer to read or go off-line with this; your developer 
time is way too valuable!
 >
 > Very 73,
 > Dave KJ9I
 >
 >
 > On 2/16/21, 4:28 PM, "Joe Taylor"   wrote:
 >
 >  Dave --
 >
 >  There is no problem using WSJT-X v2.4.0-rc1 under macOS.  Many are 
doing
 >  so; all needed instructions have been posted on this reflector.  If 
you
 >  need help, just ask.
 >
 >  Release candidates are published and updated when they are ready.  
At
 >  this stage of development we can't predict exactly when that will 
be.
 >
 >   -- Joe, K1JT
 >
 >  On 2/16/2021 5:03 PM, David Schmocker wrote:
 >  > Good afternoon/good evening gents:
 >  > Is there any estimate when WSJT-X v2.4.0rc2 might be on the 
WSJT-X home
 >  > page please?
 >  >
 >  > More detail:
 >  >
 >  > Joe K1JT mentioned it would help if I could provide 6m EME .wav 
files.
 >  > I am currently unable to run WSJT-X v2.4.0rc1 because my OS 
10.14.6
 >  > Mojave shuts down WSJTX with a Memory Allocation MALLOC error.
 >  >
 >  > Bill kindly provided the terminal-window work-around which 
doesn’t work
 >  > (blocked due to permissions) so I am unable to do much yet.I 
tried
 >  > sudo su (then my password) and then the path to launch WSJTX but 
it
 >  > fails out every time.
 >  >
 >  > I don’t wish to consume precious developers’ time on tech support 
here.
 >  > Just wondering when we may expect to see 2.4.0rc2.
 >  >
 >  > We REALLY appreciate all you’re doing!   Thank you so much,  very 
73,
 >  >
 >  >
 >  > Dave KJ9I





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

Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[David Schmocker]

Bill, 
Thank you so much for your patience.
Here's bottom section of my finder in which I have left just single instance of 
WSJTX v2.4.0rc1 (named wsjtx).  

And what I get when I try to run it in terminal window with or without 
"Untitled" up front.I appreciate any inputs/suggestions.  Thank you   very 
73,
Dave


On 2/16/21, 5:05 PM, "Bill Somerville"  wrote:

Hi David,

to uninstall an application bundle like WSJT-X simply drag and drop it 
into the trash can.

73
Bill
G4WJS.

On 16/02/2021 22:39, David Schmocker wrote:
> Gents
> Thank you; I believe I foolishly (and contrary to User-Guide instruction) 
 installed WSJTX v2.4.0rc1 and v2.3.0 over the top of  formerly working v2.2.2 
because I don't understand how you create a separate install folder in OS.
> After doing the terminal window set-up commands for Mac, I dragged all 
(2.3.0 and 2.4.0rc1) installer shortcuts into the same Mac Applications folder).
>
> Next thinking I could somehow get the computer to separate these three 
WSJT shortcuts all same name in Applications folder (viewed in Finder), I went 
into finder and renamed two of the three instances with the version number.
>
> Now I think I need to learn how to uninstall all of the parts in OS 
10.14.6, I think I need to start over with a clean install of just 2.4.0rc1.
>
> I would highly prefer to read or go off-line with this; your developer 
time is way too valuable!
>
> Very 73,
> Dave KJ9I
>
>
> On 2/16/21, 4:28 PM, "Joe Taylor"  wrote:
>
>  Dave --
>
>  There is no problem using WSJT-X v2.4.0-rc1 under macOS.  Many are 
doing
>  so; all needed instructions have been posted on this reflector.  If 
you
>  need help, just ask.
>
>  Release candidates are published and updated when they are ready.  At
>  this stage of development we can't predict exactly when that will be.
>
>   -- Joe, K1JT
>
>  On 2/16/2021 5:03 PM, David Schmocker wrote:
>  > Good afternoon/good evening gents:
>  > Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X 
home
>  > page please?
>  >
>  > More detail:
>  >
>  > Joe K1JT mentioned it would help if I could provide 6m EME .wav 
files.
>  > I am currently unable to run WSJT-X v2.4.0rc1 because my OS 
10.14.6
>  > Mojave shuts down WSJTX with a Memory Allocation MALLOC error.
>  >
>  > Bill kindly provided the terminal-window work-around which doesn’t 
work
>  > (blocked due to permissions) so I am unable to do much yet.I 
tried
>  > sudo su (then my password) and then the path to launch WSJTX but it
>  > fails out every time.
>  >
>  > I don’t wish to consume precious developers’ time on tech support 
here.
>  > Just wondering when we may expect to see 2.4.0rc2.
>  >
>  > We REALLY appreciate all you’re doing!   Thank you so much,  very 
73,
>  >
>  >
>  > Dave KJ9I




___
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-x2.3.0 Anwser problem

[Adrian]

Ok, yes I do work multiple at the same period when one lags to respond, 
and I pick up another while waiting .


Usually the system knows the flow of events when I return to a another 
qso after a gap, but my method helps work the queue in the shortest time 
and contain its size.


The method I use to recover the log popup is quicker than the log qso 
button, and makes sure the system has recorded it as a qso.



On 17/2/21 6:53 am, Reino Talarmo wrote:


Adrian,

The “Log QSO” button on left hand side of the middle row is for that 
purpose. If all information needed for a QSO is exchanged, then 
clicking the Log QSO button will bring up the logging window and there 
is no need to “rework” the station. You may need to check that all 
information is correct in that window and may need to edit it.
Without seeing your Rx Frequency window or all.txt record around that 
instance it is difficult to explain why that happened. You said that 
there are multiple callers. Typical reason in that kind of cases I 
have had is unintended interleaving of QSOs. The Auto sequence cannot 
handle those, only a single QSO at a time.


73, Reino OH3mA

>Yes but I am busy with 10 or so callers and want to get the logging 
done and the call area flagged green as worked. So I hit it again for 
another 73 cycle to bring up the log window, ok then onto the next. It 
happens enough to be annoying.




___
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] Is there any forecast for WSJT-X v2.4.0rc2 please

[Bill Somerville]

Hi David,

to uninstall an application bundle like WSJT-X simply drag and drop it 
into the trash can.


73
Bill
G4WJS.

On 16/02/2021 22:39, David Schmocker wrote:

Gents
Thank you; I believe I foolishly (and contrary to User-Guide instruction)  
installed WSJTX v2.4.0rc1 and v2.3.0 over the top of  formerly working v2.2.2 
because I don't understand how you create a separate install folder in OS.
After doing the terminal window set-up commands for Mac, I dragged all (2.3.0 
and 2.4.0rc1) installer shortcuts into the same Mac Applications folder).

Next thinking I could somehow get the computer to separate these three WSJT 
shortcuts all same name in Applications folder (viewed in Finder), I went into 
finder and renamed two of the three instances with the version number.

Now I think I need to learn how to uninstall all of the parts in OS 10.14.6, I 
think I need to start over with a clean install of just 2.4.0rc1.

I would highly prefer to read or go off-line with this; your developer time is 
way too valuable!

Very 73,
Dave KJ9I


On 2/16/21, 4:28 PM, "Joe Taylor"  wrote:

 Dave --

 There is no problem using WSJT-X v2.4.0-rc1 under macOS.  Many are doing
 so; all needed instructions have been posted on this reflector.  If you
 need help, just ask.

 Release candidates are published and updated when they are ready.  At
 this stage of development we can't predict exactly when that will be.

-- Joe, K1JT

 On 2/16/2021 5:03 PM, David Schmocker wrote:
 > Good afternoon/good evening gents:
 > Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X home
 > page please?
 >
 > More detail:
 >
 > Joe K1JT mentioned it would help if I could provide 6m EME .wav files.
 > I am currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6
 > Mojave shuts down WSJTX with a Memory Allocation MALLOC error.
 >
 > Bill kindly provided the terminal-window work-around which doesn’t work
 > (blocked due to permissions) so I am unable to do much yet.I tried
 > sudo su (then my password) and then the path to launch WSJTX but it
 > fails out every time.
 >
 > I don’t wish to consume precious developers’ time on tech support here.
 > Just wondering when we may expect to see 2.4.0rc2.
 >
 > We REALLY appreciate all you’re doing!   Thank you so much,  very 73,
 >
 >
 > Dave KJ9I





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

Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[David Schmocker]

Gents
Thank you; I believe I foolishly (and contrary to User-Guide instruction)  
installed WSJTX v2.4.0rc1 and v2.3.0 over the top of  formerly working v2.2.2 
because I don't understand how you create a separate install folder in OS.
After doing the terminal window set-up commands for Mac, I dragged all (2.3.0 
and 2.4.0rc1) installer shortcuts into the same Mac Applications folder). 

Next thinking I could somehow get the computer to separate these three WSJT 
shortcuts all same name in Applications folder (viewed in Finder), I went into 
finder and renamed two of the three instances with the version number.   

Now I think I need to learn how to uninstall all of the parts in OS 10.14.6, I 
think I need to start over with a clean install of just 2.4.0rc1.

I would highly prefer to read or go off-line with this; your developer time is 
way too valuable! 

Very 73,
Dave KJ9I 


On 2/16/21, 4:28 PM, "Joe Taylor"  wrote:

Dave --

There is no problem using WSJT-X v2.4.0-rc1 under macOS.  Many are doing 
so; all needed instructions have been posted on this reflector.  If you 
need help, just ask.

Release candidates are published and updated when they are ready.  At 
this stage of development we can't predict exactly when that will be.

-- Joe, K1JT

On 2/16/2021 5:03 PM, David Schmocker wrote:
> Good afternoon/good evening gents:
> Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X home 
> page please?
> 
> More detail:
> 
> Joe K1JT mentioned it would help if I could provide 6m EME .wav files. 
> I am currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6 
> Mojave shuts down WSJTX with a Memory Allocation MALLOC error.
> 
> Bill kindly provided the terminal-window work-around which doesn’t work 
> (blocked due to permissions) so I am unable to do much yet.I tried 
> sudo su (then my password) and then the path to launch WSJTX but it 
> fails out every time.
> 
> I don’t wish to consume precious developers’ time on tech support here.  
> Just wondering when we may expect to see 2.4.0rc2.
> 
> We REALLY appreciate all you’re doing!   Thank you so much,  very 73,
> 
> 
> Dave KJ9I
> 
> 
> 
> ___
> 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] Q65 confusion

[Ted Gisske]

Bill,

I'm no longer confused!

Thanks,

Ted

K9IMM

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Tuesday, February 16, 2021 4:03 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Q65 confusion

 

On 16/02/2021 21:36, Ted Gisske wrote:

I find myself confused (not an alien state) about the standard messages in
Q65. The available notes on RC1 say that standard messages are the same as
other modes. When I click on "Generate Std Msgs", this is what shows up:



That  does not look at all familiar. What do the @ numbers mean? Why are
they in the standard messages? 

If I change the Tx6 message to "CQ K9IMM EN52" it reverts back to the above.
If I double click on Tx4, no RR73 comes up, but the messages revert to the
above.

 

Thanks

73,

Ted

K9IMM

Hi Ted,

you have short-code messages selected, the "Sh" checkbox.

73
Bill
G4WJS.

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

Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[Joe Taylor]

Dave --

There is no problem using WSJT-X v2.4.0-rc1 under macOS.  Many are doing 
so; all needed instructions have been posted on this reflector.  If you 
need help, just ask.


Release candidates are published and updated when they are ready.  At 
this stage of development we can't predict exactly when that will be.


-- Joe, K1JT

On 2/16/2021 5:03 PM, David Schmocker wrote:

Good afternoon/good evening gents:
Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X home 
page please?


More detail:

Joe K1JT mentioned it would help if I could provide 6m EME .wav files. 
    I am currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6 
Mojave shuts down WSJTX with a Memory Allocation MALLOC error.


Bill kindly provided the terminal-window work-around which doesn’t work 
(blocked due to permissions) so I am unable to do much yet.    I tried 
sudo su (then my password) and then the path to launch WSJTX but it 
fails out every time.


I don’t wish to consume precious developers’ time on tech support here.  
Just wondering when we may expect to see 2.4.0rc2.


We REALLY appreciate all you’re doing!   Thank you so much,  very 73,


Dave KJ9I



___
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] Is there any forecast for WSJT-X v2.4.0rc2 please

[Bill Somerville]

Hi David,

WSJT-X is shipped as application bundle on macOS, the command you're 
looking for will be something like:


/Applications/WSJTX_2.4.0rc1.app/Contents/MacOS/wsjtx

73
Bill
G4WJS.

On 16/02/2021 22:15, David Schmocker wrote:


Hi Bill:
Screenshot attached:   (note my application is named ‘WSJTX_2.4.0rc1’).

Thank you

*From: *Bill Somerville 
*Reply-To: *WSJT software development 
*Date: *Tuesday, February 16, 2021 at 4:08 PM
*To: *
*Subject: *Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 
please


On 16/02/2021 22:03, David Schmocker wrote:

Good afternoon/good evening gents:
Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X
home page please?

More detail:

Joe K1JT mentioned it would help if I could provide 6m EME .wav
files.    I am currently unable to run WSJT-X v2.4.0rc1 because my
OS 10.14.6 Mojave shuts down WSJTX with a Memory Allocation MALLOC
error.

Bill kindly provided the terminal-window work-around which doesn’t
work (blocked due to permissions) so I am unable to do much
yet.    I tried sudo su (then my password) and then the path to
launch WSJTX but it fails out every time.

I don’t wish to consume precious developers’ time on tech support
here.  Just wondering when we may expect to see 2.4.0rc2.

We REALLY appreciate all you’re doing!   Thank you so much,  very 73,


Dave KJ9I

Hi Dave,

please explain what "blocked due to permissions" consists of? You 
don't need to use root privileges to run WSJT-X, in fact it strongly 
recommended not to.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Q65 confusion

[Phil]

Hi Ted, Try turning off SH.That worked for me PhilN8LRGSent from my Verizon, 
Samsung Galaxy smartphone
 Original message From: Ted Gisske  Date: 
2/16/21  16:57  (GMT-05:00) To: 'WSJT software development' 
 Subject: [wsjt-devel] Q65 confusion  I find 
myself confused (not an alien state) about the standard messages in Q65. The 
available notes on RC1 say that standard messages are the same as other modes. 
When I click on “Generate Std Msgs”, this is what shows up:That  does not look 
at all familiar. What do the @ numbers mean? Why are they in the standard 
messages? If I change the Tx6 message to “CQ K9IMM EN52” it reverts back to the 
above. If I double click on Tx4, no RR73 comes up, but the messages revert to 
the above. Thanks73,TedK9IMM___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Clipping

[Bill Somerville]

On 16/02/2021 22:10, Jim Brown wrote:

On 2/16/2021 2:01 PM, Bill Somerville wrote:
there are no analog audio stages involved. The trival distortion 
(lower than -65dB) is probably the result of being passed through an 
unnecessary sample rate converter with a small defect within the MS 
Windows audio sub-system. The issue can be demonstrated without ever 
leaving the digital domain.


I understand that, but I understood Michael to be saying that he used 
one computer to look at the audio output of the other. Yes, -65dB is 
pretty low, trivial unless the guy transmitting it is 40 dB over S9 
and you're trying to work weak signals. :) Not an uncommon situation 
in Northern California on 160 and 6M.


73, Jim K9YC 


Hi Jim,

I believe you have misread what Mike did, he used two instances of 
WSJT-X on the **same** machine using a digital only loopback like VAC or 
VB Cable.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[David Schmocker]

Hi Bill:
Screenshot attached:   (note my application is named ‘WSJTX_2.4.0rc1’).    

Thank you 

 

 

From: Bill Somerville 
Reply-To: WSJT software development 
Date: Tuesday, February 16, 2021 at 4:08 PM
To: 
Subject: Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

 

On 16/02/2021 22:03, David Schmocker wrote:

Good afternoon/good evening gents:
Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X home page 
please?

 

More detail:

Joe K1JT mentioned it would help if I could provide 6m EME .wav files.I am 
currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6 Mojave shuts 
down WSJTX with a Memory Allocation MALLOC error.

 

Bill kindly provided the terminal-window work-around which doesn’t work 
(blocked due to permissions) so I am unable to do much yet.I tried sudo su 
(then my password) and then the path to launch WSJTX but it fails out every 
time.

I don’t wish to consume precious developers’ time on tech support here.  Just 
wondering when we may expect to see 2.4.0rc2. 

 

We REALLY appreciate all you’re doing!   Thank you so much,  very 73,


Dave KJ9I

Hi Dave,

please explain what "blocked due to permissions" consists of? You don't need to 
use root privileges to run WSJT-X, in fact it strongly recommended not to.

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

[Jim Brown]

On 2/16/2021 2:01 PM, Bill Somerville wrote:
there are no analog audio stages involved. The trival distortion (lower 
than -65dB) is probably the result of being passed through an 
unnecessary sample rate converter with a small defect within the MS 
Windows audio sub-system. The issue can be demonstrated without ever 
leaving the digital domain.


I understand that, but I understood Michael to be saying that he used 
one computer to look at the audio output of the other. Yes, -65dB is 
pretty low, trivial unless the guy transmitting it is 40 dB over S9 and 
you're trying to work weak signals. :) Not an uncommon situation in 
Northern California on 160 and 6M.


73, Jim K9YC



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

Re: [wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[Bill Somerville]

On 16/02/2021 22:03, David Schmocker wrote:


Good afternoon/good evening gents:
Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X 
home page please?


More detail:

Joe K1JT mentioned it would help if I could provide 6m EME .wav files. 
   I am currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6 
Mojave shuts down WSJTX with a Memory Allocation MALLOC error.


Bill kindly provided the terminal-window work-around which doesn’t 
work (blocked due to permissions) so I am unable to do much yet.    I 
tried sudo su (then my password) and then the path to launch WSJTX but 
it fails out every time.


I don’t wish to consume precious developers’ time on tech support 
here.  Just wondering when we may expect to see 2.4.0rc2.


We REALLY appreciate all you’re doing! Thank you so much,  very 73,


Dave KJ9I


Hi Dave,

please explain what "blocked due to permissions" consists of? You don't 
need to use root privileges to run WSJT-X, in fact it strongly 
recommended not to.


73
Bill
G4WJS.

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

[wsjt-devel] Is there any forecast for WSJT-X v2.4.0rc2 please

[David Schmocker]

Good afternoon/good evening gents:
Is there any estimate when WSJT-X v2.4.0rc2 might be on the WSJT-X home page 
please?

 

More detail:

Joe K1JT mentioned it would help if I could provide 6m EME .wav files.    I am 
currently unable to run WSJT-X v2.4.0rc1 because my OS 10.14.6 Mojave shuts 
down WSJTX with a Memory Allocation MALLOC error.

 

Bill kindly provided the terminal-window work-around which doesn’t work 
(blocked due to permissions) so I am unable to do much yet.    I tried sudo su 
(then my password) and then the path to launch WSJTX but it fails out every 
time.

I don’t wish to consume precious developers’ time on tech support here.  Just 
wondering when we may expect to see 2.4.0rc2. 

 

We REALLY appreciate all you’re doing!   Thank you so much,  very 73,


Dave KJ9I

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

Re: [wsjt-devel] Q65 confusion

[Bill Somerville]

On 16/02/2021 21:36, Ted Gisske wrote:


I find myself confused (not an alien state) about the standard 
messages in Q65. The available notes on RC1 say that standard messages 
are the same as other modes. When I click on “Generate Std Msgs”, this 
is what shows up:


That  does not look at all familiar. What do the @ numbers mean? 
Why are they in the standard messages?


If I change the Tx6 message to “CQ K9IMM EN52” it reverts back to the 
above. If I double click on Tx4, no RR73 comes up, but the messages 
revert to the above.


Thanks

73,

Ted

K9IMM


Hi Ted,

you have short-code messages selected, the "Sh" checkbox.

73
Bill
G4WJS.

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

Re: [wsjt-devel] Clipping

[Bill Somerville]

On 16/02/2021 20:53, Jim Brown wrote:

On 2/16/2021 12:40 PM, Black Michael via wsjt-devel wrote:
Also there with no transmitter involved.  2nd copy of WSJT-X 
listening to the 1st WSJT_X transmit audio device.


But the audio stages of two computers. The measurements I cited were 
at the audio output of a "good" computer generating a sine wave.


73, Jim


Hi Jim,

there are no analog audio stages involved. The trival distortion (lower 
than -65dB) is probably the result of being passed through an 
unnecessary sample rate converter with a small defect within the MS 
Windows audio sub-system. The issue can be demonstrated without ever 
leaving the digital domain.


73
Bill
G4WJS.

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

[wsjt-devel] Q65 confusion

[Ted Gisske]

 

I find myself confused (not an alien state) about the standard messages in
Q65. The available notes on RC1 say that standard messages are the same as
other modes. When I click on "Generate Std Msgs", this is what shows up:



That  does not look at all familiar. What do the @ numbers mean? Why are
they in the standard messages? 

If I change the Tx6 message to "CQ K9IMM EN52" it reverts back to the above.
If I double click on Tx4, no RR73 comes up, but the messages revert to the
above.

 

Thanks

73,

Ted

K9IMM

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

Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

[Reino Talarmo]

Adrian,

The “Log QSO” button on left hand side of the middle row is for that purpose. 
If all information needed for a QSO is exchanged, then clicking the Log QSO 
button will bring up the logging window and there is no need to “rework” the 
station. You may need to check that all information is correct in that window 
and may need to edit it.
Without seeing your Rx Frequency window or all.txt record around that instance 
it is difficult to explain why that happened. You said that there are multiple 
callers. Typical reason in that kind of cases I have had is unintended 
interleaving of QSOs. The Auto sequence cannot handle those, only a single QSO 
at a time.

73, Reino OH3mA

>Yes but I am busy with 10 or so callers and want to get the logging done and 
>the call area flagged green as worked. So I hit it again for another 73 cycle 
>to bring up the log window, ok then onto the next. It happens enough to be 
>annoying.

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

Re: [wsjt-devel] Clipping

[Jim Brown]

On 2/16/2021 12:40 PM, Black Michael via wsjt-devel wrote:
Also there with no transmitter involved.  2nd copy of WSJT-X listening 
to the 1st WSJT_X transmit audio device.


But the audio stages of two computers. The measurements I cited were at 
the audio output of a "good" computer generating a sine wave.


73, Jim



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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Bill Frantz]

On 2/16/21 at 10:51 AM, dg2...@gmx.de (DG2YCB, Uwe) wrote:

Hasan, I’m sorry, but I totally disagree. Configurations are 
there to switch e.g. between 2 completely different hardware 
setups, but not between two modes (or bands). Come on! That is 
the most basic task of a multi-mode program itself.


I have about 10 different configurations to switch between 
different radios (a K3 and a KX3) and different 
contests/fox-hound/wsjtx modes etc. It works very well for me.


When I switch between modes (FT8 and FT4 are the ones I use(, I 
automatically get the only the preferred frequencies for each 
mode. When I change contests and fox-hound, I get the correct 
settings for that mode. Not only is switching configuration much 
faster, it also avoids the problem of me forgetting an important 
setting and having to go back and fix it. When I switch radios, 
I automatically get the right settings, including the specific 
USB<->RS232 adapter attached to the radio. (I'm a Mac user where 
the adapters are remembered by their serial numbers works.)


73 Bill AE6JV

---
Bill Frantz| Since the IBM Selectric, keyboards have gotten
408-348-7900   | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?



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

Re: [wsjt-devel] Clipping

[Black Michael via wsjt-devel]

Also there with no transmitter involved.  2nd copy of WSJT-X listening to the 
1st WSJT_X transmit audio device.
But seems nobody cares about getting rid of unnecessary noise (albeit minimal 
it's still noise). 

On Tuesday, February 16, 2021, 02:25:25 PM CST, Jim Brown 
 wrote:  
 
 On 2/16/2021 5:56 AM, Black Michael via wsjt-devel wrote:
> You're wrong -- it's being transmitted too.
> I send that example a while ago.

That doesn't mean it's necessarily coming from the code -- the 
distortion could be generated anywhere in the analog chain, from the 
analog side of the D/A of the computer, through the rig's audio stages, 
the transmitter's RF stages, a power amp if there is one, the receiver's 
RF chain and audio stages, to the audio side of the computer's A/D.

The audio side of computers are notoriously lousy. Years ago, I measured 
distortion on the output of a "good" computer sound card as -30 dB just 
below clip, and -40 dB at 6 dB below clip.

73, Jim K9YC



___
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] Clipping

[Jim Brown]

On 2/16/2021 5:56 AM, Black Michael via wsjt-devel wrote:

You're wrong -- it's being transmitted too.
I send that example a while ago.


That doesn't mean it's necessarily coming from the code -- the 
distortion could be generated anywhere in the analog chain, from the 
analog side of the D/A of the computer, through the rig's audio stages, 
the transmitter's RF stages, a power amp if there is one, the receiver's 
RF chain and audio stages, to the audio side of the computer's A/D.


The audio side of computers are notoriously lousy. Years ago, I measured 
distortion on the output of a "good" computer sound card as -30 dB just 
below clip, and -40 dB at 6 dB below clip.


73, Jim K9YC



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

Re: [wsjt-devel] Continuing decodes on Q65 mode

[Joe Taylor]

Hi Mike,

On 2/16/2021 2:47 PM, Mike Lewis K7MDL wrote:
I just finished a Q65 contact on 2M and after the QSO completed, no more 
decodes arrived since the other party stopped (confirmed) but the 
initial call to me keep popping up on the right panel.  I thought he was 
running a 2^nd time to started to answer until I figured out it was not 
real, he had stopped.


Mike
K7MDL  EL87sm & CN88sf


It seems you have selected "Enable averaging" without understanding how 
it works, and have failed to select "Auto Clear Avg after decode".


-- Joe, K1JT


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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Bill Frantz]

[Resend because I didn't see it come back and "Receive your own 
posts" is yes.]


On 2/16/21 at 10:51 AM, dg2...@gmx.de (DG2YCB, Uwe) wrote:

Hasan, I’m sorry, but I totally disagree. Configurations are 
there to switch e.g. between 2 completely different hardware 
setups, but not between two modes (or bands). Come on! That is 
the most basic task of a multi-mode program itself.


I have about 10 different configurations to switch between 
different radios (a K3 and a KX3) and different 
contests/fox-hound/wsjtx modes etc. It works very well for me.


When I switch between modes (FT8 and FT4 are the ones I use(, I 
automatically get the only the preferred frequencies for each 
mode. When I change contests and fox-hound, I get the correct 
settings for that mode. Not only is switching configuration much 
faster, it also avoids the problem of me forgetting an important 
setting and having to go back and fix it. When I switch radios, 
I automatically get the right settings, including the specific 
USB<->RS232 adapter attached to the radio. (I'm a Mac user where 
the adapters are remembered by their serial numbers works.)


73 Bill AE6JV

---
Bill Frantz| Since the IBM Selectric, keyboards have gotten
408-348-7900   | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?



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

Re: [wsjt-devel] Continuing decodes on Q65 mode

[Mike Lewis]

Good call, I debated on setting the auto clear.  Sometimes on other modes when 
I send a RR73 and I see the other station has not heard it, requiring a resend. 
 As a result I like to keep the data and the log entry until I am certain I am 
completed so hesitant to auto clear much of anything.

Mike
K7MDL  EL87sm & CN88sf

From: Bill Somerville 
Sent: Tuesday, February 16, 2021 14:56
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Continuing decodes on Q65 mode

On 16/02/2021 19:47, Mike Lewis wrote:
I just finished a Q65 contact on 2M and after the QSO completed, no more 
decodes arrived since the other party stopped (confirmed) but the initial call 
to me keep popping up on the right panel.  I thought he was running a 2nd time 
to started to answer until I figured out it was not real, he had stopped.

Hi Mike,

it looks like you have message averaging enabled but not the option next to it 
to automatically clear averaging after a successful decode. Without that option 
it is up to you to decide when accumulated messages from past periods are no 
longer relevant. For normal operation having the auto clear averaging on decode 
option checked is recommended.

The next release candidate has revised message averaging functionality that 
will greatly reduce the likelihood out of date message information being 
printed as averaged decodes.

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

Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

[Adrian]

Yes but I am busy with 10 or so callers and want to get the logging done 
and the call area flagged green as worked. So I hit it again for another 
73 cycle to bring up the log window, ok then onto the next. It happens 
enough to be annoying.


On 17/2/21 5:15 am, da...@beauchesne.net wrote:


Adrian,

Regarding your “need to rework the station”, all the data you need to 
log the QSO is in WSJT-X’s ALL.TXT file.  I occasionally have to use 
that to record a QSO.


David, AK2L

*From:* Adrian 
*Sent:* Tuesday, February 16, 2021 12:01
*To:* WSJT software development 
*Subject:* Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

The problem I am having with v2.3.0 is the auto log popup sometimes 
not working on the RR73 or 73, and a need to rework the station to get 
the logging popup. The effect is random and not often.


The Call 1st feature you describe always works here on v2.3.0, but I 
also have the checkbox in settings to force 1st call on CQ


On 17/2/21 2:53 am, on4...@telenet.be  wrote:

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with 
WSJT-X version 2.3.0 in Windows 7. Everything has always worked fine, until 
now. He's going to call CQ. On his right screen he sees a station coming back 
to him, but he keeps calling CQ. WSJT-X does not answer the answering station. 
If PA3GZD then clicks on that station on the right screen, the QSO will 
continue and reports will be exchanged. What can go wrong here. Like info. 
Thanks in advance. See alo attachment.

Kind regards

ON4CKT Rudy

https://www.qsl.net/on4ckt  




___

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] Continuing decodes on Q65 mode

[Bill Somerville]

On 16/02/2021 19:47, Mike Lewis wrote:
I just finished a Q65 contact on 2M and after the QSO completed, no 
more decodes arrived since the other party stopped (confirmed) but the 
initial call to me keep popping up on the right panel.  I thought he 
was running a 2^nd time to started to answer until I figured out it 
was not real, he had stopped.


Hi Mike,

it looks like you have message averaging enabled but not the option next 
to it to automatically clear averaging after a successful decode. 
Without that option it is up to you to decide when accumulated messages 
from past periods are no longer relevant. For normal operation having 
the auto clear averaging on decode option checked is recommended.


The next release candidate has revised message averaging functionality 
that will greatly reduce the likelihood out of date message information 
being printed as averaged decodes.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

[Adrian]

Yes I have that option checked already. It happens more when I am 
working multiple callers.


On 17/2/21 5:09 am, Hasan N0AN wrote:
Click on the Log QSO button in WSJT-X and force it. I have had to do 
that now and again, but not often.

73, N0AN
Hasan


On Tue, Feb 16, 2021 at 1:06 PM Adrian > wrote:


The problem I am having with v2.3.0 is the auto log popup
sometimes not working on the RR73 or 73, and a need to rework the
station to get the logging popup. The effect is random and not often.

The Call 1st feature you describe always works here on v2.3.0, but
I also have the checkbox in settings to force 1st call on CQ

On 17/2/21 2:53 am, on4...@telenet.be 
wrote:

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with 
WSJT-X version 2.3.0 in Windows 7. Everything has always worked fine, until 
now. He's going to call CQ. On his right screen he sees a station coming back 
to him, but he keeps calling CQ. WSJT-X does not answer the answering station. 
If PA3GZD then clicks on that station on the right screen, the QSO will 
continue and reports will be exchanged. What can go wrong here. Like info. 
Thanks in advance. See alo attachment.

Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt  


___
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-x2.3.0 Anwser problem

[david]

Adrian,

 

Regarding your “need to rework the station”, all the data you need to log the 
QSO is in WSJT-X’s ALL.TXT file.  I occasionally have to use that to record a 
QSO.

 

David, AK2L

 

 

From: Adrian  
Sent: Tuesday, February 16, 2021 12:01
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

 

The problem I am having with v2.3.0 is the auto log popup sometimes not working 
on the RR73 or 73, and a need to rework the station to get the logging popup. 
The effect is random and not often.

The Call 1st feature you describe always works here on v2.3.0, but I also have 
the checkbox in settings to force 1st call on CQ

On 17/2/21 2:53 am, on4...@telenet.be   wrote:

Hi Joe and colleagues,
 
I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.
 
Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt






___
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-x2.3.0 Anwser problem

[Hasan N0AN]

Click on the Log QSO button in WSJT-X and force it. I have had to do that
now and again, but not often.
73, N0AN
Hasan


On Tue, Feb 16, 2021 at 1:06 PM Adrian  wrote:

> The problem I am having with v2.3.0 is the auto log popup sometimes not
> working on the RR73 or 73, and a need to rework the station to get the
> logging popup. The effect is random and not often.
>
> The Call 1st feature you describe always works here on v2.3.0, but I also
> have the checkbox in settings to force 1st call on CQ
> On 17/2/21 2:53 am, on4...@telenet.be wrote:
>
> Hi Joe and colleagues,
>
> I have identified a problem here with a colleague PA3GZD. It works with 
> WSJT-X version 2.3.0 in Windows 7. Everything has always worked fine, until 
> now. He's going to call CQ. On his right screen he sees a station coming back 
> to him, but he keeps calling CQ. WSJT-X does not answer the answering 
> station. If PA3GZD then clicks on that station on the right screen, the QSO 
> will continue and reports will be exchanged. What can go wrong here. Like 
> info. Thanks in advance. See alo attachment.
>
> Kind regards
> ON4CKT Rudyhttps://www.qsl.net/on4ckt
>
>
>
> ___
> 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-x2.3.0 Anwser problem

[Adrian]

The problem I am having with v2.3.0 is the auto log popup sometimes not 
working on the RR73 or 73, and a need to rework the station to get the 
logging popup. The effect is random and not often.


The Call 1st feature you describe always works here on v2.3.0, but I 
also have the checkbox in settings to force 1st call on CQ


On 17/2/21 2:53 am, on4...@telenet.be wrote:

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.

Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt


___
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-x2.3.0 Anwser problem

[on4ckt]

Sam also thanks!73s ON4CKT Rudyhttps://www.qsl.net/on4ckt73s ON4CKT 
Rudyhttps://www.qsl.net/on4cktVerzonden vanaf mijn Galaxy
 Oorspronkelijk bericht Van: Sam W2JDB via wsjt-devel 
 Datum: 16/02/21  18:25  (GMT+01:00) Aan: 
wsjt-devel@lists.sourceforge.net Cc: Sam W2JDB  Onderwerp: Re: 
[wsjt-devel] WSJT-x2.3.0 Anwser problem 

Hi Rudy,




Make sure the checkbox Call 1st is checked.




73,





Sam W2JDB








-Original Message-
From: on4...@telenet.be
To: wsjt-devel 
Sent: Tue, Feb 16, 2021 11:53 am
Subject: [wsjt-devel] WSJT-x2.3.0 Anwser problem


Hi Joe and colleagues,





I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.





Kind regards


ON4CKT Rudy


https://www.qsl.net/on4ckt
___
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-x2.3.0 Anwser problem

[on4ckt]

Bill, Ik have check it and Call 1st was not checked. Now it Works again.Thanks 
for the help.Kind regards,73s ON4CKT Rudyhttps://www.qsl.net/on4ckt73s ON4CKT 
Rudyhttps://www.qsl.net/on4cktVerzonden vanaf mijn Galaxy
 Oorspronkelijk bericht Van: Bill Somerville 
 Datum: 16/02/21  18:23  (GMT+01:00) Aan: 
wsjt-devel@lists.sourceforge.net Onderwerp: Re: [wsjt-devel] WSJT-x2.3.0 Anwser 
problem On 16/02/2021 16:53, on4...@telenet.be wrote:> Hi Joe and colleagues,>> 
I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.>> Kind regards> ON4CKT RudyHi Rudy,automatic 
answering of callers is only done when the "Call 1st" and "Auto Seq" options 
are 
checked.73BillG4WJS.___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-x2.3.0 Anwser problem

[on4ckt]

Hi Gill,Thanks for info. I will check it.Kind regards. 73s ON4CKT 
Rudyhttps://www.qsl.net/on4cktVerzonden vanaf mijn Galaxy
 Oorspronkelijk bericht Van: Bill Somerville 
 Datum: 16/02/21  18:23  (GMT+01:00) Aan: 
wsjt-devel@lists.sourceforge.net Onderwerp: Re: [wsjt-devel] WSJT-x2.3.0 Anwser 
problem On 16/02/2021 16:53, on4...@telenet.be wrote:> Hi Joe and colleagues,>> 
I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.>> Kind regards> ON4CKT RudyHi Rudy,automatic 
answering of callers is only done when the "Call 1st" and "Auto Seq" options 
are 
checked.73BillG4WJS.___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-x2.3.0 Anwser problem

[Neil Zampella]

Hi Rudy,

the obvious first question is does the operator have Call 1st checked ?

Neil, KN3ILZ

On 2/16/2021 10:53 AM, on4...@telenet.be wrote:

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.

Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt



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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Neil Zampella]

Hi Charlie,

I'm so glad to hear that, makes more sense then to clone the Q65
settings to save the basic settings, and adjust for the submode.

Neil, KN3ILZ

On 2/16/2021 10:42 AM, Charles Suckling wrote:

Hi Neil

Judging by the activity reported today on the HB9Q EME logger, there
is lots of activity on Q65 already (432, 1296 and 10368). Stations are
rapidly learning to state the submode they are using, and increasingly
their TxFreq.  On 432 today,  folks were seeing for themselves the
benefits of AP, by experimenting with entries in the DX Call and Grid
boxes.

73

Charlie G3WDG

On Tue, 16 Feb 2021 at 17:29, Neil Zampella mailto:ne...@techie.com>> wrote:

So .. ??

It's like that for EVERY new mode, probably was like that for JT65 and
its various permutations.  You have to setup Q65 at least once to
get it up and running for the Q65 permutation you want to try.   
Saving
that to a configuration takes a selection from a menu, typing a name,
and saving.    Using that setup to adjust for the other permutations
starts with CLONING the original Q65 configuration and adjusting.

Much less time and effort, and all your previous settings are saved in
the original configuration. As far as 'very few use Q65', its
still
in beta and frankly is not a replacement for any of the FT modes, so
fewer will use it currently.

Neil, KN3ILZ

On 2/16/2021 10:07 AM, Serge Szpilfogel wrote:
> Very true Uwe I am on EME & if I go from JT65 to Q65 there is
always an issue with configuration. So very few people use Q65 or
if they do there is often an issue. Result they stay on JT65 & do
not use Q65 which is a pity
> 73,
> Serge VE1KG
>
> -Original Message-
> From: DG2YCB, Uwe mailto:dg2...@gmx.de>>
> Sent: Tuesday, February 16, 2021 15:51
> To: 'WSJT software development'
mailto:wsjt-devel@lists.sourceforge.net>>
> Subject: Re: [wsjt-devel] Please save the T/R sequence lengths
for each mode separately
>
> Hasan, I’m sorry, but I totally disagree. Configurations are
there to switch e.g. between 2 completely different hardware
setups, but not between two modes (or bands). Come on! That is the
most basic task of a multi-mode program itself.
>
> It is a pity that on this reflector EVERY suggestion for
improvement is immediately discredited. Rather frustrating! That’s
why the "clones" are more and more are growing in popularity ...
>
> The point is that in case of the new modes FST4, Q65, etc., a
user cannot simply switch to the mode and get started (as it was
with FT8, FT4, JT9, JT65, etc.) but first has to find out and put
in the correct sub and sub-sub parameters, and has to do that
every time he switches between these modes. No wonder that there
are only VERY few users… (Here in EU the five or six stations
using FST4 had QSOs with each other (or missed them because of
sub-mode mismatch), and due to missing success they went back to
FT8.) But all similar questions or comments from other users on
that were also rejected. Sad story…
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com
]
> Gesendet: Dienstag, 16. Februar 2021 15:18
> An: WSJT software development
> Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths
for each mode separately
>
>
>
> It looks to me that's precisely why Configurations were created.
Why reinvent the wheel?
>
>
>
> People should learn to use configurations and they can then
customize their ops in any way they like.
>
>
>
> I have 12 configs, every mode has its own config. No mistakes,
no forgetting, no mis-setting. ...and no code bloat.
>
>
>
> 73, N0AN
>
> Hasan
>
>
>
>
>
> On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville
mailto:g4...@classdesign.com>
> > wrote:
>
>       Uwe,
>
>
>
>       your description of your amendment sounds different from
what you are asking for. If you have a version that switches to
the T/R periods *you* use with certain modes, then that is fine
for you but it is definitely not a general solution. if you have a
general solution that you have tested for all modes and usage
scenarios then why not contribute a patch?
>
>
>
>       73
>       Bill
>       G4WJS.
>
>
>
>       On 16/02/2021 12:27, DG2YCB, Uwe wrote:
>
>               Hi Bill,
>
>               Why are you not open to such a solution? Would
certainly help to increase the extremely small number of FST4
users. It takes too long to switch configurations.
>
>               But: I've already found a 

Re: [wsjt-devel] WSJT-x2.3.0 Anwser problem

[Sam W2JDB via wsjt-devel]

Hi Rudy,
Make sure the checkbox Call 1st is checked.
73,

Sam W2JDB


-Original Message-
From: on4...@telenet.be
To: wsjt-devel 
Sent: Tue, Feb 16, 2021 11:53 am
Subject: [wsjt-devel] WSJT-x2.3.0 Anwser problem

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.

Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt___
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-x2.3.0 Anwser problem

[Bill Somerville]

On 16/02/2021 16:53, on4...@telenet.be wrote:

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.

Kind regards
ON4CKT Rudy


Hi Rudy,

automatic answering of callers is only done when the "Call 1st" and 
"Auto Seq" options are checked.


73
Bill
G4WJS.



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

[wsjt-devel] WSJT-x2.3.0 Anwser problem

[on4ckt]

Hi Joe and colleagues,

I have identified a problem here with a colleague PA3GZD. It works with WSJT-X 
version 2.3.0 in Windows 7. Everything has always worked fine, until now. He's 
going to call CQ. On his right screen he sees a station coming back to him, but 
he keeps calling CQ. WSJT-X does not answer the answering station. If PA3GZD 
then clicks on that station on the right screen, the QSO will continue and 
reports will be exchanged. What can go wrong here. Like info. Thanks in 
advance. See alo attachment.

Kind regards
ON4CKT Rudy
https://www.qsl.net/on4ckt___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Charles Suckling]

Hi Neil

Judging by the activity reported today on the HB9Q EME logger, there is
lots of activity on Q65 already (432, 1296 and 10368). Stations are rapidly
learning to state the submode they are using, and increasingly their
TxFreq.  On 432 today,  folks were seeing for themselves the benefits of
AP, by experimenting with entries in the DX Call and Grid boxes.

73

Charlie G3WDG

On Tue, 16 Feb 2021 at 17:29, Neil Zampella  wrote:

> So .. ??
>
> It's like that for EVERY new mode, probably was like that for JT65 and
> its various permutations.  You have to setup Q65 at least once to
> get it up and running for the Q65 permutation you want to try.Saving
> that to a configuration takes a selection from a menu, typing a name,
> and saving.Using that setup to adjust for the other permutations
> starts with CLONING the original Q65 configuration and adjusting.
>
> Much less time and effort, and all your previous settings are saved in
> the original configuration. As far as 'very few use Q65', its still
> in beta and frankly is not a replacement for any of the FT modes, so
> fewer will use it currently.
>
> Neil, KN3ILZ
>
> On 2/16/2021 10:07 AM, Serge Szpilfogel wrote:
> > Very true Uwe I am on EME & if I go from JT65 to Q65 there is always an
> issue with configuration. So very few people use Q65 or if they do there is
> often an issue. Result they stay on JT65 & do not use Q65 which is a pity
> > 73,
> > Serge VE1KG
> >
> > -Original Message-
> > From: DG2YCB, Uwe 
> > Sent: Tuesday, February 16, 2021 15:51
> > To: 'WSJT software development' 
> > Subject: Re: [wsjt-devel] Please save the T/R sequence lengths for each
> mode separately
> >
> > Hasan, I’m sorry, but I totally disagree. Configurations are there to
> switch e.g. between 2 completely different hardware setups, but not between
> two modes (or bands). Come on! That is the most basic task of a multi-mode
> program itself.
> >
> > It is a pity that on this reflector EVERY suggestion for improvement is
> immediately discredited. Rather frustrating! That’s why the "clones" are
> more and more are growing in popularity ...
> >
> > The point is that in case of the new modes FST4, Q65, etc., a user
> cannot simply switch to the mode and get started (as it was with FT8, FT4,
> JT9, JT65, etc.) but first has to find out and put in the correct sub and
> sub-sub parameters, and has to do that every time he switches between these
> modes. No wonder that there are only VERY few users… (Here in EU the five
> or six stations using FST4 had QSOs with each other (or missed them because
> of sub-mode mismatch), and due to missing success they went back to FT8.)
> But all similar questions or comments from other users on that were also
> rejected. Sad story…
> >
> >
> >
> > 73 de Uwe, DG2YCB
> >
> >
> >
> > Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com]
> > Gesendet: Dienstag, 16. Februar 2021 15:18
> > An: WSJT software development
> > Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each
> mode separately
> >
> >
> >
> > It looks to me that's precisely why Configurations were created. Why
> reinvent the wheel?
> >
> >
> >
> > People should learn to use configurations and they can then customize
> their ops in any way they like.
> >
> >
> >
> > I have 12 configs, every mode has its own config. No mistakes, no
> forgetting, no mis-setting. ...and no code bloat.
> >
> >
> >
> > 73, N0AN
> >
> > Hasan
> >
> >
> >
> >
> >
> > On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville   > wrote:
> >
> >   Uwe,
> >
> >
> >
> >   your description of your amendment sounds different from what you
> are asking for. If you have a version that switches to the T/R periods
> *you* use with certain modes, then that is fine for you but it is
> definitely not a general solution. if you have a general solution that you
> have tested for all modes and usage scenarios then why not contribute a
> patch?
> >
> >
> >
> >   73
> >   Bill
> >   G4WJS.
> >
> >
> >
> >   On 16/02/2021 12:27, DG2YCB, Uwe wrote:
> >
> >   Hi Bill,
> >
> >   Why are you not open to such a solution? Would certainly
> help to increase the extremely small number of FST4 users. It takes too
> long to switch configurations.
> >
> >   But: I've already found a solution for myself. In my
> wsjt-x_improved versions, I have now programmed it so that the mode buttons
> automatically switch on the most common sub-mode (FST4-A60 or Q65-A30).
> Only needed two additional lines in the source code ...
> >
> >   73 de Uwe, DG2YCB
> >
> >
> >
> >   Von: Bill Somerville [mailto:g4...@classdesign.com]
> >   Gesendet: Dienstag, 16. Februar 2021 11:39
> >   An: wsjt-devel@lists.sourceforge.net  wsjt-devel@lists.sourceforge.net>
> >   Betreff: Re: [wsjt-devel] Please save the T/R sequence
> lengths for each mode separately
> >
> >
> >
> > 

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Joe Taylor]

Hi Serge,

On 2/16/2021 11:07 AM, Serge Szpilfogel VE1KG wrote:

Very true Uwe I am on EME & if I go from JT65 to Q65 there is always an issue with 
configuration. So very few people use Q65 or if they do there is often an issue. Result 
they stay on JT65 & do not use Q65 which is a pity


This is silly.

Just clone your JT65 setup into a new configuration.  Rename this 
configuration as "Q65".  In the Q65 configuration, switch mode to Q65 
and make whatever other changes you wish: T/R sequence length 60 s, 
submode A, etc.


Then whenever you want to operate Q65, switch to the Q65 configuration.

-- Joe, K1JT


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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Neil Zampella]

So .. ??

It's like that for EVERY new mode, probably was like that for JT65 and
its various permutations.  You have to setup Q65 at least once to
get it up and running for the Q65 permutation you want to try.    Saving
that to a configuration takes a selection from a menu, typing a name,
and saving.    Using that setup to adjust for the other permutations
starts with CLONING the original Q65 configuration and adjusting.

Much less time and effort, and all your previous settings are saved in
the original configuration. As far as 'very few use Q65', its still
in beta and frankly is not a replacement for any of the FT modes, so
fewer will use it currently.

Neil, KN3ILZ

On 2/16/2021 10:07 AM, Serge Szpilfogel wrote:

Very true Uwe I am on EME & if I go from JT65 to Q65 there is always an issue with 
configuration. So very few people use Q65 or if they do there is often an issue. Result 
they stay on JT65 & do not use Q65 which is a pity
73,
Serge VE1KG

-Original Message-
From: DG2YCB, Uwe 
Sent: Tuesday, February 16, 2021 15:51
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately

Hasan, I’m sorry, but I totally disagree. Configurations are there to switch 
e.g. between 2 completely different hardware setups, but not between two modes 
(or bands). Come on! That is the most basic task of a multi-mode program itself.

It is a pity that on this reflector EVERY suggestion for improvement is immediately 
discredited. Rather frustrating! That’s why the "clones" are more and more are 
growing in popularity ...

The point is that in case of the new modes FST4, Q65, etc., a user cannot 
simply switch to the mode and get started (as it was with FT8, FT4, JT9, JT65, 
etc.) but first has to find out and put in the correct sub and sub-sub 
parameters, and has to do that every time he switches between these modes. No 
wonder that there are only VERY few users… (Here in EU the five or six stations 
using FST4 had QSOs with each other (or missed them because of sub-mode 
mismatch), and due to missing success they went back to FT8.) But all similar 
questions or comments from other users on that were also rejected. Sad story…



73 de Uwe, DG2YCB



Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com]
Gesendet: Dienstag, 16. Februar 2021 15:18
An: WSJT software development
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately



It looks to me that's precisely why Configurations were created. Why reinvent 
the wheel?



People should learn to use configurations and they can then customize their ops 
in any way they like.



I have 12 configs, every mode has its own config. No mistakes, no forgetting, 
no mis-setting. ...and no code bloat.



73, N0AN

Hasan





On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville mailto:g4...@classdesign.com> > wrote:

Uwe,



your description of your amendment sounds different from what you are 
asking for. If you have a version that switches to the T/R periods *you* use 
with certain modes, then that is fine for you but it is definitely not a 
general solution. if you have a general solution that you have tested for all 
modes and usage scenarios then why not contribute a patch?



73
Bill
G4WJS.



On 16/02/2021 12:27, DG2YCB, Uwe wrote:

Hi Bill,

Why are you not open to such a solution? Would certainly help 
to increase the extremely small number of FST4 users. It takes too long to 
switch configurations.

But: I've already found a solution for myself. In my 
wsjt-x_improved versions, I have now programmed it so that the mode buttons 
automatically switch on the most common sub-mode (FST4-A60 or Q65-A30). Only 
needed two additional lines in the source code ...

73 de Uwe, DG2YCB



Von: Bill Somerville [mailto:g4...@classdesign.com]
Gesendet: Dienstag, 16. Februar 2021 11:39
An: wsjt-devel@lists.sourceforge.net 

Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths 
for each mode separately



On 16/02/2021 10:16, DG2YCB, Uwe wrote:

Hi Bill,



Please let wsjt-x save the T/R sequence lengths for 
each mode separately. Why? Because for FST4 on 160m, FST4-A60 seems to become 
something like a “standard”, and for Q65 on 6m Q65-A30. But as wsjt-x currently 
saves only one T/R sequence lengths setting, each time the users have to change 
T/R sequence length when switching from FST4 to Q65 mode. It would help a lot 
when for FST4 and Q65 individual values are remembered. (And let FST4-A60 and 
Q65-A30 become the default settings when switching to “FST4” or “Q65”, so that 
it is easier for less-experienced users to start with these new modes.) Only a 
very minor change, but a significant 

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Serge Szpilfogel]

Very true Uwe I am on EME & if I go from JT65 to Q65 there is always an issue 
with configuration. So very few people use Q65 or if they do there is often an 
issue. Result they stay on JT65 & do not use Q65 which is a pity
73,
Serge VE1KG

-Original Message-
From: DG2YCB, Uwe  
Sent: Tuesday, February 16, 2021 15:51
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately

Hasan, I’m sorry, but I totally disagree. Configurations are there to switch 
e.g. between 2 completely different hardware setups, but not between two modes 
(or bands). Come on! That is the most basic task of a multi-mode program 
itself. 

It is a pity that on this reflector EVERY suggestion for improvement is 
immediately discredited. Rather frustrating! That’s why the "clones" are more 
and more are growing in popularity ... 

The point is that in case of the new modes FST4, Q65, etc., a user cannot 
simply switch to the mode and get started (as it was with FT8, FT4, JT9, JT65, 
etc.) but first has to find out and put in the correct sub and sub-sub 
parameters, and has to do that every time he switches between these modes. No 
wonder that there are only VERY few users… (Here in EU the five or six stations 
using FST4 had QSOs with each other (or missed them because of sub-mode 
mismatch), and due to missing success they went back to FT8.) But all similar 
questions or comments from other users on that were also rejected. Sad story…

 

73 de Uwe, DG2YCB 

 

Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com] 
Gesendet: Dienstag, 16. Februar 2021 15:18
An: WSJT software development
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately

 

It looks to me that's precisely why Configurations were created. Why reinvent 
the wheel?

 

People should learn to use configurations and they can then customize their ops 
in any way they like.

 

I have 12 configs, every mode has its own config. No mistakes, no forgetting, 
no mis-setting. ...and no code bloat.

 

73, N0AN

Hasan

 

 

On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville mailto:g4...@classdesign.com> > wrote:

Uwe,

 

your description of your amendment sounds different from what you are 
asking for. If you have a version that switches to the T/R periods *you* use 
with certain modes, then that is fine for you but it is definitely not a 
general solution. if you have a general solution that you have tested for all 
modes and usage scenarios then why not contribute a patch?

 

73
Bill
G4WJS.

 

On 16/02/2021 12:27, DG2YCB, Uwe wrote:

Hi Bill,

Why are you not open to such a solution? Would certainly help 
to increase the extremely small number of FST4 users. It takes too long to 
switch configurations.

But: I've already found a solution for myself. In my 
wsjt-x_improved versions, I have now programmed it so that the mode buttons 
automatically switch on the most common sub-mode (FST4-A60 or Q65-A30). Only 
needed two additional lines in the source code ...

73 de Uwe, DG2YCB 

 

Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Dienstag, 16. Februar 2021 11:39
An: wsjt-devel@lists.sourceforge.net 
 
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths 
for each mode separately

 

On 16/02/2021 10:16, DG2YCB, Uwe wrote:

Hi Bill,

 

Please let wsjt-x save the T/R sequence lengths for 
each mode separately. Why? Because for FST4 on 160m, FST4-A60 seems to become 
something like a “standard”, and for Q65 on 6m Q65-A30. But as wsjt-x currently 
saves only one T/R sequence lengths setting, each time the users have to change 
T/R sequence length when switching from FST4 to Q65 mode. It would help a lot 
when for FST4 and Q65 individual values are remembered. (And let FST4-A60 and 
Q65-A30 become the default settings when switching to “FST4” or “Q65”, so that 
it is easier for less-experienced users to start with these new modes.) Only a 
very minor change, but a significant improvement. Thanks!

 

73 de Uwe, DG2YCB 

Hi Uwe,

rather than undertake such a change I will recommend that you 
try using configurations to change mode, that way you can set the required T/R 
period along with other settings per mode, and even have multiple 
configurations for each mode you use, each with customized settings.

73
Bill
G4WJS.

 

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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Joe Taylor]

Hi Uwe,

On 2/16/2021 10:51 AM, DG2YCB, Uwe wrote:
Hasan, I’m sorry, but I totally disagree. Configurations are there to 
switch e.g. between 2 completely different hardware setups, but not 
between two modes (or bands). Come on! That is the most basic task of a 
multi-mode program itself.


Hasan is correct: experienced and knowledgeable users almost always use 
a Configuration for each mode.  That's precisely why the Configuration 
facility was created.


From the WSJT-X User Guide, Section 10.1.3:

"Many users prefer to create and use entries on the Configurations menu 
for switching between modes. Simply Clone the Default entry, Rename it 
as desired, and then make all desired settings for that configuration. 
These settings are restored whenever you select that configuration."


-- Joe, K1JT


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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[DG2YCB, Uwe]

Hasan, I’m sorry, but I totally disagree. Configurations are there to switch 
e.g. between 2 completely different hardware setups, but not between two modes 
(or bands). Come on! That is the most basic task of a multi-mode program 
itself. 

It is a pity that on this reflector EVERY suggestion for improvement is 
immediately discredited. Rather frustrating! That’s why the "clones" are more 
and more are growing in popularity ... 

The point is that in case of the new modes FST4, Q65, etc., a user cannot 
simply switch to the mode and get started (as it was with FT8, FT4, JT9, JT65, 
etc.) but first has to find out and put in the correct sub and sub-sub 
parameters, and has to do that every time he switches between these modes. No 
wonder that there are only VERY few users… (Here in EU the five or six stations 
using FST4 had QSOs with each other (or missed them because of sub-mode 
mismatch), and due to missing success they went back to FT8.) But all similar 
questions or comments from other users on that were also rejected. Sad story…

 

73 de Uwe, DG2YCB 

 

Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com] 
Gesendet: Dienstag, 16. Februar 2021 15:18
An: WSJT software development
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately

 

It looks to me that's precisely why Configurations were created. Why reinvent 
the wheel?

 

People should learn to use configurations and they can then customize their ops 
in any way they like.

 

I have 12 configs, every mode has its own config. No mistakes, no forgetting, 
no mis-setting. ...and no code bloat.

 

73, N0AN

Hasan

 

 

On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville  wrote:

Uwe,

 

your description of your amendment sounds different from what you are asking 
for. If you have a version that switches to the T/R periods *you* use with 
certain modes, then that is fine for you but it is definitely not a general 
solution. if you have a general solution that you have tested for all modes and 
usage scenarios then why not contribute a patch?

 

73
Bill
G4WJS.

 

On 16/02/2021 12:27, DG2YCB, Uwe wrote:

Hi Bill,

Why are you not open to such a solution? Would certainly help to increase the 
extremely small number of FST4 users. It takes too long to switch 
configurations.

But: I've already found a solution for myself. In my wsjt-x_improved versions, 
I have now programmed it so that the mode buttons automatically switch on the 
most common sub-mode (FST4-A60 or Q65-A30). Only needed two additional lines in 
the source code ...

73 de Uwe, DG2YCB 

 

Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Dienstag, 16. Februar 2021 11:39
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode 
separately

 

On 16/02/2021 10:16, DG2YCB, Uwe wrote:

Hi Bill,

 

Please let wsjt-x save the T/R sequence lengths for each mode separately. Why? 
Because for FST4 on 160m, FST4-A60 seems to become something like a “standard”, 
and for Q65 on 6m Q65-A30. But as wsjt-x currently saves only one T/R sequence 
lengths setting, each time the users have to change T/R sequence length when 
switching from FST4 to Q65 mode. It would help a lot when for FST4 and Q65 
individual values are remembered. (And let FST4-A60 and Q65-A30 become the 
default settings when switching to “FST4” or “Q65”, so that it is easier for 
less-experienced users to start with these new modes.) Only a very minor 
change, but a significant improvement. Thanks!

 

73 de Uwe, DG2YCB 

Hi Uwe,

rather than undertake such a change I will recommend that you try using 
configurations to change mode, that way you can set the required T/R period 
along with other settings per mode, and even have multiple configurations for 
each mode you use, each with customized settings.

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] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Bill Somerville]

Alan,

Hamlib is a separate library, although WSJT-X development team members 
contribute to Hamlib it is not our project. We provide a summarized 
Hamlib change log with changes not relevant to WSJT-X's usage omitted. I 
gave you the exact unique change reference so you could find the changes 
in question in the log, but it took me only a few seconds to find them 
using a general search for PTT. It seems we have done all the things you 
ask for. If you seriously think we are going to go through the 
potentially thousands of changes in each library we use and re-write in 
some form that you think is necessary, then forget it unless you are 
prepared to do that yourself as a contribution to the project. It tales 
a lot of time each time we make a release to do what we already do.


Please note that this PTT sharing capability was removed from Hamlib 
because it supposedly caused problems to some users. This facility is 
only used by a tiny subset of WSJT-X users. You are complaining in the 
wrong place, we have done what is necessary to allow users of this 
facility to carry on using it without having to diverge from the 
mainstream Hamlib library with a customized version.


There seems to be nothing I can write that you will not find fault with, 
please go elsewhere and complain about Hamlib changes you don't like on 
a forum where that has at least a chance of making a difference.


73
Bill
G4WJS.

On 16/02/2021 14:08, Alan Groups wrote:


hanks, but my comment referred only to changes that impact users, not 
details behind the scenes - that would indeed be unnecessary.


I've looked at the link to the change log, but even that wasn't 
obvious to me what it is - it doesn't say change log in the filename, 
just wsjt-x xxx.log.  Then the change titles aren't exactly user 
friendly either!


For the bewildered non-programmer user perhaps trying to find out why 
something doesn't work any more, or has changed behaviour, it's almost 
impossible even if they did know where to look in the first place.


The issue reported here doesn't affect me, but my plea is simply for 
documentation to be clear, complete and intuitive as that's what 
seemed to me to be missing this case.  Programmers will of course know 
the detail, but users will not.


If there's detail that would be simply too much to document then 
simply include a statement about that as well, and for such changes in 
other libraries all that's needed is a simple link to their change 
logs, unless a change looks like it might result in significantly 
different behaviour within wsjt-x.


I'm not complaining, just trying to make already excellent software 
better by hopefully reducing support requests, by enabling users to 
more easily find stuff out for themselves. Keep up the good work.


Alan G0TLK
On 16/02/2021 11:16, Bill Somerville wrote:

Alan,

that is a completely unreasonable request, WSJT-X uses many 
supporting libraries and on some platforms the version used is 
dependent on the operating system version rather than what we 
specify. Nevertheless we do include a summary change history for both 
WSJT-X and Hamlib with every release.


For example review the change log for WSJT-X v2.3.0 which you can 
find here next to the release notes: 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/


Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e

and for change: 4faad82da727e908cfc79d856f391d9feed46e7e

to see the two changes related to this issue.

Note that a Hamlib developer made a change to fix an issue, we took 
that change on good faith. We also asked for an option to revert to 
the old behaviour for users that needed it. You would have us not 
take the fix for the problem so you can remain a Luddite, sorry 
that's not the way things work.


I have changed WSJT-X for the next release to override the Hamlib 
behaviour and enable PTT sharing for all users, that will mean that 
if the original problem is real then unsuspecting users will have 
problems even if they have no use or knowledge of PTT sharing between 
Hamlib clients. Let's see how that goes?


73
Bill
G4WJS.

On 16/02/2021 10:59, Alan Groups wrote:


And if I may chip in most importantly please make sure *all* changes 
are listed in release notes, with a link to release notes for 
libraries that are used - so users can see them intuitively.


Leaving users to find out about changes unexpectedly in what is 
becoming a large and complex app leads to unnecessary bug reports 
and frustration/irritation all round!


Alan G0TLK
On 16/02/2021 10:49, tom wrote:

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it 
- ’never touch a running system’ - tidy up coding to make it more 
robust yes but removing a feature IMO is same as altering a default 
- it no longer works the same.


Also as with Alex just deleted a chuck of this reply so the thread 
does not go down hill fast.


Expressed my point I hope some more consideration may be 

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Hasan N0AN]

It looks to me that's precisely why Configurations were created. Why
reinvent the wheel?

People should learn to use configurations and they can then customize their
ops in any way they like.

I have 12 configs, every mode has its own config. No mistakes, no
forgetting, no mis-setting. ...and no code bloat.

73, N0AN
Hasan


On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville 
wrote:

> Uwe,
>
> your description of your amendment sounds different from what you are
> asking for. If you have a version that switches to the T/R periods **you**
> use with certain modes, then that is fine for you but it is definitely not
> a general solution. if you have a general solution that you have tested for
> all modes and usage scenarios then why not contribute a patch?
>
> 73
> Bill
> G4WJS.
>
> On 16/02/2021 12:27, DG2YCB, Uwe wrote:
>
> Hi Bill,
>
> Why are you not open to such a solution? Would certainly help to increase
> the extremely small number of FST4 users. It takes too long to switch
> configurations.
>
> But: I've already found a solution for myself. In my wsjt-x_improved
> versions, I have now programmed it so that the mode buttons automatically
> switch on the most common sub-mode (FST4-A60 or Q65-A30). Only needed two
> additional lines in the source code ...
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Bill Somerville [mailto:g4...@classdesign.com
> ]
> *Gesendet:* Dienstag, 16. Februar 2021 11:39
> *An:* wsjt-devel@lists.sourceforge.net
> *Betreff:* Re: [wsjt-devel] Please save the T/R sequence lengths for each
> mode separately
>
>
>
> On 16/02/2021 10:16, DG2YCB, Uwe wrote:
>
> Hi Bill,
>
>
>
> Please let wsjt-x save the T/R sequence lengths for each mode separately.
> Why? Because for FST4 on 160m, FST4-A60 seems to become something like a
> “standard”, and for Q65 on 6m Q65-A30. But as wsjt-x currently saves only
> one T/R sequence lengths setting, each time the users have to change T/R
> sequence length when switching from FST4 to Q65 mode. It would help a lot
> when for FST4 and Q65 individual values are remembered. (And let FST4-A60
> and Q65-A30 become the default settings when switching to “FST4” or “Q65”,
> so that it is easier for less-experienced users to start with these new
> modes.) Only a very minor change, but a significant improvement. Thanks!
>
>
>
> 73 de Uwe, DG2YCB
>
> Hi Uwe,
>
> rather than undertake such a change I will recommend that you try using
> configurations to change mode, that way you can set the required T/R period
> along with other settings per mode, and even have multiple configurations
> for each mode you use, each with customized settings.
>
> 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] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Alan Groups]

Thanks, but my comment referred only to changes that impact users, not 
details behind the scenes - that would indeed be unnecessary.


I've looked at the link to the change log, but even that wasn't obvious 
to me what it is - it doesn't say change log in the filename, just 
wsjt-x xxx.log.  Then the change titles aren't exactly user friendly either!


For the bewildered non-programmer user perhaps trying to find out why 
something doesn't work any more, or has changed behaviour, it's almost 
impossible even if they did know where to look in the first place.


The issue reported here doesn't affect me, but my plea is simply for 
documentation to be clear, complete and intuitive as that's what seemed 
to me to be missing this case.  Programmers will of course know the 
detail, but users will not.


If there's detail that would be simply too much to document then simply 
include a statement about that as well, and for such changes in other 
libraries all that's needed is a simple link to their change logs, 
unless a change looks like it might result in significantly different 
behaviour within wsjt-x.


I'm not complaining, just trying to make already excellent software 
better by hopefully reducing support requests, by enabling users to more 
easily find stuff out for themselves. Keep up the good work.


Alan G0TLK

On 16/02/2021 11:16, Bill Somerville wrote:

Alan,

that is a completely unreasonable request, WSJT-X uses many supporting 
libraries and on some platforms the version used is dependent on the 
operating system version rather than what we specify. Nevertheless we 
do include a summary change history for both WSJT-X and Hamlib with 
every release.


For example review the change log for WSJT-X v2.3.0 which you can find 
here next to the release notes: 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/


Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e

and for change: 4faad82da727e908cfc79d856f391d9feed46e7e

to see the two changes related to this issue.

Note that a Hamlib developer made a change to fix an issue, we took 
that change on good faith. We also asked for an option to revert to 
the old behaviour for users that needed it. You would have us not take 
the fix for the problem so you can remain a Luddite, sorry that's not 
the way things work.


I have changed WSJT-X for the next release to override the Hamlib 
behaviour and enable PTT sharing for all users, that will mean that if 
the original problem is real then unsuspecting users will have 
problems even if they have no use or knowledge of PTT sharing between 
Hamlib clients. Let's see how that goes?


73
Bill
G4WJS.

On 16/02/2021 10:59, Alan Groups wrote:


And if I may chip in most importantly please make sure *all* changes 
are listed in release notes, with a link to release notes for 
libraries that are used - so users can see them intuitively.


Leaving users to find out about changes unexpectedly in what is 
becoming a large and complex app leads to unnecessary bug reports and 
frustration/irritation all round!


Alan G0TLK
On 16/02/2021 10:49, tom wrote:

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - 
’never touch a running system’ - tidy up coding to make it more 
robust yes but removing a feature IMO is same as altering a default 
- it no longer works the same.


Also as with Alex just deleted a chuck of this reply so the thread 
does not go down hill fast.


Expressed my point I hope some more consideration may be given if 
this sort of issue arrises in the future.


Tom
GM8MJV

On 16 Feb 2021, at 10:32, Bill Somerville > wrote:


Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of 
a feature that apparently was causing issues. I asked that it not 
be removed and the option offered was to make it a configuration 
option.


73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:


Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in 
IT we always said “never touch a running system” and for 
programming also apply, why change the previous default for 
something doesn’t works? And create just problems?


PTT and associated routines was working great up to WSJT-X 2.2.2, 
why change that?, the proof of the pudding is in the eating, for 
sure exist a valid reason by “the authors” but unfortunate this 
time maybe wrong.


Alex, HB9DRI

*From:* tom 
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael ; WSJT software 
development 

*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my 
comments.


It seems a LOT of the errors recently seem to be because HamLib 
have altered defaults and others have to pick up the flack.


It always used to be the case ’never alter the default’ - yes add 
new features but never change the default.


There has been the 

Re: [wsjt-devel] Clipping

[Bill Somerville]

Mike,

reducing the output to eliminate a smaller than -65 dB source of noise 
in the transmitted signal on Windows only is dancing on the head of a 
pin. If you are concerned then feel free to reduce the Pwr slider a tad. 
I have no wish to invoke the Qt volume control on all platforms, or even 
on Windows, when it's not necessary. Having the Pwr slider at 0dB is a 
special case that uses less processing of the signal.


73
Bill
G4WJS.

On 16/02/2021 13:54, Black Michael via wsjt-devel wrote:

Well I guess can wait for Microsoft to fix it...lemme' hold my breath...

Problem verified on Windows 10 with VoiceMeter VAC, and Muzychenko
Problem verified on another operator's IC7300 system Microsoft USB 
audio driver.
So that's 3 different audio drivers which indicates it's an OS problem 
to me.

Using

It's a small change that nobody will notice and solves a problem 
(however minimal it may be) that most operators won't even know 
they're transmitting.


FYI...here's what my dB meter shows without the patch
Inline image


Mike W9MDB

On Tuesday, February 16, 2021, 04:30:29 AM CST, Bill Somerville 
 wrote:



Mike,

we have verified the output from WSJT-X is clean, this is not an issue 
that needs fixing in WSJT-X. Note also that on Linux and macOS no such 
distortion is present.


73
Bill
G4WJS.

On 16/02/2021 04:18, Black Michael via wsjt-devel wrote:

Patch to fix the problem

index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@ -1288,6 +1288,7 @@ void MainWindow::readSettings()
    // setup initial value of tx attenuator
    m_block_pwr_tooltip = true;
    ui->outAttenuation->setValue (m_settings->value ("OutAttenuation", 0).toInt 
());
+  on_outAttenuation_valueChanged(ui->outAttenuation->value());
    m_block_pwr_tooltip = false;
    ui->sbCQTxFreq->setValue (m_settings->value ("CQTxFreq", 260).toInt());
    m_noSuffix=m_settings->value("NoSuffix",false).toBool();
@@ -7424,7 +7425,7 @@ void MainWindow::transmit (double snr)
  void MainWindow::on_outAttenuation_valueChanged (int a)
  {
    QString tt_str;
-  qreal dBAttn {a / 10.};       // slider interpreted as dB / 100
+  qreal dBAttn {a / 10. + 3};       // slider interpreted as dB / 100  (+3 to 
keep minimize artifacts)
    if (m_tune && m_config.pwrBandTuneMemory()) {
      tt_str = tr ("Tune digital gain ");
    } else {


Mike W9MDB





On Monday, February 15, 2021, 07:36:18 AM CST, Bill Somerville 
   wrote:






Mike,




the "nastiness" you refer to is more than 65 dB down. As far as we have been 
able to determine it is due to either Windows or VAC. My money is on Windows since VB 
Cable exhibits the same behaviour, although that is not conclusive. Note that 65 dB down 
is below the distortion added by almost all transmitters. We are pretty certain Qt is not 
the cause since when the Pwr slider is at 0dB Qt does nothing with the samples other than 
copy them to the Windows MME audio buffers.




73
Bill
G4WJS.




On 15/02/2021 13:23, Black Michael via wsjt-devel wrote:


   
   
   
It's not just the waterfallthat nastiness gets transmitted too.





Mike W9MDB




   













   
   
   On Monday, February 15, 2021, 02:53:44 AM CST, Reino Talarmo    wrote:








   
   
   
   
Hi Mike and Bill,


I looked those *.wav files using v2.4.0-rc1 and noted interesting presentation 
difference, when I had Flatten activated or non-activated. Especially the 
waterfall display changed a lot. It was difficult to see those multiple 
sidebands in non-flatten display totally independent of gain and zero settings. 
In spectrum display I can see the carrier and weak sidebands at 310 Hz or so. 
In both flattened and non-flattened spectrum other than the 310 Hz sidebands 
are really weak some are just a pixel or two and others none.Could the 
flattening do more than modify the frequency amplitude and be an additional 
reason for a bad waterfall display?

73, Reino OH3mA



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

Re: [wsjt-devel] Clipping

[Black Michael via wsjt-devel]

You're wrong -- it's being transmitted too.I send that example a while ago.
Mike W9MDB

 

On Tuesday, February 16, 2021, 02:44:26 AM CST, Reino Talarmo 
 wrote:  
 
 >Patch to fix the problem

index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@ -1288,6 +1288,7 @@ void MainWindow::readSettings()
  // setup initial value of tx attenuator
  m_block_pwr_tooltip = true;
  ui->outAttenuation->setValue (m_settings->value ("OutAttenuation", 0).toInt 
());
+  on_outAttenuation_valueChanged(ui->outAttenuation->value());
  m_block_pwr_tooltip = false;
  ui->sbCQTxFreq->setValue (m_settings->value ("CQTxFreq", 260).toInt());
  m_noSuffix=m_settings->value("NoSuffix",false).toBool();
@@ -7424,7 +7425,7 @@ void MainWindow::transmit (double snr)
 void MainWindow::on_outAttenuation_valueChanged (int a)
 {
  QString tt_str;
-  qreal dBAttn {a / 10.};      // slider interpreted as dB / 100
+  qreal dBAttn {a / 10. + 3};      // slider interpreted as dB / 100  (+3 to 
keep minimize artifacts)
  if (m_tune && m_config.pwrBandTuneMemory()) {
    tt_str = tr ("Tune digital gain ");
  } else {

>Mike W9MDB

Hi 
I still would like to know where the issue really is. I have now impression 
that it is at receiving entity not at transmitting one. Looks more like a 
measurement artifact due to some (dynamic range) problem at waterfall display. 
Correct me, if I am wrong.

73, Reino OH3mA

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

Re: [wsjt-devel] Clipping

[Black Michael via wsjt-devel]

Well I guess can wait for Microsoft to fix it...lemme' hold my breath...
Problem verified on Windows 10 with VoiceMeter VAC, and MuzychenkoProblem 
verified on another operator's IC7300 system Microsoft USB audio driver.So 
that's 3 different audio drivers which indicates it's an OS problem to me.Using 
 It's a small change that nobody will notice and solves a problem (however 
minimal it may be) that most operators won't even know they're transmitting.
FYI...here's what my dB meter shows without the patch


Mike W9MDB
On Tuesday, February 16, 2021, 04:30:29 AM CST, Bill Somerville 
 wrote:  
 
  Mike, 
  we have verified the output from WSJT-X is clean, this is not an issue that 
needs fixing in WSJT-X. Note also that on Linux and macOS no such distortion is 
present. 
  73
 Bill
 G4WJS. 
  On 16/02/2021 04:18, Black Michael via wsjt-devel wrote:
  
 Patch to fix the problem

index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@ -1288,6 +1288,7 @@ void MainWindow::readSettings()
   // setup initial value of tx attenuator
   m_block_pwr_tooltip = true;
   ui->outAttenuation->setValue (m_settings->value ("OutAttenuation", 0).toInt 
());
+  on_outAttenuation_valueChanged(ui->outAttenuation->value());
   m_block_pwr_tooltip = false;
   ui->sbCQTxFreq->setValue (m_settings->value ("CQTxFreq", 260).toInt());
   m_noSuffix=m_settings->value("NoSuffix",false).toBool();
@@ -7424,7 +7425,7 @@ void MainWindow::transmit (double snr)
 void MainWindow::on_outAttenuation_valueChanged (int a)
 {
   QString tt_str;
-  qreal dBAttn {a / 10.};       // slider interpreted as dB / 100
+  qreal dBAttn {a / 10. + 3};       // slider interpreted as dB / 100  (+3 to 
keep minimize artifacts)
   if (m_tune && m_config.pwrBandTuneMemory()) {
     tt_str = tr ("Tune digital gain ");
   } else {


Mike W9MDB





On Monday, February 15, 2021, 07:36:18 AM CST, Bill Somerville 
 wrote: 






Mike,




the "nastiness" you refer to is more than 65 dB down. As far as we have been 
able to determine it is due to either Windows or VAC. My money is on Windows 
since VB Cable exhibits the same behaviour, although that is not conclusive. 
Note that 65 dB down is below the distortion added by almost all transmitters. 
We are pretty certain Qt is not the cause since when the Pwr slider is at 0dB 
Qt does nothing with the samples other than copy them to the Windows MME audio 
buffers.




73
Bill
G4WJS.




On 15/02/2021 13:23, Black Michael via wsjt-devel wrote:


 
   
  
  
It's not just the waterfallthat nastiness gets transmitted too.




Mike W9MDB




  












  
  
  On Monday, February 15, 2021, 02:53:44 AM CST, Reino Talarmo 
 wrote: 







  
  
  
  
Hi Mike and Bill,

I looked those *.wav files using v2.4.0-rc1 and noted interesting presentation 
difference, when I had Flatten activated or non-activated. Especially the 
waterfall display changed a lot. It was difficult to see those multiple 
sidebands in non-flatten display totally independent of gain and zero settings. 
In spectrum display I can see the carrier and weak sidebands at 310 Hz or so. 
In both flattened and non-flattened spectrum other than the 310 Hz sidebands 
are really weak some are just a pixel or two and others none.Could the 
flattening do more than modify the frequency amplitude and be an additional 
reason for a bad waterfall display?

73, Reino OH3mA 
 
 

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

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Black Michael via wsjt-devel]

Since you are putting it back to what didn't work for a couple of users how 
about a checkbox to enable/disable sharing?
Mike W9MDB

 

On Tuesday, February 16, 2021, 05:20:45 AM CST, Bill Somerville 
 wrote:  
 
   Alan, 
  that is a completely unreasonable request, WSJT-X uses many supporting 
libraries and on some platforms the version used is dependent on the operating 
system version rather than what we specify. Nevertheless we do include a 
summary change history for both WSJT-X and Hamlib with every release. 
  For example review the change log for WSJT-X v2.3.0 which you can find here 
next to the release notes: 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/
  
  Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e 
  and for change: 4faad82da727e908cfc79d856f391d9feed46e7e 
  to see the two changes related to this issue. 
  Note that a Hamlib developer made a change to fix an issue, we took that 
change on good faith. We also asked for an option to revert to the old 
behaviour for users that needed it. You would have us not take the fix for the 
problem so you can remain a Luddite, sorry that's not the way things work. 
  I have changed WSJT-X for the next release to override the Hamlib behaviour 
and enable PTT sharing for all users, that will mean that if the original 
problem is real then unsuspecting users will have problems even if they have no 
use or knowledge of PTT sharing between Hamlib clients. Let's see how that goes?
  
  73
 Bill
 G4WJS. 
  On 16/02/2021 10:59, Alan Groups wrote:
  
 
And if I may chip in most importantly please make sure *all* changes are listed 
in release notes, with a link to release notes for libraries that are used - so 
users can see them intuitively.
 
Leaving users to find out about changes unexpectedly in what is becoming a 
large and complex app leads to unnecessary bug reports and 
frustration/irritation all round! 
 
 Alan G0TLK On 16/02/2021 10:49, tom wrote:
  
 Thanks for the update Bill 
  I have no issue with options being configurable but as Alex put it - ’never 
touch a running system’ - tidy up coding to make it more robust yes but 
removing a feature IMO is same as altering a default - it no longer works the 
same. 
  Also as with Alex just deleted a chuck of this reply so the thread does not 
go down hill fast. 
  Expressed my point I hope some more consideration may be given if this sort 
of issue arrises in the future. 
  Tom GM8MJV
 
 
 On 16 Feb 2021, at 10:32, Bill Somerville  wrote: 
   Hi Alex and Tom, 
  the Hamlib change was not a change of defaults, it was a removal of a feature 
that apparently was causing issues. I asked that it not be removed and the 
option offered was to make it a configuration option. 
  73
 Bill
 G4WJS. 
  On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:
  
 
Totally in agree with Tom
 
  
 
I delete part of my previous email to avoid start arguments BUT in IT we always 
said “never touch a running system” and for programming also apply, why change 
the previous default for something doesn’t works? And create just problems?
 
  
 
PTT and associated routines was working great up to WSJT-X 2.2.2, why change 
that?, the proof of the pudding is in the eating, for sure exist a valid reason 
by “the authors” but unfortunate this time maybe wrong.
 
  
 
Alex, HB9DRI
 
  
   
From: tom  
 Sent: Tuesday, February 16, 2021 4:18 PM
 To: Black Michael ; WSJT software development 

 Subject: Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port
   
  
 
Hi All
  
  
   
Don’t want to start an argument and please feel free to ignore my comments.
   
  
   
It seems a LOT of the errors recently seem to be because HamLib have altered 
defaults and others have to pick up the flack.
   
  
   
It always used to be the case ’never alter the default’ - yes add new features 
but never change the default.
   
  
   
There has been the issue of powering rigs on - default changed, shared ptt - 
default changed.
   
  
   
There are more than a ‘couple of complains’ on this mailing list alone to keep 
the status quo.
   
  
   
Please Please Please DO NOT start to toss the blame around - oh it up to xyz to 
change their software to over-ride the changes we made.  Just keep defaults as 
they were and all will be happy.
   
  
   
End of rant
   
  
   
Tom
   
GM8MJV
   
  
   
  
   
  
On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
 wrote:
  
  
  
A couple of complaints from those who were using a single instance were having 
problems with the constant open/close of the serial port.
   
So it was changed to support the simple case and those that want the more 
complex case of multiple apps have to use the additional file as WSJT-X authors 
have decided to not include any options in the rig control user interface.
   
  
   
I'm looking at the sharing now to see if there is a problem going on.
   
  
   
Mike W9MDB
   
  

  
 
  
   
  
  
On Monday, February 15, 2021, 10:33:13 PM 

Re: [wsjt-devel] Clipping

[Stefan HB9TMC]

Hi Mike,

For further identification of the source of the issue, you could try to 
generate a 100% modulated sine wave in audacity and play it back.

"Generate -> Tone -> Amplitude 1".
That will contain no clipping or distortion.

You can also use audacity to search for clipping "Analyze -> Find 
Clipping". But none of your uploaded wav files shows clipping or a 
significantly distorted signal.


I've seen sound cards that cause distortion at 100% drive, but that will 
be another issue (driver/hardware).


73
Stefan


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

Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Alex Artieda, HB9DRI]

Hello Bill

 

The file you send me has the same code send to me from the beginning, I delete 
the file I create and I confirm your file was installed into the log directory 
in each WSJT-X instance I had, doesn’t work.

 

To confirm the problem I install in another computer two WSJT-X and use your 
file and doesn’t work.

 

As you mention in one of your last emails you will back in the next release to 
sharing the PTT port, something make totally sense if you consider it was 
working ok in version 2.2.2.

 

Regards

Alex, HB9DRI

 

From: Bill Somerville  
Sent: Tuesday, February 16, 2021 5:31 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

Hi Alex,

 

the file I attached was the correct one. Others have used it without issues. 
Please double check the file is correctly named and has not been mangled by 
Windows in some way. Note the file name must be hamlib_settings.json

 

73
Bill
G4WJS.

 

On 16/02/2021 04:29, Alex Artieda, HB9DRI wrote:

Hello Bill

 

Following your instructions I use your file  (looks the same as I use before) 
and I place in the properly log directory for each of the WSJT-X (totally 4) 
and doesn’t work, the PTT is not share.

 

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
not?

 

Regards

Alex, HB9DRI

 

From: Bill Somerville    
Sent: Monday, February 15, 2021 6:29 PM
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

Hi Alex,

 

try the attached file. It needs to go in the log files directory of each WSJT-X 
instance ("Settings->File->Open log directory").

 

73
Bill
G4WJS.

 

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

 

Sorry I didn’t answer to the list;

 

I create a file named hamlib_settings.json and paste inside the code you send 
me:

 

{

 "config": {

"ptt_share": 1

 }

}

 

Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in 

Each of the 4 WSJT-X folders but doesn’t work,

 

Alex, HB9DRI

 

 

From: Black Michael via wsjt-devel   
 
Sent: Monday, February 15, 2021 11:11 AM
To: wsjt-devel@lists.sourceforge.net  
Cc: Black Michael   
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

The PTT port is no longer shareable by default.

 

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

 

{

 "config": {

"ptt_share": 1

 }

}

 

 

Mike W9MDB

 

 

 

On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI < 
 hb9...@emeham.com> wrote: 

 

 

Just to inform you, I found a bug regarding COM port for PTT, it appears in 
WSJT-X 2.3 and in 2.4 RC1, let me explain.

 

I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT is 
manage via a COM port, this is a must for me to TX first a Sequencer via the 
COM port and later TX the radio, I cannot use CAT for PTT,  that guarantee me 
no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all configure to use COM3 
for PTT, in this configuration I can TX with ANY of the 6 programs, more 
precise I can TX with the program were the decodes or best decode happens, 
unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with the FIRST program 
who opens the PTT COM port, the other ones don’t work and MAP65 give a opening 
COM port ERROR, the other WSJT-X simple don’t TX, would be great to fix this 
bug because when you run multiple WSJT-X is a must to work with all instance 
capable of TX, WSJT-X 2.2.2 works perfect.

 

To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, the 
bug appear in 2.3

 

73 de Alex, HB9DRI

 

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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Bill Somerville]

Uwe,

your description of your amendment sounds different from what you are 
asking for. If you have a version that switches to the T/R periods 
**you** use with certain modes, then that is fine for you but it is 
definitely not a general solution. if you have a general solution that 
you have tested for all modes and usage scenarios then why not 
contribute a patch?


73
Bill
G4WJS.

On 16/02/2021 12:27, DG2YCB, Uwe wrote:


Hi Bill,

Why are you not open to such a solution? Would certainly help to 
increase the extremely small number of FST4 users. It takes too long 
to switch configurations.


But: I've already found a solution for myself. In my wsjt-x_improved 
versions, I have now programmed it so that the mode buttons 
automatically switch on the most common sub-mode (FST4-A60 or 
Q65-A30). Only needed two additional lines in the source code ...


73 de Uwe, DG2YCB

*Von:*Bill Somerville [mailto:g4...@classdesign.com]
*Gesendet:* Dienstag, 16. Februar 2021 11:39
*An:* wsjt-devel@lists.sourceforge.net
*Betreff:* Re: [wsjt-devel] Please save the T/R sequence lengths for 
each mode separately


On 16/02/2021 10:16, DG2YCB, Uwe wrote:

Hi Bill,

Please let wsjt-x save the T/R sequence lengths for each mode
separately. Why? Because for FST4 on 160m, FST4-A60 seems to
become something like a “standard”, and for Q65 on 6m Q65-A30. But
as wsjt-x currently saves only one T/R sequence lengths setting,
each time the users have to change T/R sequence length when
switching from FST4 to Q65 mode. It would help a lot when for FST4
and Q65 individual values are remembered. (And let FST4-A60 and
Q65-A30 become the default settings when switching to “FST4” or
“Q65”, so that it is easier for less-experienced users to start
with these new modes.) Only a very minor change, but a significant
improvement. Thanks!

73 de Uwe, DG2YCB

Hi Uwe,

rather than undertake such a change I will recommend that you try 
using configurations to change mode, that way you can set the required 
T/R period along with other settings per mode, and even have multiple 
configurations for each mode you use, each with customized settings.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[DG2YCB, Uwe]

Hi Bill,

Why are you not open to such a solution? Would certainly help to increase
the extremely small number of FST4 users. It takes too long to switch
configurations.

But: I've already found a solution for myself. In my wsjt-x_improved
versions, I have now programmed it so that the mode buttons automatically
switch on the most common sub-mode (FST4-A60 or Q65-A30). Only needed two
additional lines in the source code ...

73 de Uwe, DG2YCB



Von: Bill Somerville [mailto:g4...@classdesign.com]
Gesendet: Dienstag, 16. Februar 2021 11:39
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each mode
separately



On 16/02/2021 10:16, DG2YCB, Uwe wrote:

Hi Bill,



Please let wsjt-x save the T/R sequence lengths for each mode separately.
Why? Because for FST4 on 160m, FST4-A60 seems to become something like a
"standard", and for Q65 on 6m Q65-A30. But as wsjt-x currently saves only
one T/R sequence lengths setting, each time the users have to change T/R
sequence length when switching from FST4 to Q65 mode. It would help a lot
when for FST4 and Q65 individual values are remembered. (And let FST4-A60
and Q65-A30 become the default settings when switching to "FST4" or "Q65",
so that it is easier for less-experienced users to start with these new
modes.) Only a very minor change, but a significant improvement. Thanks!



73 de Uwe, DG2YCB

Hi Uwe,

rather than undertake such a change I will recommend that you try using
configurations to change mode, that way you can set the required T/R period
along with other settings per mode, and even have multiple configurations
for each mode you use, each with customized settings.

73
Bill
G4WJS.

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

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Bill Somerville]

Alan,

that is a completely unreasonable request, WSJT-X uses many supporting 
libraries and on some platforms the version used is dependent on the 
operating system version rather than what we specify. Nevertheless we do 
include a summary change history for both WSJT-X and Hamlib with every 
release.


For example review the change log for WSJT-X v2.3.0 which you can find 
here next to the release notes: 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/


Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e

and for change: 4faad82da727e908cfc79d856f391d9feed46e7e

to see the two changes related to this issue.

Note that a Hamlib developer made a change to fix an issue, we took that 
change on good faith. We also asked for an option to revert to the old 
behaviour for users that needed it. You would have us not take the fix 
for the problem so you can remain a Luddite, sorry that's not the way 
things work.


I have changed WSJT-X for the next release to override the Hamlib 
behaviour and enable PTT sharing for all users, that will mean that if 
the original problem is real then unsuspecting users will have problems 
even if they have no use or knowledge of PTT sharing between Hamlib 
clients. Let's see how that goes?


73
Bill
G4WJS.

On 16/02/2021 10:59, Alan Groups wrote:


And if I may chip in most importantly please make sure *all* changes 
are listed in release notes, with a link to release notes for 
libraries that are used - so users can see them intuitively.


Leaving users to find out about changes unexpectedly in what is 
becoming a large and complex app leads to unnecessary bug reports and 
frustration/irritation all round!


Alan G0TLK
On 16/02/2021 10:49, tom wrote:

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - 
’never touch a running system’ - tidy up coding to make it more 
robust yes but removing a feature IMO is same as altering a default - 
it no longer works the same.


Also as with Alex just deleted a chuck of this reply so the thread 
does not go down hill fast.


Expressed my point I hope some more consideration may be given if 
this sort of issue arrises in the future.


Tom
GM8MJV

On 16 Feb 2021, at 10:32, Bill Somerville > wrote:


Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of 
a feature that apparently was causing issues. I asked that it not be 
removed and the option offered was to make it a configuration option.


73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:


Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in 
IT we always said “never touch a running system” and for 
programming also apply, why change the previous default for 
something doesn’t works? And create just problems?


PTT and associated routines was working great up to WSJT-X 2.2.2, 
why change that?, the proof of the pudding is in the eating, for 
sure exist a valid reason by “the authors” but unfortunate this 
time maybe wrong.


Alex, HB9DRI

*From:* tom 
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael ; WSJT software 
development 

*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my 
comments.


It seems a LOT of the errors recently seem to be because HamLib 
have altered defaults and others have to pick up the flack.


It always used to be the case ’never alter the default’ - yes add 
new features but never change the default.


There has been the issue of powering rigs on - default changed, 
shared ptt - default changed.


There are more than a ‘couple of complains’ on this mailing list 
alone to keep the status quo.


Please Please Please DO NOT start to toss the blame around - oh it 
up to xyz to change their software to over-ride the changes we 
made.  Just keep defaults as they were and all will be happy.


End of rant

Tom

GM8MJV

On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> wrote:

A couple of complaints from those who were using a single
instance were having problems with the constant open/close of
the serial port.

So it was changed to support the simple case and those that
want the more complex case of multiple apps have to use the
additional file as WSJT-X authors have decided to not include
any options in the rig control user interface.

I'm looking at the sharing now to see if there is a problem
going on.

Mike W9MDB

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Hello Bill

Following your instructions I use your file  (looks the same as
I use before) and I place in the properly log directory for
each of the WSJT-X (totally 4) and doesn’t work, the PTT is not
share.

I wonder why if in WSJT-X 2.2.2 the PTT 

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Alan Groups]

And if I may chip in most importantly please make sure *all* changes are 
listed in release notes, with a link to release notes for libraries that 
are used - so users can see them intuitively.


Leaving users to find out about changes unexpectedly in what is becoming 
a large and complex app leads to unnecessary bug reports and 
frustration/irritation all round!


Alan G0TLK

On 16/02/2021 10:49, tom wrote:

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - 
’never touch a running system’ - tidy up coding to make it more robust 
yes but removing a feature IMO is same as altering a default - it no 
longer works the same.


Also as with Alex just deleted a chuck of this reply so the thread 
does not go down hill fast.


Expressed my point I hope some more consideration may be given if this 
sort of issue arrises in the future.


Tom
GM8MJV

On 16 Feb 2021, at 10:32, Bill Somerville > wrote:


Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of a 
feature that apparently was causing issues. I asked that it not be 
removed and the option offered was to make it a configuration option.


73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:


Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in 
IT we always said “never touch a running system” and for programming 
also apply, why change the previous default for something doesn’t 
works? And create just problems?


PTT and associated routines was working great up to WSJT-X 2.2.2, 
why change that?, the proof of the pudding is in the eating, for 
sure exist a valid reason by “the authors” but unfortunate this time 
maybe wrong.


Alex, HB9DRI

*From:* tom 
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael ; WSJT software development 


*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my 
comments.


It seems a LOT of the errors recently seem to be because HamLib have 
altered defaults and others have to pick up the flack.


It always used to be the case ’never alter the default’ - yes add 
new features but never change the default.


There has been the issue of powering rigs on - default changed, 
shared ptt - default changed.


There are more than a ‘couple of complains’ on this mailing list 
alone to keep the status quo.


Please Please Please DO NOT start to toss the blame around - oh it 
up to xyz to change their software to over-ride the changes we made. 
 Just keep defaults as they were and all will be happy.


End of rant

Tom

GM8MJV

On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> wrote:

A couple of complaints from those who were using a single
instance were having problems with the constant open/close of
the serial port.

So it was changed to support the simple case and those that want
the more complex case of multiple apps have to use the
additional file as WSJT-X authors have decided to not include
any options in the rig control user interface.

I'm looking at the sharing now to see if there is a problem
going on.

Mike W9MDB

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Hello Bill

Following your instructions I use your file  (looks the same as
I use before) and I place in the properly log directory for each
of the WSJT-X (totally 4) and doesn’t work, the PTT is not share.

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by
default now is not?

Regards

Alex, HB9DRI

*From:*Bill Somerville mailto:g4...@classdesign.com>>
*Sent:* Monday, February 15, 2021 6:29 PM
*To:* wsjt-devel@lists.sourceforge.net

*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM
port

Hi Alex,

try the attached file. It needs to go in the log files directory
of each WSJT-X instance ("Settings->File->Open log directory").

73
Bill
G4WJS.

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

Sorry I didn’t answer to the list;

I create a file named hamlib_settings.json and paste inside
the code you send me:

{

     "config": {

"ptt_share": 1

     }

}

Then placethis file in
C:\Users\[username]\AppData\Local\WSJT-X and in

Each of the 4 WSJT-X folders but doesn’t work,

Alex, HB9DRI

*From:*Black Michael via wsjt-devel


*Sent:* Monday, February 15, 2021 11:11 AM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Black Michael 

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Bill Somerville]

Tom,

the Hamlib support list is here: 
https://sourceforge.net/projects/hamlib/lists/hamlib-developer


73
Bill
G4WJS.

On 16/02/2021 10:49, tom wrote:

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - 
’never touch a running system’ - tidy up coding to make it more robust 
yes but removing a feature IMO is same as altering a default - it no 
longer works the same.


Also as with Alex just deleted a chuck of this reply so the thread 
does not go down hill fast.


Expressed my point I hope some more consideration may be given if this 
sort of issue arrises in the future.


Tom
GM8MJV

On 16 Feb 2021, at 10:32, Bill Somerville > wrote:


Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of a 
feature that apparently was causing issues. I asked that it not be 
removed and the option offered was to make it a configuration option.


73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:


Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in 
IT we always said “never touch a running system” and for programming 
also apply, why change the previous default for something doesn’t 
works? And create just problems?


PTT and associated routines was working great up to WSJT-X 2.2.2, 
why change that?, the proof of the pudding is in the eating, for 
sure exist a valid reason by “the authors” but unfortunate this time 
maybe wrong.


Alex, HB9DRI

*From:* tom 
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael ; WSJT software development 


*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my 
comments.


It seems a LOT of the errors recently seem to be because HamLib have 
altered defaults and others have to pick up the flack.


It always used to be the case ’never alter the default’ - yes add 
new features but never change the default.


There has been the issue of powering rigs on - default changed, 
shared ptt - default changed.


There are more than a ‘couple of complains’ on this mailing list 
alone to keep the status quo.


Please Please Please DO NOT start to toss the blame around - oh it 
up to xyz to change their software to over-ride the changes we made. 
 Just keep defaults as they were and all will be happy.


End of rant

Tom

GM8MJV

On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> wrote:

A couple of complaints from those who were using a single
instance were having problems with the constant open/close of
the serial port.

So it was changed to support the simple case and those that want
the more complex case of multiple apps have to use the
additional file as WSJT-X authors have decided to not include
any options in the rig control user interface.

I'm looking at the sharing now to see if there is a problem
going on.

Mike W9MDB

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Hello Bill

Following your instructions I use your file  (looks the same as
I use before) and I place in the properly log directory for each
of the WSJT-X (totally 4) and doesn’t work, the PTT is not share.

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by
default now is not?

Regards

Alex, HB9DRI

*From:*Bill Somerville mailto:g4...@classdesign.com>>
*Sent:* Monday, February 15, 2021 6:29 PM
*To:* wsjt-devel@lists.sourceforge.net

*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM
port

Hi Alex,

try the attached file. It needs to go in the log files directory
of each WSJT-X instance ("Settings->File->Open log directory").

73
Bill
G4WJS.

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

Sorry I didn’t answer to the list;

I create a file named hamlib_settings.json and paste inside
the code you send me:

{

     "config": {

"ptt_share": 1

     }

}

Then placethis file in
C:\Users\[username]\AppData\Local\WSJT-X and in

Each of the 4 WSJT-X folders but doesn’t work,

Alex, HB9DRI

*From:*Black Michael via wsjt-devel


*Sent:* Monday, February 15, 2021 11:11 AM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Black Michael 

*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1
COM port

The PTT port is no longer shareable by default.

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

{

 "config": {

    

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[tom]

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - ’never 
touch a running system’ - tidy up coding to make it more robust yes but 
removing a feature IMO is same as altering a default - it no longer works the 
same.

Also as with Alex just deleted a chuck of this reply so the thread does not go 
down hill fast.

Expressed my point I hope some more consideration may be given if this sort of 
issue arrises in the future.

Tom
GM8MJV

> On 16 Feb 2021, at 10:32, Bill Somerville  wrote:
> 
> Hi Alex and Tom,
> 
> the Hamlib change was not a change of defaults, it was a removal of a feature 
> that apparently was causing issues. I asked that it not be removed and the 
> option offered was to make it a configuration option.
> 
> 73
> Bill
> G4WJS.
> 
> On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:
>> Totally in agree with Tom
>> 
>>  
>> 
>> I delete part of my previous email to avoid start arguments BUT in IT we 
>> always said “never touch a running system” and for programming also apply, 
>> why change the previous default for something doesn’t works? And create just 
>> problems?
>> 
>>  
>> 
>> PTT and associated routines was working great up to WSJT-X 2.2.2, why change 
>> that?, the proof of the pudding is in the eating, for sure exist a valid 
>> reason by “the authors” but unfortunate this time maybe wrong.
>> 
>>  
>> 
>> Alex, HB9DRI
>> 
>>  
>> 
>> From: tom   
>> Sent: Tuesday, February 16, 2021 4:18 PM
>> To: Black Michael  ; WSJT 
>> software development  
>> 
>> Subject: Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port
>> 
>>  
>> 
>> Hi All
>> 
>>  
>> 
>> Don’t want to start an argument and please feel free to ignore my comments.
>> 
>>  
>> 
>> It seems a LOT of the errors recently seem to be because HamLib have altered 
>> defaults and others have to pick up the flack.
>> 
>>  
>> 
>> It always used to be the case ’never alter the default’ - yes add new 
>> features but never change the default.
>> 
>>  
>> 
>> There has been the issue of powering rigs on - default changed, shared ptt - 
>> default changed.
>> 
>>  
>> 
>> There are more than a ‘couple of complains’ on this mailing list alone to 
>> keep the status quo.
>> 
>>  
>> 
>> Please Please Please DO NOT start to toss the blame around - oh it up to xyz 
>> to change their software to over-ride the changes we made.  Just keep 
>> defaults as they were and all will be happy.
>> 
>>  
>> 
>> End of rant
>> 
>>  
>> 
>> Tom
>> 
>> GM8MJV
>> 
>>  
>> 
>>  
>> 
>> On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
>> mailto:wsjt-devel@lists.sourceforge.net>> 
>> wrote:
>> 
>>  
>> 
>> A couple of complaints from those who were using a single instance were 
>> having problems with the constant open/close of the serial port.
>> 
>> So it was changed to support the simple case and those that want the more 
>> complex case of multiple apps have to use the additional file as WSJT-X 
>> authors have decided to not include any options in the rig control user 
>> interface.
>> 
>>  
>> 
>> I'm looking at the sharing now to see if there is a problem going on.
>> 
>>  
>> 
>> Mike W9MDB
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
>> mailto:hb9...@emeham.com>> wrote:
>> 
>>  
>> 
>>  
>> 
>> Hello Bill
>> 
>>  
>> 
>> Following your instructions I use your file  (looks the same as I use 
>> before) and I place in the properly log directory for each of the WSJT-X 
>> (totally 4) and doesn’t work, the PTT is not share.
>> 
>>  
>> 
>> I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
>> not?
>> 
>>  
>> 
>> Regards
>> 
>> Alex, HB9DRI
>> 
>>  
>> 
>> From: Bill Somerville mailto:g4...@classdesign.com>> 
>> Sent: Monday, February 15, 2021 6:29 PM
>> To: wsjt-devel@lists.sourceforge.net 
>> 
>> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
>> 
>>  
>> 
>> Hi Alex,
>> 
>>  
>> 
>> try the attached file. It needs to go in the log files directory of each 
>> WSJT-X instance ("Settings->File->Open log directory").
>> 
>>  
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>>  
>> 
>> On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:
>> 
>> Hello Mike
>> 
>>  
>> 
>> Sorry I didn’t answer to the list;
>> 
>>  
>> 
>> I create a file named hamlib_settings.json and paste inside the code you 
>> send me:
>> 
>>  
>> 
>> {
>> 
>>  "config": {
>> 
>> "ptt_share": 1
>> 
>>  }
>> 
>> }
>> 
>>  
>> 
>> Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in
>> 
>> Each of the 4 WSJT-X folders but doesn’t work,
>> 
>>  
>> 
>> Alex, HB9DRI
>> 
>>  
>> 
>>  
>> 
>> From: Black Michael via wsjt-devel  
>>  
>> Sent: Monday, February 15, 2021 11:11 AM
>> To: wsjt-devel@lists.sourceforge.net 
>> 

Re: [wsjt-devel] Please save the T/R sequence lengths for each mode separately

[Bill Somerville]

On 16/02/2021 10:16, DG2YCB, Uwe wrote:


Hi Bill,

Please let wsjt-x save the T/R sequence lengths for each mode 
separately. Why? Because for FST4 on 160m, FST4-A60 seems to become 
something like a “standard”, and for Q65 on 6m Q65-A30. But as wsjt-x 
currently saves only one T/R sequence lengths setting, each time the 
users have to change T/R sequence length when switching from FST4 to 
Q65 mode. It would help a lot when for FST4 and Q65 individual values 
are remembered. (And let FST4-A60 and Q65-A30 become the default 
settings when switching to “FST4” or “Q65”, so that it is easier for 
less-experienced users to start with these new modes.) Only a very 
minor change, but a significant improvement. Thanks!


73 de Uwe, DG2YCB


Hi Uwe,

rather than undertake such a change I will recommend that you try using 
configurations to change mode, that way you can set the required T/R 
period along with other settings per mode, and even have multiple 
configurations for each mode you use, each with customized settings.


73
Bill
G4WJS.

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

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Bill Somerville]

Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of a 
feature that apparently was causing issues. I asked that it not be 
removed and the option offered was to make it a configuration option.


73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:


Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in IT 
we always said “never touch a running system” and for programming also 
apply, why change the previous default for something doesn’t works? 
And create just problems?


PTT and associated routines was working great up to WSJT-X 2.2.2, why 
change that?, the proof of the pudding is in the eating, for sure 
exist a valid reason by “the authors” but unfortunate this time maybe 
wrong.


Alex, HB9DRI

*From:* tom 
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael ; WSJT software development 


*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my 
comments.


It seems a LOT of the errors recently seem to be because HamLib have 
altered defaults and others have to pick up the flack.


It always used to be the case ’never alter the default’ - yes add new 
features but never change the default.


There has been the issue of powering rigs on - default changed, shared 
ptt - default changed.


There are more than a ‘couple of complains’ on this mailing list alone 
to keep the status quo.


Please Please Please DO NOT start to toss the blame around - oh it up 
to xyz to change their software to over-ride the changes we made. 
 Just keep defaults as they were and all will be happy.


End of rant

Tom

GM8MJV

On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> wrote:

A couple of complaints from those who were using a single instance
were having problems with the constant open/close of the serial port.

So it was changed to support the simple case and those that want
the more complex case of multiple apps have to use the additional
file as WSJT-X authors have decided to not include any options in
the rig control user interface.

I'm looking at the sharing now to see if there is a problem going on.

Mike W9MDB

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Hello Bill

Following your instructions I use your file  (looks the same as I
use before) and I place in the properly log directory for each of
the WSJT-X (totally 4) and doesn’t work, the PTT is not share.

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by
default now is not?

Regards

Alex, HB9DRI

*From:*Bill Somerville mailto:g4...@classdesign.com>>
*Sent:* Monday, February 15, 2021 6:29 PM
*To:* wsjt-devel@lists.sourceforge.net

*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi Alex,

try the attached file. It needs to go in the log files directory
of each WSJT-X instance ("Settings->File->Open log directory").

73
Bill
G4WJS.

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

Sorry I didn’t answer to the list;

I create a file named hamlib_settings.json and paste inside
the code you send me:

{

   "config": {

          "ptt_share": 1

   }

}

Then placethis file in
C:\Users\[username]\AppData\Local\WSJT-X and in

Each of the 4 WSJT-X folders but doesn’t work,

Alex, HB9DRI

*From:*Black Michael via wsjt-devel


*Sent:* Monday, February 15, 2021 11:11 AM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Black Michael 

*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1
COM port

The PTT port is no longer shareable by default.

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

{

   "config": {

          "ptt_share": 1

   }

}

Mike W9MDB

On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Just to inform you, I found a bug regarding COM port for PTT,
it appears in WSJT-X 2.3 and in 2.4 RC1, let me explain.

I run 4 WSJT-X at the same time, I use Omnirig to control my
IC9700 but PTT is manage via a COM port, this is a must for me
to TX first a Sequencer via the COM port and later TX the
radio, I cannot use CAT for PTT,  that guarantee me no RF
spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all configure
to use COM3 for PTT, in this configuration I can TX with 

Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Bill Somerville]

Hi Alex,

the file I attached was the correct one. Others have used it without 
issues. Please double check the file is correctly named and has not been 
mangled by Windows in some way. Note the file name must be 
hamlib_settings.json


73
Bill
G4WJS.

On 16/02/2021 04:29, Alex Artieda, HB9DRI wrote:


Hello Bill

Following your instructions I use your file  (looks the same as I use 
before) and I place in the properly log directory for each of the 
WSJT-X (totally 4) and doesn’t work, the PTT is not share.


I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default 
now is not?


Regards

Alex, HB9DRI

*From:* Bill Somerville 
*Sent:* Monday, February 15, 2021 6:29 PM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi Alex,

try the attached file. It needs to go in the log files directory of 
each WSJT-X instance ("Settings->File->Open log directory").


73
Bill
G4WJS.

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

Sorry I didn’t answer to the list;

I create a file named hamlib_settings.json and paste inside the
code you send me:

{

   "config": {

          "ptt_share": 1

   }

}

Then placethis file in C:\Users\[username]\AppData\Local\WSJT-X
and in

Each of the 4 WSJT-X folders but doesn’t work,

Alex, HB9DRI

*From:* Black Michael via wsjt-devel


*Sent:* Monday, February 15, 2021 11:11 AM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Black Michael  
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

The PTT port is no longer shareable by default.

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

{

   "config": {

          "ptt_share": 1

   }

}

Mike W9MDB

On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda,
HB9DRI mailto:hb9...@emeham.com>> wrote:

Just to inform you, I found a bug regarding COM port for PTT, it
appears in WSJT-X 2.3 and in 2.4 RC1, let me explain.

I run 4 WSJT-X at the same time, I use Omnirig to control my
IC9700 but PTT is manage via a COM port, this is a must for me to
TX first a Sequencer via the COM port and later TX the radio, I
cannot use CAT for PTT,  that guarantee me no RF spikes etc. 4
WSJT-X plus MAP65 plus WSJT10 are all configure to use COM3 for
PTT, in this configuration I can TX with ANY of the 6 programs,
more precise I can TX with the program were the decodes or best
decode happens, unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX
ONLY with the FIRST program who opens the PTT COM port, the other
ones don’t work and MAP65 give a opening COM port ERROR, the other
WSJT-X simple don’t TX, would be great to fix this bug because
when you run multiple WSJT-X is a must to work with all instance
capable of TX, WSJT-X 2.2.2 works perfect.

To confirm this bug I roll back to 2.2.2 and install 2.3 and later
2.4RC1, the bug appear in 2.3

73 de Alex, HB9DRI



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

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Alex Artieda, HB9DRI]

Totally in agree with Tom

 

I delete part of my previous email to avoid start arguments BUT in IT we always 
said “never touch a running system” and for programming also apply, why change 
the previous default for something doesn’t works? And create just problems?

 

PTT and associated routines was working great up to WSJT-X 2.2.2, why change 
that?, the proof of the pudding is in the eating, for sure exist a valid reason 
by “the authors” but unfortunate this time maybe wrong.

 

Alex, HB9DRI

 

From: tom  
Sent: Tuesday, February 16, 2021 4:18 PM
To: Black Michael ; WSJT software development 

Subject: Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

Hi All

 

Don’t want to start an argument and please feel free to ignore my comments.

 

It seems a LOT of the errors recently seem to be because HamLib have altered 
defaults and others have to pick up the flack.

 

It always used to be the case ’never alter the default’ - yes add new features 
but never change the default.

 

There has been the issue of powering rigs on - default changed, shared ptt - 
default changed.

 

There are more than a ‘couple of complains’ on this mailing list alone to keep 
the status quo.

 

Please Please Please DO NOT start to toss the blame around - oh it up to xyz to 
change their software to over-ride the changes we made.  Just keep defaults as 
they were and all will be happy.

 

End of rant

 

Tom

GM8MJV

 

 

On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

A couple of complaints from those who were using a single instance were having 
problems with the constant open/close of the serial port.

So it was changed to support the simple case and those that want the more 
complex case of multiple apps have to use the additional file as WSJT-X authors 
have decided to not include any options in the rig control user interface.

 

I'm looking at the sharing now to see if there is a problem going on.

 

Mike W9MDB

 

 

 

 

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
mailto:hb9...@emeham.com> > wrote: 

 

 

Hello Bill

 

Following your instructions I use your file  (looks the same as I use before) 
and I place in the properly log directory for each of the WSJT-X (totally 4) 
and doesn’t work, the PTT is not share.

 

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
not?

 

Regards

Alex, HB9DRI

 

From: Bill Somerville mailto:g4...@classdesign.com> > 
Sent: Monday, February 15, 2021 6:29 PM
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

Hi Alex,

 

try the attached file. It needs to go in the log files directory of each WSJT-X 
instance ("Settings->File->Open log directory").

 

73
Bill
G4WJS.

 

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

 

Sorry I didn’t answer to the list;

 

I create a file named hamlib_settings.json and paste inside the code you send 
me:

 

{

 "config": {

"ptt_share": 1

 }

}

 

Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in 

Each of the 4 WSJT-X folders but doesn’t work,

 

Alex, HB9DRI

 

 

From: Black Michael via wsjt-devel   
 
Sent: Monday, February 15, 2021 11:11 AM
To: wsjt-devel@lists.sourceforge.net  
Cc: Black Michael   
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

The PTT port is no longer shareable by default.

 

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

 

{

 "config": {

"ptt_share": 1

 }

}

 

 

Mike W9MDB

 

 

 

On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI 
mailto:hb9...@emeham.com> > wrote: 

 

 

Just to inform you, I found a bug regarding COM port for PTT, it appears in 
WSJT-X 2.3 and in 2.4 RC1, let me explain.

 

I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT is 
manage via a COM port, this is a must for me to TX first a Sequencer via the 
COM port and later TX the radio, I cannot use CAT for PTT,  that guarantee me 
no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all configure to use COM3 
for PTT, in this configuration I can TX with ANY of the 6 programs, more 
precise I can TX with the program were the decodes or best decode happens, 
unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with the FIRST program 
who opens the PTT COM port, the other ones don’t work and MAP65 give a opening 
COM port ERROR, the other WSJT-X simple don’t TX, would be great to fix this 
bug because when you run multiple WSJT-X is a must to work with all instance 
capable of TX, WSJT-X 2.2.2 works perfect.

 

To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, the 
bug appear in 2.3

 

73 de Alex, HB9DRI

 

Re: [wsjt-devel] Clipping

[Bill Somerville]

Mike,

we have verified the output from WSJT-X is clean, this is not an issue 
that needs fixing in WSJT-X. Note also that on Linux and macOS no such 
distortion is present.


73
Bill
G4WJS.

On 16/02/2021 04:18, Black Michael via wsjt-devel wrote:

Patch to fix the problem

index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@ -1288,6 +1288,7 @@ void MainWindow::readSettings()
    // setup initial value of tx attenuator
    m_block_pwr_tooltip = true;
    ui->outAttenuation->setValue (m_settings->value ("OutAttenuation", 0).toInt 
());
+  on_outAttenuation_valueChanged(ui->outAttenuation->value());
    m_block_pwr_tooltip = false;
    ui->sbCQTxFreq->setValue (m_settings->value ("CQTxFreq", 260).toInt());
    m_noSuffix=m_settings->value("NoSuffix",false).toBool();
@@ -7424,7 +7425,7 @@ void MainWindow::transmit (double snr)
  void MainWindow::on_outAttenuation_valueChanged (int a)
  {
    QString tt_str;
-  qreal dBAttn {a / 10.};       // slider interpreted as dB / 100
+  qreal dBAttn {a / 10. + 3};       // slider interpreted as dB / 100  (+3 to 
keep minimize artifacts)
    if (m_tune && m_config.pwrBandTuneMemory()) {
      tt_str = tr ("Tune digital gain ");
    } else {


Mike W9MDB





On Monday, February 15, 2021, 07:36:18 AM CST, Bill 
Somerville  wrote:






Mike,




the "nastiness" you refer to is more than 65 dB down. As far as we have been 
able to determine it is due to either Windows or VAC. My money is on Windows since VB 
Cable exhibits the same behaviour, although that is not conclusive. Note that 65 dB down 
is below the distortion added by almost all transmitters. We are pretty certain Qt is not 
the cause since when the Pwr slider is at 0dB Qt does nothing with the samples other than 
copy them to the Windows MME audio buffers.




73
Bill
G4WJS.




On 15/02/2021 13:23, Black Michael via wsjt-devel wrote:


   
   
   
It's not just the waterfallthat nastiness gets transmitted too.





Mike W9MDB




   













   
   
   On Monday, February 15, 2021, 02:53:44 AM CST, Reino Talarmo  wrote:








   
   
   
   
Hi Mike and Bill,


I looked those *.wav files using v2.4.0-rc1 and noted interesting presentation 
difference, when I had Flatten activated or non-activated. Especially the 
waterfall display changed a lot. It was difficult to see those multiple 
sidebands in non-flatten display totally independent of gain and zero settings. 
In spectrum display I can see the carrier and weak sidebands at 310 Hz or so. 
In both flattened and non-flattened spectrum other than the 310 Hz sidebands 
are really weak some are just a pixel or two and others none.Could the 
flattening do more than modify the frequency amplitude and be an additional 
reason for a bad waterfall display?

73, Reino OH3mA



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

Re: [wsjt-devel] Clipping

[Stefan HB9TMC]

No clipping found in wsjtx-2.4.0-rc1 with slider at 0 dB on linux, 
feedback using pulseaudio null sink.

Unwanted tones are >70 dB reduced (tune function).


73
Stefan


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

[wsjt-devel] Please save the T/R sequence lengths for each mode separately

[DG2YCB, Uwe]

Hi Bill,



Please let wsjt-x save the T/R sequence lengths for each mode separately.
Why? Because for FST4 on 160m, FST4-A60 seems to become something like a
"standard", and for Q65 on 6m Q65-A30. But as wsjt-x currently saves only
one T/R sequence lengths setting, each time the users have to change T/R
sequence length when switching from FST4 to Q65 mode. It would help a lot
when for FST4 and Q65 individual values are remembered. (And let FST4-A60
and Q65-A30 become the default settings when switching to "FST4" or "Q65",
so that it is easier for less-experienced users to start with these new
modes.) Only a very minor change, but a significant improvement. Thanks!



73 de Uwe, DG2YCB



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

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[tom]

Hi All

Don’t want to start an argument and please feel free to ignore my comments.

It seems a LOT of the errors recently seem to be because HamLib have altered 
defaults and others have to pick up the flack.

It always used to be the case ’never alter the default’ - yes add new features 
but never change the default.

There has been the issue of powering rigs on - default changed, shared ptt - 
default changed.

There are more than a ‘couple of complains’ on this mailing list alone to keep 
the status quo.

Please Please Please DO NOT start to toss the blame around - oh it up to xyz to 
change their software to over-ride the changes we made.  Just keep defaults as 
they were and all will be happy.

End of rant

Tom
GM8MJV


> On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
>  wrote:
> 
> A couple of complaints from those who were using a single instance were 
> having problems with the constant open/close of the serial port.
> So it was changed to support the simple case and those that want the more 
> complex case of multiple apps have to use the additional file as WSJT-X 
> authors have decided to not include any options in the rig control user 
> interface.
> 
> I'm looking at the sharing now to see if there is a problem going on.
> 
> Mike W9MDB
> 
> 
> 
> 
> On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
>  wrote:
> 
> 
> Hello Bill
> 
>  
> Following your instructions I use your file  (looks the same as I use before) 
> and I place in the properly log directory for each of the WSJT-X (totally 4) 
> and doesn’t work, the PTT is not share.
> 
>  
> I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
> not?
> 
>  
> Regards
> 
> Alex, HB9DRI
> 
>  
> From: Bill Somerville  
> Sent: Monday, February 15, 2021 6:29 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
> 
>  
> Hi Alex,
> 
>  
> try the attached file. It needs to go in the log files directory of each 
> WSJT-X instance ("Settings->File->Open log directory").
> 
>  
> 73
> Bill
> G4WJS.
> 
>  
> On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:
> 
> Hello Mike
> 
>  
> Sorry I didn’t answer to the list;
> 
>  
> I create a file named hamlib_settings.json and paste inside the code you send 
> me:
> 
>  
> {
> 
>  "config": {
> 
> "ptt_share": 1
> 
>  }
> 
> }
> 
>  
> Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in
> 
> Each of the 4 WSJT-X folders but doesn’t work,
> 
>  
> Alex, HB9DRI
> 
>  
>  
> From: Black Michael via wsjt-devel  
>  
> Sent: Monday, February 15, 2021 11:11 AM
> To: wsjt-devel@lists.sourceforge.net 
> Cc: Black Michael  
> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
> 
>  
> The PTT port is no longer shareable by default.
> 
>  
> Place this file in C:\Users\[username]\AppData\Local\WSJT-X
> 
>  
> {
> 
>  "config": {
> 
> "ptt_share": 1
> 
>  }
> 
> }
> 
>  
>  
> Mike W9MDB
> 
>  
>  
>  
> On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI 
> mailto:hb9...@emeham.com>> wrote:
> 
>  
>  
> Just to inform you, I found a bug regarding COM port for PTT, it appears in 
> WSJT-X 2.3 and in 2.4 RC1, let me explain.
> 
>  
> I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT 
> is manage via a COM port, this is a must for me to TX first a Sequencer via 
> the COM port and later TX the radio, I cannot use CAT for PTT,  that 
> guarantee me no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all 
> configure to use COM3 for PTT, in this configuration I can TX with ANY of the 
> 6 programs, more precise I can TX with the program were the decodes or best 
> decode happens, unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with 
> the FIRST program who opens the PTT COM port, the other ones don’t work and 
> MAP65 give a opening COM port ERROR, the other WSJT-X simple don’t TX, would 
> be great to fix this bug because when you run multiple WSJT-X is a must to 
> work with all instance capable of TX, WSJT-X 2.2.2 works perfect.
> 
>  
> To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, 
> the bug appear in 2.3
> 
>  
> 73 de Alex, HB9DRI
> 
>  
> ___
> 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] Clipping

[Reino Talarmo]

>Patch to fix the problem

index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@ -1288,6 +1288,7 @@ void MainWindow::readSettings()
   // setup initial value of tx attenuator
   m_block_pwr_tooltip = true;
   ui->outAttenuation->setValue (m_settings->value ("OutAttenuation", 0).toInt 
());
+  on_outAttenuation_valueChanged(ui->outAttenuation->value());
   m_block_pwr_tooltip = false;
   ui->sbCQTxFreq->setValue (m_settings->value ("CQTxFreq", 260).toInt());
   m_noSuffix=m_settings->value("NoSuffix",false).toBool();
@@ -7424,7 +7425,7 @@ void MainWindow::transmit (double snr)
 void MainWindow::on_outAttenuation_valueChanged (int a)
 {
   QString tt_str;
-  qreal dBAttn {a / 10.};   // slider interpreted as dB / 100
+  qreal dBAttn {a / 10. + 3};   // slider interpreted as dB / 100  (+3 to 
keep minimize artifacts)
   if (m_tune && m_config.pwrBandTuneMemory()) {
 tt_str = tr ("Tune digital gain ");
   } else {

>Mike W9MDB

Hi 
I still would like to know where the issue really is. I have now impression 
that it is at receiving entity not at transmitting one. Looks more like a 
measurement artifact due to some (dynamic range) problem at waterfall display. 
Correct me, if I am wrong.

73, Reino OH3mA



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

Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

[Alex Artieda, HB9DRI]

Hello Bill and Mike

 

Thank you for your tremendous effort in supporting WSJT-X

 

The additional file Bill send me doesn’t work.

 

Alex, HB9DRI

 

From: Black Michael via wsjt-devel  
Sent: Tuesday, February 16, 2021 11:54 AM
To: 'WSJT software development' 
Cc: Black Michael 
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

A couple of complaints from those who were using a single instance were having 
problems with the constant open/close of the serial port.

So it was changed to support the simple case and those that want the more 
complex case of multiple apps have to use the additional file as WSJT-X authors 
have decided to not include any options in the rig control user interface.

 

I'm looking at the sharing now to see if there is a problem going on.

 

Mike W9MDB

 

 

 

 

On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
mailto:hb9...@emeham.com> > wrote: 

 

 

Hello Bill

 

Following your instructions I use your file  (looks the same as I use before) 
and I place in the properly log directory for each of the WSJT-X (totally 4) 
and doesn’t work, the PTT is not share.

 

I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
not?

 

Regards

Alex, HB9DRI

 

From: Bill Somerville mailto:g4...@classdesign.com> > 
Sent: Monday, February 15, 2021 6:29 PM
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

Hi Alex,

 

try the attached file. It needs to go in the log files directory of each WSJT-X 
instance ("Settings->File->Open log directory").

 

73
Bill
G4WJS.

 

On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

Hello Mike

 

Sorry I didn’t answer to the list;

 

I create a file named hamlib_settings.json and paste inside the code you send 
me:

 

{

 "config": {

"ptt_share": 1

 }

}

 

Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in 

Each of the 4 WSJT-X folders but doesn’t work,

 

Alex, HB9DRI

 

 

From: Black Michael via wsjt-devel   
 
Sent: Monday, February 15, 2021 11:11 AM
To: wsjt-devel@lists.sourceforge.net  
Cc: Black Michael   
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port

 

The PTT port is no longer shareable by default.

 

Place this file in C:\Users\[username]\AppData\Local\WSJT-X

 

{

 "config": {

"ptt_share": 1

 }

}

 

 

Mike W9MDB

 

 

 

On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI 
mailto:hb9...@emeham.com> > wrote: 

 

 

Just to inform you, I found a bug regarding COM port for PTT, it appears in 
WSJT-X 2.3 and in 2.4 RC1, let me explain.

 

I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT is 
manage via a COM port, this is a must for me to TX first a Sequencer via the 
COM port and later TX the radio, I cannot use CAT for PTT,  that guarantee me 
no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all configure to use COM3 
for PTT, in this configuration I can TX with ANY of the 6 programs, more 
precise I can TX with the program were the decodes or best decode happens, 
unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with the FIRST program 
who opens the PTT COM port, the other ones don’t work and MAP65 give a opening 
COM port ERROR, the other WSJT-X simple don’t TX, would be great to fix this 
bug because when you run multiple WSJT-X is a must to work with all instance 
capable of TX, WSJT-X 2.2.2 works perfect.

 

To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, the 
bug appear in 2.3

 

73 de Alex, HB9DRI

 

___
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