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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
