How to Make Wsjtx Altomaticly Call Cq Again After a Contact




No one has replied to my state of affairs, where I am calling CQ in FT8, someone replies, I ship xxxxxxx AD4TJ -nineteen, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should ship xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is non selected. I do have Disable Tx afterwards sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I accept to quickly select TX5 and click on Enable TX.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ




   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, simply instead it but quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is non selected. I practise have Disable Tx later sending 73 checked, just the 73 is not sent. Information technology is disabling TX BEFORE the 73 is sent. I have to chop-chop select TX5 and click on Enable TX. Simply happens when I call CQ; replying to others CQing is not a problem.

This is v2.iv.0-rc3.

No ane else is seeing this?

David AD4TJ



Lamentable if y'all run across this multiple times; I have not seen information technology once in my inbox.

   No i has replied to my situation, where I am calling CQ in FT8, someone replies, I ship xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx later on sending 73 checked, only the 73 is non sent. It is disabling TX BEFORE the 73 is sent. I have to speedily select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is non a trouble.

This is v2.4.0-rc3.

No ane else is seeing this?

David AD4TJ


Neb Somerville


On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-x, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; information technology prompts me to log the Q, but doesn't ship the concluding 73.  RR73 is non selected. I do have Disable Tx after sending 73 checked, but the 73 is non sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX.

This is v2.four.0-rc3.

No 1 else is seeing this?

David AD4TJ

David,

what is the purpose of the actress 73 message yous wish top send?

73
Pecker
G4WJS.


Larry Banks


Hi David,

There is no reason to send the second "73" as you have already sent your "RRR" signifying that y'all acknowledge the QSO.  Therefore the system doesn't send it.

toggle quoted bulletinShow quoted text

Sent: Tuesday, March 23, 2022 9:06

Bailiwick: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73

   No one has replied to my state of affairs, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is non selected. I practice take Disable Tx after sending 73 checked, but the 73 is non sent. Information technology is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Merely happens when I phone call CQ; replying to others CQing is not a problem.

This is v2.four.0-rc3.

No ane else is seeing this?

David AD4TJ




I believe this is how it is supposed to work. You ship RRR, he sends 73; QSO done! That'south how it works for me.

Pecker K1NS

Sent from my T-Mobile 5G Device

Sent from my T-Mobile 5G Device

toggle quoted messageShow quoted text

-------- Original message --------

From: "David AD4TJ via groups.io" <ad4tj@...>

Engagement: 3/23/21 9:36 AM (GMT-05:00)

To: "WSTJ-X Groups.IO" <wsjtx@groups.io>

Field of study: [WSJTX] #FT8 CQing Refuses to Transport 73 After Receiving 73

Sorry if y'all see this multiple times; I take not seen it once in my inbox.

   No 1 has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I ship xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead information technology only quits; it prompts me to log the Q, but doesn't transport the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, simply the 73 is not sent. Information technology is disabling TX BEFORE the 73 is sent. I accept to rapidly select TX5 and click on Enable TX. But happens when I call CQ; replying to others CQing is not a trouble.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ



Larry and David,
Y'all tin also modify the RRR to RR73.
Then did I !
73, Karl OE3JAG

Am 23.03.21, xv:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:

toggle quoted messageShow quoted text

Hello David,

There is no reason to ship the 2d "73" equally you accept already sent your "RRR" signifying that y'all acknowledge the QSO.  Therefore the organisation doesn't send it.

Sent: Tuesday, March 23, 2022 nine:06

Bailiwick: [WSJTX] #FT8 CQing Refuses to Ship 73 Later Receiving 73

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, simply doesn't send the last 73.  RR73 is non selected. I do have Disable Tx after sending 73 checked, but the 73 is non sent. It is disabling TX Earlier the 73 is sent. I accept to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a trouble.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ



Larry Banks


Correct, and if yous use "RR73" you shouldn't expect a "73" at all.  Only then, "RR73" should only be used with practiced propagation.  From the manual:

Similarly, double-click the Tx4 control to toggle between sending RRR and RR73 in that message. The RR73 message should be used only if you are reasonably confident that no repetitions volition exist required.

