Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Al Pawlowski
A nice new feature for WSJTx might be to not reset the custom (tx5) message (to 
CS 73) for a QSO and instead skip, or end with,  tx5 depending on the message 
content, i.e. a blank (or *** say) in the window would mean skip - it might 
even make sense to make the skip message the default.


Al Pawlowski, K6AVP
Los Osos, CA USA



> On May 20, 2020, at 16:52, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Wed, 20 May 2020 16:51:57 -0700
> From: Paul Kube mailto:paul.k...@gmail.com>>
> To: WSJT software development  <mailto:wsjt-devel@lists.sourceforge.net>>
> Subject: Re: [wsjt-devel] Clicking on RR73 produced wrong TX response
>   msg
> 
> On Wed, May 20, 2020 at 2:05 PM Gary McDuffie  <mailto:mcduf...@ag0n.net>> wrote:
> 
>> 
>> If you call letting him know that you got his acknowledgement of your
>> report a courtesy, I guess so.  I call it a necessity in order to allow him
>> to move on.  If I don?t send the 73, it means I didn?t get his RR73.  If he
>> doesn?t finish, he isn?t in the log.
>> 
> 
> If you didn't get his RR73 (Tx4), certainly the thing to do is to resend
> your report (Tx3), no?
> 
> On the other hand, if you did get his RR73, you can consider the QSO
> completed, and respond in whatever way you want. At least, that's the view
> I've come to after using the FT* modes since they were invented. Was it
> "really" a QSO? I'll let LoTW or the contest logcheck software sort it out.
> 
> A special case is when I see a station I've worked sending RR73 again. That
> shows they're probably expecting a 73 from me and didn't get it. So in that
> case I'll send 73 (Tx5, which is totally customizable, there's even a TX
> Macros page in Settings that lets you create a whole library of them). But
> that almost never happens anymore.

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Bill Somerville

Hi Mike,

the history is that a bunch of HF operators thought that they could be 
clever by using an extremely rare grid (RR73) as a short-form RRR+73 so 
they could get on with the next QSO. Then I believe JTDX added support 
for unilaterally it despite the obvious problems. Eventually Joe gave in 
and we added support in WSJT-X. The rational has always been a way of 
shortening QSOs, akthough in many cases that is not achieved.


73
Bill
G4WJS.

On 21/05/2020 14:58, Black Michael via wsjt-devel wrote:

Guess I was recalling the wrong reason for the RR73 then

What is the history?



On Thursday, May 21, 2020, 08:55:50 AM CDT, Bill Somerville 
 wrote:



On 21/05/2020 14:33, Black Michael via wsjt-devel wrote:
> The whole intent of RR73 was for meteor scatter QSOs which can take a
> really long time.  So RR73 eliminates one exchange that can take 
minutes.

>
>
> Mike W9MDB

Mike,

that's not correct. With MS the RRR then 73 is necessary so both
stations know when to stop transmitting. There may be many periods in an
MS QSO when nothing is copied. These days it is common to inform your
QSO partner via a back channel, Ping Jockey or ON4KST IRC for example,
so that everyone can stop. Once an RRR message has been received the QSO
is complete and it is allowed to confirm that by some other means than a
73 message on air. This breaks the potential loop of not knowing that a
73 message has been received, and so on ad infinitum.

73
Bill
G4WJS.




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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Black Michael via wsjt-devel
Guess I was recalling the wrong reason for the RR73 then
What is the history?
 

On Thursday, May 21, 2020, 08:55:50 AM CDT, Bill Somerville 
 wrote:  
 
 On 21/05/2020 14:33, Black Michael via wsjt-devel wrote:
> The whole intent of RR73 was for meteor scatter QSOs which can take a 
> really long time.  So RR73 eliminates one exchange that can take minutes.
>
>
> Mike W9MDB

Mike,

that's not correct. With MS the RRR then 73 is necessary so both 
stations know when to stop transmitting. There may be many periods in an 
MS QSO when nothing is copied. These days it is common to inform your 
QSO partner via a back channel, Ping Jockey or ON4KST IRC for example, 
so that everyone can stop. Once an RRR message has been received the QSO 
is complete and it is allowed to confirm that by some other means than a 
73 message on air. This breaks the potential loop of not knowing that a 
73 message has been received, and so on ad infinitum.

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] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Bill Somerville

On 21/05/2020 14:33, Black Michael via wsjt-devel wrote:
The whole intent of RR73 was for meteor scatter QSOs which can take a 
really long time.  So RR73 eliminates one exchange that can take minutes.



Mike W9MDB


Mike,

