Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
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 message
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 <g4...@classdesign.com> 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 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
Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
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 <g4...@classdesign.com> To: WSJT software development <wsjt-devel@lists.sourceforge.net> 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
Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
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 <wsjt-devel@lists.sourceforge.net> 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. -- Chec
Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final message
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 <wsjt-devel@lists.sourceforge.net> 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 scen
[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! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
