One way to address the single issue of a SuperFox with mismatched Tx
and Rx dial frequencies is this small change to setXIT. My
understanding is that, in the SuperFox case, setXIT still must
actively set the Tx frequency, because it may often be misconfigured
if (for example) normal FT8 had been us
Here's apparently a bug in both WSJT-X 2.7.0-rc7 and WSJT-X
v2.7.1-devel 241005-RC7 (aka yesterday's wsjt-x_improved). The essence
is that a SuperFox transmitting station can sometimes accidentally be
misconfigured with their radio's dial frequency different on transmit
and receive (e.g., transmit
> Be sure to setup a contest-specific CQ message, e.g., CQ FTRU
If you transmit CQ FTRU instead of CQ RU, then the number of stations
decoding your CQ will (on average) be fewer.
The a1 AP decoding for FT4 and FT8 depends on the standard CQ message
format for the selected contest setting. For exa
> Log a QSO when you send RR73 if you are reasonably confident it will be
> copied.
I'm also active in FT4/FT8 contesting (https://ww-digi.com/scores.htm
etc.), and have worked on design of a different (not yet active)
FT4/FT8 contest for a different major sponsor. I feel that this
guideline shou
> Was there any more recent info on frequencies for field day?
https://groups.io/g/FT8-Digital-Mode/message/2202 has a different plan
with (for example) 14130 instead of 14080. That might be a better
place for discussion, because Field Day frequencies for this year
probably won't have a direct eff
Yes, possibly it would help if individual users choose an OS other
than Windows 10 Home. This doesn't solve the general problem. The
presence of any users with misconfigured time synchronization hurts
everyone because it reduces the probability that an arbitrary QSO
attempt will be completed effici
WSJT-X on Windows has generally expected that the machine has
third-party NTP software and doesn't use the Windows Time service.
This affects clock accuracy, and consequently affects decoding
performance in various ways, including the possibility of being
affected by the recently identified "negati
hint65.f90 currently has "MAXMSG=2*MAXCALLS + 2 + MAXRPT" and
generates thousands of hypothetical messages of the form:
msg=mycall//' '//call2(i)//' '//grid2(i)
msg='CQ '//call2(i)//' '//grid2(i)
These aren't as helpful when chasing an EME DXpedition. Is there
interest in an increase to "MAXM
I had an issue where, after upgrading from 1.8.0-rc1 to 1.8.0-rc2, no
receiver output was shown in the Wide Graph and no signals (e.g., FT8
or JT65) were decoded. It turned out that WSJT-X.ini had a UseRef=true
line in the [WideGraph] section. Changing it to false fixed the issue.
For me, this is