that's not correct. With MS the RRR then 73 is necessary so both 
stations know when to stop transmitting. There may be many periods in an 
MS QSO when nothing is copied. These days it is common to inform your 
QSO partner via a back channel, Ping Jockey or ON4KST IRC for example, 
so that everyone can stop. Once an RRR message has been received the QSO 
is complete and it is allowed to confirm that by some other means than a 
73 message on air. This breaks the potential loop of not knowing that a 
73 message has been received, and so on ad infinitum.


73
Bill
G4WJS.



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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Black Michael via wsjt-devel
RR73 requires no response...if the receiving party doesn't get the RR73 they 
automatically retransmit TX3...
The RR73 is stating "I expect no further replies from you".  There is no 73 
required at allit is a courtesy done on HF bands.
The whole intent of RR73 was for meteor scatter QSOs which can take a really 
long time.  So RR73 eliminates one exchange that can take minutes.

Mike W9MDB


 

On Thursday, May 21, 2020, 08:25:17 AM CDT, Andy Durbin  
wrote:  
 
  "Both stations should log the QSO when RR73 is sent.  At that point in the 
message sequence both QSO partners have exchanged call signs, reports and 
acknowledgements (R -04 and RR73).  No further messages need to be exchanged."
The flaw in this argument is that transmission of RR73 does not ensure 
reception of RR73.  "Exchanged" requires both transmission and reception,
73,
Andy, k3wyc___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Bill Somerville

On 21/05/2020 14:20, Andy Durbin wrote:
"Both stations should log the QSO when RR73 is sent.  At that point in 
the message sequence both QSO partners have exchanged call signs, 
reports and acknowledgements (R -04 and RR73).  No further messages 
need to be exchanged."


The flaw in this argument is that transmission of RR73 does not ensure 
reception of RR73. "Exchanged" requires both transmission and reception,


73,
Andy, k3wyc


Hi Andy,

the requirement usually is that both operators are assured that they 
have completed the QSO. A rapid QSO followed by the other station 
calling CQ or calling another station straight away is often all that is 
needed to be sure that an RR73 message has been successfully decoded and 
the QSO logged at the other end.


73
Bill
G4WJS.

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Andy Durbin
"Both stations should log the QSO when RR73 is sent.  At that point in the 
message sequence both QSO partners have exchanged call signs, reports and 
acknowledgements (R -04 and RR73).  No further messages need to be exchanged."

The flaw in this argument is that transmission of RR73 does not ensure 
reception of RR73.  "Exchanged" requires both transmission and reception,

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-21 Thread Reino Talarmo
>> On May 20, 2020, at 10:28, Neil Zampella  wrote:
>> 
>> The 73 from you is a courtesy ... the RR73 is saying  "Roger Roger -
>> BYE'"basically ... we're good.This is why the program then
>> switches to the Tx6 to send the next CQ call.

>If you call letting him know that you got his acknowledgement of your report a 
>courtesy, I guess so.  I call it a necessity in order to allow him to move on. 
> If I don’t send the 73, it means I didn’t get his RR73.  If he doesn’t 
>finish, he isn’t in the log.

>Gary - AG0N

Gary,
You may have misunderstood the protocol and when QSO is confirmed. Let's assume 
that he is still hearing you, then in the case you did not received his RR73 
you should resend your R-xx and that will tell him the situation and he should 
resend his RR73. If he in addition wants to know that you really got his 
confirmation and you should send 73, then he should send RRR not RR73. 
Each sending 73, either RR73 or 73, means I am going to log this contact unless 
you indicate that you have not received my confirmation RR73.
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] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Paul Kube
On Wed, May 20, 2020 at 2:05 PM Gary McDuffie  wrote:

>
> If you call letting him know that you got his acknowledgement of your
> report a courtesy, I guess so.  I call it a necessity in order to allow him
> to move on.  If I don’t send the 73, it means I didn’t get his RR73.  If he
> doesn’t finish, he isn’t in the log.
>

If you didn't get his RR73 (Tx4), certainly the thing to do is to resend
your report (Tx3), no?

On the other hand, if you did get his RR73, you can consider the QSO
completed, and respond in whatever way you want. At least, that's the view
I've come to after using the FT* modes since they were invented. Was it
"really" a QSO? I'll let LoTW or the contest logcheck software sort it out.

A special case is when I see a station I've worked sending RR73 again. That
shows they're probably expecting a 73 from me and didn't get it. So in that
case I'll send 73 (Tx5, which is totally customizable, there's even a TX
Macros page in Settings that lets you create a whole library of them). But
that almost never happens anymore.

73, Paul K6PO