...although nearly hams still send the "concluding 73."

Larry / W1DYJ

toggle quoted messageTestify quoted text

Sent: Tuesday, March 23, 2022 10:53

Bailiwick: Re: Re: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73

Larry and David,
Yous can also change the RRR to RR73.
So did I !
73, Karl OE3JAG

Am 23.03.21, 15:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:

How-do-you-do David,

There is no reason to send the 2d "73" every bit you take already sent your "RRR" signifying that you acknowledge the QSO.  Therefore the system doesn't transport it.

Sent: Tuesday, March 23, 2022 nine:06

Field of study: [WSJTX] #FT8 CQing Refuses to Transport 73 After Receiving 73

   No 1 has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -nineteen, I receive AD4TJ xxxxxxx R-10, I ship xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it only quits; it prompts me to log the Q, merely doesn't transport the concluding 73.  RR73 is not selected. I practise have Disable Tx after sending 73 checked, but the 73 is non sent. It is disabling TX Before the 73 is sent. I take to quickly select TX5 and click on Enable TX. But happens when I call CQ; replying to others CQing is not a problem.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ




Bob G8HGN


Hello,

Perchance something has changed in the newer versions, equally I've just had a QSO using RRR and got 73 from the other op' and sent a 73, all using Auto. As far as I'thousand aware this has e'er been the case. Meet fastened screengrab.

The 2d 73 may exist superflous, simply it'southward sent by the plan unless prevented past the op' manually.

73 Bob G8HGN

toggle quoted messageBear witness quoted text

On 23/03/2021 xv:02, Larry Banks via groups.io wrote:

Right, and if yous use "RR73" yous shouldn't expect a "73" at all.  But and then, "RR73" should simply exist used with adept propagation.  From the transmission:

Similarly, double-click the Tx4 control to toggle betwixt sending RRR and RR73 in that message. The RR73 message should be used only if you are reasonably confident that no repetitions volition exist required.

...although most hams nevertheless send the "terminal 73."

Larry / W1DYJ

Sent: Tuesday, March 23, 2022 10:53

Subject area: Re: Re: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73

Larry and David,
You tin as well change the RRR to RR73.
So did I !
73, Karl OE3JAG

Am 23.03.21, fifteen:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:

Howdy David,

In that location is no reason to send the 2d "73" as yous accept already sent your "RRR" signifying that you lot acknowledge the QSO.  Therefore the system doesn't send it.

Sent: Tuesday, March 23, 2022 9:06

Subject: [WSJTX] #FT8 CQing Refuses to Transport 73 After Receiving 73

   No i has replied to my state of affairs, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -nineteen, I receive AD4TJ xxxxxxx R-ten, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it simply quits; it prompts me to log the Q, simply doesn't send the last 73.  RR73 is not selected. I practise have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX Before the 73 is sent. I have to quickly select TX5 and click on Enable TX. Simply happens when I call CQ; replying to others CQing is not a problem.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ




                      



Um ... no ... if you ship an RR73, y'all're washed, the RRR is usually used when the conditions are bad, and you want to be sure that both sides of the QSO have confirmed the receipt of the data.

This is covered in the User Manual.

Neil, KN3ILZ

toggle quoted messageProve quoted text

On 3/23/2021 9:31 AM, bill.neuro wrote:

I believe this is how it is supposed to work. You ship RRR, he sends 73; QSO done! That'due south how information technology works for me.

Bill K1NS

Sent from my T-Mobile 5G Device

Sent from my T-Mobile 5G Device

-------- Original bulletin --------

From: "David AD4TJ via groups.io" <ad4tj@...>

Date: 3/23/21 9:36 AM (GMT-05:00)

Subject: [WSJTX] #FT8 CQing Refuses to Transport 73 After Receiving 73

Deplorable if you lot run across this multiple times; I have not seen it in one case in my inbox.

   No ane has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -xix, I receive AD4TJ xxxxxxx R-ten, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, only instead it just quits; it prompts me to log the Q, merely doesn't send the final 73.  RR73 is not selected. I do take Disable Tx later sending 73 checked, but the 73 is not sent. It is disabling TX Before the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I telephone call CQ; replying to others CQing is not a trouble.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ


                      


