[wsjt-devel] FT8 Soft Demapper in WSJT-X

[James VK3JPK]

WSJT-X Developers,

I have been studying the WSJT-X source code to learn how it decodes FT8 signals 
to enhance my rather outdated (1980s) understanding of DSP and information 
theory.  There is one part of the source code that I can’t figure out and I was 
hoping that one of the WSJT-X developers could point me in the right direction.

The source code in question is lines 168 through 215 of lib/ft8/ft8b.f90 (Git 
tag wsjtx-x 2.1).  This source code appears to implement a “soft demapper” that 
takes groups of 1, 2 or 3 successive symbol observations and turns these into 
groups of 3, 6 or 9 log likelihood ratios that are subsequently consumed by one 
of the LDPC decoders.  As part of the demapping process, the Gray code 
permutation applied to symbols at the transmitter is removed.

Is there a textbook or specific journal/conference papers that describe how 
this demapper works?  I can figure out the algorithm being used, but I am 
looking for an explanation as to why that algorithm generates a good 
approximation to the LLR for FT8’s 8-GFSK modulation, and what specific channel 
impairments it is trying to deal with.

I was also wondering how the specific Gray code mapping in FT8 was chosen?  It 
is clearly not the “reflected binary code” that normally passes for a Gray 
code, so clearly it is something else that I don’t yet understand.

James (VK3JPK)



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

Re: [wsjt-devel] Lid operators or bad design?

[rjai...@gmail.com]

Are they in the same time slot? If they are on odd and you are on even, no
real harm. FT8 is operated primarily split anyway.

I do know this used to be an issue when lock rx=tx was a thing that people
would work you then transmit in your frequency slot.

73,
Ria
N2RJ

On Sun, Jul 28, 2019 at 11:58 AM Andy Durbin  wrote:

> Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> who answer a CQ and then, when the QSO is complete, call CQ on the same
> frequency.   Are all these operators really stupid or are they being
> trapped by a weakness in the user interface design?
>
> 73,
> Andy, k3wyc
> ___
> 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 Frequency on 40-m

[Paul Kube]

Steve --

Related to this, and to another recent thread on replying to CQ's on the
caller's frequency:

What is the decoding probability a FT8 (or FT4) signal when being
interfered with by another FT8 (or FT4) signal, as a function of frequency
separation and signal strength difference? Seems clear that it would not be
appropriate to model the interfering signal as additive Gaussian noise, so
is this even something that you can solve or nicely approximate
analytically? I'd be interested to know.

73, Paul K6PO

On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Gene,
>
> FT8 is WAY MORE sensitive! (~8db)
>
>
> That number is not right. On the additive white Gaussian noise (AWGN)
> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
> difference is therefore 3.3 dB.
>
> On channels with severe Doppler spreading, the threshold SNR is higher for
> both modes, and the difference between FT8 and FT4 will decrease somewhat
> because FT4’s larger tone separation tends to give it an advantage in those
> cases.
>
> It might be of interest to some to consider that FT8 uses symbols with
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
> to send 2 bits apiece. For a given average transmitter power, the energy
> that is transmitted per bit for FT8 is larger than the energy transmitted
> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
> sensitivity difference (ignoring any differences in signal detection,
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
> very close to the actual difference of 3.3 dB that I quoted above.
>
> I have no strong feelings one way or the other about your main point, but
> I think that it’s preferable to base the discussion on accurate numbers.
>
>
> FT4 is awesome for MORE contacts (i.e. contests).
>
> I’m sticking with FT8 for QUALITY.
>
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974
>
>
> Steve, K9AN
>
>
> ___
> 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] Lid operators or bad design?

[Doug Bates]

Nothing is foolproof to a sufficiently determined fool. From a retired
gunsmith, you would not believe some things some fools have tried to do.

Doug Bates, KV4ZY
Sent from my Verizon mobile phone.
330-590-1429

On Sun, Jul 28, 2019, 5:01 PM Jim Nuytens via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> No user interface design will ever be idiot proof. The supply of idiots
> far outstrips the supply of programmers.
>
> Sent from my iPad
>
> On Jul 28, 2019, at 11:53 AM, Andy Durbin  wrote:
>
> Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> who answer a CQ and then, when the QSO is complete, call CQ on the same
> frequency.   Are all these operators really stupid or are they being
> trapped by a weakness in the user interface design?
>
> 73,
> Andy, k3wyc
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Bill Richter]

Could be a combination of hams wanting to get OTA with the new mode, 
playing/fighting with integration/configuration (some radios are easy, many 
more are not), and an 87 page manual.


As a software developer for a couple of decades, RTFM isn't done nearly as much 
as it needs to, but that's just human nature.


--
Thanks,
Bill

> On July 28, 2019 at 2:10 PM VE3FBZ  wrote:
> 
> Why do we have to hold “their” hand.
> 
> In the documentation it says 
> 
> 
> “To avoid QRM from competing callers, it is frequently desirable to 
> answer a CQ on a different frequency from that of the CQing station. Choose a 
> Tx frequency that appears to be not in use. The same is true when you 
> tail-end another QSO.”
> 
> Find an open spot, click hold TX and operate.
> 
> When you change bands make sure you are still clear of other operators.
> 
> Use common sense and courtesy.
> 
> No sense brow beating the ones who do not care - they probably do not 
> listen anyhow.
> 
> My 2 cents
> 
> 
>  Regards and 73s
> VE3FBZ
> London Amateur Radio Clubhttp://www.larc.ca
>  
> 
> 
> 
> 
> On Jul 28, 2019, at 16:45, Jim Nuytens via wsjt-devel < 
> wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net > 
> wrote:
> 
> 
> > > No user interface design will ever be idiot proof. The 
> supply of idiots far outstrips the supply of programmers.
> > 
> > Sent from my iPad
> > 
> > On Jul 28, 2019, at 11:53 AM, Andy Durbin < a.dur...@msn.com 
> > mailto:a.dur...@msn.com > wrote:
> > 
> > 
> > > > > Everyone who uses WSJT-X for FT8 must have 
> > noticed the number of operators who answer a CQ and then, when the QSO is 
> > complete, call CQ on the same frequency.   Are all these operators really 
> > stupid or are they being trapped by a weakness in the user interface design?
> > > 
> > > 73,
> > > Andy, k3wyc
> > > 
> > > > > 
> > > > >  
> > > 
> > > > > 
> > > > > 
> > ___
> > > wsjt-devel mailing list
> > > wsjt-devel@lists.sourceforge.net 
> > > mailto:wsjt-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> > > 
> > > > > 
> > > 
> > >  
> > 
> > > 
> > > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net 
> > mailto:wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> > 
> > > 


 

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


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

Re: [wsjt-devel] FT4 Frequency on 40-m

[Gene Marsh via wsjt-devel]

Hi Steve, 

I didn’t calculate everything - and thank you for doing “my work” for me.  ;)

In the real world, we need more empirical data to support my thought = FT8 is 
superior for weak signal/DX/“valuable” contacts (and, of course, “value” is 
purely subjective).  We know is “better” qualitatively, but in the real world, 
how much?  We don’t have the history for FT4 DX pileups. In fact, we have only 
a smattering of good FT8 data. 

I *believe*, in more than 8000+ FT8 contacts (vs ~175 FT4 contacts!), FT8 is 
clearly better than FT4 for weak signals.  But, how much value can be used for 
a QUANTITATIVE assessment (rare DX vs many more contacts).  I need more data. 

Thanks for your response!

I’m staying tuned

73 de W8NET Miles / “Gene”
Secretary, Portage County Amateur Radio Service (PCARS)
3905 Century Club - Master #47
DV2/W8NET in the Philippines
Licensed since 1974

> On Jul 28, 2019, at 10:32 AM, Steven Franke  wrote:
> 
> Hi Gene,
> 
>> FT8 is WAY MORE sensitive! (~8db)
> 
> That number is not right. On the additive white Gaussian noise (AWGN) 
> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the 50% 
> decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity difference 
> is therefore 3.3 dB. 
> 
> On channels with severe Doppler spreading, the threshold SNR is higher for 
> both modes, and the difference between FT8 and FT4 will decrease somewhat 
> because FT4’s larger tone separation tends to give it an advantage in those 
> cases.
> 
> It might be of interest to some to consider that FT8 uses symbols with 
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms 
> to send 2 bits apiece. For a given average transmitter power, the energy that 
> is transmitted per bit for FT8 is larger than the energy transmitted per bit 
> for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical 
> sensitivity difference (ignoring any differences in signal detection, 
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB, 
> very close to the actual difference of 3.3 dB that I quoted above.
> 
> I have no strong feelings one way or the other about your main point, but I 
> think that it’s preferable to base the discussion on accurate numbers.
> 
>> 
>> FT4 is awesome for MORE contacts (i.e. contests).
>> 
>> I’m sticking with FT8 for QUALITY. 
>> 
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
> 
> Steve, K9AN
> 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Andy Durbin]

"That could lead to a long discussion on the impact of the use of the "Call 
1st" option and whether it's deletion would encourage better opting practices. "

Of course that should have read "better operating practices".

Andy, k3wyc



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

Re: [wsjt-devel] FT4 Frequency on 40-m

[Christoph Berg]

Re: Roy Gould 2019-07-27 

> It does not seem to me that there is any reason that FT4 and FT8 cannot
> operate together in the same channel. If this is so, then why have separate
> channels for them?

FT8 is quite good at decoding even overlapping signals in parallel.
However, from my experience, what it does not like, is when some
strong signal (dis)appears halfway through the RX cycle, probably
because of the TRX's AGC changing. If the same strong signal is there
all the time on the next cycle, decoding works.

If FT4 were on the same channel, that would happen all the time,
making decoding weak FT8 signals very difficult.

Christoph


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

Re: [wsjt-devel] Lid operators or bad design?

[VE3FBZ]

Why do we have to hold “their” hand.

In the documentation it says 


“To avoid QRM from competing callers, it is frequently desirable to answer a CQ 
on a different frequency from that of the CQing station. Choose a Tx frequency 
that appears to be not in use. The same is true when you tail-end another QSO.”

Find an open spot, click hold TX and operate.

When you change bands make sure you are still clear of other operators.

Use common sense and courtesy.

No sense brow beating the ones who do not care - they probably do not listen 
anyhow.

My 2 cents


 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




