Topics

locked Involuntary CQing


Jim SIMON
 

I have WSJT-x set to “disable Tx after sending 73”. Nevertheless, often when I finish a contact and the “73” message is sent in Tx5, Tx6 triggers with me transmitting an unwanted CQ. How can I prevent that from happening?

 

Tnx es 73,

 

Jim  W1YY

 


mmpiehl@...
 

I think default settings has this problem, to fix:
File/Settings/General/check - Disable Tx after sending 73

Even worse is this:
You're sitting and waiting, and a super rare DX shows up
You call, and nothing happens??!?
Finally you realize you have no Tx Power, WSJT-X isn't generating audio (even though your PC never sleeps).
You quickly kill WSJT-X, and Restart
You enable Tx, and suddenly 6 stations are calling you, and the DX is long gone.  You're calling CQ unintentionally.
Is there some way to inhibit/prevent CQ?  If 50 stations are always calling CQ, what's the benefit?


Reino Talarmo
 

Hi,

 

> You quickly kill WSJT-X, and Restart
You enable Tx, and suddenly 6 stations are calling you, and the DX is long gone.  You're calling CQ unintentionally.

I think that you have a minor failure in your thinking.

After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?

Of course you could also type the rare DX call into “DX call” field and select proper “Tx even/1st” depending what DX happened to use and put your TX to a free spot and only then Enable Tx, I think.

Or have I missed something?

 

73, Reino OH3mA


Frode Igland
 

Checking or unchecking "Disable Tx after sending 73" has no effect in popular modes like FT8 and FT4. It only works in modes where it is expected to have to repeat your 73 message many times in order to complete the QSO, e.g. meteor scatter. In these modes it is normally difficult to complete a QSO in one attempt. However, even in these modes conditions may sometimes be such that you can expect to be successful in completing on the first attempt. This is so rare that you reallly don't want to waste the time with unnecessary repetition. THAT is the when you check "Disable Tx after sending 73", i.e. order to avoid repeating otherwise expected repetitions.

In modes where you can expect to complete the QSO on the first attempt, and that sending a 73 actually completes the QSO, you will find that TX is always disabled after sending 73, in order to avoid a fully automated QSO machines or QSO robots. That is why you always have to click "Enable Tx" to start a new CQ or a new QSO in FT8 and FT4. So the situation you describe simply does not happen in FT8 or FT4, because you will never be able to send a CQ and solicit calls unless you have actively clicked on "Enable Tx" and, I repeat, because "Disable tx after sending 73" has no effect in FT8 and FT4.


Gary - AG0N
 

On Jan 11, 2021, at 14:10, Reino Talarmo <reino.talarmo@kolumbus.fi> wrote:

I think that you have a minor failure in your thinking.
After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?
I complained about this long ago and it catches me often. I almost never call CQ, and don’t want to most of the time. On the rare occasion that I do, I typically work 5-10 stations in a row before I hit a period of rest. Also, If I use TX5 to send a directional CQ (i.e. CQ DX, CQ RI, CQ AS, etc.) I seriously don’t want to send out a series of TX6 without wanting to. I’ve sent many a CQ inadvertently when the program decided that it was the thing to do and switched without me noticing it. I’ve love to see a CQ inhibit function right up front so that it can be prevented.

Gary - AG0N


Reino Talarmo
 

On Jan 11, 2021, at 14:10, Reino Talarmo <reino.talarmo@kolumbus.fi> wrote:
I think that you have a minor failure in your thinking.
After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?
I complained about this long ago and it catches me often. I almost never call CQ, and don’t want to most of the time. On the rare occasion that I do, I typically work 5-10 stations in a row before I hit a period of rest. Also, If I use TX5 to send a directional CQ (i.e. CQ DX, CQ RI, CQ AS, etc.) I seriously don’t want to send out a series of TX6 without wanting to. I’ve sent many a CQ inadvertently when the program decided that it was the thing to do and switched without me noticing it. I’ve love to see a CQ inhibit function right up front so that it can be prevented.
Gary - AG0N
Gary,

