locked About MSK144


F8RZ
 

Hello...

1- When on MSK144, it is not a good thing that transmit is halted after the first RR73 sent... it is unusual that only one transmission is enough to complete the QSO, so I wouild like that the transmission continues until manual halt.

2-for some reason, the last message from the other station "F8RZ F1XXX 73"is not displayed under "Rx Frequency", but only in "Band activity". Minor problem, but...

Best 73, and thanks for the outstanding work !

Jean F8RZ


JP Tucson, AZ
 

You could uncheck the "Auto Seq(uence)" box & just do everything manually, ...or... un-click it after you get an "R-xx" &  it switches to the first RR73, then end it manually as you stated.



73 - John - N7GHZ


On Mon, May 4, 2020, 5:01 AM F8RZ <f8rz@...> wrote:
Hello...

1- When on MSK144, it is not a good thing that transmit is halted after
the first RR73 sent... it is unusual that only one transmission is
enough to complete the QSO, so I wouild like that the transmission
continues until manual halt.

2-for some reason, the last message from the other station "F8RZ F1XXX
73"is not displayed under "Rx Frequency", but only in "Band activity".
Minor problem, but...

Best 73, and thanks for the outstanding work !

Jean F8RZ




Bill Somerville
 

On 04/05/2020 13:01, F8RZ wrote:
Hello...

1- When on MSK144, it is not a good thing that transmit is halted after the first RR73 sent... it is unusual that only one transmission is enough to complete the QSO, so I wouild like that the transmission continues until manual halt.

2-for some reason, the last message from the other station "F8RZ F1XXX 73"is not displayed under "Rx Frequency", but only in "Band activity". Minor problem, but...

Best 73, and thanks for the outstanding work !

Jean F8RZ
Hi Jean,

in MSK144 mode for MS operating I recommend double-clicking one of the Tx4 buttons to change the default message to "<dx-call> <de-call> RRR" rather than using the RR73 message. You can also uncheck the option "Settings->General->Disable Tx after sending 73" if you wish.

73
Bill
G4WJS.


Joe
 

Bonjour Jean,

1. Auto-sequencing in WSJT-X is provided as an operatpr aid, not an operator replacement.  The User Guide includes this advice about using "RR73":

"The RR73 message should be used only if you are reasonably confident that no repetitions will be required."

The nature of meteor scatter communication is such that one can never be confident that a particular transmission will be copied.

2. Since you chose to send RR73, you have indicated that -- as far as you are concerned -- the QSO is complete.  Your DX Call entry field has been cleared, so receipt of the 73 message will not appear in the right-hand panel.

  -- 73, Joe, K1JT


F8RZ
 


Bill and Joe,

Thanks for the help. Switching fromr RR73 to RRR cured the problem.

Maybe I could find it myself, but when ?

Best 73 and tu for the great fun.

Jean F8RZ

Le 04/05/2020 à 13:05, Joe a écrit :

Bonjour Jean,

1. Auto-sequencing in WSJT-X is provided as an operatpr aid, not an operator replacement.  The User Guide includes this advice about using "RR73":

"The RR73 message should be used only if you are reasonably confident that no repetitions will be required."

The nature of meteor scatter communication is such that one can never be confident that a particular transmission will be copied.

2. Since you chose to send RR73, you have indicated that -- as far as you are concerned -- the QSO is complete.  Your DX Call entry field has been cleared, so receipt of the 73 message will not appear in the right-hand panel.

  -- 73, Joe, K1JT

    


Bob G8HGN
 

Hi Bill,

The check box "Disable Tx after sending 73" does not work, certainly in FT8, haven't tried MSK144 recently. If you leave it unchecked the program stops sending the same as if it were checked.

We had a short discussion about it a while ago, and it was to be looked at in a future revision. I'm assuming that hasn't happened yet.

While I'm here, did you think of anything that may have caused my signal report discrepancy I posted last night? As far as I can remeber I've only had this happen once before and that was in EU contest mode, which I believe is a work in progress.