> On Jul 28, 2019, at 16:45, Jim Nuytens via wsjt-devel 
>  wrote:
> 
> No user interface design will ever be idiot proof. The supply of idiots far 
> outstrips the supply of programmers.
> 
> Sent from my iPad
> 
>> On Jul 28, 2019, at 11:53 AM, Andy Durbin  wrote:
>> 
>> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
>> who answer a CQ and then, when the QSO is complete, call CQ on the same 
>> frequency.   Are all these operators really stupid or are they being trapped 
>> by a weakness in the user interface design?
>> 
>> 73,
>> Andy, k3wyc
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 Frequency on 40-m

[Edfel Rivera]

Hi All:

My experience from the Caribbean for example 6M  no FT4 QSO so far. Tried
80m and similar experience,  although I can hear some stations.  No QSO.
For users working the magic bad, at distant locations FT4 is out the scene
unless conditions are excellent.  Just my experience,  However, will test
more the FT4 mode.

73'

Edfel
KP4AJ

On Sun, Jul 28, 2019 at 10:38 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Gene,
>
> FT8 is WAY MORE sensitive! (~8db)
>
>
> That number is not right. On the additive white Gaussian noise (AWGN)
> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
> difference is therefore 3.3 dB.
>
> On channels with severe Doppler spreading, the threshold SNR is higher for
> both modes, and the difference between FT8 and FT4 will decrease somewhat
> because FT4’s larger tone separation tends to give it an advantage in those
> cases.
>
> It might be of interest to some to consider that FT8 uses symbols with
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
> to send 2 bits apiece. For a given average transmitter power, the energy
> that is transmitted per bit for FT8 is larger than the energy transmitted
> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
> sensitivity difference (ignoring any differences in signal detection,
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
> very close to the actual difference of 3.3 dB that I quoted above.
>
> I have no strong feelings one way or the other about your main point, but
> I think that it’s preferable to base the discussion on accurate numbers.
>
>
> FT4 is awesome for MORE contacts (i.e. contests).
>
> I’m sticking with FT8 for QUALITY.
>
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974
>
>
> Steve, K9AN
>
>
> ___
> 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] Lid operators or bad design?

[Christoph Berg]

Is there a reason the "Hold Tx" checkbox isn't checked by default?
This list seems to be discussing this over an over, and instead of
hoping that people might click it, why isn't it just on?

Christoph


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

Re: [wsjt-devel] Lid operators or bad design?

[Jim Nuytens via wsjt-devel]

No user interface design will ever be idiot proof. The supply of idiots far 
outstrips the supply of programmers.

Sent from my iPad

> On Jul 28, 2019, at 11:53 AM, Andy Durbin  wrote:
> 
> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
> who answer a CQ and then, when the QSO is complete, call CQ on the same 
> frequency.   Are all these operators really stupid or are they being trapped 
> by a weakness in the user interface design?
> 
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[Andy Durbin]

"IMO, when using FT8, I consider it rude and poor operating practice to
call a station on their frequency, simply because the station is more
likely to be able to decode multiple callers of they're spread out."

That could lead to a long discussion on the impact of the use of the "Call 1st" 
option and whether it's deletion would encourage better opting practices.

73,
Andy, k3wyc

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

Re: [wsjt-devel] Lid operators or bad design?

[Martin Davies G0HDB]

On 28 Jul 2019 at 11:07, Jim Brown wrote:

> On 7/28/2019 8:53 AM, Andy Durbin wrote:
> > Everyone who uses WSJT-X for FT8 must have noticed the number of 
> > operators who answer a CQ and then, when the QSO is complete, call CQ on 
> > the same frequency.   Are all these operators really stupid or are they 
> > being trapped by a weakness in the user interface design?
> 
> Let's say a combination of failure to RTFM and a poor decision in the 
> user interface design. That decision is the default to uncheck the box 
> of Hold TX frequency, and to not remember it's last used state when 
> switching modes.

Doesn't this become a complete non-issue if a separate configuration is used 
for each and 
every mode that one wishes to use?

Switching between configurations takes essentially no more time than switching 
modes within 
a default configuration, and the settings for each configuration can be 
specifically tailored to 
suit the selected mode, eg. with a mode-specific frequency list and different 
Wide Graph 
settings.

I've currently got nine separate configurations, including for 6m MSK144, 
'normal' FT4, 
'normal' FT8, FT8 Hound, etc etc, and have never had an issue with the 'Hold 
Tx' control 
becoming unchecked when switching between configurations - the state of the 
control is 
remembered for each individual configuration and doesn't get changed.

IMO the ability to configure and select completely different configurations for 
different modes 
is one that should be much more widely used.

---
Martin, G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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

Re: [wsjt-devel] Lid operators or bad design?

[Patrick 9A5CW]

Hi,
I agree with Jim K9YC,
On 6m i prefer that when i call CQ a station coming back to me calls me
with report instead of grid. Openings are very short and QSO flows faster.
Also i prefer that those stations call me off freq.
My program it set to call with report always especially on 6m band.
JA's are using the same kind of sequencing and many more QSO's could be
made during short openings. Theirs discipline and spectrum spreading are
best of all contintines around the globe. Hat down to them all.

About Lids, we had them b4 on CW, SSB and other modes and we will have them
always. When someone makes a QSO with me and later starts to CQ on my freq
i simply delete that QSO if he doesnt move from my freq when i ask him to
QSY.  QSO its saved into the Adif but he will never get a QSO confirmation
of any kind. My rule ;)