You may as well edit TX6 and put there your directed call " CQ EU AG0N " and then you don't send a general CQ at all.

73, Reino OH3mA


Austin 2E0MNV
 

One thing that has been annoying me lately is that once wsjtx has sent RR73, the TX stops.  By the time you get that next one out, it's too late and the DX station is working someone else.  I've lost many a QSL as a result, because some operators expect a 73 or they won't log you.  Clicking tx again results in an involuntary CQ if you're not careful.

I know there is an RRR option, but that's not a 73. It just draws out the QSO and the OP is still expecting a 73 and he will not log you until he gets it.  (Not all ops, but some).

I log everyone if there is an exchange of signal reports. Waiting for the 73 is just not realistic on FT8 in certain conditions and especially in a pile up, someone is going to jump on top of that 73 anyway. The person working the pile up "should" be experienced enough to realise this, but still, I get many who still won't QSL.

Conclusion, it would be great if 73 could repeat say a maximum of three times until both parties are satisfied the QSO is complete.  Of course, it wouldn't be necessary if people were not so upset about not getting their 73 and refusing to QSL.  
This behaviour also happens after 15 minute SSB QSO's too. I've received a "not in my log" back from them, because QSB closed in before we could say 73.  Wow!


Reino Talarmo
 

>One thing that has been annoying me lately is that once wsjtx has sent RR73, the TX stops.  By the time you get that next one out, it's too late and the DX station is working someone else.  I've lost many a QSL as a result, because some operators expect a 73 or they won't log you.  Clicking tx again results in an involuntary CQ if you're not careful.

Hi Austin,

I am a bit lost, what is your scenario. If I have sent RR73, then I may receive 73. Do their expect from you a 73 to that? Or is it some other sequence of messages as normally I need to send 73 after receiving RR73 or RRR?

 

In any case I have not seen that as problem, but as an opportunity to select what you want do next. If I consider that I need to send something right after sending my RR73, then I Enable Tx at the beginning of rx period. That opens me opportunity to select what to send once reception is completed. Typical need is to repeat RR73, when I receive again R-report. For that I hover pointer at Tx4 Now button and click that if needed. Otherwise I may need to send 73 or CQ. I just move pointer to appropriate button and click. If I am a bit late, it normally does not mean anything as only a small portion the message contains wrong bits and error correction does its job. Of course Halt Tx is an option as well; I may generate some QRM in that case.

 

Even better could be to activate Alternated F1-F6 bindings and just hit F key; it equivalent to pressing Tx* Now. See User Guide 6.7. FT4 last but one note. Work also at FT8.

 

My sixpence.

 

73, Reino OH3mA

 

 

 


Austin 2E0MNV
 

Just because I have sent RR73 does not mean he has received it.   There have been occasions when the operator has refused to log me because he did not get my RR73.

The issue is, WSJTX stops transmitting immediately after RR73.  You have to click in two separate places on the screen after RR73 is sent, in anticipation that you may need to send it again because the last one went into outer space.  You do not know he got your RR73 until he sends 73 back.  If you set the option to continue transmitting after RR73, it transmits the unwanted CQ, which is unhelpful.

It happened to me 3 times yesterday and all the operators failed to log me even though we exchanged signal reports.  I suspect it was because they did not receive my RR73 for whatever reason.  They expect RR73 or they do not log.

I know there is an RRR option.  However, in this scenario, I transmit RRR, he receives it and sends RR73.  But then I have to send 73, and if he does not get this last 73, he will not log the contact.  There is no option in WSJTX to send 73 more than once.  There is only option to send a CQ after 73 which is a useless option unless you are the calling station.  


Martin G0HDB
 

On Tue, Jan 12, 2021 at 09:24 AM, Austin 2E0MNV wrote:
Just because I have sent RR73 does not mean he has received it.   There have been occasions when the operator has refused to log me because he did not get my RR73.

The issue is, WSJTX stops transmitting immediately after RR73.  You have to click in two separate places on the screen after RR73 is sent, in anticipation that you may need to send it again because the last one went into outer space.  You do not know he got your RR73 until he sends 73 back.  If you set the option to continue transmitting after RR73, it transmits the unwanted CQ, which is unhelpful.