>
> Gary - AG0N
>
> ___
> 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] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Stephen VK3SIR
Ed,

There is a strange anomaly that makes no sense yet many of us that (especially) 
work weak DX observe frequently ... Sometimes when you end up in a R -XX/RR73 
loop ("RR/73 loop" or "ACK dance" as you term it) with a station anecdotally 
and observationally sometimes sending 73 sequences back manually appears to 
break the loop-cycle. 

Why ? it makes no sense when logic is analysed or informed thought is applied 
to the observation.

Note that it is not restricted to Weak DX - but is more often observed when 
both ends have desperation to complete the QSO.

Yet from my direct observation, experimentation and simulation conducted a 
couple of back (when on "down time" with research that I was on - and using 
earlier on earlier FT8 releases and the "main fork") it is able to be 
replicated - yet inconsistently. 

There are "theories" that if the data stream is changed slightly then QRM/QRN 
effects that interact with signals passed over the decoder can change and 
therefore decoding impasses can be broken ...

More likely the observation is just a statistical/probability anomaly. Yet some 
Amateurs SWEAR by this method to break impasses; I also admit that I have often 
found it to be observationally useful operationally to break a RR/73 loop !

A "revert and hold" over-ride over Tx4 sequencing when Tx5 is selected may be 
useful. Yet without mathematical or statistical justification for it - just 
observation and anecdote - it will be hard to convince the core developers of 
mitigation strategies that can and will consume valuable signal processing 
resources.

73

Steve I
VK3VM / VK3SIR

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Gary Hinson
There will always be uncertainty about what the other guy is thinking and 
doing, whether our messages have been received and understood etc.  Exchanging 
RR73, 73 and free text messages at the end of a QSO extends the QSO sequence so 
reducing any remaining uncertainty with each additional message.  Even after 
all that, it is still possible the other guy won't have logged the QSO 
'correctly', updated his online log pages, uploaded it to 
LoTW/QRZ/eQSL/Twitter, sent a QSL card, emailed us, popped round to say hello, 
blogged about it ... 

So, too bad.  That's just how it is.  No amount of laying down the rules about 
what constitutes a completed QSO is going to eliminate all doubt.  The rules 
are barely relevant, and are not universally agreed or imposed anyway.  That's 
the point.

Luckily, the requirement is not to remove ALL uncertainty but to increase 
assurance that both parties have exchanged information sufficiently accurately 
and completely to consider it a QSO.  For everyday run-o-the-mill QSOs, very 
little assurance is needed since the consequences of being wrong are 
negligible.  For special, rare or remarkable QSOs (whatever that means to 
either party), greater assurance is welcome.  Unfortunately, without additional 
info beyond the typical minimalist exchange, it’s not easy to tell whether the 
other guy is sufficiently assured ... but continuing to send any message, or 
re-starting the QSO, or sending an email, QSL card etc. are all clues that more 
assurance is needed or would be welcome.  Likewise, ending the QSO by not 
sending further messages or starting the next QSO are clues that the earlier 
QSO is over (whether complete or not).  There are dynamics here.

Good luck to anyone coding the autosequencer state table for all those 
possibilities, and more besides (messages-sequence-out-of, QSB, QRN and QRM 
corrupting messages from either end, duplicate/early/late/incomplete/corrupted 
messages, wrong format, hash collisions and misses, etc.)!  

For anyone obsessed about working actual living breathing hams rather than 
their computers and autosequence robots, there is plenty of latitude for 
deliberately meddling with the message contents, sequencing and timing to see 
whether and how the other guy responds on the basis that people and computers 
react differently.  I'm blabbering about a digimode version of the Turing test 
which is, again, about reducing not eliminating uncertainty.  Just as people 
can be trained to ace lie detector tests, computers can be programmed to appear 
human.  

What makes you think I am a human?  I'm not even sure myself.

73
Gary  ZL2iFB  aka HAL


-Original Message-
From: Gary McDuffie  
Sent: 21 May 2020 09:01
To: WSJT software development 
Subject: Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg



> On May 20, 2020, at 10:28, Neil Zampella  wrote:
> 
> The 73 from you is a courtesy ... the RR73 is saying  "Roger Roger -
> BYE'"basically ... we're good.This is why the program then
> switches to the Tx6 to send the next CQ call.

If you call letting him know that you got his acknowledgement of your report a 
courtesy, I guess so.  I call it a necessity in order to allow him to move on.  
If I don’t send the 73, it means I didn’t get his RR73.  If he doesn’t finish, 
he isn’t in the log.

Gary - AG0N

___
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] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Gary McDuffie


> On May 20, 2020, at 10:28, Neil Zampella  wrote:
> 
> The 73 from you is a courtesy ... the RR73 is saying  "Roger Roger -
> BYE'"basically ... we're good.This is why the program then
> switches to the Tx6 to send the next CQ call.

If you call letting him know that you got his acknowledgement of your report a 
courtesy, I guess so.  I call it a necessity in order to allow him to move on.  
If I don’t send the 73, it means I didn’t get his RR73.  If he doesn’t finish, 
he isn’t in the log.

Gary - AG0N

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Ed Muns
Both stations should log the QSO when RR73 is sent.  At that point in the 
message sequence both QSO partners have exchanged call signs, reports and 
acknowledgements (R -04 and RR73).  No further messages need to be exchanged.

Rather than sending a third ACK, e.g., 73, to confirm receipt of the second 
ACK, e.g., RR73, instead re-send the first ACK message, e.g., R -04, only if 
you do not print the second ACK (RR73).  Thus, absence of the re-send of R -04 
is implicit confirmation the RR73 message was received.  Furthermore, if the 
QSO partner sends CQ or calls another station in the next TX cycle, that is 
pretty solid confirmation that the RR73 was indeed received.  This message 
sequence protocol has the advantage of both speed and clarity to both QSO 
partners about whether the QSO is complete and can be logged.

No matter what message sequence protocol we use, the last message is always 
subject to loss.  In the limit, the ACK dance could go on forever which takes 
more time for no benefit.  If we agree and stick to a single message sequence 
protocol, then we can use that contextual information to determine QSO 
completion, by both QSO partners.

The recommended message sequence is the same as has worked in the other modes 
for decades: exchange call signs, exchange parameters and ACKs (one each).  The 
cordial practice of sending, or expecting, a 73 message as a third ACK to the 
RR73 message creates the inadvertent consequence of uncertainty about whether 
the other side is a "73 advocate" or not.

73,
Ed W0YK

-Original Message-
From: Gary McDuffie  
Sent: 19 May, 2020 20:48
To: WSJT software development 
Subject: Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg



> On May 19, 2020, at 10:05, Neil Zampella  wrote:
> 
>  .. someone sending an RR73 does not expect a reply, the last 73 is a 
> courtesy from you the answering station. 

I certainly do, in order to let him know I got his RR73 and he needs to sen 
nothing else.  If I don’t send 73, I expect him to repeat it because I 
obviously didn’t get his RR73 in the first place.  When he gets my 73, he stops 
sending RR73, telling me that we are done!

Gary - AG0N

___
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] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Neil Zampella

Gary ...

The 73 from you is a courtesy ... the RR73 is saying  "Roger Roger -
BYE'"    basically ... we're good.    This is why the program then
switches to the Tx6 to send the next CQ call.

If you didn't get the RR73, the program will resend the Tx3 R-xx message.

Neil, KN3ILZ


On 5/19/2020 11:48 PM, Gary McDuffie wrote:



On May 19, 2020, at 10:05, Neil Zampella  wrote:

  .. someone sending an RR73 does not expect a reply, the last 73 is a courtesy 
from you the answering station.

I certainly do, in order to let him know I got his RR73 and he needs to sen 
nothing else.  If I don’t send 73, I expect him to repeat it because I 
obviously didn’t get his RR73 in the first place.  When he gets my 73, he stops 
sending RR73, telling me that we are done!

Gary - AG0N



--
This email has been checked for viruses by AVG.
https://www.avg.com



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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-19 Thread Gary McDuffie


> On May 19, 2020, at 10:05, Neil Zampella  wrote:
> 
>  .. someone sending an RR73 does not expect a reply, the last 73 is a 
> courtesy from you the answering station. 

I certainly do, in order to let him know I got his RR73 and he needs to sen 
nothing else.  If I don’t send 73, I expect him to repeat it because I 
obviously didn’t get his RR73 in the first place.  When he gets my 73, he stops 
sending RR73, telling me that we are done!

Gary - AG0N

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-19 Thread Black Michael via wsjt-devel
Yeah, I know, but a good number do it anyways...
Mike

 

On Tuesday, May 19, 2020, 11:09:47 AM CDT, Neil Zampella  
wrote:  
 
  
FWIW .. someone sending an RR73 does not expect a reply, the last 73 is a 
courtesy from you the answering station.    If someone keeps sending RR73, they 
don't understand the use of that response.
 
 Neil, KN3ILZ
 
 On 5/19/2020 10:06 AM, Black Michael wrote:
  
 
  What he's describing has happened to me numerous times... 
  You send 73 and move on to another QSO...then the last QSO sends RR73 again 
