Hi, Joe and team...
I think the ver. 2 FT8/MSK supporting six digit grids is a great idea.
Now that you're willing to encode six-digit subgrids and have a bit more
payload,
I'd like to request support of six-digit subgrids for the NA UHF and microwave
contests.
The requirements are similar to, but not same as, support for the EU VHF
contests.
---- background ----
The ARRL 222 and Up contest ("NA UHF") exchange requires:
- support for 6 digit grids (like EU VHF)
- support for /R (like NA VHF, unlike EU VHF)
The ARRL 10 GHz and Up and SBMS 2 GHz and Up contest ("NA SHF") exchanges
require:
- support for 6 digit grids (like EU VHF)
I believe that the other NA UHF/SHF sprints would also be covered by the above
two cases.
None of NA VHF and up contests use a serial number or /P (unlike EU).
Nor do they require a signal report, but if it should happen to fit in the
payload without increasing the number of messages/QSO, why not let the other
guy know how well he's getting out?
One property of terrestrial SHF is that the narrow beamwidths (typ just a few
degrees) lead to using side channel coordination (vhf/uhf ssb/fm/etc) to
acquire signal and align the antennas by an exchange of full energy carriers
prior to the QSO.
Together with the low density of SHF operators, this means that there is no
confusion about who is replying, unlike in an HF pileup or contest, where
repeating the other station's call helps to establish who is being answered, so
I propose the partial suffix ID (see below) in the interest of shaving one
message out of the total QSO duration.
IMHO there is also little chance of confusion at UHF and VHF (except possibly
during a 6M Es opening), so I propose the shorthand suffix ID below for the UHF
contests as well as SHF.
I leave it to you to decide if you dare to do it at VHF as well. Personally, I
see no problem, as a false ID due to a shorthand aliasing (in the second
proposed message) will be caught during the following messages (the rest use
full IDs).
Even if you won't buy into my shorthand idea to streamline the sequence length,
please still add support for NA six-digit contests.
--- proposal ---
If I understand the new plan described in your whitepaper and email, there will
be no QSO modes "on the air", just a collection of per-message encoding formats
(i3.n3) and various QSO modes only "at the sender" when generating standard
message sets and when autosequencing. The decoder would recognize any message
regardless of QSO mode, but the autosequencer might still be fooled by an
unexpected sequence, so we still need to define the expected seqeunces.
So, I'm asking for these new expected sequences and some new encodings:
--- NA UHF contest exchange ---
CQ TEST K1ABC/R FN42KH
ABC W9XYZ/R EN37VQ
W9XYZ/R K1ABC/R R-12
K1ABC/R W9XYZ/R R-10
W9XYZ/R K1ABC/R 73
If I understand the encoding and payload restrictions correctly,
- the first message would be a new 0.x format, similar to 0.2, but using the 19
deleted sequence bits to extend the grid bits from 4 to 6 digits (needs 10
bits) and to provide full compound callsign and /R support for the first
station
- the second message a new 0.x format (perhaps same format as the first),
similar to 0.2, that supports full callsign (including /R option) and 6 digit
grid off the second station. There won't be enough bits to fully identify the
first caller... but if we send the first station's suffix (15 bits) as a
shorthand ID, that should be enough for the decoder to highlight the message as
a reply and to drive the autosequencer to advance. If I'm counting correctly,
we can afford to send more than the suffix "ABC", but not the full call, so
maybe even send "1ABC" in place of "K1ABC/R"
- the third message is an existing encoding if we don't require /R support
(probably OK, as both sides have already met the /R requirement in other
messages; we just need to be sure the logger includes the /R). If we want to
include /R support for one side or both, that would be a new format, I think.
- the fourth message is same format as the third
- the fifth message tells the second station that his roger has been heard and
he can stop repeating it. Again we can use an existing encoding if we don't
require /R support. If we do, reuse the new format invented for messages 3&4.
--- NA SHF contest exchange ---
Same as UHF, except no need for the optional /R rover ID
--- tail ending ---
Note that if a third station wants to 'tail end' on the first QSO, the
autosequencer could also support starting with the second message:
CQ TEST K1ABC/R FN42KH
ABC W9XYZ/R EN37VQ
W9XYZ/R K1ABC/R R-12
K1ABC/R W9XYZ/R R-10
W9XYZ/R K1ABC/R 73
ABC W8STR/R EM81AV
W8STR/R K1ABC/R R-12
K1ABC/R W8STR/R R-10
W8STR/R K1ABC/R 73
--- free form messages ---
Somewhat unrelated, but triggered by how I sometimes work around things today
...
It would be great if a free form message could be entered on he fly in any of
the autosequencing slots, not just the last (so we don't have to compose and
type the message and click a button within 15 seconds :).
It would be even better if when a free form message (and I guess a telemetry
message, etc) is entered, the encoder dis a quick check an echoed back what
will be sent if the message is too long or uses invalid characters ... right
now, we don't see this until the message starts transmitting and it's too late
to fix it.
Also, IIRC, sometimes a free form message entered on the fly is erased and will
revert to one of the standard messages after the program feels it's no longer
needed... I'd prefer that it stay available (at least in the drop down), so
that it can be repeated or edited for use in the next message. This may be
because the only free form slot right now is the "73" slot and the program
assumes that the QSO is over after the first use of that slot.
73 and thanks for your consideration,
Mike Lavelle, K6ML
------------------------------------------------------------------------------
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