It happened to me 3 times yesterday and all the operators failed to log me even though we exchanged signal reports.  I suspect it was because they did not receive my RR73 for whatever reason.  They expect RR73 or they do not log.

I know there is an RRR option.  However, in this scenario, I transmit RRR, he receives it and sends RR73.  But then I have to send 73, and if he does not get this last 73, he will not log the contact.  There is no option in WSJTX to send 73 more than once.  There is only option to send a CQ after 73 which is a useless option unless you are the calling station.  
Austin:

As far as you're concerned a QSO is complete when you've sent either your RRR or RR73 so you can (and should) log the QSO as soon as that stage in the sequence has been reached.  It's not necessary for you to wait until you've received a 73 from the other station before logging the QSO - their final 73 is simply a courtesy.

I acknowledge that it can be helpful to receive a 73 because it does confirm that your RRR or RR73 has been received by the other station but it's not an essential part of the QSO.  Also, if you feel that the other station might not have received your RR73 or RRR because of QSB, QRM or whatever then there's nothing to stop you, as the operator of your station, sending your RR73 or RRR again even if doing so necessitates a couple of extra mouse-clicks - after all, you're supposed to be in control of what gets transmitted.

I don't see any need whatosever in having the software automatically send multiple RRRs or RR73s (or even 73s) - it's all under your control, and in any event there's no certainty that multiple re-sends of RRR or RR73 would get through any better than the first one if the station at the other end is suffering from QRM or if signals had faded significantly.

From the other side, if you're in a QSO and you've sent your R-xx report but for whatever reason (QSB, QRM etc) you haven't copied an RRR or RR73 from the other station then I acknowledge that you don't know that your report has been received; in this situation you, as the operator, can either initiate re-sending your report maybe a couple more times and hope that you eventually receive the RRR or RR73 that confirms that your report has been received, and/or you can log the QSO anyway with a comment to the effect that from your perspective the QSO was only partially complete because you hadn't received the other station's RRR or RR73 because of QRM or whatever.  By doing that you will at least have a record in your log of the exchange of reports and you can at a later date if necessary use that, along with the relevant extracts from your ALL.TXT file, to provide evidence that the essential information was exchanged and hence the QSO was valid.

--
Martin G0HDB


Austin 2E0MNV
 

Thank you, I never knew about the ALL.txt file.  That could be useful.  There have been a few occasions where I'm not in club log or HRD log even though I was 100% convinced that we had a QSO that day.  It always happens with some new DXCC (that's the only time when it bothers me they failed to log me).

I know that it's not necessary to wait for a 73 before logging. I always log after an exchange of signal reports.  I do not wait for the 73.  I suspect it is users using automatic logging, where perhaps the auto logging software is only recording after a 73 is received.  Anyhow, if you don't have quick trigger fingers, it's easy to send an involuntary CQ instead of a second 73.


Gary - AG0N
 

On Jan 11, 2021, at 22:54, Reino Talarmo <reino.talarmo@kolumbus.fi> wrote:

You may as well edit TX6 and put there your directed call " CQ EU AG0N " and then you don't send a general CQ at all.
I haven’t tried it for a long time, but at last check, you can’t edit that box and have it stick.

Gary - AG0N


Patrick Hung
 

Austin (and others),

Reading through this thread, I had one concern in mind, and it was finally pointed out by Austin in the last paragraph above - auto logging only logs when a 73 is sent/received. Oftentimes I would encounter an abrupt stop to a QSO, after signal exchange, whereby the other station stops transmitting (until this point I've chalked it up to sudden signal degradation and they can't hear me/vice-versa) - is this a case of the other station logging without needing a 73/sending a 73 to me? In such cases, I have no idea if he/she received my last transmit, so I continue sending my 73s, until I finally abandon the QSO without logging. In any case, if I don't receive/send a 73, my software won't log the QSO (no pop-up to indicate so), and being new, I don't know how to trigger WSJT-X log manually; I can log it on ACLog, but would prefer to have the QSO noted on the WSJT-X_log as well. 
--
73,
Patrick, W6AJR