so you have to double-click it. 
  Seems to me double-clicking an RR73 that has your callsign in it should 
automatically go to Tx 5 instead of TX3. 
  de Mike W9MDB  

  
  On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor 
 wrote:  
  
   Hi Rich,
 
 On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:
 
 > *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
 > send a 73. However if the station doesn't receive my '73' message, he 
 > re-sends his TX4 RR73 message. When I double click on his first RR73 
 > line, instead of sending me sending the correct Tx5 '73' message,  
 > WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
 > roger report. *
 > *
 > *Is this a bug or a 'feature' to keep us on our toes?*
 
 Think of it as a 'feature'.  The program's logic is that you sent 73, so 
 the QSO is over as far as you're concerned.  If you want the program to 
 send 73 again upon receipt of another RR73 from the same QSO partner, 
 toggle *Enable Tx* to red, again, during the Rx interval after you send 73.
 
     -- Joe, K1JT 
 
 
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  

|  | Virus-free. www.avg.com  |

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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-19 Thread Neil Zampella

FWIW .. someone sending an RR73 does not expect a reply, the last 73 is
a courtesy from you the answering station.    If someone keeps sending
RR73, they don't understand the use of that response.

Neil, KN3ILZ

On 5/19/2020 10:06 AM, Black Michael wrote:

What he's describing has happened to me numerous times...

You send 73 and move on to another QSO...then the last QSO sends RR73
again so you have to double-click it.

Seems to me double-clicking an RR73 that has your callsign in it
should automatically go to Tx 5 instead of TX3.

de Mike W9MDB



On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor
 wrote:


Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

> *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I
> send a 73. However if the station doesn't receive my '73' message, he
> re-sends his TX4 RR73 message. When I double click on his first RR73
> line, instead of sending me sending the correct Tx5 '73' message,
> WSJT-X sends the incorrect response of a  'Tx3' message of calls and
> roger report. *
> *
> *Is this a bug or a 'feature' to keep us on our toes?*

Think of it as a 'feature'.  The program's logic is that you sent 73, so
the QSO is over as far as you're concerned.  If you want the program to
send 73 again upon receipt of another RR73 from the same QSO partner,
toggle *Enable Tx* to red, again, during the Rx interval after you
send 73.

    -- Joe, K1JT



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



--
This email has been checked for viruses by AVG.
https://www.avg.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-19 Thread Black Michael via wsjt-devel
What he's describing has happened to me numerous times...
You send 73 and move on to another QSO...then the last QSO sends RR73 again so 
you have to double-click it.
Seems to me double-clicking an RR73 that has your callsign in it should 
automatically go to Tx 5 instead of TX3.
de Mike W9MDB
 

On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor  
wrote:  
 
 Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

> *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
> send a 73. However if the station doesn't receive my '73' message, he 
> re-sends his TX4 RR73 message. When I double click on his first RR73 
> line, instead of sending me sending the correct Tx5 '73' message,  
> WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
> roger report. *
> *
> *Is this a bug or a 'feature' to keep us on our toes?*

Think of it as a 'feature'.  The program's logic is that you sent 73, so 
the QSO is over as far as you're concerned.  If you want the program to 
send 73 again upon receipt of another RR73 from the same QSO partner, 
toggle *Enable Tx* to red, again, during the Rx interval after you send 73.

    -- Joe, K1JT


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


Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-19 Thread Joe Taylor

Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

*Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
send a 73. However if the station doesn't receive my '73' message, he 
re-sends his TX4 RR73 message. When I double click on his first RR73 
line, instead of sending me sending the correct Tx5 '73' message,  
WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
roger report. *

*
*Is this a bug or a 'feature' to keep us on our toes?*


Think of it as a 'feature'.  The program's logic is that you sent 73, so 
the QSO is over as far as you're concerned.  If you want the program to 
send 73 again upon receipt of another RR73 from the same QSO partner, 
toggle *Enable Tx* to red, again, during the Rx interval after you send 73.


-- Joe, K1JT


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


[wsjt-devel] Clicking on RR73 produced wrong TX response msg

2020-05-18 Thread Rich Zwirko - K1HTV
*Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I send
a 73. However if the station doesn't receive my '73' message, he re-sends
his TX4 RR73 message. When I double click on his first RR73 line, instead
of sending me sending the correct Tx5 '73' message,  WSJT-X sends the
incorrect response of a  'Tx3' message of calls and roger report. *

*Is this a bug or a 'feature' to keep us on our toes?*

*73,*
*Rich - K1HTV*
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel