Hi Grant,
Thanks for your message of May 11, sharing your thoughts after operating
as YJ0AG. It's good to hear that you achieved QSO rates as high as
50/hour using standard FT8 mode.
You and others will be happy to know that a General Availability (GA)
release of WSJT-X Version 1.9.0 is planned in about a week. It will
permit full operation in FT8 DXpedition Mode (Fox or Hound) without
callsign restrictions, but will not allow such operation in any of the
conventional FT8 sub-bands.
The release announcement will state once more that DXpedition Mode
should be used only in rare-entity circumstances in which sustained QSO
rates well above 100/hour are expected by the Fox station.
In the future we will consider your suggestions for possible GUI
enhancements for standard FT8 mode. In passing, though, I will note
that in an operation like yours at YJ0AG, if the potential hourly QSO
rate is 100 or higher you might be best served by using Fox mode. Even
with NSlots=1, the QSO rate can be doubled. Moreover, the Fox operator
already has a number of options for filtering and sorting the list of
calling stations.
-- 73, Joe, K1JT
On 5/11/2018 6:41 PM, Grant Willis wrote:
Hello,
I recently returned home having run a mini DXPedition from Vanuatu for 2
weeks in the South Pacific as YJ0AG. While there I ran a lot of FT8
operations among other modes. At Joe’s request I deliberately did not
run expedition mode, and can see that real problems are going to arise
if a way to control access to expedition mode as a Fox is not hard coded
into the software before the GA release. At the same time, if you can’t
run expedition mode, there are some enhancements that I would have found
very valuable running FT8 pileups from Vanuatu in standard mode (where I
still reached 50 contacts/hr). I am hoping perhaps some of these could
be taken on board by the developer team.
Expedition Mode Useability Feedback
Firstly, for Expedition Mode, access control to the mode is paramount
before pandemonium reigns. We are already seeing expeditions trying to
use it on the main FT8 channels (ignoring the fact that it isn’t
supposed to be used yet). I would strongly recommend the following
additions to the software be considered prior to GA release:
1.Can access to expedition mode only be via a time restricted key -
expeditions planning to use the mode as a FOX have to apply for a key
against an expedition callsign that the software is programmed to
recognise as only valid between certain dates. You have to have the key
and enter the correct callsign to enable fox mode. Make sure of course
that the key cant be decrypted back or reverse engineered (goes without
saying probably).
a.To support this I see that there would need to be an application
portal perhaps via the WSJT website where expedition operators can apply
for expedition mode access, and potentially have this administered
through 2-3 of the major DX Associations – eg NCDXF, CDXC etc
In this way you can minimise the risk of FOXs proliferating when the
people are not really expeditions. The definition of expediton may also
need to be considered as any operator in a rare DXCC entity that has
regular pileup situations to contend with (eg XZ2A in Myanmar, 9G1SD in
Ghana, VK0AI on Macquarie Is etc).
2.Can expedition mode only be activated in the software when the
selected radio frequency is NOT one of the main FT8 channels? Lock it
out so that you cant turn on fox or hound mode if you are on one of
1840, 3573, 7074, 10136, 14074, 18100, 21074, 24915 or 28074? Other
proposed Expedition mode frequencies are included in the software so let
it only be activated away from the main channels?
These two steps should prevent widespread abuse of expedition mode.
Standard Mode Useability Feedback
In standard mode when faced with a major pileup, the following ideas
would be very helpful. These are mostly GUI changes.
1.In standard mode there is a simple tweak to the GUI that would be
helpful. When I am being called currently I get everyone coming back
marked in RED - I can have up to 50 stations replying (and did when I
was running YJ0AG last month). Now I do not always let it run with call
first for various reasons – mlostly revolving around trying to provide
ATNOs or target particular call areas). What would be really handy is if
the station I was actually working who was listed in my message
sequencves was in a colour other than the colour of the stations calling
me. I could pick them out much easier if I wanted to follow their
sequence and make sure the contact didnt just stall for some reason. (I
do watch very closely otherwise I found if you get stuck on someone
having issues you can loose minutes and badly hit your contact rate).
2.If I am observing things correctly, the call first is taking the first
station on the decode list. I find with pileup situations where there is
a dominant country that is not the area I want to work (say for example
Japan) I have to disable call first and make my selections by hand to
get around it. This list appears to be populated with the lowest station
on the band or it seems sometimes the lowest plus strongest which is I
presume because it was decoded in the first pass, with the weaker lower
stations being decoded on the second pass. What would help this is some
sort of randomisation function within the call first algorithm that
ignores the "first decoded" and instead calls a random station from the
list. It would reduce the chances of being dominated by strong stations
from one area low in the band to the detriment of other fainter stations
which otherwise have no hope of being picked unless the callers from the
dominant country stop calling. I can see there are issues where on slow
processors with deep decoding selected you might still be finishing up
the decoding process before the next slot - but from a practical
standpoint that doesn’t really matter when the pile is 20 deep - you
will pick someone - and if there is no pile - you will pick whomever you
decode anyway.
3.More controversially - provide a call first filter mechanism. The need
to black list stations calling who can’t seem to hear you but always get
trapped as the first you decode is there. The ability to say take all
calls but calls starting with J would be useful as well. Pit timeouts on
the black list perhaps - you can set it for say 30 minutes maximum and
it isn’t persistent with software start-up - but something like that
would be most helpful in managing pileups when again you are trying to
target more needy call areas (like US East Coast or Europe from Vanuatu)
over Japan (which I could work in my sleep hi hi).
Anyway more than enough to consider. I wish I could code properly so I
could help build some of this but alas that is not my strong suit. Happy
to be involved as a tester however.
Best 73 de Grant YJ0AG / VK5GR
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
