Re: [wsjt-devel] WST4W-300 2.4.0-rc4

[Claude Frantz]

On 5/7/21 7:55 PM, Thomas Mills wrote:


Thanks Gary you were correct.  TOT set for 3 minutes, I never thought
about that!Problem solved!


Hi Tom, Bill and all,

I suggest to the developers to introduce a pop-up window which will 
appear when the mode is changed in a manner which is not compatible with 
the current timeout setting. This window can then offer to…


- do nothing

- change the timeout to an reasonable value, compatible with the new 
selected mode. I suggest to populate the entry field for the new 
proposed value of the timeout with a reasonable value which the operator 
can change or accept as is.


Best regards,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 logging prompt

[Jeff Stillinger via wsjt-devel]

WSJT-X is open source.  You can make those changes you are suggesting, 
thereby customizing your station operations.   There is no licensing 
restrictions that would stop you from doing so (see GPL 3).


However, do not be surprised if you actually loose a lot of 
confirmations.   Yes, I am one of those stations that expect the basic 
exchange format as outlined in the User Guide to be completed in order 
to be confirmed.   My station.  My logbook.  My rules.   I will always 
complete any QSO regardless.  I just don't log for confirmation the ones 
that have missing pieces.  I strongly believe this helps maintain the 
integrity of awards.   But...  that is me. Someone else may feel 
differently.   It's all good in the rf hood.





