Re: [wsjt-devel] adding a "skip TX1" checkbox

[Mark Turner via wsjt-devel]

Hi Bill,

could it be implemented it such that, if set, "Skip Tx 1" is simply 
ignored if the dx call is a compound callsign?


In fact the whole Tx1/RR73 thing might be boiled down to a more generic 
option, like "minimal", or "optimise", or similar - i.e. attempt to use 
the least number of exchanges to achieve a valid qso, that would 
automatically take things like compound callsigns into account. Sounds 
very tweaky though...


Regards, Mark


On 20/07/2017 17:27, Bill Somerville wrote:

On 20/07/2017 17:19, AB1NJ wrote:
I see the discussion on the RR73, but possibly more important is a 
easy way to skip TX1 message, in order to send a report (normally 
TX2) on first reply to CQ instead of grid. A checkbox would be 
obvious solution. Thoughts? 


Hi Rob,

I am considering it. Like the RR73 issue, some investigation needs to 
be done into how it might work for those with compound callsigns. 
Skipping Tx1 may lock out compound callsign holders in several 
scenarios which seems harsh to me especially if it is combined with 
using RR73 to truncate QSOs.


Clearly 6m multi-hop Es and similar on other bands could be a driving 
force to skip Tx1 but if that were to exclude compound call holders 
then I would probably prefer to use FT8 for stronger signal openings 
and JT65/9/QRA64 for weaker signal openings/paths.


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



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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Joe Taylor]

Hi Neil,

but doesn't that mean you have to redo the logic used by the double 
click to change the current function from seeing RR73 as a grid, ...


The change in logic is minimal.

I'm also guessing that you would have to make this band specific so its 
not used with MS/EME/etc modes which would mess up the normal QSO 
there.   


No.  RR73 is already used sometimes for MS, with no confusion.  Anyone 
receiving an RR73 knows what it means.


Few (if any) use RR73 for EME.  EME operators are seldom in a hurry; 
they generally prefer solid, perfectly documented QSOs with every box 
separately checked.


You have plenty of people still using WSJT v10 that it would 
cause headaches for.


WSJT has no trouble coping with RR73.  Why should it?

There are plenty of us who DON'T use RR73 as it doesn't save any time on 
the slow modes whatsoever, and its an affectation that does not need to 
be formalized as part of the protocol (IMHO).


There's a simple solution: if you don't like it, don't use it!  (But 
you'd be well advised to be prepared to receive it, sometimes.)


-- 73, Joe, K1JT

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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Bill Somerville]

Hi Neil,

despite your comments and their validity, it has become common practice 
to end QSOs with an RR73 grid message. Because of this it is fairly 
essential that WSJT-X knows to not treat such a message as a standard 
grid message, extending that to handling such a message as a logging 
prompt and final message, like it does for a 73 message, is not a great 
deal of extra work. It does create some ambiguities and difficulties but 
I would rather add some support than have many QSOs being logged with 
incorrect grid squares. If I can find a way to accommodate a way of 
generating RR73 messages to finish a QSO then I will add it but that 
will always be optional. This all becomes far more important with the 
use of auto-sequencing to make operating manageable with T/R periods don 
to as fast as 5s.


73
Bill
G4WJS.

On 21/07/2017 00:45, Neil Zampella wrote:

Bill (G4WJS),

but doesn't that mean you have to redo the logic used by the double 
click to change the current function from seeing RR73 as a grid, and 
overwriting, then sending a -XX signal report?


I'm also guessing that you would have to make this band specific so 
its not used with MS/EME/etc modes which would mess up the normal QSO 
there.   You have plenty of people still using WSJT v10 that it would 
cause headaches for.


There are plenty of us who DON'T use RR73 as it doesn't save any time 
on the slow modes whatsoever, and its an affectation that does not 
need to be formalized as part of the protocol (IMHO).


Neil, KN3ILZ


On 7/20/2017 1:32 PM, Bill Somerville wrote:

On 20/07/2017 17:27, Bill Turner wrote:

How about R-73 to avoid confusion with grids RR-73?


Hi Bill,

that defeats the purpose of RR73, it is because it is a valid grid 
that two complete callsigns can be sent with it as a standard 
message. You suggestion would require a free text message with a 13 
character (inc. spaces) size limitation.


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Neil Zampella]