73

Bob G8HGN

On 04/05/2020 13:33, Bill Somerville wrote:

On 04/05/2020 13:01, F8RZ wrote:
Hello...

1- When on MSK144, it is not a good thing that transmit is halted after the first RR73 sent... it is unusual that only one transmission is enough to complete the QSO, so I wouild like that the transmission continues until manual halt.

2-for some reason, the last message from the other station "F8RZ F1XXX 73"is not displayed under "Rx Frequency", but only in "Band activity". Minor problem, but...

Best 73, and thanks for the outstanding work !

Jean F8RZ

Hi Jean,

in MSK144 mode for MS operating I recommend double-clicking one of the Tx4 buttons to change the default message to "<dx-call> <de-call> RRR" rather than using the RR73 message. You can also uncheck the option "Settings->General->Disable Tx after sending 73" if you wish.

73
Bill
G4WJS.



    


Bill Somerville
 

On 04/05/2020 19:17, Bob G8HGN wrote:

Hi Bill,

The check box "Disable Tx after sending 73" does not work, certainly in FT8, haven't tried MSK144 recently. If you leave it unchecked the program stops sending the same as if it were checked.

We had a short discussion about it a while ago, and it was to be looked at in a future revision. I'm assuming that hasn't happened yet.
Hi Bob,

if you have "Call 1st" checked then WSJT-X will not leave "Enable Tx" active after a QSO is completed, this is to stop the obvious and undesirable robotic operation that would ensue.

73
Bill
G4WJS.


Bob G8HGN
 

Hi Bill,

I never use "Call 1st" but undersand the reasoning.

73

Bob G8HGN

On 04/05/2020 20:16, Bill Somerville wrote:

On 04/05/2020 19:17, Bob G8HGN wrote:

Hi Bill,

The check box "Disable Tx after sending 73" does not work, certainly in FT8, haven't tried MSK144 recently. If you leave it unchecked the program stops sending the same as if it were checked.

We had a short discussion about it a while ago, and it was to be looked at in a future revision. I'm assuming that hasn't happened yet.

Hi Bob,

if you have "Call 1st" checked then WSJT-X will not leave "Enable Tx" active after a QSO is completed, this is to stop the obvious and undesirable robotic operation that would ensue.

73
Bill
G4WJS.



    


Bill Somerville
 

Hi Bob,

OK, thanks for the report, it seems we have a defect to repair for the next release.

73
Bill
G4WJS.

On 04/05/2020 20:20, Bob G8HGN wrote:

Hi Bill,

I never use "Call 1st" but undersand the reasoning.

73

Bob G8HGN

On 04/05/2020 20:16, Bill Somerville wrote:
On 04/05/2020 19:17, Bob G8HGN wrote:

Hi Bill,

The check box "Disable Tx after sending 73" does not work, certainly in FT8, haven't tried MSK144 recently. If you leave it unchecked the program stops sending the same as if it were checked.

We had a short discussion about it a while ago, and it was to be looked at in a future revision. I'm assuming that hasn't happened yet.
Hi Bob,

if you have "Call 1st" checked then WSJT-X will not leave "Enable Tx" active after a QSO is completed, this is to stop the obvious and undesirable robotic operation that would ensue.

73
Bill
G4WJS.


Bob G8HGN
 

Hi Bill,

Yes, seems so.

Thanks,

Bob G8HGN

On 04/05/2020 20:24, Bill Somerville wrote:

Hi Bob,

OK, thanks for the report, it seems we have a defect to repair for the next release.

73
Bill
G4WJS.

On 04/05/2020 20:20, Bob G8HGN wrote:

Hi Bill,

I never use "Call 1st" but undersand the reasoning.

73

Bob G8HGN

On 04/05/2020 20:16, Bill Somerville wrote:
On 04/05/2020 19:17, Bob G8HGN wrote:

Hi Bill,

The check box "Disable Tx after sending 73" does not work, certainly in FT8, haven't tried MSK144 recently. If you leave it unchecked the program stops sending the same as if it were checked.

We had a short discussion about it a while ago, and it was to be looked at in a future revision. I'm assuming that hasn't happened yet.

Hi Bob,

if you have "Call 1st" checked then WSJT-X will not leave "Enable Tx" active after a QSO is completed, this is to stop the obvious and undesirable robotic operation that would ensue.

73
Bill
G4WJS.




    


Frode Igland
 

Checking or unchecking the "Disable Tx after sending 73" checkbox in Settings - General -  Behavior has no effect in FT8 and FT4, as disabling Tx is the hardcoded default overriding the "Enable Tx" button in order to avoid unattended robot operation by enabling automated CQs after completing a QSO.

However, in modes like MSK144, the TX is not disabled after sending 73, for example because it can be expected that repeating the 73 may be required to be able to complete the QSO. The same applies to JT9 and JT65, where sending 73 does not disable the TX (and the "Enable Tx" button remains red until you log the QSO). For these modes the "Disable Tx after sending 73" becomes effective. If for example the conditions are so good that one 73 can be expected to be sufficient to complete the QSO, this checkbox can be checked to avoid the transmission of repeated 73. So if  you want to keep the TX enabled after sending 73 in MSK144, make sure that you have not checked the "Disable Tx after sending 73". If you have checked this box, the TX will be disabled, and you may lose an opportunity to complete the QSO.

The "Disable Tx after sending 73" checkbox has created some confusion when FT8/FT4 operators have wanted to avoid the hardcoded default in FT8/FT4 of having to click "Enable Tx" to start the next QSO. This issue regularly pops up here and in various WSJT-X/FT8 Facebook groups, but as mentioned above, this checkbox has no function in FT8/FT4.

Frode LA6VQ


Bob G8HGN
 

Hi Frode,

It did work in previous versions, was this a developement decision to stop robot type calls? It did come as a shock when it didn't work the 1st few times we tried it and it was queried at the time, and we were led to believe it would return in a later version.

The problem is under varying conditions, like ES, you may be using "RR73". If the other party comes back with "R-10" or whatever, he hasn't seen the "RR73" and you would send it again. Of course the program has moved on to a "CQ" call as the next message and stopped. So you have to change the message and enable the TX again, all in a few milliseconds to get the right response, maybe missing the message being decoded at the other end.

Perhaps "3 strikes and you're out" is a better option. It would allow a further  3 repeats and then stop. Should you need to carry on, you know you will have to reset the message after 3 times, and it avoids robotic calls.

73

Bob G8HGN

On 05/05/2020 13:50, Frode Igland wrote:

Checking or unchecking the "Disable Tx after sending 73" checkbox in Settings - General -  Behavior has no effect in FT8 and FT4, as disabling Tx is the hardcoded default overriding the "Enable Tx" button in order to avoid unattended robot operation by enabling automated CQs after completing a QSO.

However, in modes like MSK144, the TX is not disabled after sending 73, for example because it can be expected that repeating the 73 may be required to be able to complete the QSO. The same applies to JT9 and JT65, where sending 73 does not disable the TX (and the "Enable Tx" button remains red until you log the QSO). For these modes the "Disable Tx after sending 73" becomes effective. If for example the conditions are so good that one 73 can be expected to be sufficient to complete the QSO, this checkbox can be checked to avoid the transmission of repeated 73. So if  you want to keep the TX enabled after sending 73 in MSK144, make sure that you have not checked the "Disable Tx after sending 73". If you have checked this box, the TX will be disabled, and you may lose an opportunity to complete the QSO.

The "Disable Tx after sending 73" checkbox has created some confusion when FT8/FT4 operators have wanted to avoid the hardcoded default in FT8/FT4 of having to click "Enable Tx" to start the next QSO. This issue regularly pops up here and in various WSJT-X/FT8 Facebook groups, but as mentioned above, this checkbox has no function in FT8/FT4.

