Joe/everyone...
On 8/17/2017 7:45 PM, Joe Taylor wrote:
Hi Alex, Iztok, and all,
Thanks for your comments and suggestions for optimizing FT8 QSO rates
in pileup conditions.
In my message posted yesterday I kept things simple and did not go
into any detail about what to do when things do not go exactly "by the
book". Of course you are right to emphasize that these issues must be
addressed.
How best to keep busted or difficult QSOS from dreadfully slowing down
a run? After further thought, I've begun to like something close to
Alex's original suggestion. Suppose we define five new standard
message formats that start with the fragments "73 NOW ", "73 CQ ", "73
CQ UP ",
"NIL NOW ", and "NIL CQ UP ". Example messages would look like these:
73 NOW W9XYZ R QH72
73 CQ VK9MA QH72
73 CQ UP VK9MA QH72
NIL NOW W9XYZ R QH72
NIL CQ UP VK9MA QH72
I feel a key to success in handling large pileups is getting callers to
stop calling when the DXpedition station is trying to complete with a
decoded caller. If these messages above will cause
everyone-who-is-not-being-called's AutoSequencer to disable
transmitting, I am all for it. If not, then people will simply call all
the time until they finally make it and QRM will reign. I sense that
both the DXpedition's call and the decoded callsign need to be in these
messages for the non-worked stations' AutoSequencer to stop.
The first three types tell the previously worked station that she's in
the log. The last two terminate a failed QSO attempt, tell that
operator he is NOT in the log, and attempt to start a new QSO.
A series of QSOs made from VK9MA might then look something like this:
1. CQ UP VK9MA QH72
2. VK9MA K1ABC FN42, K9MA W9XYZ EN37, VK9MA WB6DEF CM88, ...
3. K1ABC VK9MA R QH72
4. VK9MA K1ABC RRR
5. 73 NOW W9XYZ R QH72
6a. VK9MA W9XYZ RRR (not copied at VK9MA)
6b. VK9MA W9XYZ EN37 (W9XYZ did not copy #5, he calls again)
7. W9XYZ VK9MA R QH72 (try him again)
8. VK9MA W9XYZ RRR
9. 73 NOW WB6DEF R QH72
10. VK9MA WB6DEF RRR (not copied at VK9MA)
11. WB6DEF VK9MA R QH72 (try him again)
12. VK9MA WB6DEF RRR (still not copied at VK9MA)
13a. NIL NOW G4AAA R QH72 (on to the next one...)
13b. NIL CQ UP VK9MA QH72 (nobody in the queue, call CQ again)
Do you see any situations not adequately covered by this scheme?
This might not be a situation, but from plenty of first hand experience
at DXpedition pileups, the DXpedition operator cannot be expected to use
a mouse. Never used one once on VP8STI or VP8SGI. Takes too long to
register the mouse over some small button on the screen and then click.
All control of the software needs to be using keyboard shortcuts. You
never want to take your eyes off the screen to find the mouse and then
re-align yourself with the desktop. F-keys are cool.
Offhand, I do not like the idea of the DXpedition station jumping
around in frequency. (No doubt that could be made to work, but it
seems better to me that he should stay put.) Maybe if he transmits,
say, on 14.070 he should respond only to calls between 14.071 and
14.075, or something like that.
A concern I have is jamming. If the DXpedition station is on one
frequency, it's pretty simple to jam it. I really think the idea of
Russian Roulette might work. Since the pileup will be constrained to one
or two "voice" channels, it might be acceptable (unlike the previous use
of the protocol on SSB which took up the entire 20 m band on some
infamous DXpditions).
73 and thanks for working this process out in the open.
Ned/AA7A
(newest member of the upcoming KH1 DXpedition team)
------------------------------------------------------------------------------
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