73,
Patrik 9A5CW




ned, 28. srp 2019. 22:14 Jim Brown  je napisao:

> On 7/28/2019 12:56 PM, Gary Kohtala - K7EK via wsjt-devel wrote:
> > Also those that call my station with a signal report on their first
> > transmission (no full callup and no grid).
> >
> > I ignore folks like that. If they don't start the contact with a full
> > set of calls and grid square there will be no joy for them.
>
> Hmmm. What's your problem with that? I see only three good reasons to
> call with grid first and no signal report. 1) It's a contest that
> requires the grid, so VHF contest mode is in use; 2) the calling station
> is in a location not consistent with his callsign, so you know where to
> point your antenna; or 3) you're on VHF, where collecting grids is
> common practice. And even then, you can get the grid from LOTW.
>
> Since I'm a K9 call operating from NorCal, I usually call with my grid,
> for reason #2.
>
> When 6M is open to JA, calling stations almost always call with the
> signal report first. If you don't respond, you'll be the one with no
> joy. And, BTW, almost all of my 6M FT8 JA QSOs (about 50) are in LOTW!
>
> 73, Jim K9YC
>
>
> ___
> 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] Lid operators or bad design?

[Bill Somerville]

On 28/07/2019 21:23, Bill Somerville wrote:
... snip
fully supports replying to CQ calls with a *Tx3 message rather than 
using the possibly redundant Tx2* message. I don't think it should be 
your choice to demand a grid from your QSO partner unless you really 
need it, in which case you can ask for it.



snip


What's you opinion on using an RR73 message to finalize a QSO? I ask 
because many stations like to shorten QSOs by a whole Tx and Rx period 
by combining starting *with a Tx3 reply* and finishing with an RR73 
message.

snip ...

Corrections below, I blame a w/e with a head cold and IOTA operating for 
my errors :(


Tx2 -> Tx1

Tx3 ->Tx2

73
Bill
G4WJS.

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

Re: [wsjt-devel] Lid operators or bad design?

[Bill Somerville]

On 28/07/2019 20:56, Gary Kohtala - K7EK via wsjt-devel wrote:
Also those that call my station with a signal report on their first 
transmission (no full callup and no grid).


I ignore folks like that. If they don't start the contact with a full 
set of calls and grid square there will be no joy for them.


Best regards,

Gary, K7EK


Gary,

you need to rethink your approach otherwise you are going to be 
considered very rude by many operators. Let's look at a couple of things 
you may not have considered.


1) there's absolutely no requirement to exchange grids, except for on 
VHF and up bands where the grid may be important to your QSO partner,


2) many stations are not able reply to your calls and include their 
grid, i.e. any station with a non-standard call. Your attitude means you 
will never work any of them unless you make exceptions to your draconian 
rule,


3) on HF the most important reason for sending a grid is to get 
receptions of one's decodes spotted on PSKReporter, surely it is up to 
the sending station whether they want to see where their signal is being 
decoded, not you; although you can choose to disable spotting to 
PSKReporter,


4) WSJT-X in FT8, MSK144, and FT4 modes fully supports replying to CQ 
calls with a Tx3 message rather than using the possibly redundant Tx2 
message. I don't think it should be your choice to demand a grid from 
your QSO partner unless you really need it, in which case you can ask 
for it.


The only solid counter argument I can think of, other than on VHF and up 
where grids can be very helpful to both parties, is that sending a grid 
message or CQ with a grid where possible allows an extra check that a 
decode is not a false one. This is because of the nature of the 
information compression used in the WSJT-X modes makes callsigns in 
false decodes very plausible and a check that the grid covers some part 
of the call prefix's landmass is often the best indicator of a good 
decode of such suspicious messages.


What's you opinion on using an RR73 message to finalize a QSO? I ask 
because many stations like to shorten QSOs by a whole Tx and Rx period 
by combining starting with a Tx3 reply and finishing with an RR73 
message. Again this is fully supported by WSJT-X and can be very useful 
in good copy conditions and I'm sure is appreciated by semi rare DX 
stations that want to give confirmations to as many callers as possible. 
Of course FT8 DXpedtion mode formalizes this even more for those most 
high desirable DX stations that can attract many callers to a separate 
frequency.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Lid operators or bad design?

[Edfel Rivera]

Hi All:

I noticed this behavior and try move to another frequency to respect the
original calling CQ station.  Maybe set WSJTX to move to a fixed (extreme
end) freq after answering a CQ, say 3000.  Just an idea.

73'

Edfel
KP4AJ

On Sun, Jul 28, 2019 at 4:14 PM Jim Brown 
wrote:

> On 7/28/2019 12:56 PM, Gary Kohtala - K7EK via wsjt-devel wrote:
> > Also those that call my station with a signal report on their first
> > transmission (no full callup and no grid).
> >
> > I ignore folks like that. If they don't start the contact with a full
> > set of calls and grid square there will be no joy for them.
>
> Hmmm. What's your problem with that? I see only three good reasons to
> call with grid first and no signal report. 1) It's a contest that
> requires the grid, so VHF contest mode is in use; 2) the calling station
> is in a location not consistent with his callsign, so you know where to
> point your antenna; or 3) you're on VHF, where collecting grids is
> common practice. And even then, you can get the grid from LOTW.
>
> Since I'm a K9 call operating from NorCal, I usually call with my grid,
> for reason #2.
>
> When 6M is open to JA, calling stations almost always call with the
> signal report first. If you don't respond, you'll be the one with no
> joy. And, BTW, almost all of my 6M FT8 JA QSOs (about 50) are in LOTW!
>
> 73, Jim K9YC
>
>
> ___
> 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] Lid operators or bad design?