Frode LA6VQ


    


Bob G8HGN
 

Hi,

To clarify, I was only talking about FT8. My post could have been misread to mean MSK144 as well.

73

Bob G8HGN


On 05/05/2020 15:13, Bob G8HGN wrote:

Hi Frode,

It did work in previous versions, was this a developement decision to stop robot type calls? It did come as a shock when it didn't work the 1st few times we tried it and it was queried at the time, and we were led to believe it would return in a later version.

The problem is under varying conditions, like ES, you may be using "RR73". If the other party comes back with "R-10" or whatever, he hasn't seen the "RR73" and you would send it again. Of course the program has moved on to a "CQ" call as the next message and stopped. So you have to change the message and enable the TX again, all in a few milliseconds to get the right response, maybe missing the message being decoded at the other end.

Perhaps "3 strikes and you're out" is a better option. It would allow a further  3 repeats and then stop. Should you need to carry on, you know you will have to reset the message after 3 times, and it avoids robotic calls.

73

Bob G8HGN

On 05/05/2020 13:50, Frode Igland wrote:
Checking or unchecking the "Disable Tx after sending 73" checkbox in Settings - General -  Behavior has no effect in FT8 and FT4, as disabling Tx is the hardcoded default overriding the "Enable Tx" button in order to avoid unattended robot operation by enabling automated CQs after completing a QSO.

However, in modes like MSK144, the TX is not disabled after sending 73, for example because it can be expected that repeating the 73 may be required to be able to complete the QSO. The same applies to JT9 and JT65, where sending 73 does not disable the TX (and the "Enable Tx" button remains red until you log the QSO). For these modes the "Disable Tx after sending 73" becomes effective. If for example the conditions are so good that one 73 can be expected to be sufficient to complete the QSO, this checkbox can be checked to avoid the transmission of repeated 73. So if  you want to keep the TX enabled after sending 73 in MSK144, make sure that you have not checked the "Disable Tx after sending 73". If you have checked this box, the TX will be disabled, and you may lose an opportunity to complete the QSO.

The "Disable Tx after sending 73" checkbox has created some confusion when FT8/FT4 operators have wanted to avoid the hardcoded default in FT8/FT4 of having to click "Enable Tx" to start the next QSO. This issue regularly pops up here and in various WSJT-X/FT8 Facebook groups, but as mentioned above, this checkbox has no function in FT8/FT4.

Frode LA6VQ



    


Bob Lewis
 

My solution is to set the first free msg in the list to RR73. If the station doesn’t copy your automatic RR73 then just click the free msg button followed by send and it’ll repeat until you manually stop it. The “73” doesn’t disable transmit if its sent as a free msg.

 

 

From: WSJTX@groups.io [mailto:WSJTX@groups.io] On Behalf Of Bob G8HGN
Sent: Tuesday, May 05, 2020 10:14 AM
To: WSJTX@groups.io
Subject: Re: [WSJTX] About MSK144

 

Hi Frode,

It did work in previous versions, was this a developement decision to stop robot type calls? It did come as a shock when it didn't work the 1st few times we tried it and it was queried at the time, and we were led to believe it would return in a later version.

The problem is under varying conditions, like ES, you may be using "RR73". If the other party comes back with "R-10" or whatever, he hasn't seen the "RR73" and you would send it again. Of course the program has moved on to a "CQ" call as the next message and stopped. So you have to change the message and enable the TX again, all in a few milliseconds to get the right response, maybe missing the message being decoded at the other end.

Perhaps "3 strikes and you're out" is a better option. It would allow a further  3 repeats and then stop. Should you need to carry on, you know you will have to reset the message after 3 times, and it avoids robotic calls.

73

Bob G8HGN

On 05/05/2020 13:50, Frode Igland wrote:

Checking or unchecking the "Disable Tx after sending 73" checkbox in Settings - General -  Behavior has no effect in FT8 and FT4, as disabling Tx is the hardcoded default overriding the "Enable Tx" button in order to avoid unattended robot operation by enabling automated CQs after completing a QSO.

 

However, in modes like MSK144, the TX is not disabled after sending 73, for example because it can be expected that repeating the 73 may be required to be able to complete the QSO. The same applies to JT9 and JT65, where sending 73 does not disable the TX (and the "Enable Tx" button remains red until you log the QSO). For these modes the "Disable Tx after sending 73" becomes effective. If for example the conditions are so good that one 73 can be expected to be sufficient to complete the QSO, this checkbox can be checked to avoid the transmission of repeated 73. So if  you want to keep the TX enabled after sending 73 in MSK144, make sure that you have not checked the "Disable Tx after sending 73". If you have checked this box, the TX will be disabled, and you may lose an opportunity to complete the QSO.

 

The "Disable Tx after sending 73" checkbox has created some confusion when FT8/FT4 operators have wanted to avoid the hardcoded default in FT8/FT4 of having to click "Enable Tx" to start the next QSO. This issue regularly pops up here and in various WSJT-X/FT8 Facebook groups, but as mentioned above, this checkbox has no function in FT8/FT4.

 

Frode LA6VQ



 


Dave_G0WBX
 

Re:-

The "Disable Tx after sending 73" checkbox has created some confusion
when FT8/FT4 operators have wanted to avoid the hardcoded default in
FT8/FT4 of having to click "Enable Tx" to start the next QSO. This issue
regularly pops up here and in various WSJT-X/FT8 Facebook groups, but as
mentioned above, this checkbox has no function in FT8/FT4.


Perhaps show it enabled, but "Greyed out" in a future release, when in
FT8/4 mode?  That would indicate that the system was set to "Disable Tx
after sending 73", and that you can do nothing about it in that mode. 
Or even, hide it from view, but make sure first, that "Disable TX (etc)"
is actually in force.

Other software I'm aware of (not Ham Radio) works that way, anything
that is not relevant to the hardware it is working with, is greyed out,
or removed from view.   Same in drop-down menu's.   It really does make
it a lot more obvious as to what you can/cant do, same sort of thing is
also often done in database entry forms, so it's not as if it'd be
anything no one had ever seen happen before.


Back under my rock.

73. Dave G0WBX.

--
Created on and sent from a Unix like PC running and using free and open source software:


Frode Igland
 

Hi, Bob.

This "operational inconvenience" is caused by the RR73 "convenient QSO completion procedure" when the conditions are good enough for RR73. It is easy to solve.  First of all, follow the User Guide recommendation to use RR73 only when the conditions are good enough that you can be almost certain that your QSO partner will revert with 73. Otherwise, always use RRR and 73 in separate messages. Then no confusion will arise.

Secondly, if you insist on using RR73 no matter what, I have good experience with the following procedure as soon as the RR73 transmission starts (which is what causes the logging window to pop up, and the Enable Tx button to be disabled):

1. Do not click OK in the logging window, but do click "Enable Tx" as soon as it has been disabled, and certainly before your QSO partner's transmission is finished.

2. If your QSO partner reverts with his 73,
a. the Enabled TX will either send a CQ, or,
b. if you have been called by another station and "Call 1st" is checked, the Enabled TX will respond to the next caller.
c. if you have not checked "Call 1st", you are free to select a caller to respond to by double-clicking on his line.

If your QSO partner reverts with his 73, you know that the previous QSO is completed and you can click OK in the logging window and log the previous QSO.   

3. If your QSO partner reverts with e.g. R-10, the Enabled TX will automatically respond to the R-10 and repeat the RR73.

Then repeat from 1. above until 73s are exchanged, and both parties know that call signs, reports and acknowledgements of call signs and reports (and a final 73) have been exchanged for a good QSO.