The main affair I was trying to say is, information technology seems as if this is a new behavior; I don't retrieve ever non having me (my software) non sending a 73 after receiving a 73.

  And the RR73 deal; unless signals are very strong, I don't like to use it, every bit at that place are many times that I've sent that and the other guy is still sending AD4TJ xxxxxx RRR; he has not received my RR73.

  On another note, I rarely utilise FT4; it'southward aggravating to call up the QSO is over just the other guy is still sending RRR; and then in the overall scheme of things, I'm not really saving time, as messages have to be repeated to complete. Even signals as strong as single digits below 0 accept to exist repeated to complete.

David AD4TJ

toggle quoted messageShow quoted text

On Tuesday, March 23, 2021, ix:38:54 AM EDT, Bill Somerville <g4wjs@...> wrote:

On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No i has replied to my situation, where I am calling CQ in FT8, someone replies, I transport xxxxxxx AD4TJ -nineteen, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; at present the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, merely doesn't transport the concluding 73.  RR73 is non selected. I do have Disable Tx after sending 73 checked, but the 73 is non sent. Information technology is disabling TX BEFORE the 73 is sent. I have to apace select TX5 and click on Enable TX.

This is v2.iv.0-rc3.

No one else is seeing this?

David AD4TJ

David,

what is the purpose of the actress 73 message you wish top send?

73
Bill
G4WJS.



David

Have you ever operated on CW QSOing a rare station, a contest or a DXpedition. The exchange is

    DX station: QRZ

    ME: K1NS

    DX: K1NS 5NN

    ME: R 5NN

    DX: TU QRZ

Annotation that I never send his call sign, he usually sometimes sends his call every several QRZs, and unremarkably a TU instead of a 73.

I think the wsjt modes are just following gimmicky standards. Quick and minimal.

Bill K1NS

Sent from my T-Mobile 5G Device

toggle quoted bulletinShow quoted text

-------- Original message --------

From: "David AD4TJ via groups.io" <ad4tj@...>

Date: three/23/21 2:52 PM (GMT-05:00)

To: main@wsjtx.groups.io, "WSTJ-10 Groups.IO" <wsjtx@groups.io>, main@WSJTX.groups.io

Subject area: [WSJTX] re: #FT8 CQing Refuses to Send 73 After Receiving 73

The principal thing I was trying to say is, information technology seems as if this is a new behavior; I don't remember ever not having me (my software) not sending a 73 subsequently receiving a 73.

  And the RR73 deal; unless signals are very potent, I don't like to use it, as at that place are many times that I've sent that and the other guy is notwithstanding sending AD4TJ xxxxxx RRR; he has not received my RR73.

  On some other note, I rarely use FT4; it'southward aggravating to recall the QSO is over simply the other guy is however sending RRR; so in the overall scheme of things, I'grand not really saving time, as letters have to exist repeated to complete. Fifty-fifty signals as strong every bit unmarried digits below 0 have to be repeated to consummate.

David AD4TJ

On Tuesday, March 23, 2021, 9:38:54 AM EDT, Bill Somerville <g4wjs@...> wrote:

On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -nineteen, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should ship xxxxxxx AD4TJ 73, just instead it just quits; it prompts me to log the Q, but doesn't send the concluding 73.  RR73 is not selected. I practice take Disable Tx after sending 73 checked, but the 73 is not sent. Information technology is disabling TX Earlier the 73 is sent. I take to quickly select TX5 and click on Enable TX.

This is v2.iv.0-rc3.

No 1 else is seeing this?

David AD4TJ

David,

what is the purpose of the extra 73 bulletin you wish top send?

73
Neb
G4WJS.



Replace your RRR with RR73 and everything will be fine.

Jim, AF6O

toggle quoted messageEvidence quoted text

On 3/23/2021 half-dozen:06 AM, David AD4TJ via groups.io wrote:


   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, just instead it just quits; it prompts me to log the Q, just doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. Information technology is disabling TX Before the 73 is sent. I take to apace select TX5 and click on Enable TX. Only happens when I phone call CQ; replying to others CQing is not a trouble.

