G4WJS.
Bill,
Regarding the use of "RR73", I believe that it should be formalized as an
option to the present "73" TX5 message.
Let's look at this senario regarding when a QSO is assumed to be complete:
Station #1 sends Station #2 a report.
Station #2 sends either "RRR" or "RR73" because he has received Station #1's
"RR-report".
At this point Station #2 believes the QSO is complete because of the rogers he
has heard in the "RRR" or "RR-report"
which has been received.
But Station #1 still needs to have confirmed that his "RRR" or "RR73" report
has been received.
This confirmation in the mind of Station#1 is realized if:
1) An "RRR" or "RR73" message is received from #2.
2) He copies Station #2 that he was working immediately calling CQ or
responding to another station.
In either of these two cases, the contact can be assumed to be complete. There
would be no need for station #2 to
continue sending either "73" or a repeat of "RR73". I believe that if either
TX5 messages ("73" or optional "RR73")
is sent, it should only be sent only once, then the TX disabled, if this option
is checked.
However......if Station #1 does NOT hear Station #2 either calling "CQ" or
another station, then there will be a
question in his mind of the QSO being complete. This can happen under rapidly
changing propagation conditions, as
happens on 50 MHz. In that case, I would assume that Station #1 would continue
sending his "RR-report" in hopes that
Station #2 would see that Station #1 still needed a confirmation. If Station #2
saw this, he would have to click "TX Enable" and send another "73" or "RR73".
Thanks for the coding that you have been doing to make the WSJT-X suite of
modes the success that they have become.
73,
Rich - K1HTV
= = =
Date: Thu, 20 Jul 2017 13:18:01 +0100
From: Bill Somerville <g4...@classdesign.com mailto:g4...@classdesign.com >
To: WSJT software development <wsjt-devel@lists.sourceforge.net
mailto:wsjt-devel@lists.sourceforge.net >
Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final
message
Message-ID: <83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com
mailto:83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com >
Content-Type: text/plain; charset=utf-8; format=flowed
Hi All,
we are looking at changing the WSJT-X logic such that a grid message of
the form:
"<dx-call> <de-call> RR73"
is treated as a sign off message.
This has several implications and I need some clarification so that I
can adjust the code. For now I will put aside any potential issues for
holders of compound callsigns as I have not analysed the impact for them
yet.
The first change is already in place, sending such an RR73 message is
treated the same as sending a standard 73 message or any free text
message containing the word "73". This means that, if prompt to log
after 73 is set the log QSO window will be popped up, and if
"Settings->General->Behavior->Disable Tx after 73" is checked, auto
transmit will be disabled and the next message to be sent will be moved
on to Tx6 (CQ message). This part is straightforward.
I propose to add a check box option to "Settings->General->Behavior"
along the lines of "Use RR73 in place of RRR", when checked this would
generate the above RR73 message for the Tx4 (RRR) message, thus
formalizing the usage of RR73 as a final QSO message.
So now the questions. If we have disabled auto Tx and switched the next
message to Tx6/CQ, how do we proceed if no "73" message is received from
ones QSO partner. Listening on the bands it seems that sending an RR73
message has some special significance in that it is always assumed to be
received by ones QSO partner. This may be reasonable in propagation such
that any subsequent messages can be taken by ones QSO partner to mean
that the QSO is indeed complete even if the RR73 message was never decoded.
For example if you have called a station calling CQ, received a report,
sent a R+report and then get no decode from them in the next period;
then the next decode from the other station is a CQ call or them giving
a report to a different station or even calling another station on a
different frequency, then are we safe to assume that our QSO was
complete and there is no requirement to repeat the R+report message (the
normal action if an RRR message is not decoded) or even send a 73
message ourselves? BTW this does beg the question of how a station
running a frequency completes their last QSO on a band, do we take
silence to be an indication that a missed RR73 decode was in fact sent.
The above is fairly easy to implement in that, if an RR73 message is
received from ones QSO partner ones next message will be set to Tx5/73
(note not RR73) and if prompt to log is checked the log QSO window will
pop up. Also if "Settings->General->Behavior->Disable Tx after 73" is
checked, auto transmit will be disabled. In other words, receiving an
RR73 message will be treated exactly the same as receiving a 73 message
(note this would not be optional).
Note the implication of the above is that no reply would be sent to an
RR73 message if one is received. I suppose this is the intent of the
original calling station and they might expect a tail-end caller to
utilize the period after they send RR73 without you QRMing such a caller
by sending a 73 message. This raises an issue of what to do when an
expected RRR or RR73 message is not received or decoded since it is
impossible to know if the original caller received ones R+report
message, or whether they sent RRR and are expecting a 73 message, or
whether they repeated their report and are expecting an R+report
message, or they actually sent RR73 and expect that the QSO is over. How
can the software and indeed the operator deal with this scenario? It
would seem that resending the R+report message is the only deterministic
option which makes a mockery of any assumption that RR73 messages are
always decoded.
More questions to follow once I have a feel for how this is expected to
work. I do not really want a debate on the merits of this common tactic
to speed up QSOs, just the mechanics of how it should work.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