On 5/6/21 3:28 PM, Martin Davies G0HDB wrote:
The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the 
release notes and announcements state that the mode is intended for 
use in HF digital contesting where 'quick-fire' exchanges such as 
those achieved using RTTY are desired.  I'd like to suggest a change 
that would help achieve this aim a bit better; the following applies 
to v2.1.0 and all subsequent versions up to and including v2.3.1 (I 
haven't yet tried any of the RC versions of v2.4.0).


An FT4 (and an FT8!) QSO generally looks something like the following:

CQ K1JT FN20
  K1JT G0HDB IO82
G0HDB K1JT -10
  K1JT G0HDB R-08
G0HDB K1JT RR73
  K1JT G0HDB 73

Currently, the logging window only pops open on my screen to prompt me 
to log the QSO when the final (Tx5) '73' message is being sent - this 
is to all extents and purposes superfluous because the QSO has been 
successfully completed when K1JT has sent his RR73 (and I've received 
it).  My sending the superfluous '73' message extends the overall 
duration of the QSO by adding a further Tx period at my end of the 
sequence so I can't move on to trying to start the next QSO.


I'd like to suggest that the logging window is opened when I've 
*received* the other station's RR73 message and that sending the final 
Tx5 '73' message is either removed from the sequence altogether or is 
made optional.  This would help to improve the overall throughput of 
FT4 QSOs.


The code to open the logging window on receipt of an incoming 'RR73' 
message and to desist from sending the Tx5 '73' message must already 
exist within the app because that's what already happens when I 
operate as a Hound in FT8 Fox & Hounds mode - when I receive the Fox's 
'RR73' the logging window pops open and my system doesn't send the 
unnecessary Tx5 '73' .


I'd actually like to see the logging window open in any mode when I 
either send *or receive* an RRR or RR73 message - in my opinion that 
would align the prompting to log the QSO much more closely with the 
completion of the exchange of the essential information for the QSO 
and would leave the sending of a final '73' as an optional nicety.


--
73, Martin G0HDB

 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Jeff Stillinger - KB6IBB
KB6IBB Laboratories
Wylie, Texas - United States

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 logging prompt

[Paul Kube]

I agree with Martin and others, but let me suggest a slight compromise.

Instead of changing the default sequence for all FT4 QSO's, change it for
FT8/FT4 in WWDIGI contest mode only, and advertise the change. This won't
disrupt anyone's ideas about how general FT QSO's should be done;
contesters will understand the change, and appreciate it. 2021 WWDIGI is
August 28-29; should be time enough to implement it.

In more detail:


   1. Eliminate Tx5, “73”, from the default QSO message sequence. Its use
   should be discouraged in WWDIGI (and in fact in all FT4/FT8 contests). It
   is not needed for the exchange and acknowledgement of required information,
   and – because  its use is not widely understood not to be required --  just
   leads to longer QSO’s on average, and general confusion about whether a QSO
   has been completed which increases NIL’s.

   Since in WWDIGI  the only exchange info is callsigns and grids, the
   default QSO -- exchanging and acknowledging all required information --
   could be as short as 3 transmissions. Examples:
  1. Answering a CQ:
  CQ WW W0YK DM97  Tx6
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  2. Tailending a QSO. K6PO has already copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  3. Tailending a QSO. K6PO has not yet copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO DM12   Tx2
  K6PO W0YK R DM97   Tx3
  W0YK K6PO RR73 Tx4

  2. Automatically log the QSO sending *or receiving* Tx4, “RR73”. One
   reason sending Tx5, “73”, is currently in the default QSO sequence for
   WWDIGI is that this triggers automatic logging of the QSO from  WSJT-X. Tx5
   is never sent in examples 1a-1c above, and so one QSO partner would need to
   manually log the QSO in each case (i.e. hit the “Log QSO” button in WSJT-X,
   and in the case of 1b, perhaps also manually enter the copied grid). If
   automatic logging is desired, triggering it on sending *or receiving*
   Tx4 would accomplish that.

   3. Note: in some of the examples above, part of the contest exchange
   (the grid) is not explicitly sent from the first QSO partner (W0YK) to the
   second (K6PO). Some might object to this, but note that it is copied by the
   second QSO partner as part of the first partner’s CQ or other transmission,
   and so this  is as much or more in the spirit of 2-way over-the-air
   communication as commonly used contest techniques like call history files,
   giving your call only once every few QSO’s in a run, etc.


73, Paul K6PO

On Thu, May 6, 2021 at 1:34 PM Martin Davies G0HDB 
wrote:

> The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release
> notes and announcements state that the mode is intended for use in HF
> digital contesting where 'quick-fire' exchanges such as those achieved
> using RTTY are desired.  I'd like to suggest a change that would help
> achieve this aim a bit better; the following applies to v2.1.0 and all
> subsequent versions up to and including v2.3.1 (I haven't yet tried any of
> the RC versions of v2.4.0).
>
> An FT4 (and an FT8!) QSO generally looks something like the following:
>
> CQ K1JT FN20
>   K1JT G0HDB IO82
> G0HDB K1JT -10
>   K1JT G0HDB R-08
> G0HDB K1JT RR73
>   K1JT G0HDB 73
>
> Currently, the logging window only pops open on my screen to prompt me to
> log the QSO when the final (Tx5) '73' message is being sent - this is to
> all extents and purposes superfluous because the QSO has been successfully
> completed when K1JT has sent his RR73 (and I've received it).  My sending
> the superfluous '73' message extends the overall duration of the QSO by
> adding a further Tx period at my end of the sequence so I can't move on to
> trying to start the next QSO.
>
> I'd like to suggest that the logging window is opened when I've *received*
> the other station's RR73 message and that sending the final Tx5 '73'
> message is either removed from the sequence altogether or is made
> optional.  This would help to improve the overall throughput of FT4 QSOs.
>
> The code to open the logging window on receipt of an incoming 'RR73'
> message and to desist from sending the Tx5 '73' message must already exist
> within the app because that's what already happens when I operate as a
> Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the
> logging window pops open and my system doesn't send the unnecessary Tx5
> '73' .
>
> I'd actually like to see the logging window open in any mode when I either
> send *or receive* an RRR or RR73 message - in my opinion that would align
> the prompting to log the QSO much more closely with the completion of the
> exchange of the essential information for the QSO and would leave the
> sending of a final '73' as an optional nicety.
>
> 

Re: [wsjt-devel] FT4 logging prompt

[Alan]

Indeed one cannot be certain, but the further exchange increases the 
probability of the QSO being complete for both parties.


Alan G0TLK, sent from my mobile device
On 7 May 2021 18:30:43 Bill Frantz  wrote:


On 5/7/21 at 2:54 AM, al...@alangroups.plus.com (Alan) wrote:


The final 73 is a confirmation for some that the QSO is indeed
fully completed.  If omitted there's intrinsic doubt that the
RR has been received.


How can I be sure that the other end received the final 73
message? ?

This question is particularly important in contests since if you
log a QSO and the other station doesn't, you usually actually
lose points from your score.

73 Bill AE6JV

---
Bill Frantz| Concurrency is hard. 12   | Periwinkle
(408)348-7900  | out 10 programmers get it | 150 Rivermead
Rd #235
www.pwpconsult.com | wrong.  - Jeff Frantz | Peterborough,
NH 03458



___
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] WST4W-300 2.4.0-rc4

[Thomas Mills]

 Thanks Gary you were correct.  TOT set for 3 minutes, I never thought about 
that!Problem solved!
Tom WB4JWM

On Friday, May 7, 2021, 1:15:46 PM EDT, Gary McDuffie  
wrote:  
 
 


On May 7, 2021, at 7:47 AM, Thomas Mills  wrote:


When I transmit on FST4W-300, wsjt-x only keys the radio for180 seconds but the 
RX/Tx box is still yellow in the transmit mode.  I have even turned off CAT and 
used VOX, but WST4Wstill sends an un-key to the radio after 180 seconds, and 
the tones are stillgoing out.  I don’t see any problems with the120 sec mode.  


It sounds like you have a 3 minute timeout timer set within the radio.
Gary - AG0N___
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] FT4 logging prompt