Sam Birnbaum
 

Hi
There is a button log wap. Click On that and the log qso dialog will pop up

73

S am W2JDB




-----Original Message-----
From: Patrick Hung <pathung@...>
To: main <main@WSJTX.groups.io>
Sent: Tue, Jan 12, 2021 11:40 AM
Subject: Re: [WSJTX] Involuntary CQing


Austin (and others),

Reading through this thread, I had one concern in mind, and it was finally pointed out by Austin in the last paragraph above - auto logging only logs when a 73 is sent/received. Oftentimes I would encounter an abrupt stop to a QSO, after signal exchange, whereby the other station stops transmitting (until this point I've chalked it up to sudden signal degradation and they can't hear me/vice-versa) - is this a case of the other station logging without needing a 73/sending a 73 to me? In such cases, I have no idea if he/she received my last transmit, so I continue sending my 73s, until I finally abandon the QSO without logging. In any case, if I don't receive/send a 73, my software won't log the QSO (no pop-up to indicate so), and being new, I don't know how to trigger WSJT-X log manually; I can log it on ACLog, but would prefer to have the QSO noted on the WSJT-X_log as well. 

--
73,

Patrick, W6AJR




Martin G0HDB
 

On Tue, Jan 12, 2021 at 04:39 PM, Gary - AG0N wrote:
I haven’t tried it for a long time, but at last check, you can’t edit that box and have it stick.
How long do you want it to stick for?  Any amendments to the Tx6 message don't persist through a WSJT-X restart (which includes a swap to a different configuration) but in my experience I'm pretty sure that a modified Tx6 message persists throughout any band and mode changes, which to me seems more than sufficient.

--
Martin G0HDB


Martin G0HDB
 

On Tue, Jan 12, 2021 at 06:20 PM, Sam Birnbaum wrote:

Hi
There is a button log wap. Click On that and the log qso dialog will pop up
The ALT-Q keyboard shortcut also brings up the QSO logging pop-up window.

--
Martin G0HDB


Gary - AG0N
 

On Jan 12, 2021, at 16:13, Martin G0HDB <marting0hdb@gmail.com> wrote:

How long do you want it to stick for?
Until I change it.

Any amendments to the Tx6 message don't persist through a WSJT-X restart (which includes a swap to a different configuration) but in my experience I'm pretty sure that a modified Tx6 message persists throughout any band and mode changes, which to me seems more than sufficient.
Tried it again today but too the msg is too long. Can’t give the grid that way.

Gary - AG0N


Reino Talarmo
 

On Jan 12, 2021, at 16:13, Martin G0HDB <marting0hdb@gmail.com> wrote:
How long do you want it to stick for?
Until I change it.
Any amendments to the Tx6 message don't persist through a WSJT-X restart (which includes a swap to a different configuration) but in my experience I'm pretty sure that a modified Tx6 message persists throughout any band and mode changes, which to me seems more than sufficient.
Tried it again today but too the msg is too long. Can’t give the grid that way.
Hi Gary,

Could you share what you exactly put into Tx6? It can support numbers 000 to 999 or letters up to four characters e.g. EURO. Those need to follow CQ e.g. CQ ASIA AG0N FN01 should be fine.

So it can be longer than 13 characters that is the limit in Tx5, but there are strict rules what and where it can accept typing.

73, Reino OH3mA


Martin G0HDB
 

On Wed, Jan 13, 2021 at 06:03 AM, Gary - AG0N wrote:
Tried it again today but too the msg is too long. Can’t give the grid that way.

Gary - AG0N
Hi again Gary, exactly what were you trying to send?

You can add up to four characters, either alphabetic or numeric but not a mix of the two, into the Tx6 message so that looks like, for example:

CQ ASIA G0HDB IO82

Won't that suit your needs?

--
Martin G0HDB


Reino Talarmo
 

>You can add up to four characters, either alphabetic or numeric

 

Martin, just for completeness only exactly three numeric i.e. 000 to 999, hi!

See https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf, table 7.

73, Reino Oh3mA