I completely agree with your comments, although I think the "FT8
Kool-Aid" slam is unwarranted.
But as I have said before, it's not the mode (FT8 or FT4) that is the
problem ... it's the fact that WSJT-X is a rigid and contest-unfriendly
user interface. The mode itself gives us great sensitivity and
bandwidth usage, and FT4 is fundamentally fast enough for contest
usage. WSJT-X, on the other hand, is built around such a preset
assumption for what a QSO should look like that any deviation due to
propagation or operator error causes great amounts of confusion.
I think it should be entirely possible to wrap a proper UI around the
core FT4 engine that still adheres to the fixed time windows required to
achieve the desired performance, but has a more conventional, flexible
message exchange format. If the UI required the "meeting of the minds"
you describe instead of reliance on the machine doing it for us I think
we'd be far better off.
The mode isn't the problem ... the current user interface is. I wish I
was a programmer capable of building a proper contest UI around the
existing open source FT4 engine, but I'm not. Done properly, I think
such a UI might look something like this:
1. Adherence to fixed time frames that are required by the physics of
the mode.
2. Flexible message format that still has both send and receive
callsigns (required because of the split frequency nature of the mode)
but allows a more generalized report as long as it stays within the bit
limit.
3. Uses UDP to feed the exchange information to N1MM+, with N1MM+
handling the logging and scoring for different contests just as it does
now for any other mode. Think MMTTY for FT4.
4. A better layout with better utilization of space.
5. Allows function keys for various actions (such as Monitor pause,
Transmit, Halt, Message selection, etc) instead of mouse clicks.
The problem is that I am not a programmer, so I think the mode is going
to suffer unless and until somebody who is a programmer is willing to
tackle the job (for which I'd be willing to contribute modest funds). I
am pretty certain that a contest UI for FT4 is not on K1JT's priority
list, so I think it would have to come from somewhere else.
73,
Dave AB7E
On 1/13/2020 9:24 AM, Tim Shoppa wrote:
I was a vigorous participator in the CQ WW Digi and have some thoughts
about the high NIL rate.
First of all - I was not at all surprised. I work with some DXpedition QSL
managers and they have been complaining about the incredibly high NIL rate
seen with DXpeditions in FT8 mode for a while now.
In CW, SSB, or RTTY there is (at the 99% accuracy level) a "meeting of
minds" over the air as to whether the QSO was complete or not on both
sides. Part of it the fraction of a second it takes in these modes to send
a "thanks" or "TU" before moving to the next caller. Another part is that a
human actually makes the call on each end as to whether it was complete
using the human's best judgement, and the cycle time it takes to be sure is
infinitesimal (just seconds, not a 30-second cycle).
In FT4/FT8 this meeting of minds is far more slippery and tenuous. This is
completely inexplicable to those who have drunk the FT8 Kool-Aid because
they trust the computer for all aspects of a QSO. As a result the FT4/FT8
NIL rate (even with DXpeditions) is far far higher than the traditional
modes. Adding a whole additional transmit/receive cycle for an extra level
of confirmation may not actually improve things but make it worse because
if reception is lost by one side but not the other in that extra cycle that
itself will lead to more NIL's.
Tim N3QE
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|