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
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