[Reino Talarmo]

Three points.
1. the other end should resend RR73 in that case, if that operator really
requires 73 for this QSO. If he sends another message e.g. CQ or a message
to another station, then it is highly likely that he logged your QSO or just
gave up.
2. 73 is not a mandatory message at all.
3. not all contests use that rule.
73, Reino OH3mA

-Alkuperäinen viesti-
Lähettäjä: Bill Frantz [mailto:ae...@arrl.net] 
Lähetetty: 07 May 2021 20:29
Vastaanottaja: WSJT software development 
Aihe: Re: [wsjt-devel] FT4 logging prompt

On 5/7/21 at 2:54 AM, al...@alangroups.plus.com (Alan) wrote:

>The final 73 is a confirmation for some that the QSO is indeed fully 
>completed.  If omitted there's intrinsic doubt that the RR has been 
>received.

How can I be sure that the other end received the final 73 message?
?

This question is particularly important in contests since if you log a QSO
and the other station doesn't, you usually actually lose points from your
score.

73 Bill AE6JV

---
Bill Frantz| Concurrency is hard. 12   | Periwinkle
(408)348-7900  | out 10 programmers get it | 150 Rivermead 
Rd #235
www.pwpconsult.com | wrong.  - Jeff Frantz | Peterborough, 
NH 03458



___
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] FT4 logging prompt

[Bill Frantz]

On 5/7/21 at 2:54 AM, al...@alangroups.plus.com (Alan) wrote:

The final 73 is a confirmation for some that the QSO is indeed 
fully completed.  If omitted there's intrinsic doubt that the 
RR has been received.


How can I be sure that the other end received the final 73 
message? ?


This question is particularly important in contests since if you 
log a QSO and the other station doesn't, you usually actually 
lose points from your score.


73 Bill AE6JV

---
Bill Frantz| Concurrency is hard. 12   | Periwinkle
(408)348-7900  | out 10 programmers get it | 150 Rivermead 
Rd #235
www.pwpconsult.com | wrong.  - Jeff Frantz | Peterborough, 
NH 03458




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WST4W-300 2.4.0-rc4

[Gary McDuffie]

> On May 7, 2021, at 7:47 AM, Thomas Mills  wrote:
> 
> When I transmit on FST4W-300, wsjt-x only keys the radio for 180 seconds but 
> the RX/Tx box is still yellow in the transmit mode.  I have even turned off 
> CAT and used VOX, but WST4W still sends an un-key to the radio after 180 
> seconds, and the tones are still going out.  I don’t see any problems with 
> the 120 sec mode.  
> 

It sounds like you have a 3 minute timeout timer set within the radio.

Gary - AG0N___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WST4W-300 2.4.0-rc4

[Thomas Mills]

When I transmit on FST4W-300, wsjt-x only keys the radio for180 seconds but the 
RX/Tx box is still yellow in the transmit mode.  I have even turned off CAT and 
used VOX, but WST4Wstill sends an un-key to the radio after 180 seconds, and 
the tones are stillgoing out.  I don’t see any problems with the120 sec mode.  


Tom

WB4JWM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RC4 Issues

[Russ]

Hi all. I’ve been using RC4 for a while now for JT65, FT8, and MSK144, and 
wanted to report a few issues.
 
1.  On both FT8 and JT65, often it skips sending 73 at the end of a QSO.  
Mostly it seems to do that when I would be sending 73 last, but not sure if it 
also happens the other way.  When it skips sending 73, it also does not auto 
log.


2.  As shown below, on JT65, working EME, I am seeing an odd second decode 
at times.  In all cases the second line does not actually decode, but it is for 
the same frequency within a Hz or two, and usually a stronger signal is 
indicated.  It often a much stronger signal, like 5 dB stronger, but in this 
example there is only 1 dB difference.
 
1106 -21  2.4 1276 #* RD3FD IK4WLV JN54f
1106 -20  2.4 1275 ##
1107 -30  6.6 1087 #
1108 -19  2.5 1274 #* RD3FD IK4WLV JN54f
1108 -20  2.5 1275 ##
 