Bill (G4WJS),

but doesn't that mean you have to redo the logic used by the double 
click to change the current function from seeing RR73 as a grid, and 
overwriting, then sending a -XX signal report?


I'm also guessing that you would have to make this band specific so its 
not used with MS/EME/etc modes which would mess up the normal QSO 
there.   You have plenty of people still using WSJT v10 that it would 
cause headaches for.


There are plenty of us who DON'T use RR73 as it doesn't save any time on 
the slow modes whatsoever, and its an affectation that does not need to 
be formalized as part of the protocol (IMHO).


Neil, KN3ILZ


On 7/20/2017 1:32 PM, Bill Somerville wrote:

On 20/07/2017 17:27, Bill Turner wrote:

How about R-73 to avoid confusion with grids RR-73?


Hi Bill,

that defeats the purpose of RR73, it is because it is a valid grid 
that two complete callsigns can be sent with it as a standard message. 
You suggestion would require a free text message with a 13 character 
(inc. spaces) size limitation.


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

Re: [wsjt-devel] CAT error do not select radio configuration

[Bill Somerville]

On 20/07/2017 21:52, Alessandro Gorobey via wsjt-devel wrote:
for a my error I notice that with a CAT error program go to select 
configuration, not to the radio CAT of current configuration.


Is it wanted ?

It is simple to simulate turning off radio.

Tested only with 1.8.0 and 1.7.1 > r7920 


Hi Sandro,

I do not follow you with what the issue is, can you try and explain a 
different way please?


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

[wsjt-devel] CAT error do not select radio configuration

[Alessandro Gorobey via wsjt-devel]

Hi,

for a my error I notice that with a CAT error program go to select 
configuration, not to the radio CAT of current configuration.


Is it wanted ?

It is simple to simulate turning off radio.

Tested only with 1.8.0 and 1.7.1 > r7920



--
73
Sandro
IW3RAB
--
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

[wsjt-devel] WSJT-X 1.8 rc2 Issue

[Ed Wilson via wsjt-devel]

 I have been testing rc2 today. As I reported previously (when testing an 
earlier release) there is an issue where Tx5 (the 73 line) appears blank on an 
apparently random basis maybe 10% of the time. I have not been able to pin-down 
if any particular sequence of events causes this problem. Mike sent me a patch 
earlier but I was unable to test it having received an error message which may 
have been due to my own ignorance.
In any case I wanted to point this out prior to release of rc2.
Ed, K0KC
k0kc@arrl.nethttp://k0kc.us/--
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

Re: [wsjt-devel] FT8 Bad Spots

[Black Michael via wsjt-devel]

I took a look at the pskpost entries.
There are 3 places where this occurs and only one of the three has any 
protection against early posts.
I'm thinking what's best is to have a m_bandStart and m_bandEnd that gets set 
on audio recording start/end.That way you check those two to ensure that the 
band doesn't change during the recording period in the WAV file and if it it 
has, then don't post to pskreporter.
Does that sound reasonable?  That would be in lieu of the one tr_period check 
in the code now.
de Mike W9MDB   

   From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Saturday, July 15, 2017 9:30 AM
 Subject: Re: [wsjt-devel] FT8 Bad Spots
  
 On 15/07/2017 15:20, Black Michael via wsjt-devel wrote:
  
 Hopefully Bill can answer this as do believe he wrote it. I've never examined 
the pskreporter flow. 
  
 Hi Mike, I didn't write it but have updated parts of it. I believe there is 
some protection from sending spots after a band change where decodes might be 
for either old or new band. There may be a hard coded minute somewhere that 
needs to be the T/R period. I am busy with other issues at present but I can 
look at it later.
  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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Bill Somerville]

On 20/07/2017 17:27, Bill Turner wrote:

How about R-73 to avoid confusion with grids RR-73?


Hi Bill,

that defeats the purpose of RR73, it is because it is a valid grid that 
two complete callsigns can be sent with it as a standard message. You 
suggestion would require a free text message with a 13 character (inc. 
spaces) size limitation.


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Rich - K1HTV]