This is v2.4.0-rc3.

No ane else is seeing this?

David AD4TJ


                      

Geza Szabados-Hann


Hi David,

it seems that nobody understood the pregnant of the closing 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable nether bad weather. The closing 73 *is* the key for it. The station receiving RRR should send 73 and should expect for receiving the closing 73. If the closing 73 non received, the station cannot be sure that the other station logged the QSO too.
I as well obtained this beliefs with earlier versions.  information technology seems to exist a timing issue. WSJTX disables TX-enable before starting to send the closing 73.

Geza DG5LP.


Beak Somerville


On 24/03/2021 22:37, Geza Szabados-Hann wrote:

Howdy David,

it seems that nobody understood the meaning of the closing 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable under bad conditions. The endmost 73 *is* the cardinal for information technology. The station receiving RRR should ship 73 and should await for receiving the closing 73. If the closing 73 not received, the station cannot be sure that the other station logged the QSO too.
I also obtained this beliefs with earlier versions.  it seems to exist a timing issue. WSJTX disables TX-enable before starting to send the closing 73.

Geza DG5LP.

Geza,

your logic is flawed. If yous expect a 73 bulletin in reply to a 73 bulletin so how does the sender know when to cease sending repeats? A better strategy is for the recipient of an RRR bulletin to send one or more 73 messages, how many to send is a judgement call based on the progress of the QSO and so far. The recipient of the RRR message has a small chance of logging an incomplete QSO only no greater than their QSO partner doing then if you fail to decode RRR letters upward until the they give up sending them.

Lesser line is that not every QSO gets completed 2-fashion in adverse conditions.

73
Beak
G4WJS.



On 2021-03-24 6:37 PM, Geza Szabados-Hann wrote:

The closing 73 *is* the central for it.

No! 73 in response to 73 is redundant and wasteful.

When the first station sends R-## he is already acknowledging the
calling station'due south report. When the calling station sends RRR
and the start station sends 73 *THE QSO IS Complete*. If the
kickoff station has not copied RRR, he doesn't sent 73, he sends
R-## *again* until he receives RRR.

There is no need for the calling station to transport 73 in response
to the get-go station's 73. He has already received RRR and the
QSO *IS COMPLETE*.

IT SEEMS THAT MANY PEOPLE DO NOT Empathise WHAT A COMPLETE QSO IS.

73,

... Joe, W4TV

On 2021-03-24 half dozen:37 PM, Geza Szabados-Hann wrote:

Hi David,
information technology seems that nobody understood the meaning of the endmost 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable under bad atmospheric condition. The closing 73 *is* the key for it. The station receiving RRR should send 73 and should wait for receiving the closing 73. If the closing 73 non received, the station cannot exist sure that the other station logged the QSO likewise.
I also obtained this behavior with earlier versions.  it seems to be a timing issue. WSJTX disables TX-enable earlier starting to send the endmost 73.
Geza DG5LP.


On Mar 24, 2021, at 16:51, Bill Somerville <g4wjs@classdesign.com> wrote:

your logic is flawed. If yous expect a 73 message in respond to a 73 message then how does the sender know when to stop sending repeats?

I may not exist an old timer at this, Neb, but he IS right. It has been used in this fashion on VHF MS operation since I got started in it near 10 years ago when I retired. RRR waits for a 73 and the 73 waits for an acknowledging 73 to signal it is done. It is normal operation. It seems like every time we turn around, someone is trying to shorten the whole thing to be even faster. It's like changing the rules mid stream to go far easier for people who are too lazy to expect for the whole process to properly complete. Offset nosotros stick in RR73 to arrive faster, then nosotros say skip TX1 and beginning with TX2 on reply to a CQ. Another shortcut. Then we say RR73 needs no acknowledgement. Why don't you just get full auto and work the world while you're off at the job? Many of u.s. like the integrity of the full exchange.

Gary - AG0N



On 3/24/2021 9:36 PM, Gary - AG0N wrote:

I may not exist an old timer at this, Bill, just he IS right. It has been used in this way on VHF MS functioning since I got started in information technology almost 10 years ago when I retired.

Hullo Gary,

