Re: [wsjt-devel] RRR as 73
Mike -- I'm not inclined to argue the point further. RRR means RRR, and 73 means 73. If both operators are happy then anything (or even nothing) will do after acknowledgment has been *received*. The program should not be making decisions about whether both operators are happy, or not. -- Joe, K1JT On 5/13/2015 12:56 PM, Michael Black wrote: > I thought I was asking for equal treatment...for the GUI (i.e the normal > path the user takes) to behave the same no matter which side of the QSO > you're on. > > Answer this one question: > > Is RRR an implied 73 or not? > > If it is then it should be treated in the GUI just like a 73 is. > > I take it you don't use the auto log feature? At worst we could make this > another option along the same lines as the 73 logging is an option now. > > My goal is to reduce mouse moves and clicks and have the same experience on > both sides of the conversation. > > Would you accept this as a separate option? As a separate option it would > help even more to each users about using RRR without the added 73. > > 73 > Mike W9MDB > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Wednesday, May 13, 2015 11:43 AM > To: WSJT software development > Subject: Re: [wsjt-devel] RRR as 73 > > Mike -- > >> But that only works if you are the receiver whereas the CQ'r is stuck >> manually doing these things after message#5. And yes, I know it's >> just two extra clicks and one extra mouse move but they are totally >> unnecessary if we just treat the two sides the same - equal >> representation and all that stuff donchya' know!! > > You're not asking for equal treatment. > > When G0XYZ sends "K1ABC G0XYZ 73" he knows that the QSO is complete. > > When K1ABC sends "G0XYZ K1ABC RRR" he knows only that he has all desired > information. He *hopes* that G0XYZ will receive his acknowledgment of same, > and then the QSO will be complete. > > > I'm sure you understand that the history and pedigree of WSJT(-X) lies in > the VHF-and-up world, especially for paths like meteor scatter and EME. For > good reasons, "ping jockeys" and "moonbouncers" tend to be rather fussy > about what constitutes a legitimate minimal QSO. By longstanding tradition, > a valid contact is taken to be one where both operators during the contact > have > > (1) mutually identified each other > > (2) received a report (or other information such as a locator), and > > (3) received a confirmation of the successful identification and the > reception of the report. > > It's understood that responsibility for the integrity of the contact always > lies with the operator. > > At HF, especially in contest of pile-up circumstances, I'm perfectly happy > to log QSOs of the following form (and similarly brief ones): > > CQ K1ABC > W9XYZ > W9XYZ 599 MA > 599 WI > TU K1ABC > > Signal strength, timing of transmissions, etc., can leave no reasonable > doubt in either operator's mind that the contact is complete. > > Again: responsibility for integrity of a contact (and if/when it gets > logged) lies with the operator. > > -- 73, Joe, K1JT > > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications Performance > metrics, stats and reports that give you Actionable Insights Deep dive > visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
I thought I was asking for equal treatment...for the GUI (i.e the normal path the user takes) to behave the same no matter which side of the QSO you're on. Answer this one question: Is RRR an implied 73 or not? If it is then it should be treated in the GUI just like a 73 is. I take it you don't use the auto log feature? At worst we could make this another option along the same lines as the 73 logging is an option now. My goal is to reduce mouse moves and clicks and have the same experience on both sides of the conversation. Would you accept this as a separate option? As a separate option it would help even more to each users about using RRR without the added 73. 73 Mike W9MDB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Wednesday, May 13, 2015 11:43 AM To: WSJT software development Subject: Re: [wsjt-devel] RRR as 73 Mike -- > But that only works if you are the receiver whereas the CQ'r is stuck > manually doing these things after message#5. And yes, I know it's > just two extra clicks and one extra mouse move but they are totally > unnecessary if we just treat the two sides the same - equal > representation and all that stuff donchya' know!! You're not asking for equal treatment. When G0XYZ sends "K1ABC G0XYZ 73" he knows that the QSO is complete. When K1ABC sends "G0XYZ K1ABC RRR" he knows only that he has all desired information. He *hopes* that G0XYZ will receive his acknowledgment of same, and then the QSO will be complete. I'm sure you understand that the history and pedigree of WSJT(-X) lies in the VHF-and-up world, especially for paths like meteor scatter and EME. For good reasons, "ping jockeys" and "moonbouncers" tend to be rather fussy about what constitutes a legitimate minimal QSO. By longstanding tradition, a valid contact is taken to be one where both operators during the contact have (1) mutually identified each other (2) received a report (or other information such as a locator), and (3) received a confirmation of the successful identification and the reception of the report. It's understood that responsibility for the integrity of the contact always lies with the operator. At HF, especially in contest of pile-up circumstances, I'm perfectly happy to log QSOs of the following form (and similarly brief ones): CQ K1ABC W9XYZ W9XYZ 599 MA 599 WI TU K1ABC Signal strength, timing of transmissions, etc., can leave no reasonable doubt in either operator's mind that the contact is complete. Again: responsibility for integrity of a contact (and if/when it gets logged) lies with the operator. -- 73, Joe, K1JT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
Mike -- > But that only works if you are the receiver whereas the CQ'r is stuck > manually doing these things after message#5. And yes, I know it's just two > extra clicks and one extra mouse move but they are totally unnecessary if we > just treat the two sides the same - equal representation and all that stuff > donchya' know!! You're not asking for equal treatment. When G0XYZ sends "K1ABC G0XYZ 73" he knows that the QSO is complete. When K1ABC sends "G0XYZ K1ABC RRR" he knows only that he has all desired information. He *hopes* that G0XYZ will receive his acknowledgment of same, and then the QSO will be complete. I'm sure you understand that the history and pedigree of WSJT(-X) lies in the VHF-and-up world, especially for paths like meteor scatter and EME. For good reasons, "ping jockeys" and "moonbouncers" tend to be rather fussy about what constitutes a legitimate minimal QSO. By longstanding tradition, a valid contact is taken to be one where both operators during the contact have (1) mutually identified each other (2) received a report (or other information such as a locator), and (3) received a confirmation of the successful identification and the reception of the report. It's understood that responsibility for the integrity of the contact always lies with the operator. At HF, especially in contest of pile-up circumstances, I'm perfectly happy to log QSOs of the following form (and similarly brief ones): CQ K1ABC W9XYZ W9XYZ 599 MA 599 WI TU K1ABC Signal strength, timing of transmissions, etc., can leave no reasonable doubt in either operator's mind that the contact is complete. Again: responsibility for integrity of a contact (and if/when it gets logged) lies with the operator. -- 73, Joe, K1JT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
According to the WSJT-X docs and previous discussions this is what I understand to be a standard exchange.taken from the docs. 0001 CQ K1ABC FN42 K1ABC calls CQ 0002 K1ABC G0XYZ IO91 G0XYZ answers 0003 G0XYZ K1ABC -19 K1ABC sends report 0004 K1ABC G0XYZ R-22 G0XYZ sends acknowledgment and report 0005 G0XYZ K1ABC RRR K1ABC sends acknowledgment 0006 K1ABC G0XYZ 73 G0XYZ sends 73 The way WSJT-X works now is if you are the one transmitting message#6 it can popup the log window and sets the last Std Msg as the next to transmit (i.e. CQ). But that only works if you are the receiver whereas the CQ'r is stuck manually doing these things after message#5. And yes, I know it's just two extra clicks and one extra mouse move but they are totally unnecessary if we just treat the two sides the same - equal representation and all that stuff donchya' know!! Either RRR means 73 or it doesn't. It is my understanding that there are a few pedantic hams who won't QSL unless they get a 73 (apparently says so on their QRZ page) but I'm not too worried about them.perhaps they just need to be informed. I don't see why WSJT-X behavior should be any different depending on which end of the QSO you are. You still get the 73 which acknowledges the RRR. If the sender doesn't give RRR then you send R-22 again. The concept, to me, is "at end of transmission display log window and set CQ as next" which is RRR for the sender. What I find (and maybe it's just me) is that when I switch back and forth between CQ and listening the different behavior has caused me to lose (i.e. forget) log entries since the window doesn't ALWAYS pop up. You can get too used to the log window prompting you which is what has happened to me after over 8000 QSOs using WSJT-X. Mike W9MDB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Wednesday, May 13, 2015 10:19 AM To: WSJT software development Subject: Re: [wsjt-devel] RRR as 73 Hi Mike, On 5/11/2015 11:14 AM, Michael Black wrote: > Since RRR is the 73 for the CQ side this is a simple patch that allows > RRR to act the same as 73 for getting the log pop up window and > advancing the Next button. > > Does this sound OK or are there other side effects? In the recommended sequence of standard messages for JT65-JT4-JT9 QSOs, I consider receipt of "RRR" from my QSO partner to be sufficient for logging the QSO. Your suggested patch goes one step further. You are suggesting that by *transmitting* "RRR" to your QSO partner you have completed a minimal QSO. What if your QSO partner fails to receive your "RRR" because of QSB, QRM, or whatever? You'll be calling CQ again, while he/she is still waiting for your "RRR". It's a busted QSO, or at least cause for significant confusion. You can (and should) make your own decision about when a QSO is complete and should be logged. WSJT-X can remind you to log a QSO, when you're clearly done; but it shouldn't make the decision for you, and certainly not prematurely. -- Joe, K1JT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list <mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
Hi Mike, On 5/11/2015 11:14 AM, Michael Black wrote: > Since RRR is the 73 for the CQ side this is a simple patch that allows RRR > to act the same as 73 for getting the log pop up window and advancing the > Next button. > > Does this sound OK or are there other side effects? In the recommended sequence of standard messages for JT65-JT4-JT9 QSOs, I consider receipt of "RRR" from my QSO partner to be sufficient for logging the QSO. Your suggested patch goes one step further. You are suggesting that by *transmitting* "RRR" to your QSO partner you have completed a minimal QSO. What if your QSO partner fails to receive your "RRR" because of QSB, QRM, or whatever? You'll be calling CQ again, while he/she is still waiting for your "RRR". It's a busted QSO, or at least cause for significant confusion. You can (and should) make your own decision about when a QSO is complete and should be logged. WSJT-X can remind you to log a QSO, when you're clearly done; but it shouldn't make the decision for you, and certainly not prematurely. -- Joe, K1JT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
Here's the exchange I see frequently which RR73 would most certainly curtail…. CQ W9MDB EM49 W9MDB OH3T KP11 OH3T W9MDB -04 W9MDB OH3T R-03 OH3T W9MDB RRR W9MDB OH35 73 OH3T W9MDB 73 – mind you I don't do this anymore once I found out RRR is 73-equivalent Wait a minute…. CQ W9MDB EM49 This is what I see others doing (not me anymore) because the RRR is not easily recognized as end of transmission unless you can glean that info from the help docs. I see all sort of ways done to shortcut it, RR73, R73, R 73, RR 73. It's too bad there is a technical reason to avoid doing the RR73. I've got over 8,000 JT modes in my log. Just a count of what's seen since Sep 2014 in my ALL.TXT RRR = 51809 RR73 = 4216 R73 = 201 R 73 = 168 73 Mike W9MDB From: Toni Sormunen [mailto:o...@sral.fi] Sent: Tuesday, May 12, 2015 1:54 AM To: WSJT software development; o...@sral.fi Subject: Re: [wsjt-devel] RRR as 73 Greetings! This is my first post to this developer list. I have been following this list for quite some time already. I have been active on JT modes for nearly 3 years now (HF exclusively) 2500+ JT mode QSOs in the log. Regarding this discussion on RRR & RR73 and speeding up the report exchange here are my 2 cents. I am sorry to say that the proposed RR73 does not speed up anything. It just adds a new dimension to message exchange. Please let me demonstrate my point. These are actual QSO examples from my logs. Standard QSO: 0443 Tx 2546 @ CQ OH3T KP11 0444 -4 -0.0 2547 @ OH3T UN7DA NO00 0445 Tx 2546 @ UN7DA OH3T -04 0446 -3 -0.0 2547 @ OH3T UN7DA R-03 0447 Tx 2546 @ UN7DA OH3T 73 0448 -12 0.0 2547 @ OH3T UN7DA 73 QSO with kind courtesy at the end: 2159 Tx 2546 @ CQ OH3T KP11 2200 -10 0.4 2542 @ OH3T DF9YW JO41 2201 Tx 2546 @ DF9YW OH3T -10 2202 -12 0.3 2542 @ OH3T DF9YW R-21 2203 Tx 2546 @ DF9YW OH3T 73 2204 -10 0.4 2543 @ TU TONI 73 QSO with RRR 73 (could be as well RR73) at the end: 0201 Tx 1497 # CQ OH3T KP11 0202 -18 -0.1 1494 # OH3T CO2YQ EL83 0203 Tx 1497 # CO2YQ OH3T -18 0204 -20 0.1 1494 # OH3T CO2YQ R-16 0205 Tx 1497 # CO2YQ OH3T 73 0206 -21 0.2 1495 # OH3T RRR 73 >From the examples above we can easily draw the conclusion that RR73 does not >change the standard QSO structure. It is still six (6) overs to complete >exchange of all information. Please notice, that I have omitted sending RRR >for quite some time already. RRR does not add, in my opinion, any value to the >QSO exchange. The only way to speed up the QSO is to remove some information from the exchange. Now we have to go to the very fundamental definition of the QSO. It is mandatory to 1. exchange calls, and 2. exchange report. This is generally accepted definition of the QSO. Locator, name, tx power, etc. is not needed. For QRP and weak signal work the locator is a valuable tool and I like the 6 over standard QSO structure. However, if a DX would like to speed up the QSO rate the following QSO structure of four (4) overs should be considered. This is especially valuable when DX calls CQ on one QRG and his customers are replying split. 0605 Tx 2561 @ CQ OH3T KP11 0606 13 0.1 2561 @ OH3T OH3NE +07 (*) 0607 Tx 2561 @ OH3NE OH3T R+13 0608 13 0.1 2561 @ OH3T OH3NE 73 0609 Tx 2561 @ CQ OH3T KP11 (*) some people send R+07 at this point, but I propose Tx2 instead of Tx3, because it lands more nicely to the structure. (If I get Tx3 I will still reply with Tx3 on my next over.) Here (time 0609) I have omitted sending 73. 73 is implicit in the next CQ. Otherwise I would have repeated sending the R+13 report.(This QSO exhange was constructed by me working me :) with remote connection to our club station OH3NE. That is why the reports are what they are.. Having confessed that, quite a few stations have worked me with this exact four over QSO mode already, and I have worked quite a few DX with this exact way (recent T6 activation for example). CU on the bands! 73s, Toni oh3t On Mon, May 11, 2015 at 11:12 PM, Guy G4DWV/4X1LT wrote: Michael Black writes: > > > Since RRR is the 73 for the CQ side this is a simple patch that allows RRR to act the same as 73 for getting the log pop up window and advancing the Next button. > Does this sound OK or are there other side effects? If RRR is the 73 for the CQ side, changing it to RR73 (as I have seen proposed elsewhere) would make that quite clear - in 6 months of almost exclusive JTx use, I never knew that as hams each end up sending separate 73 messages after the RRR. 73 de Guy G4DWV/4X1LT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics,
Re: [wsjt-devel] RRR as 73
Greetings! This is my first post to this developer list. I have been following this list for quite some time already. I have been active on JT modes for nearly 3 years now (HF exclusively) 2500+ JT mode QSOs in the log. Regarding this discussion on RRR & RR73 and speeding up the report exchange here are my 2 cents. I am sorry to say that the proposed RR73 does not speed up anything. It just adds a new dimension to message exchange. Please let me demonstrate my point. These are actual QSO examples from my logs. Standard QSO: 0443 Tx 2546 @ CQ OH3T KP11 0444 -4 -0.0 2547 @ OH3T UN7DA NO00 0445 Tx 2546 @ UN7DA OH3T -04 0446 -3 -0.0 2547 @ OH3T UN7DA R-03 0447 Tx 2546 @ UN7DA OH3T 73 0448 -12 0.0 2547 @ OH3T UN7DA 73 QSO with kind courtesy at the end: 2159 Tx 2546 @ CQ OH3T KP11 2200 -10 0.4 2542 @ OH3T DF9YW JO41 2201 Tx 2546 @ DF9YW OH3T -10 2202 -12 0.3 2542 @ OH3T DF9YW R-21 2203 Tx 2546 @ DF9YW OH3T 73 2204 -10 0.4 2543 @ TU TONI 73 QSO with RRR 73 (could be as well RR73) at the end: 0201 Tx 1497 # CQ OH3T KP11 0202 -18 -0.1 1494 # OH3T CO2YQ EL83 0203 Tx 1497 # CO2YQ OH3T -18 0204 -20 0.1 1494 # OH3T CO2YQ R-16 0205 Tx 1497 # CO2YQ OH3T 73 0206 -21 0.2 1495 # OH3T RRR 73 >From the examples above we can easily draw the conclusion that RR73 does not change the standard QSO structure. It is still six (6) overs to complete exchange of all information. Please notice, that I have omitted sending RRR for quite some time already. RRR does not add, in my opinion, any value to the QSO exchange. The only way to speed up the QSO is to remove some information from the exchange. Now we have to go to the very fundamental definition of the QSO. It is mandatory to 1. exchange calls, and 2. exchange report. This is generally accepted definition of the QSO. Locator, name, tx power, etc. is not needed. For QRP and weak signal work the locator is a valuable tool and I like the 6 over standard QSO structure. However, if a DX would like to speed up the QSO rate the following QSO structure of four (4) overs should be considered. This is especially valuable when DX calls CQ on one QRG and his customers are replying split. 0605 Tx 2561 @ CQ OH3T KP11 0606 13 0.1 2561 @ OH3T OH3NE +07 (*) 0607 Tx 2561 @ OH3NE OH3T R+13 0608 13 0.1 2561 @ OH3T OH3NE 73 0609 Tx 2561 @ CQ OH3T KP11 (*) some people send R+07 at this point, but I propose Tx2 instead of Tx3, because it lands more nicely to the structure. (If I get Tx3 I will still reply with Tx3 on my next over.) Here (time 0609) I have omitted sending 73. 73 is implicit in the next CQ. Otherwise I would have repeated sending the R+13 report.(This QSO exhange was constructed by me working me :) with remote connection to our club station OH3NE. That is why the reports are what they are.. Having confessed that, quite a few stations have worked me with this exact four over QSO mode already, and I have worked quite a few DX with this exact way (recent T6 activation for example). CU on the bands! 73s, Toni oh3t On Mon, May 11, 2015 at 11:12 PM, Guy G4DWV/4X1LT wrote: > Michael Black writes: > > > > > > > Since RRR is the 73 for the CQ side this is a simple patch that allows > RRR > to act the same as 73 for getting the log pop up window and advancing the > Next button. > > Does this sound OK or are there other side effects? > > If RRR is the 73 for the CQ side, changing it to RR73 (as I have seen > proposed elsewhere) would make that quite clear - in 6 months of almost > exclusive JTx use, I never knew that as hams each end up sending separate > 73 > messages after the RRR. > > 73 de Guy G4DWV/4X1LT > > > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
I also did a patch for RR73 as a standard message but it was pretty much disapproved for technical reasons and apparently has been discussed before. RRR is one of the special short code single tones so changing that is not good for weak/QSB situations. 'tis true if you read the help it shows you (without explicitly stating so) that the CQ partner need not send a 73, just RRR. But seeing all the RR73's flying by the last few days and the unneeded 73's it's pretty obvious that there are a lot that didn't read the docs (like me) and just assume double 73's was the norm like all other protocols. Mike W9MDB -Original Message- From: Guy G4DWV/4X1LT [mailto:g...@drteeth.co.uk] Sent: Monday, May 11, 2015 3:12 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] RRR as 73 Michael Black writes: > > > Since RRR is the 73 for the CQ side this is a simple patch that allows > RRR to act the same as 73 for getting the log pop up window and advancing the Next button. > Does this sound OK or are there other side effects? If RRR is the 73 for the CQ side, changing it to RR73 (as I have seen proposed elsewhere) would make that quite clear - in 6 months of almost exclusive JTx use, I never knew that as hams each end up sending separate 73 messages after the RRR. 73 de Guy G4DWV/4X1LT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR as 73
Michael Black writes: > > > Since RRR is the 73 for the CQ side this is a simple patch that allows RRR to act the same as 73 for getting the log pop up window and advancing the Next button. > Does this sound OK or are there other side effects? If RRR is the 73 for the CQ side, changing it to RR73 (as I have seen proposed elsewhere) would make that quite clear - in 6 months of almost exclusive JTx use, I never knew that as hams each end up sending separate 73 messages after the RRR. 73 de Guy G4DWV/4X1LT -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
