Personally, I don't see how weak signal work and contesting are ain the
least mutually exclusive. I've done a lot of contesting and being able
to work more weak ones is a huge advantage. Even more relevant, I'm
convinced that the format of FT8/4 encourages a lot more hams to
participate in contesting for reasons I've pointed out before:
1. Decoding is either there or not and all signals are (supposedly)
spread out as if everyone was operating split, which means that a weaker
signal has a similar chance of being able to make a contact as a
stronger one. FT8 is a playing field leveler.
2. The fixed format of FT8/4 makes "running" far less intimidating for
casual operators than for other modes.
The fact is that the appeal of FT8/4 for contesting goes beyond its weak
signal capability.
In any case, the WSJT manual says:
"Standard messages consist of two 28-bit fields normally used for
callsigns and a 15-bit field for a grid locator, report, acknowledgment,
or 73."
It is true that my earlier suggestion would require 16 bits, but 15 bits
(per above) still offers 32,768 possibilities ... more than enough to
cover every "county"on earth, I think.
By the way, I'm not stomping for WSJT to be able to handle QSO
parties. I'm just trying to understand why it would be a problem.
73,
Dave AB7E
On 9/26/2019 10:33 PM, Robert A. Klahn (AD6I) wrote:
Im a little hesitant to jump into this conversation because Im new to
the list, but here I go.....
Support for long-ish messages, such as what you find in some State QSO
parties, or Sweepstakes comes to mind, is somewhat contradictory to
the original purpose of WSJT-X, which is, weak signal work. With weak
signals, you want to exchange as little information as possible, with
a reasonable amount of error checking. In contesting, the messages are
not short enough to fit into this model, and the "fill" as an error
check is at best, expensive.
This is not to distract from Bill, G4WJS, and company efforts to fit
contesting into WSJT-X. It certainly has contributed to the
popularity, but let us not take the idea to its extremes.
Each mode has a fixed number of message bits. Assuming Dave, AB7E and
my math is right, 16 bits would be required to exchange the
county/state/nation combination as suggested. I don't recall exactly
how many bits are in an FT-X message, but thats just an enormous amount.
Let us assume for a moment that Texas, with its 254 counties, is the
greatest number of counties that would need to be represented in a
message exchange. That is still 8 bits. And after that, you would need
some agreed to overlay of the message for each QSO party that maps
these 8 bits. Seems to me that we are deviating from the point of weak
signal work.
Just my thoughts. YMMV.
Thanks. Robert. AD6I.
On Thu, Sep 26, 2019, at 9:27 PM, David Gilbert wrote:
I'll admit I'm not really understanding the discussion here so please
be gentle with me, but would having only one large table change the
situation? I think we're only talking about the bits required for
transmission, right?
If WSJT used unique non-descriptive three letter/number combinations,
there would easily be enough to cover every county in the United
States and probably all of the rest of the world as well. I.E., ....
AAA, D9Y, 5V7, etc. After all, 35x35x35 (I'll assume zero is
protected) = 42,875.
If such a large single table was feasible for WSJT, all it would take
is a simple but separate find-and-replace app that translated the
resulting WSJT/N1MM/Writelog log to the county designators currently
used by each QSO Party before official submission. If doing so made
any sense, the WSJT devs could do this completely on their own and it
would be transparent to the multiple QSO Parties.
Of course, the user would have to know his appropriate three
character designator (or WSJT would have to translate each user's
county name upon initialization, but that wouldn't be subject to
message transmission limits). I already have to know whether to use
CQ zone 3 or ITU zone 6 for my location depending upon the contest.
To be honest, in my opinion something like this should probably have
been done already for QSO Parties in general anyway.
Just a thought ...
73,
Dave AB7E
On 9/26/2019 12:55 PM, Ron WV4P wrote:
Almost all US Counties, within the state, have a Number.
Could, for the purposes of QSO Parties the designation be Hardin -
HARN - 40 as would be the case of mine ? Would that help any, just
using an already assigned number VS the County Name ? Ron WV4P
On Thu, 26 Sep 2019 at 13:48, Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
On 26/09/2019 11:59, John Zantek wrote:
>
> ØThe bottom line is that there are still a handful of selectors
> available in the FT4/FT8/MSK144 message payload bits that
could be
> used for new message schemes but nowhere near the number that
would be
> needed to support a series of county based QSO parties or similar.
>
> But Bill, isn’t the FD message structure just that, with a lookup
> table that doesn’t exceed the payload ceiling?
>
> What’s the difference between the existing QRegularExpression
> field_day_exchange_re with a table of ARRL/RAC Sections and a
proposed
> QRegularExpression WA_QSO_party_exchange_re of WA counties as
I had
> suggested at the start of this thread?
>
> 73 John W7CD
>
John,
the source code you are referring to is the validation for GUI
input
when entering one's state or province, it has no bearing on what is
packed into transmitted messages other than the selected value
is used.
If you were to have a different set of information to pack into
messages
then you must also pack into the message the selector to tell the
receiving decoder to interpret the message bits in the way that you
require. Even if your proposed table of counties only take the same
number of bits to store as the RTTY Roundup values do; you still
need
another bit somewhere else in the payload to select that table.
Extend
that to each and every QSO Party set of counties and you will
need many
more bits to select the right table. That many bits are not
available in
the FT4/FT8/MSK144 payload, it might be possible for one or
maybe two
QSO Party formats but who decides which QSO Parties get support and
which ones are excluded?
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