3.  When working EME, WSJT-X should not automatically turn off transmitting 
when it detects a signal on my frequency that is not calling me.  Due to 
doppler shift it is unlikely that my signal is causing any QRM, and it is 
common for many EME stations to all be calling the same station in contests or 
expeditions.  It is rather upsetting to finally get an answer from a dx station 
and then discover that your transmitter has been turned off.  (Note that this 
situation may not be as noticeable for operators who listen to their signal or 
sit next to their equipment, as they will notice the change.  But when 
operating remotely, there are no audio indicators that something has changed.)

The same argument can be made for FT8 and MSK144 operations.  Even though 
doppler is not an issue, on FT8 it is common for two stations to share a 
frequency with opposite sequencing.  But most often both stations are working 
someone on a different frequency so there is no interference.  This is much 
more likely to be the case than any actual QRM.  In general, software should 
not assume that it is smarter than the operator, who usually knows what he is 
doing…

For MSK144, meteor scatter operations there is no reason to ever shut off the 
transmitter, except if the operator has specified to shut off after sending 73. 
 Due to the way meteor reflections work, there is almost never QRM between 
multiple stations all on the same frequency.  Again, the software cannot be 
smarter than the operator.
 
4.  For MSK144, and FT8, the flag to not stop transmitting after sending 73 
does not work.  It makes no difference if it is checked or not.  Very often I 
need to continue sending 73 for a few transmissions, but I have to manually 
change the message and restart the transmitter to do so.  Since sequences are 
every 15 seconds, this becomes a big burden when trying to log a contact, maybe 
respond to a comments on chat, observe other calling stations, and having to 
manage the transmissions manually all at the same time.

When the flag to stop tx after 73 is not checked, the program should not 
advance to TX6, and should continue sending 73 until the operator decides to 
stop – or the watchdog timer stops it.
 
73, Russ K2TXB
 
 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 logging prompt

[Alan]

On the face of it looks like a good idea, but...

The final 73 is a confirmation for some that the QSO is indeed fully 
completed.  If omitted there's intrinsic doubt that the RR has been received.


Omission might give a few more QSO's in a session but for contests that's 
irrelevant since it's the individuals score in comparison to other 
participants that counts.


Therefore so long as everyone uses the same protocol surely it doesn't matter?


The existing protocol keeps a little bit of humanity and politeness in the 
proceedings, which in my view at least is just as important as anything else.


Alan G0TLK, sent from my mobile device
On 6 May 2021 23:59:23 David Gillooly  wrote:
Some hams on there end will not log a QSO unless they receive the 
confirmation 73 after their RRR/RR73.


I am not saying its wrong or right just that it's the practice of some hams


Dave, AA6RE

On Thu, May 6, 2021 at 1:34 PM Martin Davies G0HDB  
wrote:


The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release 
notes and announcements state that the mode is intended for use in HF 
digital contesting where 'quick-fire' exchanges such as those achieved 
using RTTY are desired.  I'd like to suggest a change that would help 
achieve this aim a bit better; the following applies to v2.1.0 and all 
subsequent versions up to and including v2.3.1 (I haven't yet tried any of 
the RC versions of v2.4.0).



An FT4 (and an FT8!) QSO generally looks something like the following:


CQ K1JT FN20
 K1JT G0HDB IO82
G0HDB K1JT -10
 K1JT G0HDB R-08
G0HDB K1JT RR73
 K1JT G0HDB 73


Currently, the logging window only pops open on my screen to prompt me to 
log the QSO when the final (Tx5) '73' message is being sent - this is to 
all extents and purposes superfluous because the QSO has been successfully 
completed when K1JT has sent his RR73 (and I've received it).  My sending 
the superfluous '73' message extends the overall duration of the QSO by 
adding a further Tx period at my end of the sequence so I can't move on to 
trying to start the next QSO.



I'd like to suggest that the logging window is opened when I've *received* 
the other station's RR73 message and that sending the final Tx5 '73' 
message is either removed from the sequence altogether or is made optional. 
 This would help to improve the overall throughput of FT4 QSOs.



The code to open the logging window on receipt of an incoming 'RR73' 
message and to desist from sending the Tx5 '73' message must already exist 
within the app because that's what already happens when I operate as a 
Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the 
logging window pops open and my system doesn't send the unnecessary Tx5 '73' .



I'd actually like to see the logging window open in any mode when I either 
send *or receive* an RRR or RR73 message - in my opinion that would align 
the prompting to log the QSO much more closely with the completion of the 
exchange of the essential information for the QSO and would leave the 
sending of a final '73' as an optional nicety.



--
73, Martin G0HDB


Virus-free. www.avast.com


___
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