Dave,
You can't look at it as a simple case of 15 bits, you have to look at
the bit size for each set of characters. This is the reason why FD
requirements can be met in the 77 bits, but the 'winter' field day
cannot. The winter field day uses the same number of characters, but
the bit requirements are beyond what the package can hold.
Neil, KN3ILZ
On 9/27/2019 5:17 AM, David Gilbert wrote:
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
---
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
