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

[jan0]

Paul,The term for the performance parameter you're asking about is "co-channel 
rejection" and, as Steve points out, it's very messy to analyze analytically, 
as it's a very nonlinear function of many variables.  Even validating 
simulation results via experiment can be tricky.Ed N4II.
 Original message From: Paul Kube  Date: 
7/29/19  3:31 PM  (GMT-05:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] FT4 Frequency on 
40-m TOK, thanks Steve. If I get inspired maybe I'll fire up ft8sim and ft4sim 
and run some experiments.73, Paul K6POOn Mon, Jul 29, 2019 at 9:35 AM Steven 
Franke via wsjt-devel  wrote:Paul,I don’t 
know the answer to your question(s).In addition to frequency separation and 
signal strength difference, one would have to consider overall signal strength 
(not just difference), the DT difference between the two signals, and the delay 
and Doppler spread on each of the two channels that are involved. There are too 
many dimensions in that parameter space!  Steve k9anOn Jul 28, 2019, at 8:06 
PM, Paul Kube  wrote: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 K6POOn Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel 
 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 #47DV2/W8NET in the PhilippinesLicensed since 1974Steve, 
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

___
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?

[Paul Randall]

whoosh  - sharp intake of breath
Rich you are Sooo... picky,
73 = best regards
73s = more than one best regards
73's = 73, his best regards.

As I understand, 's is possesive, so "Richard's email" is shorthand for 
"Richard, his email". I'd love to be corrected.
Nice to see the new world is equally saddled with medieval language structures.
..But in a software forum, punctuation is crucial.
So you are forgiven.

My two cents worth is;-
Before I transmit I listen a lot and use the spectrum display to select slots 
that are "empty" on both time periods. I have the magic "hold tx freq" box 
checked most always. Sending CQ I use one of these frequencies and after a few 
cycles rest and check both time slots again. If I get no replies I use another 
frequency.

On every band each receiving station has an individual spectrum to deal with, 
close-in vs dx. It's impossible to know what the station on the other end is 
receiving. The only feedback is "is he replying to me?"

So, If I am calling a DX station on what I think is a clear frequency and 
getting no replies, I try another, and another. If still no success I think to 
myself, maybe he thinks like me, maybe I don't have to look for a clear 
frequency, the DX station has already done that and is CQ'ing on it, so I call 
on his frequency, unchecking the magic "hold tx freq" box. Not easy going 
forward as the software switches you off if it detects the DX is involved in 
another QSO. But sometimes it works immediately. The clever bit is to remember 
the magic box is unchecked as you go on your way afterward. At age 70 I don't 
think of myself as a LID, I have 50 years of operating experience in there 
somewhere but my usual memory addressing algorithm seems to have changed, maybe 
i missed the update, so ... I make mistakes.

Summary - I never have any expectation that this is "my" frequency, it is too 
dynamic. I run 100W to wire antennae so getting good dx QSOs without kW+ to a 
beam means being very flexible and frequency/time hopping, not just frequency 
warming. It is S done biologically hihi.

Regarding time slots, in Europe we try to obey a rule that stations beaming 
east use the odd slot (Tx even/1st check box UNCHECKED) and vice versa. I think 
this tallies with your convention.

Huge thanks to the WSJT software team

Regards,
Paul G3NJV



From: Rich Zwirko - K1HTV 
Sent: 29 July 2019 16:37
To: Mike - W9MDB Black ; WSJT 

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

Hi Mike,
  Good on the note, but I'd correct the last line "73's".

73 means 'Best Regards'.
73's translates to "Best Regards's" (Regardses)  8-).
I know, picky, picky.

Regarding emailing 'educational' notes, I regularly do so to loud locals who 
call CQ on 6 Meter FT8 during the 1st & 3rd 15 second sequences when the band 
is open to Europe and Africa.

A TX sequencing convention for openings to Europe/Africa, has been agreed upon 
by the majority of 6M DXers. NA stations call CQ only during the 2nd & 4th 
sequences (Tx even/1st check box UNCHECKED). Very strong out of sequence 
stations cause the receiver's AGC to push very weak DX further into the noise. 
When all 6M DXers in the region are all using the same Tx sequence, we all have 
a better chance to decode weak DX signals.

Later in the day, when it looks like we have possible SSSP propagation to 
Japan, the sequencing convention is reversed. North American stations call CQ 
during the 1st & 3rd (Even) sequence. JA DXers religiously adhere to 
transmitting 2&4 to NA and 1&3 (Even) to Europe.

73,
Rich - K1HTV

= = =
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[James VK3JPK]

Steve,

Thank you very much for taking the time to answer my question in detail.  I 
will dig out the papers you reference and take a read.

Re the Gray map, that all makes perfect sense now with the hindsight of your 
explanation!

There are clearly a lot of things to learn in the source code of WSJT-X.

James (VK3JPK)

> On 30 Jul 2019, at 1:37 am, Steven Franke via wsjt-devel 
>  wrote:
> 
> Hi James,
> 
>> 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.
> 
> The code that you referenced implements noncoherent sequence estimation for 
> groups of symbols of length, N, for N = 1, 2, 3. When the channel happens to 
> be coherent over times that span several symbols this technique can 
> significantly improve sensitivity. 
> 
> A reference that discusses this technique is:
> 
> Simon, M.K., and D. Divsalar, “Maximum-Likelihood Block Detection of 
> Noncoherent Continuous Phase Modulation,” IEEE Trans. on Communications, Vol. 
> 41, No. 1, January 1993, p.90. 
> 
> As you might expect, there are dozens of articles on the topic — but this one 
> is a good overview.
> 
> After sequence estimation has determined a soft metric for each of the 2^N 
> possible symbol sequences, the next step is to derive soft bit metrics (“log 
> likelihoods”) for each of the 3*N bits that are conveyed by the sequence of 
> length N. 
> 
> There are many ways to do this and no one way is best for all possible 
> channels. We use a max-log approximation to the numerator and denominator of 
> the metric given in equation (17) of this reference:
> 
> Souryal, M. R., E. G. Larsson, B. Peric and B. R. Vojcic, “Soft-Decision 
> Metrics for Coded Orthogonal Signaling in Symmetric Alpha-Stable Noise,” IEEE 
> Transactions on Signal Processing, Vol. 56, No. 1, January 2008, p. 266.
> 
>> 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.
> 
> The Gray mapping is defined such that the bit sequences associated with 
> neighboring tones differ in only one position. 
> 
> With reference to subroutine genft8.f90, note that the 8 successive entries 
> in the graymap vector are indexed by indices formed from 3 successive bits, 
> and each graymap vector element represents a tone.
> 
> The graymap vector is defined like this:
> 
> integer graymap(0:7)
> data graymap/0,1,3,2,5,6,4,7/
> 
> For example, graymap(6)=4. This means that the bit sequence 110 (6) is mapped 
> to tone 4.
> 
> Here’s the correspondence between tones and bits that results from the 
> graymap definition given above:
> 
> tone bits
> 0000
> 1001
> 2011
> 3010
> 4110
> 5100
> 6101
> 7111
> 
> I hope that this addresses your questions.
> 
> Steve k9an
> 
>> 
>> James (VK3JPK)
>> 
>> 
>> 
>> ___
>> 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

[Paul Kube]

TOK, thanks Steve. If I get inspired maybe I'll fire up ft8sim and ft4sim
and run some experiments.

73, Paul K6PO

On Mon, Jul 29, 2019 at 9:35 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Paul,
>
> I don’t know the answer to your question(s).
>
> In addition to frequency separation and signal strength difference, one
> would have to consider overall signal strength (not just difference), the
> DT difference between the two signals, and the delay and Doppler spread on
> each of the two channels that are involved. There are too many dimensions
> in that parameter space!
>
> Steve k9an
>
> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
>
> 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
>
___
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:

Just a reflection about FT4 and FT8, sensitivity and cycle times.  From my
experience, FT4, is less sensitive than FT8. Please note my QTH is in
Caribbean far distant than stations in the mainland.  My opinion is that IF
FT4 could be improved (maybe a v2 of the mode) regarding sensitivity from
my point of view, cycle time could extend to 8.5 or even 9.5 seconds which
still is a BIG improvement over FT8 15 seconds.  Just looking for "happy
medium"  between the two metrics (sensitivity and speed). For me quality of
worked stations is more important than quantity.   But again maybe there is
a mix of those two attributes that could work for both types of operators,
and have FT4 that may work better for distant QSO's. Just remember that FT8
is a great mode that improved enormously vs JT65.

Regards!

and 73'

Edfel
KP4AJ

On Mon, Jul 29, 2019 at 12:35 PM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Paul,
>
> I don’t know the answer to your question(s).
>
> In addition to frequency separation and signal strength difference, one
> would have to consider overall signal strength (not just difference), the
> DT difference between the two signals, and the delay and Doppler spread on
> each of the two channels that are involved. There are too many dimensions
> in that parameter space!
>
> Steve k9an
>
> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
>
> 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
>
___
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/29/2019 8:37 AM, Rich Zwirko - K1HTV wrote:
When all 6M DXers in the region are all using the same Tx sequence, we 
all have a better chance to decode weak DX signals.


YES! I have sent educational emails to locals on this topic. Another 
observation is that we need to listen a lot more, while finding and 
nailing down a good spot to TX when you decode someone you want to work.


And the same is true on 160M. I'm on the west coast trying to work EU on 
160M. It takes high power and great antennas to do that, but I get very 
annoyed at others out here who CQ almost constantly. Again, it is FAR 
better to listen a lot more and pounce when you hear someone you 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] WWDIGI Tesdting

[OG55W]

Claude!

QSO is OK, if both stations have received R confirmation.
73 is meaning that You are super polite.

Keijo OG55W

-Alkuperäinen viesti- 
From: Claude Frantz

Sent: Monday, July 29, 2019 6:54 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WWDIGI Tesdting

On 7/29/19 3:39 PM, Joe wrote:

Hi Joe & all,


here is what happened.

N9UDO calling CQ

W9ET answers CQ with 'N9UDO W9ET EN43'

N9UDO replies with 'W9ET N9UDO R EN53'

W9ET responds by sending 73 round

N9UDO does not hear the 73 and keeps re-sending 'W9ET N9UDO R EN53'

W9ET is not aware that this is happening because it's TX has been turned 
off because the contact was logged. And W9ET is off looking for the next 
S to try to get.


A similar situation occurs outside of the contest mode, if the one
station sends RR73 and the partner stations sends 73, which the first
station was not able to decode. The QSO cannot be considered as ended.
This point has been mentioned many times previously.

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] WWDIGI Tesdting

[Reino Talarmo]

Hello Claude and All,
Claude wrote: A similar situation occurs outside of the contest mode, if the
one station sends RR73 and the partner stations sends 73, which the first
station was not able to decode. The QSO cannot be considered as ended. 
This point has been mentioned many times previously.

Yes, this has been discussed many times and a quite general conclusion for
normal QSOs has been that RR73 means 'I confirm your report (containing R
e.g. R-10) so I log the QSO and wish you all the best', more exactly 'I will
only resend RR73, if I receive again a report (containing R) from you,
meaning you have not received my RR73'. Also 'I am happy to receive your 73,
but I don't mind, if you don't send one or I miss that'.
Of course Claude you can always want receive 73, but then it is better to
use RRR, refer to Manual clause 7.1 second note. 
This is my understanding about minimum QSO on protocol point of view. Why it
should be different for normal QSO and contest QSO?
73, Reino oh3ma
PS. I hope that this mail clarifies the situation and does not generate
another fight!



___
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]

Paul,

I don’t know the answer to your question(s).

In addition to frequency separation and signal strength difference, one would 
have to consider overall signal strength (not just difference), the DT 
difference between the two signals, and the delay and Doppler spread on each of 
the two channels that are involved. There are too many dimensions in that 
parameter space!  

Steve k9an

> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
> 
> 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 
> mailto: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?

[Rich Zwirko - K1HTV]

Hi Mike,
  Good on the note, but I'd correct the last line "73's".

73 means 'Best Regards'.
73's translates to "Best Regards's" (Regardses)  8-).
I know, picky, picky.

Regarding emailing 'educational' notes, I regularly do so to loud locals
who call CQ on 6 Meter FT8 during the 1st & 3rd 15 second sequences when
the band is open to Europe and Africa.

A TX sequencing convention for openings to Europe/Africa, has been agreed
upon by the majority of 6M DXers. NA stations call CQ only during the 2nd &
4th sequences (Tx even/1st check box UNCHECKED). Very strong out of
sequence stations cause the receiver's AGC to push very weak DX further
into the noise. When all 6M DXers in the region are all using the same Tx
sequence, we all have a better chance to decode weak DX signals.

Later in the day, when it looks like we have possible SSSP propagation to
Japan, the sequencing convention is reversed. North American stations call
CQ during the 1st & 3rd (Even) sequence. JA DXers religiously adhere to
transmitting 2&4 to NA and 1&3 (Even) to Europe.

73,
Rich - K1HTV

= = =
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Steven Franke via wsjt-devel]

Hi James,

> 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.

The code that you referenced implements noncoherent sequence estimation for 
groups of symbols of length, N, for N = 1, 2, 3. When the channel happens to be 
coherent over times that span several symbols this technique can significantly 
improve sensitivity. 

A reference that discusses this technique is:

Simon, M.K., and D. Divsalar, “Maximum-Likelihood Block Detection of 
Noncoherent Continuous Phase Modulation,” IEEE Trans. on Communications, Vol. 
41, No. 1, January 1993, p.90. 

As you might expect, there are dozens of articles on the topic — but this one 
is a good overview.

After sequence estimation has determined a soft metric for each of the 2^N 
possible symbol sequences, the next step is to derive soft bit metrics (“log 
likelihoods”) for each of the 3*N bits that are conveyed by the sequence of 
length N. 

There are many ways to do this and no one way is best for all possible 
channels. We use a max-log approximation to the numerator and denominator of 
the metric given in equation (17) of this reference:

Souryal, M. R., E. G. Larsson, B. Peric and B. R. Vojcic, “Soft-Decision 
Metrics for Coded Orthogonal Signaling in Symmetric Alpha-Stable Noise,” IEEE 
Transactions on Signal Processing, Vol. 56, No. 1, January 2008, p. 266.

> 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.

The Gray mapping is defined such that the bit sequences associated with 
neighboring tones differ in only one position. 

With reference to subroutine genft8.f90, note that the 8 successive entries in 
the graymap vector are indexed by indices formed from 3 successive bits, and 
each graymap vector element represents a tone.

The graymap vector is defined like this:

integer graymap(0:7)
data graymap/0,1,3,2,5,6,4,7/

For example, graymap(6)=4. This means that the bit sequence 110 (6) is mapped 
to tone 4.

Here’s the correspondence between tones and bits that results from the graymap 
definition given above:

tone bits
0000
1001
2011
3010
4110
5100
6101
7111

I hope that this addresses your questions.

Steve k9an

> 
> James (VK3JPK)
> 
> 
> 
> ___
> 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] MacOS WSJT-X v2.1.0 users please read

[John Nelson via wsjt-devel]

Hi Bill,

Another report from 10.12.6 along with 10.11.6:

> At line 2 of file /Users/bill/wsjtx-prefix/src/lib/hspec.f90
> Fortran runtime error: Actual string length is shorter than the 
> declared one for dummy argument 'mycall' (-4294967284/12)

This refers to your comment to Steve:

—
it looks like there's a common thread emerging with strings passed between C++ 
and Fortran. I squashed one of these before the release but it seems there are 
others. I think it is related to a Fortran compiler upgrade on my build 
machine. The problem is almost certainly that some of our code is using 
techniques for passing C strings to Fortran that are not guaranteed to be well 
defined and the later versions of gfortran are not assuming that those 
techniques should work. I do have a background branch in progress to move all 
C++/Fortran boundary crossing code to more robust use of ISO_C_BINDING, I guess 
that will have to be promoted to a higher priority.
—

The work-around concerning LoTW does not cure this Fortran problem.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WWDIGI Tesdting

[Joe]

I was testing my set up with a few locals for the Up-Coming WWDIGI 
Contest, and we discovered something, that is NOT a HUGE issue, but 
looking for a workaround.


here is what happened.

N9UDO calling CQ

W9ET answers CQ with 'N9UDO W9ET EN43'

N9UDO replies with 'W9ET N9UDO R EN53'

W9ET responds by sending 73 round

N9UDO does not hear the 73 and keeps re-sending 'W9ET N9UDO R EN53'

W9ET is not aware that this is happening because it's TX has been turned 
off because the contact was logged. And W9ET is off looking for the next 
S to try to get.


This is with the N1MM+ & WSJT-X set up. Running with the Auto Log box 
checked and the special contest with the NA VHF chosen.


N9UDO can manually add the EN43 and manually log the contact,

Thinking if the 73 is it a must have for a valid contact?  if so, maybe 
the W9ET side should not shut off the TX enable button till it gets the 73?


or how should this situation be handled?

Joe WB9SBD
--
Sig
The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
http://www.idle-tyme.com
___
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]

I agree with Steve.
 Like most old time (mature) hobbies the early pioneers are either SKs or 
nearing the time when they can no longer operate. We need young blood into the 
hobby. Not many, if any will build any more, so we must move a bit into their 
sphere. 
They are growing up in the “digital” times and are dragging us into the 21 
century.
They need an Elmer not a head master.
If you are not willing to teach by setting example then stay away from the new 
and experimental modes and stick to SSB and CW.
I do not know when they”lid” terminology originated, possibly it should be 
banned from our vocabulary and replaced with “how can I help “
Enjoy.




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




> On Jul 29, 2019, at 02:03, Stephen Ireland  wrote:
> 
> Hmmm . trying to stay out of this one but can’t
> 
> Even a few minutes back on 20m minute I just had an op do just as Andy K3WYC 
> reported .. and then that very same station call CQ... 
> 
> The solution is as Bill and many others report to set “Hold Tx Freq” ... and 
> to ensure that this is set as default. 
> 
> At a technical level, perhaps any version upgrades (regardless of previous 
> state) should set this?
>  
> Yet there is also an ethical aspect to this discussion it also highlights 
> the issue and concept of the arrogant term “LID” You see some ops now 
> sending (frustration) messages such as “LID ” ...
>  
> Utilising this arrogant obnoxious term degrades all the Amateur community.
>  
> Perhaps the greatest “LID” is actually the one identifying potential “LID’s”?
> 
> Using the term “LID” in the first place is not helpful for the growth and 
> development of AR – with AR  being a regulated place of education and 
> learning that should be safe (including bullying-free) for people of all ages 
> and ways of life.
> 
> Many dominions are now permitting entry-level Licence classes to have digital 
> mode access, with more and more dominions (such as Australia) proposing and 
> granting these rights this every day. 
> 
> This opens the whole discussion internationally of whether entry-level ops 
> with entry-level qualifications, with potentially low competency levels, 
> should really have access to Digital modes – especially new and developmental 
> modes such as the relatively immature FT suites. This matter should be taken 
> up as a general discussion point with the IARU and perhaps a clear position 
> put forward for the guidance of all Amateur regulatory domains.
> 
> Operators need to learn and will make what some perceive to be mistakes ... 
> and the only way they get better is through observation, practise and through 
> constructive guidance from others. 
> 
> Perhaps also a bit of tolerance (and massive discouragement of the use of the 
> term “LID”) is required ... and not just with the JT modes either?
>  
> 73
> 
> Steve I
> 
> Sent from Mail for Windows 10
>  
> From: rjai...@gmail.com 
> Sent: Monday, July 29, 2019 1:24:50 PM
> To: WSJT software development 
> Subject: Re: [wsjt-devel] Lid operators or bad design?
>  
> 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
___
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?

[Stephen Ireland]

Hmmm . trying to stay out of this one but can’t

Even a few minutes back on 20m minute I just had an op do just as Andy K3WYC 
reported .. and then that very same station call CQ...

The solution is as Bill and many others report to set “Hold Tx Freq” ... and to 
ensure that this is set as default.

At a technical level, perhaps any version upgrades (regardless of previous 
state) should set this?

Yet there is also an ethical aspect to this discussion it also highlights 
the issue and concept of the arrogant term “LID” You see some ops now 
sending (frustration) messages such as “LID ” ...

Utilising this arrogant obnoxious term degrades all the Amateur community.

Perhaps the greatest “LID” is actually the one identifying potential “LID’s”?

Using the term “LID” in the first place is not helpful for the growth and 
development of AR – with AR  being a regulated place of education and learning 
that should be safe (including bullying-free) for people of all ages and ways 
of life.

Many dominions are now permitting entry-level Licence classes to have digital 
mode access, with more and more dominions (such as Australia) proposing and 
granting these rights this every day.

This opens the whole discussion internationally of whether entry-level ops with 
entry-level qualifications, with potentially low competency levels, should 
really have access to Digital modes – especially new and developmental modes 
such as the relatively immature FT suites. This matter should be taken up as a 
general discussion point with the IARU and perhaps a clear position put forward 
for the guidance of all Amateur regulatory domains.

Operators need to learn and will make what some perceive to be mistakes ... and 
the only way they get better is through observation, practise and through 
constructive guidance from others.

Perhaps also a bit of tolerance (and massive discouragement of the use of the 
term “LID”) is required ... and not just with the JT modes either?

73

Steve I

Sent from Mail for Windows 10


From: rjai...@gmail.com 
Sent: Monday, July 29, 2019 1:24:50 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Lid operators or bad design?

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 
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
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