[Jim Brown]

On 7/28/2019 12:56 PM, Gary Kohtala - K7EK via wsjt-devel wrote:
Also those that call my station with a signal report on their first 
transmission (no full callup and no grid).


I ignore folks like that. If they don't start the contact with a full 
set of calls and grid square there will be no joy for them.


Hmmm. What's your problem with that? I see only three good reasons to 
call with grid first and no signal report. 1) It's a contest that 
requires the grid, so VHF contest mode is in use; 2) the calling station 
is in a location not consistent with his callsign, so you know where to 
point your antenna; or 3) you're on VHF, where collecting grids is 
common practice. And even then, you can get the grid from LOTW.


Since I'm a K9 call operating from NorCal, I usually call with my grid, 
for reason #2.


When 6M is open to JA, calling stations almost always call with the 
signal report first. If you don't respond, you'll be the one with no 
joy. And, BTW, almost all of my 6M FT8 JA QSOs (about 50) are in LOTW!


73, Jim K9YC


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

Re: [wsjt-devel] Lid operators or bad design?

[Gary Kohtala - K7EK via wsjt-devel]

 I see my transmit frequency being ambushed quite regularly. My solution is to 
just stay there. Eventually it should dawn upon them. 
Also those that call my station with a signal report on their first 
transmission (no full callup and no grid).
I ignore folks like that. If they don't start the contact with a full set of 
calls and grid square there will be no joy for them.
Best regards,
Gary, K7EK
---
On Sunday, July 28, 2019, 12:20:34 PM EDT, Bill Somerville 
 wrote:  
 
  On 28/07/2019 16:53, Andy Durbin wrote:
  
   Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
who answer a CQ and then, when the QSO is complete, call CQ on the same 
frequency.   Are all these operators really stupid or are they being trapped by 
a weakness in the user interface design?  
   73,  Andy, k3wyc  
 Hi Andy,
 
WSJT-X users have a choice whether to check the "Hold Tx Frequency" option. It 
makes sense for HF style operation on a busy band but not necessarily on a 
quiet band or on higher frequencies. The traditional way of operating was to 
move to a QSO partner's frequency when answering general call and, like almost 
every other operating mode, understanding that a station calling CQ has 
temporary ownership of their Tx frequency. Operators who "steal" a frequency 
are simply poor operators who have not learnt that establishing a running 
frequency is not always easy and it is rude to take over a frequency that is in 
use, even if it is only for the unused T/R period. OTOH if everyone were to 
check the "Hold Tx Frequency" and take care to try and pick a clear slot for 
their transmissions, then there would be less frustration and avoiding using 
the same offset as a another station on the opposite T/R period to theirs would 
be unnecessary.
 
What I find most frustrating the a station calling, perhaps unknowingly, is 
swamped by one or more other stations on their Tx frequency and T/R period. 
Such QSOs are often incomplete and if the station were to realize what might be 
happening then moving their Tx offset to another slot will often get the QSO 
completed and better still should be a better Tx offset for their subsequent 
QSO with other station in my vicinity.
 
Using digital modes does not obviate operators from learning the craft of good 
operating practice.
 
I note that while writing this there have been three replies suggesting that 
using "Hold Tx Frequency" stops this happening, but that is the wrong answer. 
Checking Hold Tx really means that it doesn't matter whether your QSO partner 
calls on your Tx offset after a QSO.
 
 
73
 Bill
 G4WJS.
 
 ___
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] Lid operators or bad design?

[John Kludt]

Andy,

I am not sure I understand your issue.  If they have "Hold Tx Frequency "
checked, they are on "their" (I use the term very loosely) frequency and
they call CQ after the end of the QSO I don't see what your issue is.  If
they don't have that checked, then they probably jumped to the frequency
you called CQ on and there is a learning opportunity.  I agree with the
others, assume positive intent and see this as a chance to teach them a
better operating style.

Everyone needs to remember it is a *hobby.  *Last night I was trying to
work a Dx station on CW who was using simplex.  I became first frustrated,
then amused, by all the guys who if the Dx did not answer their call right
away keep right on sending their call  every 1 to 2 seconds *right over* the
Dx station.  There is a scene from the movie* Hunt for Red October* where
one of the characters notes, "Heck, they (the Russian anti-submarine search
planes) are flying so fast they would never even hear them (Red October) if
they were right on top of them!"

We all maybe need to slow down a bit, be a little more courteous to each
other, and not be quite so quick to jump to the pejoratives if someone
doesn't operate quite the way we think they should.  There are a lot of new
hams out there and that is a good thing for the hobby.  And an opportunity
for us to Elmer them just as I am sure many of us worked with an Elmer when
we were young pups.

Peace,

John



On Sun, Jul 28, 2019 at 11:58 AM Andy Durbin  wrote:

> Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> who answer a CQ and then, when the QSO is complete, call CQ on the same
> frequency.   Are all these operators really stupid or are they being
> trapped by a weakness in the user interface design?
>
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[Jim Brown]

On 7/28/2019 11:31 AM, Bill Frantz wrote:
The fixed time slots of FT8/FT4 make it hard to find out if there is 
another station on the same frequency as you, even if propagation would 
let you hear it. It is one of the worst features of these protocols.


An obvious solution is to not call CQ all the time, but spend most of 
our time listening instead. :) That's always been my practice on both 
bands where I use FT8, 160M and 6M. It also minimizes my QRM to others 
wanting to hear the weak signals that may be needed grids or DXCC.


Indeed, the only times I call CQ on 6M are 1) when I know the band is 
open or trying to open and I know which TX cycle the other stations are 
using, or 2) when the band is dead and I want to use PSKReporter as a 
signal probe with my TX. An old hand on 6M, WA6LIE, regularly does the 
latter. Every hour or two, or when returning home from work, he'll CQ in 
several directions for a while to see what's happening.


73, Jim K9YC


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

Re: [wsjt-devel] Lid operators or bad design?

[Kevin McQuiggin]

Same behaviour when switching mode from MSK144 to FT8.  “Hold TX” gets 
unchecked when returning to FT8.  This caught me too!

73,

Kevin VE7ZD/K7MCQ

> On Jul 28, 2019, at 11:07 AM, Jim Brown  wrote:
> 
> On 7/28/2019 8:53 AM, Andy Durbin wrote:
>> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
>> who answer a CQ and then, when the QSO is complete, call CQ on the same 
>> frequency.   Are all these operators really stupid or are they being trapped 
>> by a weakness in the user interface design?
> 
> Let's say a combination of failure to RTFM and a poor decision in the user 
> interface design. That decision is the default to uncheck the box of Hold TX 
> frequency, and to not remember it's last used state when switching modes.
> 
> Also, when switching between modes, the box is unchecked. So, for example, 
> you're working FT8 on 6M with the box checked, go to MSK144 to look for MS 
> activity, then return to FT8 to find the box unchecked and your default TX at 
> 1500 Hz.
> 
> IMO, when using FT8, I consider it rude and poor operating practice to call a 
> station on their frequency, simply because the station is more likely to be 
> able to decode multiple callers of they're spread out. My standard method is 
> to pick a TX frequency after watching band activity for a few cycles so that 
> I can quickly click on the decode of someone I want to work.
> 
> 73, Jim K9YC
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Bill Frantz]

There are indeed some bad/naive operators out there who either 
don't know or care about the ways amateurs share frequencies, or 
don't understand the wsjt-x UI and customs well enough to apply 
them to FT8/FT4. However, avoiding interfering with each other 
is hard, and a little charity is in order.


For example, propagation issues make it very difficult to avoid 
transmitting on someone else's transmit frequency. On HF we have 
the skip zone and at VHV/UHF interfering stations may not be in 
line of sight of each other. Two examples:


I was operating from California on 20M in a RTTY contest and 
heard two stations in the eastern US calling CQ on the same 
frequency. I didn't even have to change tuning to decode both of 
them. They must of been using automatic CQ systems, because they 
continued on the same frequency for several minutes, almost like 
the odd and even phases of FT8. My conclusion was that they were 
in each other's skip zone. I managed to work both of them, so it 
is unlikely they were intefering with my signal.


Our county ARES/RACES group has a set of 4 linked BBS systems 
using 1200 bps modems and the AX.25 protocol on 2M. Congestion 
control is by having each station wanting to transmit listen for 
other stations, and then wait until the other station has 
stopped transmitting before it transmits. During a county-wide 
exercise, the county Emergency Operations Center (EOC) system 
was unable to access its BBS because its antenna location kept 
it from being heard by other stations. Not hearing the EOC 
station, the other stations transmitted preventing it from 
downloading its messages.


The fixed time slots of FT8/FT4 make it hard to find out if 
there is another station on the same frequency as you, even if 
propagation would let you hear it. It is one of the worst 
features of these protocols. One way I try to address the 
problem is to press "Halt TX", look at the waterfall, and then 
press "Enable TX" to resume the transmission. If I do this fast 
enough, sometimes my QSO partner can still decode my 
transmission, just as if there were a few seconds of QSB.


It would be nice if wsjt-x could be setup to briefly halt 
transmission at random times during a transmit cycle, listen, 
and determine if there is another station transmitting in the 
transmit frequency, and then resume transmission.


Another feature that might be useful would be to have wsjt-x 
show frequencies where it is unable to decode any signals, as 
they might be good transmit frequencies.


73 Bill AE6JV

---
Bill Frantz| "The only thing we have to   | Periwinkle
(408)356-8506  | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032




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

Re: [wsjt-devel] Lid operators or bad design?

[Jim Brown]

On 7/28/2019 8:53 AM, Andy Durbin wrote:
Everyone who uses WSJT-X for FT8 must have noticed the number of 
operators who answer a CQ and then, when the QSO is complete, call CQ on 
the same frequency.   Are all these operators really stupid or are they 
being trapped by a weakness in the user interface design?


Let's say a combination of failure to RTFM and a poor decision in the 
user interface design. That decision is the default to uncheck the box 
of Hold TX frequency, and to not remember it's last used state when 
switching modes.


Also, when switching between modes, the box is unchecked. So, for 
example, you're working FT8 on 6M with the box checked, go to MSK144 to 
look for MS activity, then return to FT8 to find the box unchecked and 
your default TX at 1500 Hz.


IMO, when using FT8, I consider it rude and poor operating practice to 
call a station on their frequency, simply because the station is more 
likely to be able to decode multiple callers of they're spread out. My 
standard method is to pick a TX frequency after watching band activity 
for a few cycles so that I can quickly click on the decode of someone I 
want to work.


73, Jim K9YC




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

Re: [wsjt-devel] Lid operators or bad design?

[Bill Richter]

What threw me for a loop a couple times is that when you transition from 
fox/hound mode back to normal mode it will automatically uncheck the hold TX 
frequency box for you, even if it was selected before you switched to fox/hound 
mode.

Sent from my iPad

> On Jul 28, 2019, at 8:53 AM, Andy Durbin  wrote:
> 
> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
> who answer a CQ and then, when the QSO is complete, call CQ on the same 
> frequency.   Are all these operators really stupid or are they being trapped 
> by a weakness in the user interface design?
> 
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[VE3FBZ]

Just hold TX.—-


 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




> On Jul 28, 2019, at 11:53, Andy Durbin  wrote:
> 
> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
> who answer a CQ and then, when the QSO is complete, call CQ on the same 
> frequency.   Are all these operators really stupid or are they being trapped 
> by a weakness in the user interface design?
> 
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[Roeland Jansen]

I sometimes just used to forget. I have made a habit to keep the TX freq
now.


On Sun, Jul 28, 2019 at 6:20 PM Claude Frantz 
wrote:

> On 7/28/19 6:00 PM, Ron WV4P wrote:
>
> Hi Ron, Andy & all,
>
> > Way to much credit has been given to the ability of Operators. Hold TX
> > should be checked by default and Deep in the menu to turn it off...
> > Then, upon rebooting it should again default to on.
>
> In addition, I recommend to check, from time to time, if this holded own
> TX frequency is still a judicious choice.
>
> > On Sun, Jul 28, 2019, 10:58 AM Andy Durbin  > > wrote:
> >
> > Everyone who uses WSJT-X for FT8 must have noticed the number of
> > operators who answer a CQ and then, when the QSO is complete, call
> > CQ on the same frequency.
>
> Infortunatly, I have observed this behaviour too often, also.
>
> Best wishes,
> Claude (DJ0OT)
>
>
> ___
> 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] Lid operators or bad design?

[dgb]

Too bad many of them don't run JTAlert or have texting not set to on! 
;-) ... or don't have an email on QRZ!


73 Dwight NS9I

On 7/28/2019 11:01 AM, Black Michael via wsjt-devel wrote:
Attribute it to inexperienceyou should contact them and help to 
politely educate them.


Something like:

Hi there OM,
Saw you in a QSO with  and after the QSO was complete you called 
CQ on the same offset.
You should consider working people in split by choosing a Tx offset 
that is clear of other signals (shift click will do that) in the 
waterfall and checking "Hold Tx Freq" to keep your offset constant.
Of course I'm sure you know that calling CQ on somebody else's 
frequency is a no-no.

73's
..

de Mike W9MDB


On Sunday, July 28, 2019, 10:56:51 AM CDT, Andy Durbin 
 wrote:



Everyone who uses WSJT-X for FT8 must have noticed the number of 
operators who answer a CQ and then, when the QSO is complete, call CQ 
on the same frequency.   Are all these operators really stupid or are 
they being trapped by a weakness in the user interface design?


73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


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

Re: [wsjt-devel] Lid operators or bad design?

[hb9vqy]

Am 28.07.19 um 18:06 schrieb Doug Bates

> My thoughts are that they do not have Hold TX Freq checked and simply
> forget that answering my CQ  moved their TX freq too. Or they just don't
> care, could be either way.
> 
> 73 Doug, KV4ZY
> 
> On Sun, Jul 28, 2019 at 11:58 AM Andy Durbin  wrote:
> 
> > Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> > who answer a CQ and then, when the QSO is complete, call CQ on the same
> > frequency.   Are all these operators really stupid or are they being
> > trapped by a weakness in the user interface design?
> >
> > 73,
> > Andy, k3wyc
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >


On my side, I assumed from the start with FT8, that a new operating mode does 
not affect the operating rules at all, doesn‘t it?
It‘s clear to me and hopefully to the other hams, too. Only use a frequency 
when it is free of other signals.
I double-check what the software does before each QSO...

73, Marius
HB9VQY



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

Re: [wsjt-devel] Lid operators or bad design?

[Claude Frantz]

On 7/28/19 6:00 PM, Ron WV4P wrote:

Hi Ron, Andy & all,

Way to much credit has been given to the ability of Operators. Hold TX 
should be checked by default and Deep in the menu to turn it off... 
Then, upon rebooting it should again default to on.


In addition, I recommend to check, from time to time, if this holded own 
TX frequency is still a judicious choice.


On Sun, Jul 28, 2019, 10:58 AM Andy Durbin > wrote:


Everyone who uses WSJT-X for FT8 must have noticed the number of
operators who answer a CQ and then, when the QSO is complete, call
CQ on the same frequency.


Infortunatly, I have observed this behaviour too often, also.

Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] Lid operators or bad design?

[Bill Somerville]

On 28/07/2019 16:53, Andy Durbin wrote:
Everyone who uses WSJT-X for FT8 must have noticed the number of 
operators who answer a CQ and then, when the QSO is complete, call CQ 
on the same frequency.   Are all these operators really stupid or are 
they being trapped by a weakness in the user interface design?


73,
Andy, k3wyc

Hi Andy,

WSJT-X users have a choice whether to check the "Hold Tx Frequency" 
option. It makes sense for HF style operation on a busy band but not 
necessarily on a quiet band or on higher frequencies. The traditional 
way of operating was to move to a QSO partner's frequency when answering 
general call and, like almost every other operating mode, understanding 
that a station calling CQ has temporary ownership of their Tx frequency. 
Operators who "steal" a frequency are simply poor operators who have not 
learnt that establishing a running frequency is not always easy and it 
is rude to take over a frequency that is in use, even if it is only for 
the unused T/R period. OTOH if everyone were to check the "Hold Tx 
Frequency" and take care to try and pick a clear slot for their 
transmissions, then there would be less frustration and avoiding using 
the same offset as a another station on the opposite T/R period to 
theirs would be unnecessary.


What I find most frustrating the a station calling, perhaps unknowingly, 
is swamped by one or more other stations on their Tx frequency and T/R 
period. Such QSOs are often incomplete and if the station were to 
realize what might be happening then moving their Tx offset to another 
slot will often get the QSO completed and better still should be a 
better Tx offset for their subsequent QSO with other station in my vicinity.


Using digital modes does not obviate operators from learning the craft 
of good operating practice.


I note that while writing this there have been three replies suggesting 
that using "Hold Tx Frequency" stops this happening, but that is the 
wrong answer. Checking Hold Tx really means that it doesn't matter 
whether your QSO partner calls on your Tx offset after a QSO.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Lid operators or bad design?

[Doug Bates]

My thoughts are that they do not have Hold TX Freq checked and simply
forget that answering my CQ  moved their TX freq too. Or they just don't
care, could be either way.

73 Doug, KV4ZY

On Sun, Jul 28, 2019 at 11:58 AM Andy Durbin  wrote:

> Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> who answer a CQ and then, when the QSO is complete, call CQ on the same
> frequency.   Are all these operators really stupid or are they being
> trapped by a weakness in the user interface design?
>
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[Black Michael via wsjt-devel]

Attribute it to inexperienceyou should contact them and help to politely 
educate them.
Something like:
Hi there OM,Saw you in a QSO with  and after the QSO was complete you 
called CQ on the same offset.You should consider working people in split by 
choosing a Tx offset that is clear of other signals (shift click will do that) 
in the waterfall and checking "Hold Tx Freq" to keep your offset constant.Of 
course I'm sure you know that calling CQ on somebody else's frequency is a 
no-no.73's..
de Mike W9MDB 

On Sunday, July 28, 2019, 10:56:51 AM CDT, Andy Durbin  
wrote:  
 
  Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
who answer a CQ and then, when the QSO is complete, call CQ on the same 
frequency.   Are all these operators really stupid or are they being trapped by 
a weakness in the user interface design?
73,Andy, k3wyc___
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] Lid operators or bad design?

[Ron WV4P]

Way to much credit has been given to the ability of Operators. Hold TX
should be checked by default and Deep in the menu to turn it off... Then,
upon rebooting it should again default to on. A year ago FT8 was enjoyable
to operate. Not so much anymore. Ron, WV4P

On Sun, Jul 28, 2019, 10:58 AM Andy Durbin  wrote:

> Everyone who uses WSJT-X for FT8 must have noticed the number of operators
> who answer a CQ and then, when the QSO is complete, call CQ on the same
> frequency.   Are all these operators really stupid or are they being
> trapped by a weakness in the user interface design?
>
> 73,
> Andy, k3wyc
> ___
> 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] Lid operators or bad design?

[Andy Durbin]

Everyone who uses WSJT-X for FT8 must have noticed the number of operators who 
answer a CQ and then, when the QSO is complete, call CQ on the same frequency.  
 Are all these operators really stupid or are they being trapped by a weakness 
in the user interface design?

73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 Frequency on 40-m

[Steven Franke via wsjt-devel]

Hi Gene,

> FT8 is WAY MORE sensitive! (~8db)

That number is not right. On the additive white Gaussian noise (AWGN) channel, 
the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the 50% decode 
probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity difference is 
therefore 3.3 dB. 

On channels with severe Doppler spreading, the threshold SNR is higher for both 
modes, and the difference between FT8 and FT4 will decrease somewhat because 
FT4’s larger tone separation tends to give it an advantage in those cases.

It might be of interest to some to consider that FT8 uses symbols with duration 
160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms to send 2 
bits apiece. For a given average transmitter power, the energy that is 
transmitted per bit for FT8 is larger than the energy transmitted per bit for 
FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical sensitivity 
difference (ignoring any differences in signal detection, synchronization or 
LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB, very close to the actual 
difference of 3.3 dB that I quoted above.

I have no strong feelings one way or the other about your main point, but I 
think that it’s preferable to base the discussion on accurate numbers.

> 
> FT4 is awesome for MORE contacts (i.e. contests).
> 
> I’m sticking with FT8 for QUALITY. 
> 
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974

Steve, K9AN


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