I wouldn't worry about anyone ever being active in grid RR73. It is a water 
grid in the Russian Arctic region. $100 to the first guy to work a legitimate 
maritime mobile station on FT8 from grid RR73 :-). Its a non-problem.

73,
Rich - K1HTV

> On July 20, 2017 at 12:29 PM Bill Somerville  wrote:
>
>
> On 20/07/2017 17:27, Bill Turner wrote:
> > How about R-73 to avoid confusion with grids RR-73?
>
> Hi Bill,
>
> that defeats the purpose of RR73, it is because it is a valid grid that
> two complete callsigns can be sent with it as a standard message. You
> suggestion would require a free text message with a 13 character (inc.
> spaces) size limitation.
>
> 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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Bill Somerville]

On 20/07/2017 18:23, Black Michael via wsjt-devel wrote:
The problem I think that can occur is when you use, for example, 
JTAlert to tell you who you need.
If you enter a QSO but don't get a QSL I think JTAlert will still show 
it as a B4 entry which, if you don't have B4's being show, you won't 
see on JTAlert call slots.  So if you confirm, but your partner does 
not, then you may never recognize them again.


One could argue that's JTAlert's responsibility and perhaps JTAlert 
should check the LOTW/eQSL status to say "hmmm...not confirmed so 
still show them".

I'll ask Laurie about that one.


Hi Mike,

you have a valid point and it is true for DX Lab Suite DXKeeper as well. 
It does not consider a dupe of an unconfirmed contact worthy of working 
again to try for a confirmation. The assumption there is that they do 
not QSL. OTOH if they do send a confirmation it is all is ok. If they 
haven't logged the contact then at least they might try for another QSO 
but if they are rare and I am not then that is a slim chance.


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Seb]

Or how about RR 73.  Would this not be saved as the grid in your logging 
program?

I realize there is nobody living in the grid RR73, but bad data is bad data.  
Bad data should never be accepted as a quick fix, IMHO.

On HF, grids (at this time) are pretty much meaningless, but having this 
ability in the program will be carried over to VHF (as many already do).

While I’m not against someone sending RR73 or something similar, my concern is 
with the logging.

73 de Sebastian, W4AS




> On Jul 20, 2017, at 12:27 PM, Bill Turner via wsjt-devel 
>  wrote:
> 
> How about R-73 to avoid confusion with grids RR-73?
> 
> Bill, W4WNT
> 
> Sent from Yahoo Mail on Android 
> 
> On Thu, Jul 20, 2017 at 11:16 AM, Rich - K1HTV
>  wrote:
> G4WJS.  
> 
> 
> Bill,
> Regarding the use of "RR73", I believe that it should be formalized as an 
> option to the present "73" TX5 message.
> 
> 
> 

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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Black Michael via wsjt-devel]

The problem I think that can occur is when you use, for example, JTAlert to 
tell you who you need.If you enter a QSO but don't get a QSL I think JTAlert 
will still show it as a B4 entry which, if you don't have B4's being show, you 
won't see on JTAlert call slots.  So if you confirm, but your partner does not, 
then you may never recognize them again.
One could argue that's JTAlert's responsibility and perhaps JTAlert should 
check the LOTW/eQSL status to say "hmmm...not confirmed so still show 
them".I'll ask Laurie about that one.
de Mike W9MDB

  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Thursday, July 20, 2017 9:12 AM
 Subject: Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
   
On 20/07/2017 14:27, Black Michael via wsjt-devel wrote:
> although if autoseq detects the RR73 as the prompt to log means they 
> likely have logged it already which I think is not what should be done.

HI Mike,

there seems to be an aversion to logging a QSO before your QSO partner 
can, I don't see why this is a constraint. I have no problem with a one 
way QSOs going into my log, if I don't get a confirmation for it then 
there is no problem. Maybe in these days of electronic confirmations I 
am biased by the zero cost of the above strategy.

Surely logging one side of a QSO as complete and sending sufficient 
replies allowing a QSO partner to do the same are not the same thing, 
they are different events in time. I would happily log a QSO at the 
point I decide to send the first R whether it be R+report or RRR, but 
that does not obviate me of the need to finish the QSO allowing my QSO 
partner to do the same.

If I sent QSL cards for every QSO, I would probably un-check the send 
paper QSL option in my log for QSOs where I didn't have confirmation of 
a complete QSO, i.e. no RRR copied. That doesn't stop my QSO partner 
sending me a card to which I will then reply since unbeknownst to me he 
actually had a R+report from me and the QSO was complete two-way. If he 
sends a speculative card then he will not have my report and also I 
couldn't care less about sending him a card if he happens to guess the 
report correctly, it is down to him if he feels that he needs to cheat 
to get my QSL card.

It seems to me that the practise of sending RR73 is in line with the 
above and clearly works when used judiciously when propagation allows 
extra confidence of likely receipt.

One station logging a QSO is not the same as a QSO being complete. A QSO 
is complete when *both stations* can log the QSO and if they do, and 
only then, both may claim credit for the complete QSO.

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


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Bill Turner via wsjt-devel]

How about R-73 to avoid confusion with grids RR-73?
Bill, W4WNT

Sent from Yahoo Mail on Android 
 
  On Thu, Jul 20, 2017 at 11:16 AM, Rich - K1HTV wrote:
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 
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final
 message
Message-ID: <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:

"  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 

Re: [wsjt-devel] adding a "skip TX1" checkbox

[Bill Somerville]

On 20/07/2017 17:19, AB1NJ wrote:
I see the discussion on the RR73, but possibly more important is a 
easy way to skip TX1 message, in order to send a report (normally TX2) 
on first reply to CQ instead of grid. A checkbox would be obvious 
solution.  Thoughts? 


Hi Rob,

I am considering it. Like the RR73 issue, some investigation needs to be 
done into how it might work for those with compound callsigns. Skipping 
Tx1 may lock out compound callsign holders in several scenarios which 
seems harsh to me especially if it is combined with using RR73 to 
truncate QSOs.


Clearly 6m multi-hop Es and similar on other bands could be a driving 
force to skip Tx1 but if that were to exclude compound call holders then 
I would probably prefer to use FT8 for stronger signal openings and 
JT65/9/QRA64 for weaker signal openings/paths.


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Rich - K1HTV]

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 
To: WSJT software development 
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:

"  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).

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Bill Somerville]

On 20/07/2017 14:27, Black Michael via wsjt-devel wrote:
although if autoseq detects the RR73 as the prompt to log means they 
likely have logged it already which I think is not what should be done.


HI Mike,

there seems to be an aversion to logging a QSO before your QSO partner 
can, I don't see why this is a constraint. I have no problem with a one 
way QSOs going into my log, if I don't get a confirmation for it then 
there is no problem. Maybe in these days of electronic confirmations I 
am biased by the zero cost of the above strategy.


Surely logging one side of a QSO as complete and sending sufficient 
replies allowing a QSO partner to do the same are not the same thing, 
they are different events in time. I would happily log a QSO at the 
point I decide to send the first R whether it be R+report or RRR, but 
that does not obviate me of the need to finish the QSO allowing my QSO 
partner to do the same.


If I sent QSL cards for every QSO, I would probably un-check the send 
paper QSL option in my log for QSOs where I didn't have confirmation of 
a complete QSO, i.e. no RRR copied. That doesn't stop my QSO partner 
sending me a card to which I will then reply since unbeknownst to me he 
actually had a R+report from me and the QSO was complete two-way. If he 
sends a speculative card then he will not have my report and also I 
couldn't care less about sending him a card if he happens to guess the 
report correctly, it is down to him if he feels that he needs to cheat 
to get my QSL card.


It seems to me that the practise of sending RR73 is in line with the 
above and clearly works when used judiciously when propagation allows 
extra confidence of likely receipt.


One station logging a QSO is not the same as a QSO being complete. A QSO 
is complete when *both stations* can log the QSO and if they do, and 
only then, both may claim credit for the complete QSO.


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

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Black Michael via wsjt-devel]

Since I don't send RR73 right now can only speak as one who has received them...
I have always interpreted the RR73 to mean "I don't intend on sending a 73 
after you send 73" although if autoseq detects the RR73 as the prompt to log 
means they likely have logged it already which I think is not what should be 
done.  This does work in the vast majority of cases and requires no 
retransmitthe problem comes on weak signal where repeats are required.It's 
STILL an RRR message...so if they don't get the 73 they MUST send it again 
until they do get your 73 otherwise how's the 73 side supposed to know they got 
the report?So to me the autosequencing should turn off when 73/RR73 is 
received, not sent.  If you haven't received the 73 you need to keep sending 
your last message...whatever is was. And that's also when the log should 
prompt.  That works for all situations.    

I've numerous QSOs like that where I've not received an RRR or RR73 and 
resending the R-XX again has usually results in another RR73 or at times a 
regular RRR.  At times I've had to send R-XX numerous times to get a response 
as though the path had faded.
Note that for the last several months I'm running 2W so this seems to happen 
more than it did in the past where I don't see an RRR or 73 and, as such, I 
don't log them unless they show up on eQSL or QRZ.
de Mike W9MDB

  From: Bill Somerville 
 To: WSJT software development  
 Sent: Thursday, July 20, 2017 7:19 AM
 Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
   
Hi All,

we are looking at changing the WSJT-X logic such that a grid message of 
the form:

"  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 

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Erik -]

If I were Cqing, the way I operate JT65 with JTDX which has the option of RR73, 
is that I do assume my sending of RR73 is the end of the QSO unless I receive 
more from the QSO partner. So, I send RR73 and would expect 73 but, if nothing 
received, would start with another station that had previously called me or 
start CQ again. If in the next period I get the R-dB report again then, even if 
a new QSO could be started, I resolve to finish the original with another RR73 
and expect the 73. If nothing received again, I move on. 

Similarly, I were answering and didn't get the RR73 I would send my R+dB report 
again.


 Erik EI4KF.


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 20 July 2017 12:18
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

Hi All,

we are looking at changing the WSJT-X logic such that a grid message of the 
form:

"  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! 

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Dan Malcolm]

Bill,
I'm sure I'm not alone, but I require some acknowledgement of receipt of
signal report.  I'm not hard over about what that is, be it 73 or RR73.
Personally I like a 73 term from both stations but I think it's logical for
the original CQ station to terminate the QSO with RR73.  At that point call
signs, grids, and RST's have been exchanged and acknowledged.  Therefore
sending RR73 should be treated the same as sending 73.  That's fine for the
original CQ station, and his QSO partner who receives the RR73/73.  However,
the QSO partner who doesn't decode a RR73/73 is left hanging.  In my case, I
resend R+dB, and so should the software.  Waiting a decode cycle after
sending RR73/73 to ensure QSO completion seems like a good scenario.  If
either nothing or 73 is received from the answering CQ partner, the original
CQ station can assume the RR73/73 was received.  The same would be true if
the answering CQ stations call sign is spotted in another QSO or calling CQ.

That's my logic.  I hope it's clear.  In the end, the individual op is going
to have to pay attention and perhaps apply their own logic in any given
situation.

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Thursday, July 20, 2017 7:18 AM
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message

Hi All,

we are looking at changing the WSJT-X logic such that a grid message of the
form:

"  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 

[wsjt-devel] WSJT-X: How to handle using RR73 as a final message

[Bill Somerville]

Hi All,

we are looking at changing the WSJT-X logic such that a grid message of 
the form:


"  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

Re: [wsjt-devel] A non-technical reason to remove/relocate the audio slider

[Bruce]

Your right Bill, wasn't thinking straight, another senior moment.

73 DE VK2RT Bruce
Sent from my SAMSUNG Galaxy S7 edge on the Telstra Mobile Network
 Original message From: Bill Somerville  
Date: 20/7/17  8:20 pm  (GMT+10:00) To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] A non-technical reason to remove/relocate the
  audio slider 
On 20/07/2017 02:50, Bruce wrote:
> It would be more convienent if that slider actually did adjust the 
> audio level.

Hi Bruce,

how would you propose that a slider adjust the audio level?

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

Re: [wsjt-devel] A non-technical reason to remove/relocate the audio slider

[Bill Somerville]

On 20/07/2017 02:50, Bruce wrote:
It would be more convienent if that slider actually did adjust the 
audio level.


Hi Bruce,

how would you propose that a slider adjust the audio level?

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