Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
Wikipedia describes the problem of when to log a QSO as the "Two Generals’ Problem”. Here is part of the entry: In computing, the Two Generals' Problem is a thought experiment meant to illustrate the pitfalls and design challenges of attempting to coordinate an action by communicating over an unreliable link. In the experiment, two generals are only able to communicate with one another by sending a messenger through enemy territory. The experiment asks how they might reach an agreement on the time to launch an attack, while knowing that any messenger they send could be captured. It is related to the more general Byzantine Generals Problem and appears often in introductory classes about computer networking (particularly with regard to the Transmission Control Protocol, where it shows that TCP can't guarantee state consistency between endpoints and why this is the case), though it applies to any type of two-party communication where failures of communication are possible. A key concept in epistemic logic, this problem highlights the importance of common knowledge. Some authors also refer to this as the Two Generals' Paradox, the Two Armies Problem, or the Coordinated Attack Problem.[1][2] The Two Generals' Problem was the first computer communication problem to be proved to be unsolvable. An important consequence of this proof is that generalizations like the Byzantine Generals problem are also unsolvable in the face of arbitrary communication failures, thus providing a base of realistic expectations for any distributed consistency protocols. The problem is illustrated by the scenario: Two armies, each led by a different general, are preparing to attack a fortified city. The armies are encamped near the city, each in its own valley. A third valley separates the two hills, and the only way for the two generals to communicate is by sending messengers through the valley. Unfortunately, the valley is occupied by the city's defenders and there's a chance that any given messenger sent through the valley will be captured. While the two generals have agreed that they will attack, they haven't agreed upon a time for an attack. It is required that the two generals have their armies attack the city simultaneously to succeed, lest the lone attacker army die trying. They must thus communicate with each other to decide on a time to attack and to agree to attack at that time, and each general must know that the other general knows that they have agreed to the attack plan. Because acknowledgement of message receipt can be lost as easily as the original message, a potentially infinite series of messages is required to come to consensus. The thought experiment involves considering how they might go about coming to a consensus. In its simplest form, one general is known to be the leader, decides on the time of the attack, and must communicate this time to the other general. The problem is to come up with algorithms that the generals can use, including sending messages and processing received messages, that can allow them to correctly conclude: Yes, we will both attack at the agreed-upon time. Allowing that it is quite simple for the generals to come to an agreement on the time to attack (i.e. one successful message with a successful acknowledgement), the subtlety of the Two Generals' Problem is in the impossibility of designing algorithms for the generals to use to safely agree to the above statement. Illustrating the problem The first general may start by sending a message "Attack at 0900 on August 4." However, once dispatched, the first general has no idea whether or not the messenger got through. This uncertainty may lead the first general to hesitate to attack due to the risk of being the sole attacker. To be sure, the second general may send a confirmation back to the first: "I received your message and will attack at 0900 on August 4." However, the messenger carrying the confirmation could face capture and the second general may hesitate, knowing that the first might hold back without the confirmation. Further confirmations may seem like a solution—let the first general send a second confirmation: "I received your confirmation of the planned attack at 0900 on August 4." However, this new messenger from the first general is liable to be captured, too. Thus it quickly becomes evident that no matter how many rounds of confirmation are made, there is no way to guarantee the second requirement that each general is sure the other has agreed to the attack plan. Both generals will always be left wondering whether their last messenger got through. The same situation occurs with FT8, no matter how may RR73 messages you send. My take on it is: If I send a RR73 I log the contact. If I receive a RR73, I’ll send a RR73 and log the contact. For DXing, this is sufficient. The worst that happens is I log a contact that the other end hasn’t logged. LotW will sort i
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
I am not sure I understand this statement: “Hams have to do what the software dictates in it's design to get a qso logged. ” The software doesn’t determine what gets logged, the control operator makes that call. Don’t mistake the convenience feature of the logging box popping up for a replacement for the control operator’s requirements. Jim S. N2ADV > On Jul 15, 2022, at 10:11 AM, Neil Zampella via wsjt-devel > wrote: > > Hams have to do what the software dictates in it's design to get a qso logged. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
I run with “prompt before logging” turned on so have no problem with a log trigger on RR73 or 73 - the prompt allows me to decide when, if and what, gets logged when it is triggered. I can see, however, the disadvantage/s of auto-logging after only a RR73 when running with the prompt off. A reasonable compromise might be to have auto-log without the prompt trigger only on 73 and, if the prompt is on, RR73 or 73 like it is now. Al Pawlowski Los Osos, CA USA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
Most issues are with strong nearby stations , The station having issue to get through, should move tx to any vacant pan space on the fly, and the rx station should stop and wait. Quite often stopping enables better rx, than cycling while waiting. 73 Adrian /The /|/RR73/|/ message should be used only if you are reasonably confident that no repetitions will be required./ *Please note the last sentence* 73 and have fun – Franz – OE3FVU ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
I received several eQSL QSL rejections too for same reason. Regards, --- 73 de Marco, PY1ZRJ (former IK5BCU) Il 15/07/22 10:29, Adrian via wsjt-devel ha scritto: They should do, the ones i queried via eqsl rejections said they did not receive my RR73, and then moved on to another station. Bad op practice by them , I agree, instead of trying or perhaps they did with no luck on RX, but sometimes a cheap txcr with poor blocking gets smothered by closed in strong signals and they lose the contact. In the meantime i have them in my log, but I am not in theirs. If theirs logged when they send the 73 and mine logs when i receive it, then we both have each other in the log or have enough to confirm the qso in ALL.txt via confirm sig reports on both sides. 73 vk4tux On 15/7/22 23:14, Larry Banks via wsjt-devel wrote: If they don't get your RR73, then they will send back their R-#. IF you get nothing back they got your R73 and are playing by the rules. Larry / W1DYJ ___ 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] WSJT-X close the QSO unilaterally (?)
Il 15/07/22 05:03, Fred Price via wsjt-devel ha scritto: When sending RR73 the other station doesn't have to reply with a 73. The reason is that the QSO is over at RR73. A lot of stations take as much and move on. If you'd like your 73 just change the RR73 to RRR by double clicking Tx 4. Doing it this way it will not log until you receive the 73. This also might be a good idea as you stated you have a little station. Another thing you could do is to check Prompt me to log QSO on the Reporting tab. This pops up a box and it stays there until you feel the QSO is sufficient to log even if you send RR73. Of course this doesn't work if you are in a contest mode and you have Log automatically checked. Fred N2XK Very good point Fred! I will switch my Tx4 to defaulting in RRR instead of RR73, may be in this way I will collect less QSO dupes. As well your second hint regarding when to click on log QSO, is very useful. Best regards, --- 73 de Marco, PY1ZRJ (former IK5BCU) On Jul 14, 2022 11:24 PM, Adrian via wsjt-devel wrote: It is a good point, wsjtx should not auto log until the 73 is received, not RR73 sent. Case in point is the rejected eqsl's from stations in my log, but I am not in theirs. This would save that problem. In the meantime, in those situation's, my TX is set free to change, and I click a vacant column on pan to better my chances of finishing the qso. Many stations don't bother with the 73 because of this shortfall. 73 vk4tux On 15/7/22 13:10, Marco Calistri via wsjt-devel wrote: Il 14/07/22 23:18, jarmo ha scritto: Thu, 14 Jul 2022 23:02:32 -0300 Marco Calistri via wsjt-devel kirjoitti: Hello, This occurrence causes that WSJT-X logging the QSO then I go to hit "OK" and QSO is getting saved on my CQRLOG app. (I'm using Linux). I'm using also, now question, why you hit OK, if qso is not complete? I hit again opposite stations report to give again RR73, some cases move couple Hz TX and hit again RR73. Normally I do this max 5 times and then hit CANCEL. Can't log unfinished qso. Good point! Yes probably I just have to discard the logged QSO offered by WSJT-X in cases like this one and click OK only when QSO get really completed. The fact is that as soon as WSJT-X sends the RR73 to the partner then from a WSJT-X point of view the QSO is complete! Normally this means, that someone qrm'ing so much, that opposite station can't hear anymore me. But I would like to know if I could adjust something into WSJT-X settings, to avoid closing QSO's "unilaterally". This could ba, as sending that RR73 so long yuo get /# or if not you cancel qso.. Jarmo, oh1mrr Thanks Jarmo for your comments. I believed that this process (logging QSO) would be totally managed by WSJT-X, without any human intervention. Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Regards, --- 73 de Marco, PY1ZRJ (former IK5BCU) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sour
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
Hi Adrian, Yes your suggestion I think that will resolve once for all this QSO logging issue. But may be its easy to tell about and less easy to add the feature in the code, I don't know. Best regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* **Il 15/07/22 02:29, Adrian ha scritto: When you send a RR73 and get nothing back, then wsjtx has logged the call, but you don't know if your RR73 was received, or if the other party logged you. Making the log work only on 73 sent or received instead of RR73, confirms the sig report both ways and the qso both ways. if the program worked this way the everyone would send the 73 to get in and be logged. Why is using 73 to trigger a log entry sent/received a problem ? Send RR73 and program logs on received 73. Receive RR73 and program logs on sent 73. vk4tux On 15/7/22 15:12, Reino Talarmo via wsjt-devel wrote: >Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19 #K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 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] WSJT-X close the QSO unilaterally (?)
Il 15/07/22 02:12, Reino Talarmo ha scritto: >Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19 #K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 73, Reino OH3mA Yes Reino, WSJT-X dialog sequence is clear and it performs like you explained here, however often my WSJT-X sends RR73 to the remote station and opens up the LOG QSO window for me to click on its OK label. Unluckily due a series of reasons, if the remote station has not received back my RR73 then it sends again the latest sequence to me and in this case some times I manually hit again on my RR73 sequence to confirm the QSO to the remote station. This scenario is causing from time to time I collecting dupes QSOs in my CQRLOG which I need to delete manually. Regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* **___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
RR73 works just fine if both stations are hearing each other well. If not, it can create problems. I use FT8 almost exclusively on 2 meters. To work stations 400 miles away can be very difficult, and my setup is pretty good. I may be in FT8 qso with a station amid meteor pings and deep qsb. In a difficult qso, it may take ten minutes to complete such a qso, waiting for qsb to peak to get a decode. So, if a station hears my signal report and responds with RR73 and then moves on, it is likely thatI did not hear him. In general, stations working on the band use RRR and not RR73, just for this reason. They wait for the 73 to confirm completion of the qso. It's not unusual for a new station to turn up on the band and use RR73. If they are too weak, I am stuck sending them a signal report until they realize I never got their RR73 or one of us gives up. Running weak signal on vhf can be challenging, but the use of RR73 often makes it more difficult than it needs to be. And this discussion leads me to believe it can make things more difficult on hf too. 73,Andy, ka2uqw On Friday, July 15, 2022 at 09:20:51 AM EDT, Larry Banks via wsjt-devel wrote: If they don't get your RR73, then they will send back their R-#. IF you get nothing back they got your R73 and are playing by the rules. Larry / W1DYJ On 7/15/2022 1:29, Adrian via wsjt-devel wrote: When you send a RR73 and get nothing back, then wsjtx has logged the call, but you don't know if your RR73 was received, or if the other party logged you. Making the log work only on 73 sent or received instead of RR73, confirms the sig report both ways and the qso both ways. if the program worked this way the everyone would send the 73 to get in and be logged. Why is using 73 to trigger a log entry sent/received a problem ? Send RR73 and program logs on received 73. Receive RR73 and program logs on sent 73. vk4tux On 15/7/22 15:12, Reino Talarmo via wsjt-devel wrote: >Hopefully, in an ideal world, it should be that WSJT-X waits for a second >RR73 (hypothetical answer confirmation sequence I mean) from the remote >station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19 #K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 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 ___ 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] WSJT-X close the QSO unilaterally (?)
Yes ... take out the RR73 option double click on the Tx4 button and you switch to RRR ... then turn on the "PROMPT ME TO LOG QSO" option in Settings -> Reporting tab. You'll never get a 'autologged' QSO again as you have to manually OK what is being logged. Problem Solved. Neil, KN3ILZ On 7/15/2022 6:10 AM, Adrian wrote: The problem with that approach combining RR(received report) and 73 is 'did the other station know that you received their report' ? The return 73 says they did. Hams have to do what the software dictates in it's design to get a qso logged. Maybe take out the RR73 option so at one side has to send a 73 after both reports are sent and hence confirmed. As I said, i see a lot of this issue on eqsl, but will not lose any sleep over it. It is a suggestion for above reasons. When you move up from a toyset; 7300/811 to a FTDX101MP/SPE you work many more stations. I am on nearly 24/7. vk4tux On 15/7/22 20:29, Fred Price via wsjt-devel wrote: Maybe I replied to the wrong person, sorry. However that last 73 is not needed RR73 the QSO is over. Case in point, on SSB how many DX stations send a 73 back to you? None that I've ever worked. I say 73 and the DX calls QRZed not 73. Do I log it? absolutely. Too many using FT8 think you need that 73 for the QSO to be valid. I know ops who say: No grid no work No 73 no log Which is just being silly. However with all that said, it's up to the individual ops to what they work and when they log, but to me the software does exactly what it should do. Have a good evening. Fred N2XK On Jul 15, 2022 6:04 AM, Adrian via wsjt-devel wrote: On 15/7/22 18:03, Fred Price wrote: > This also might be a good idea as you stated you have a little station. Can you point out where I stated what you claim above ? My method of using FT8 is fine & effective, and I have method for repeat RR calls. My point is that the final 73 comes after both stations acknowledge the other parties signal report, and a final 73 lets the other party know that is the case. .. vk4tux ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
They should do, the ones i queried via eqsl rejections said they did not receive my RR73, and then moved on to another station. Bad op practice by them , I agree, instead of trying or perhaps they did with no luck on RX, but sometimes a cheap txcr with poor blocking gets smothered by closed in strong signals and they lose the contact. In the meantime i have them in my log, but I am not in theirs. If theirs logged when they send the 73 and mine logs when i receive it, then we both have each other in the log or have enough to confirm the qso in ALL.txt via confirm sig reports on both sides. 73 vk4tux On 15/7/22 23:14, Larry Banks via wsjt-devel wrote: If they don't get your RR73, then they will send back their R-#. IF you get nothing back they got your R73 and are playing by the rules. Larry / W1DYJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
If they don't get your RR73, then they will send back their R-#. IF you get nothing back they got your R73 and are playing by the rules. Larry / W1DYJ On 7/15/2022 1:29, Adrian via wsjt-devel wrote: When you send a RR73 and get nothing back, then wsjtx has logged the call, but you don't know if your RR73 was received, or if the other party logged you. Making the log work only on 73 sent or received instead of RR73, confirms the sig report both ways and the qso both ways. if the program worked this way the everyone would send the 73 to get in and be logged. Why is using 73 to trigger a log entry sent/received a problem ? Send RR73 and program logs on received 73. Receive RR73 and program logs on sent 73. vk4tux On 15/7/22 15:12, Reino Talarmo via wsjt-devel wrote: >Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19 #K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
That may have been a flyover comment for you, but in anycase it get the ones that you don't hear and really want using 0.12uV sensitivity. Have worked an amazing amount of DXpeditions in the last 2 months, it has been great. Yaesu got it right. 73 vk4tux Wow, I would hope a $5K radio isn't required to work more stations, I do just fine with an IC-7100 and a QRPlabs QDX. 8*) 73, Willie N1JBJ ___ 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] WSJT-X close the QSO unilaterally (?)
> On Jul 15, 2022, at 7:10 AM, Adrian via wsjt-devel > wrote: > > The problem with that approach combining RR(received report) and 73 is 'did > the other station know that you received their report' ? https://en.wikipedia.org/wiki/Two_Generals%27_Problem > When you move up from a toyset; 7300/811 to a FTDX101MP/SPE you work many > more stations. Wow, I would hope a $5K radio isn't required to work more stations, I do just fine with an IC-7100 and a QRPlabs QDX. 8*) 73, Willie N1JBJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
The problem with that approach combining RR(received report) and 73 is 'did the other station know that you received their report' ? The return 73 says they did. Hams have to do what the software dictates in it's design to get a qso logged. Maybe take out the RR73 option so at one side has to send a 73 after both reports are sent and hence confirmed. As I said, i see a lot of this issue on eqsl, but will not lose any sleep over it. It is a suggestion for above reasons. When you move up from a toyset; 7300/811 to a FTDX101MP/SPE you work many more stations. I am on nearly 24/7. vk4tux On 15/7/22 20:29, Fred Price via wsjt-devel wrote: Maybe I replied to the wrong person, sorry. However that last 73 is not needed RR73 the QSO is over. Case in point, on SSB how many DX stations send a 73 back to you? None that I've ever worked. I say 73 and the DX calls QRZed not 73. Do I log it? absolutely. Too many using FT8 think you need that 73 for the QSO to be valid. I know ops who say: No grid no work No 73 no log Which is just being silly. However with all that said, it's up to the individual ops to what they work and when they log, but to me the software does exactly what it should do. Have a good evening. Fred N2XK On Jul 15, 2022 6:04 AM, Adrian via wsjt-devel wrote: On 15/7/22 18:03, Fred Price wrote: > This also might be a good idea as you stated you have a little station. Can you point out where I stated what you claim above ? My method of using FT8 is fine & effective, and I have method for repeat RR calls. My point is that the final 73 comes after both stations acknowledge the other parties signal report, and a final 73 lets the other party know that is the case. .. vk4tux ___ 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___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
Maybe I replied to the wrong person, sorry.However that last 73 is not needed RR73 the QSO is over. Case in point, on SSB how many DX stations send a 73 back to you? None that I've ever worked. I say 73 and the DX calls QRZed not 73. Do I log it? absolutely. Too many using FT8 think you need that 73 for the QSO to be valid.I know ops who say:No grid no workNo 73 no logWhich is just being silly.However with all that said, it's up to the individual ops to what they work and when they log, but to me the software does exactly what it should do.Have a good evening.FredN2XK On Jul 15, 2022 6:04 AM, Adrian via wsjt-devel wrote: On 15/7/22 18:03, Fred Price wrote: > This also might be a good idea as you stated you have a little station. Can you point out where I stated what you claim above ? My method of using FT8 is fine & effective, and I have method for repeat RR calls. My point is that the final 73 comes after both stations acknowledge the other parties signal report, and a final 73 lets the other party know that is the case. .. vk4tux ___ 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] WSJT-X close the QSO unilaterally (?)
On 15/7/22 18:03, Fred Price wrote: This also might be a good idea as you stated you have a little station. Can you point out where I stated what you claim above ? My method of using FT8 is fine & effective, and I have method for repeat RR calls. My point is that the final 73 comes after both stations acknowledge the other parties signal report, and a final 73 lets the other party know that is the case. .. vk4tux ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
When sending RR73 the other station doesn't have to reply with a 73. The reason is that the QSO is over at RR73. A lot of stations take as much and move on.If you'd like your 73 just change the RR73 to RRR by double clicking Tx 4. Doing it this way it will not log until you receive the 73. This also might be a good idea as you stated you have a little station. Another thing you could do is to check Prompt me to log QSO on the Reporting tab. This pops up a box and it stays there until you feel the QSO is sufficient to log even if you send RR73. Of course this doesn't work if you are in a contest mode and you have Log automatically checked.FredN2XK On Jul 14, 2022 11:24 PM, Adrian via wsjt-devel wrote: It is a good point, wsjtx should not auto log until the 73 is received, not RR73 sent. Case in point is the rejected eqsl's from stations in my log, but I am not in theirs. This would save that problem. In the meantime, in those situation's, my TX is set free to change, and I click a vacant column on pan to better my chances of finishing the qso. Many stations don't bother with the 73 because of this shortfall. 73 vk4tux On 15/7/22 13:10, Marco Calistri via wsjt-devel wrote: Il 14/07/22 23:18, jarmo ha scritto: Thu, 14 Jul 2022 23:02:32 -0300 Marco Calistri via wsjt-devel kirjoitti: Hello, This occurrence causes that WSJT-X logging the QSO then I go to hit "OK" and QSO is getting saved on my CQRLOG app. (I'm using Linux). I'm using also, now question, why you hit OK, if qso is not complete? I hit again opposite stations report to give again RR73, some cases move couple Hz TX and hit again RR73. Normally I do this max 5 times and then hit CANCEL. Can't log unfinished qso. Good point! Yes probably I just have to discard the logged QSO offered by WSJT-X in cases like this one and click OK only when QSO get really completed. The fact is that as soon as WSJT-X sends the RR73 to the partner then from a WSJT-X point of view the QSO is complete! Normally this means, that someone qrm'ing so much, that opposite station can't hear anymore me. But I would like to know if I could adjust something into WSJT-X settings, to avoid closing QSO's "unilaterally". This could ba, as sending that RR73 so long yuo get /# or if not you cancel qso.. Jarmo, oh1mrr Thanks Jarmo for your comments. I believed that this process (logging QSO) would be totally managed by WSJT-X, without any human intervention. Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Regards, --- 73 de Marco, PY1ZRJ (former IK5BCU) ___ 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] WSJT-X close the QSO unilaterally (?)
When you send a RR73 and get nothing back, then wsjtx has logged the call, but you don't know if your RR73 was received, or if the other party logged you. Making the log work only on 73 sent or received instead of RR73, confirms the sig report both ways and the qso both ways. if the program worked this way the everyone would send the 73 to get in and be logged. Why is using 73 to trigger a log entry sent/received a problem ? Send RR73 and program logs on received 73. Receive RR73 and program logs on sent 73. vk4tux On 15/7/22 15:12, Reino Talarmo via wsjt-devel wrote: >Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19 #K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 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] WSJT-X close the QSO unilaterally (?)
>Hopefully, in an ideal world, it should be that WSJT-X waits for a second >RR73 (hypothetical answer confirmation sequence I mean) from the remote >station, before to definitely close and log the QSO. Hi Marco, I am not sure what you mean by the “second RR73”. There seems to be a generic misunderstanding how the protocol is assumed to work. User Guide sections 7.1. and 7.4. provide a nice advice. For a minimum QSO, where locator information is exchanged: CQ K1ABC FN42 #K1ABC calls CQ K1ABC G0XYZ IO91 #G0XYZ answers G0XYZ K1ABC –19#K1ABC sends report K1ABC G0XYZ R-22 #G0XYZ sends R+report G0XYZ K1ABC RR73 #K1ABC sends RR73 K1ABC G0XYZ 73 #G0XYZ sends 73 The last message (73) is optional. Relevant issue is that in none of the examples a station that receives RR73 is sending back RR73, but 73 or nothing more for that call. 73, Reino OH3mA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
It is a good point, wsjtx should not auto log until the 73 is received, not RR73 sent. Case in point is the rejected eqsl's from stations in my log, but I am not in theirs. This would save that problem. In the meantime, in those situation's, my TX is set free to change, and I click a vacant column on pan to better my chances of finishing the qso. Many stations don't bother with the 73 because of this shortfall. 73 vk4tux On 15/7/22 13:10, Marco Calistri via wsjt-devel wrote: Il 14/07/22 23:18, jarmo ha scritto: Thu, 14 Jul 2022 23:02:32 -0300 Marco Calistri via wsjt-devel kirjoitti: Hello, This occurrence causes that WSJT-X logging the QSO then I go to hit "OK" and QSO is getting saved on my CQRLOG app. (I'm using Linux). I'm using also, now question, why you hit OK, if qso is not complete? I hit again opposite stations report to give again RR73, some cases move couple Hz TX and hit again RR73. Normally I do this max 5 times and then hit CANCEL. Can't log unfinished qso. Good point! Yes probably I just have to discard the logged QSO offered by WSJT-X in cases like this one and click OK only when QSO get really completed. The fact is that as soon as WSJT-X sends the RR73 to the partner then from a WSJT-X point of view the QSO is complete! Normally this means, that someone qrm'ing so much, that opposite station can't hear anymore me. But I would like to know if I could adjust something into WSJT-X settings, to avoid closing QSO's "unilaterally". This could ba, as sending that RR73 so long yuo get /# or if not you cancel qso.. Jarmo, oh1mrr Thanks Jarmo for your comments. I believed that this process (logging QSO) would be totally managed by WSJT-X, without any human intervention. Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* ** ___ 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] WSJT-X close the QSO unilaterally (?)
Il 14/07/22 23:18, jarmo ha scritto: Thu, 14 Jul 2022 23:02:32 -0300 Marco Calistri via wsjt-devel kirjoitti: Hello, This occurrence causes that WSJT-X logging the QSO then I go to hit "OK" and QSO is getting saved on my CQRLOG app. (I'm using Linux). I'm using also, now question, why you hit OK, if qso is not complete? I hit again opposite stations report to give again RR73, some cases move couple Hz TX and hit again RR73. Normally I do this max 5 times and then hit CANCEL. Can't log unfinished qso. Good point! Yes probably I just have to discard the logged QSO offered by WSJT-X in cases like this one and click OK only when QSO get really completed. The fact is that as soon as WSJT-X sends the RR73 to the partner then from a WSJT-X point of view the QSO is complete! Normally this means, that someone qrm'ing so much, that opposite station can't hear anymore me. But I would like to know if I could adjust something into WSJT-X settings, to avoid closing QSO's "unilaterally". This could ba, as sending that RR73 so long yuo get /# or if not you cancel qso.. Jarmo, oh1mrr Thanks Jarmo for your comments. I believed that this process (logging QSO) would be totally managed by WSJT-X, without any human intervention. Hopefully, in an ideal world, it should be that WSJT-X waits for a second RR73 (hypothetical answer confirmation sequence I mean) from the remote station, before to definitely close and log the QSO. Regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* **___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X close the QSO unilaterally (?)
Thu, 14 Jul 2022 23:02:32 -0300 Marco Calistri via wsjt-devel kirjoitti: > Hello, > This occurrence causes that WSJT-X logging the QSO then I go to hit > "OK" and QSO is getting saved on my CQRLOG app. > > (I'm using Linux). I'm using also, now question, why you hit OK, if qso is not complete? I hit again opposite stations report to give again RR73, some cases move couple Hz TX and hit again RR73. Normally I do this max 5 times and then hit CANCEL. Can't log unfinished qso. Normally this means, that someone qrm'ing so much, that opposite station can't hear anymore me. > But I would like to know if I could adjust something into WSJT-X > settings, to avoid closing QSO's "unilaterally". This could ba, as sending that RR73 so long yuo get /# or if not you cancel qso.. Jarmo, oh1mrr ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X close the QSO unilaterally (?)
Hello, I've collected several use-cases wherein my WSJT-X sends the RR73 to the other station which keeps to send back the RST to me. This occurrence causes that WSJT-X logging the QSO then I go to hit "OK" and QSO is getting saved on my CQRLOG app. (I'm using Linux). Would like to know what could be the issue causing this, I suppose it could be due my setup not so powerful and due to the partner unable to decode me completely. But I would like to know if I could adjust something into WSJT-X settings, to avoid closing QSO's "unilaterally". Thanks and best regards, --- 73 de Marco, PY1ZRJ (former IK5BCU) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