I also do lots of weak indicate work on VHF and 160M, and I disagree with you, Gary. VHF/UHF is Dissimilar from HF performance in many ways, including that atmospheric condition are oftentimes marginal and information technology can accept 30-45 minutes to finish a MS QSO. The protocols that take evolved for VHF/UHF are entirely weak betoken work with WSJT modes are appropriate for those bands, but they are overkill for HF.

The QSO is complete when both stations have copied R of the other station's exchange. The only question is about how that is communicated, and that depends on long established practice.

Consider this, Gary. In a CW or SSB contest or DX pileup on HF, when the CQing station in the contest or the DX station repeats his exchange it tells y'all that he did Not copy your TU and substitution, and yous repeat it. If he send your call and TU, he'due south listening for another phone call, and you're washed. This is how information technology's been washed on the HF bands for generations (I started out in contesting in 1957, and what I describe has been standard practice for at least 3 decades. When I got back on the air in 2003 after several decades running my sown mall biz, I instinctively responded to a CQ with my telephone call and the other station came right back).

With WSJT-X modes, if he doesn't re-create your RRR, he repeats your report (R-18). Only if he DID copy your RRR or RR73, he calls CQ. If he didn't he would have sent R-18 again. The same applies with WSJT-X modes.

And, BTW, the vast bulk of my VHF weak indicate QSOs other than FT8 are coordinated on VHF-Slack (I used to utilize PJ), and it has long been considered expert practice on any of these VHF/UHF conversation sites for one station (unremarkably simply not always the guy in the rare grid) to say online, "got RRR. 73" to relieve time for the trek to piece of work more of the deserving. Think -- it is the fact that he copied the other station's RRR that completes the QSO. There is NO requirement that one or both stations re-create 73.

73, Jim K9YC


Geza Szabados-Hann


On Wednesday, Mar 24, 2022 at 04:25 PM, Joe Subich, W4TV wrote:

At that place is no need for the calling station to send 73 in response
to the first station'southward 73. He has already received RRR and the
QSO *IS Complete*.

The QSO is complete if both QSO partners can exist sure that the other station has logged the QSO. If a station selects to utilize the RRR procedure, the QSO (in contrast to RR73) is non logged on reception of the R-report, first when receiving the 73. If no closing 73 is sent, the other station can not be sure that the QSO was logged by the QSO-partner.
Using RR73 is the chief reason for the many NILs.

Geza DG5LP



On 2021-03-25 8:l AM, Geza Szabados-Hann wrote:

If a station selects to use the RRR procedure, the QSO (in contrast
to RR73) is not logged on reception of the R-report, first when
receiving the 73. If no closing 73 is sent, the other station can not
be certain that the QSO was logged by the QSO-partner.

If that is your definition of a "complete" QSO, 90+ of CW/SSB DXpedition
and contest QSOs in the last l years are not "complete". A QSO is
consummate when each station has received and acknowledged the report
from the other station. A QSO does not require an acknowledgement
of the report or and acknowledgement of the acknowledgement.

More 'good' "JT Style" QSOs are abandoned considering of some misguided
need for an acknowledgement of an acknowledgement than are logged
every bit "Nix".

73,

... Joe, W4TV

On 2021-03-25 8:50 AM, Geza Szabados-Hann wrote:

On Wed, Mar 24, 2022 at 04:25 PM, Joe Subich, W4TV wrote:
There is no need for the calling station to send 73 in response
to the get-go station'southward 73. He has already received RRR and the
QSO *IS COMPLETE*.
The QSO is consummate if both QSO partners can be sure that the other station has logged the QSO. If a station selects to use the RRR procedure, the QSO (in contrast to RR73) is not logged on reception of the R-study, kickoff when receiving the 73. If no closing 73 is sent, the other station can non be sure that the QSO was logged past the QSO-partner.
Using RR73 is the master reason for the many NILs.
Geza DG5LP

jonesmorant.blogspot.com

Source: https://wsjtx.groups.io/g/main/topic/ft8_cqing_refuses_to_send_73/81550767?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,81550767

0 Response to "How to Make Wsjtx Altomaticly Call Cq Again After a Contact"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel