[SADXA] WSJT-X Musings and food for thought

[Wes Stewart]

Somewhat against my principles I decided recently that it might be necessary to 
use these imaginary modes* someday to work a new one (SV/A). So I set out to 
investigate them. Initially, I tried receiving some JT65.  I got it working okay 
just about the time FT8 was announced.  So I began to play with FT8.

Since this is a DX club and I'm a DXer here are some observations from this 
perspective.

While a new revision is promised that will fix this, currently split operation 
is very difficult.  To set the RX frequency to a desired station, one 
double-clicks the call in the band activity window and optionally sets the 
transmitter to active. Unfortunately, even if you've set your TX frequency to an 
empty spot, the double-click equates the TX to RX frequency.  I haven't seen any 
real pileups yet but when they happen they will all be on the DX frequency.  If 
you do call a guy off his frequency be prepared to have him answer you on your 
frequency after he double-clicks your call.

Guys have admitted that with the automatic features used, they have been out of 
the room and come back to find that they "worked" someone.  One guy said that 
since this happened to him he wasn't going to QSL the other guy.  I asked him 
why.  It wasn't the other guy's fault that the reporter was out of the room, why 
shouldn't he get a QSL?  He had no answer.

I've been operating search and pounce for DX only.  I will only work previously 
worked stations on another band (slot).  My experience with other digital modes, 
RTTY and PSK, is that a very high number of ops use LoTW and QSL rates are high. 
FT8 is another story.  There was initial delay by some guys who didn't want to 
upload logs until ARRL recognized FT8 as a separate mode (WAS and VUCC only).  
Of course for DXCC purposes, it's just "Digital" or "Data."  LoW speaks of Data, 
but DXCC awards are for "Digital". Go figure.  But the ADIF standard and ARRL 
are now accepting FT8 as a mode, but the QSL rates are still abysmal.

Admittedly over a much long time, and with a few paper QSKs thrown in, my RTTY 
stats are 258 entities worked and 241 (93%) confirmed, mostly via LoTW.  
Contrast that with FT8 with 58 worked and 28 (48%) confirmed via LoTW.

I think I will set a personal standard, at least for awards purposes, that 1) I 
will be at the controls of the station. 2) I won't count any QSO that couldn't 
have been copied on CW. 3)  I won't count any QSO that requires the software to 
have prior knowledge of the two station calls or could not be copied by an 
uninterested third party.

I'm sure there will be critics who declare that I'm an old fogy who is longing 
for the return of spark.  Nothing could be further from the truth.  I have 
worked on the cutting edge of new technologies for years.  But, I also believe 
that there should be some value added by way of operator skill.

Wes  N7WS


* I call them imaginary because the programs actually decode signals that aren't 
there (1), or use databases of callsigns as lookup tables to guess received 
calls (2).

In a discussion I had with one of the FT8 developers about the TX delay in 
Elecraft radios causing transmission to be delayed until after the decode window 
opened, he opined that it might not matter because the decoder can "decode" 
signals that it never heard.

(1) Quoting G4WJS: "For FT8 the net effect is that
up to about 5 seconds of a message may be missing yet still
be decoded. The amount missing can be either a truncation or
parts of the message below the decoding threshold. The FT8
message is structured with sync symbols at the start, middle
and end so missing the start or end may have less impact
than missing other parts since mostly sync symbols may be
lost and they contain no message information."

(2) Another compelling paper discusses JT65 as used on EME. 
http://www.sm2cew.com/Digital%20communications%20using%20minimal%20transfer.pdf