locked No click response if CQ only


Andy k3wyc
 

I recently updated WSJT-X to ver 2.5.4 and JTAlert to ver 2.50.6. 

For typical DX chasing with FT8 mode I have JTAlert displaying a single "Callsigns" window configured as "Alert DXCC".  When I am alerted to DX I click on the call in the Callsigns window and expect the WSJT-X RX frequency cursor to more to the DX frequency and for DX decode to appear in WSJT-X RX Frequency pane.  I then monitor the progress of the DX QSO and may tail end when appropriate.

With the new versions I clicked several DX calls in the Callsigns window and often saw no response.  The RX cursor didn't move and the decode was not displayed in the RX Frequency pane.  I also experimented with the Callsigns window showing all decodes and saw a pattern.  Callsign click only gave the expected response for CQ decodes.

I then realized that I had accidentally set "CQ only" on the WSJT-X main window.  This limits WSJT-X Band Activity pane to CQ decodes only but does not filter the decodes shown in the JTAlert Callsigns window.

There seem to be an inconsistency here.  Either JTAlert should not display calls that are not CQ or it should display all decodes and all decoded calls should respond to a click in the same way. 

I didn't intend to select "CQ only" so, for me, the problem is easily avoided by not selecting that option. 

73,
Andy, k3wyc


Joe Subich, W4TV
 

On 2022-01-22 10:51 AM, Andy k3wyc wrote:
all decoded calls should respond to a click in the same way.
That is a limitation of WSJTX. The Developers of WSJTX limit the
ability of external applications to set the "Transmit" status to
"CQ only." If you want all decodes to respond to a click the
same way, make your feelings known to the developers of WSJTX.

73,

... Joe, W4TV


On 2022-01-22 10:51 AM, Andy k3wyc wrote:
I recently updated WSJT-X to ver 2.5.4 and JTAlert to ver 2.50.6.
For typical DX chasing with FT8 mode I have JTAlert displaying a single "Callsigns" window configured as "Alert DXCC".  When I am alerted to DX I click on the call in the Callsigns window and expect the WSJT-X RX frequency cursor to more to the DX frequency and for DX decode to appear in WSJT-X RX Frequency pane.  I then monitor the progress of the DX QSO and may tail end when appropriate.
With the new versions I clicked several DX calls in the Callsigns window and often saw no response.  The RX cursor didn't move and the decode was not displayed in the RX Frequency pane.  I also experimented with the Callsigns window showing all decodes and saw a pattern.  Callsign click only gave the expected response for CQ decodes.
I then realized that I had accidentally set "CQ only" on the WSJT-X main window.  This limits WSJT-X Band Activity pane to CQ decodes only but does not filter the decodes shown in the JTAlert Callsigns window.
There seem to be an inconsistency here.  Either JTAlert should not display calls that are not CQ or it should display all decodes and all decoded calls should respond to a click in the same way.
I didn't intend to select "CQ only" so, for me, the problem is easily avoided by not selecting that option.
73,
Andy, k3wyc


Andy k3wyc
 

On Sat, Jan 22, 2022 at 09:38 AM, Joe Subich, W4TV wrote:
That is a limitation of WSJTX. The Developers of WSJTX limit the
ability of external applications to set the "Transmit" status to
"CQ only."
How, and under what circumstances, do the developers of WSJT-X limit the ability of external applications to set the "Transmit" status to "CQ only."  In my configuration clicking a call in JTAlert has no influence on transmit status since I never have any option set that would cause TX status change with any click either in WSJT-X or in JTAlert.  

73,
Andy, k3wyc


Michael Black
 

It's the "Double-click on call sets Tx enable".
It only works for CQ messages.  Non-CQ will set the messages but not enable transmit.

Mike W9MDB



On Saturday, January 22, 2022, 12:03:18 PM CST, Andy k3wyc <a.durbin@...> wrote:


On Sat, Jan 22, 2022 at 09:38 AM, Joe Subich, W4TV wrote:
That is a limitation of WSJTX. The Developers of WSJTX limit the
ability of external applications to set the "Transmit" status to
"CQ only."
How, and under what circumstances, do the developers of WSJT-X limit the ability of external applications to set the "Transmit" status to "CQ only."  In my configuration clicking a call in JTAlert has no influence on transmit status since I never have any option set that would cause TX status change with any click either in WSJT-X or in JTAlert.  

73,
Andy, k3wyc


Andy k3wyc
 

On Sat, Jan 22, 2022 at 11:47 AM, Michael Black wrote:
It's the "Double-click on call sets Tx enable".
It only works for CQ messages.  Non-CQ will set the messages but not enable transmit.
 
As I explained in the original post  - clicking a non-CQ decode has no response when "CQ only" is active.  It does not move the RX cursor and it does not show the clicked decode in the RX Frequency pane.  I never set TX enable with a call click so TX enable status should not be a factor in the observed behavior.