The "three strikes and you're out" is not a favoured approach by me. If I have engaged in a QSO, I'd like to complete it, within reasonable effort, say five repetitions with no response.

If the conditions are not really good enough for RR73 (say FT8 reports are regularly around -15 and lower), I use RRR and 73 in separate messages, and apply my patience to let the AutoSeq do its job to complete the QSO. This keeps the TX enabled all the time, not requiring any reenabling becaus a message with 73 disabled the TX. It takes considerably shorter time than cleaning up the mess with unfinished QSOs, no logging, recuperating lost QSO data for logging from the All.txt file or somewhere up one of the windows, reverting to the unfinished QSO after finishing the next, responding to the unhappy QSO partner's repeated attempts to complete the QSO, etc. It is a typical situation where a choice of convenience (RR73) may create a mess. 

Good luck and 73, Frode LA6VQ


Bob G8HGN
 

Hi Frode,

I never click OK in the logging box until the other party has what he wants, or I feel the QSO is done, because of what can happen to conditions, especially on Es. I'm a VHF operator.

It's the unexpected drop out that catches you out. You are merrily woking someone at good levels and then the band closes just as you've sent RR73 and you don't get the73 back. If I knew the band would close I'd use RRR instead, but you can't predict of course.

I wasn't aware that this had been done in FT8, I didn't RTM for the new release changes. Note to self RTM next release, due soon!

My point about 3 strikes was you'd have time to repeat the message as the program wouldn't stop after the 1st RR73, and you could continue until you felt you'd gone as far as you could,  completed or not.

Thanks for the tips, 73,

Bob G8HGN

On 05/05/2020 20:17, Frode Igland wrote:

Hi, Bob.

This "operational inconvenience" is caused by the RR73 "convenient QSO completion procedure" when the conditions are good enough for RR73. It is easy to solve.  First of all, follow the User Guide recommendation to use RR73 only when the conditions are good enough that you can be almost certain that your QSO partner will revert with 73. Otherwise, always use RRR and 73 in separate messages. Then no confusion will arise.

Secondly, if you insist on using RR73 no matter what, I have good experience with the following procedure as soon as the RR73 transmission starts (which is what causes the logging window to pop up, and the Enable Tx button to be disabled):

1. Do not click OK in the logging window, but do click "Enable Tx" as soon as it has been disabled, and certainly before your QSO partner's transmission is finished.

2. If your QSO partner reverts with his 73,
a. the Enabled TX will either send a CQ, or,
b. if you have been called by another station and "Call 1st" is checked, the Enabled TX will respond to the next caller.
c. if you have not checked "Call 1st", you are free to select a caller to respond to by double-clicking on his line.

If your QSO partner reverts with his 73, you know that the previous QSO is completed and you can click OK in the logging window and log the previous QSO.   

3. If your QSO partner reverts with e.g. R-10, the Enabled TX will automatically respond to the R-10 and repeat the RR73.

Then repeat from 1. above until 73s are exchanged, and both parties know that call signs, reports and acknowledgements of call signs and reports (and a final 73) have been exchanged for a good QSO.

The "three strikes and you're out" is not a favoured approach by me. If I have engaged in a QSO, I'd like to complete it, within reasonable effort, say five repetitions with no response.

If the conditions are not really good enough for RR73 (say FT8 reports are regularly around -15 and lower), I use RRR and 73 in separate messages, and apply my patience to let the AutoSeq do its job to complete the QSO. This keeps the TX enabled all the time, not requiring any reenabling becaus a message with 73 disabled the TX. It takes considerably shorter time than cleaning up the mess with unfinished QSOs, no logging, recuperating lost QSO data for logging from the All.txt file or somewhere up one of the windows, reverting to the unfinished QSO after finishing the next, responding to the unhappy QSO partner's repeated attempts to complete the QSO, etc. It is a typical situation where a choice of convenience (RR73) may create a mess. 

Good luck and 73, Frode LA6VQ