73,
Andy, k3wyc


Michael Black
 

So color me confused.
What you are describing is exactly the way it is supposed to behave.
Are you expecting some other behavior?

Mike W9MDB




On Saturday, January 22, 2022, 12:54:47 PM CST, Andy k3wyc <a.durbin@...> wrote:


On Sat, Jan 22, 2022 at 11:47 AM, Michael Black wrote:
It's the "Double-click on call sets Tx enable".
It only works for CQ messages.  Non-CQ will set the messages but not enable transmit.
 
As I explained in the original post  - clicking a non-CQ decode has no response when "CQ only" is active.  It does not move the RX cursor and it does not show the clicked decode in the RX Frequency pane.  I never set TX enable with a call click so TX enable status should not be a factor in the observed behavior.

73,
Andy, k3wyc


Bill Barrett
 

I would like to see this as a user option to arm TX whenever a call is double clicked regardless of the transmitting station's status.  When chasing a needed entity it seems helpful to call ahead of the 73 transmission by the wanted station.
Perhaps for just the "73" situations?
Thanks for listening.

Bill W2PKY


On Sat, Jan 22, 2022 at 1:47 PM Michael Black via groups.io <mdblack98=yahoo.com@groups.io> wrote:
It's the "Double-click on call sets Tx enable".
It only works for CQ messages.  Non-CQ will set the messages but not enable transmit.

Mike W9MDB



On Saturday, January 22, 2022, 12:03:18 PM CST, Andy k3wyc <a.durbin@...> wrote:


On Sat, Jan 22, 2022 at 09:38 AM, Joe Subich, W4TV wrote:
That is a limitation of WSJTX. The Developers of WSJTX limit the
ability of external applications to set the "Transmit" status to
"CQ only."
How, and under what circumstances, do the developers of WSJT-X limit the ability of external applications to set the "Transmit" status to "CQ only."  In my configuration clicking a call in JTAlert has no influence on transmit status since I never have any option set that would cause TX status change with any click either in WSJT-X or in JTAlert.  

73,
Andy, k3wyc


Andy k3wyc
 

On Sat, Jan 22, 2022 at 12:04 PM, Michael Black wrote:
What you are describing is exactly the way it is supposed to behave.
Are you expecting some other behavior?
I expected clicking a call in the JTAlert Callsigns window to move the RX cursor to the callers frequency and to populate the RX Frequency pane with the decode.  I did not expect that to work sometimes and not work at other times.

73,
Andy, k3wyc


Laurie, VK3AMA
 

On 23/01/2022 6:26 am, Andy k3wyc wrote:
I expected clicking a call in the JTAlert Callsigns window to move the RX cursor to the callers frequency and to populate the RX Frequency pane with the decode.  I did not expect that to work sometimes and not work at other times.

73,
Andy, k3wyc
JTAlert cannot influence WSJT in this way. There is no facility within the WSJTX UDP API to support that functionality. There is a single message that tells WSJTX a callsign, corresponding to a specific decode, was clicked in JTAlert. What WSJTX does in response to that instruction is handled exclusively by WSJTX. There is nothing JTAlert can do to alter that behavior. If you want something different you need to discuss with the WSJTX developers.

de Laurie VK3AMA


Laurie, VK3AMA
 

On 23/01/2022 5:03 am, Andy k3wyc wrote:
How, and under what circumstances, do the developers of WSJT-X limit the ability of external applications to set the "Transmit" status to "CQ only."
That is within the WSJTX code. WSJTX itself decides how to respond to a 3rd party application click event. There is NO facility within the WSJTX API to change the WSJTX behavior.

de Laurie VK3AMA


Laurie, VK3AMA
 

On 23/01/2022 6:12 am, Bill Barrett wrote:
I would like to see this as a user option to arm TX whenever a call is double clicked regardless of the transmitting station's status.

Bill W2PKY
You need to talk to the WSJTX developers. There is NOTHING JTAlert can do with respect to this.

de Laurie VK3AMA


Jim Cooper
 

Since you are talking about WSJT-X performing setup
operations you would do a lot better to take the
complaint/suggestion to the WSJT-X support group.

JTalert cannot control what WSJT-X does unless the
authors of WSJT-X have provided that function in the
'3rd party API' .... no function, no action.

Gripe all you want here (won't be appreciated) but
there is nothing Laurie can do to change the programming
of WSJT-X.

main@WSJTX.groups.io

On 22 Jan 2022 at 11:26, Andy k3wyc wrote:

I expected clicking a call in the JTAlert Callsigns window to move
the
RX cursor to the callers frequency and to populate the RX
Frequency
pane with the decode.  I did not expect that to work sometimes and
not work at other times.

73,
Andy, k3wyc