Re: [wsjt-devel] State QSO Parties

[Paul Kube]

On Thu, Sep 26, 2019 at 10:03 PM David Gilbert 
wrote:

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

The WSJT modes can code any Maidenhead square (well, minus RR73). There are
32,400 of those, so by using one of the available selector bits, it ought
to be possible to switch to an alternate locator scheme almost as rich as
what you propose. I'm not sure it would be rich enough to map to *all *the
counties, oblasts, prefectures, sections, districts etc. that will ever be
used in any contest exchange, but maybe it is.

Then there's the issue of how to manage the mapping between entries in that
selected WSJT table and all those political entities. The WSJT team would
want it to be universal, published and transparent to every user; otherwise
it involves too much of what Bill G4WJS calls "not passing all information
on air" -- I take it he is alluding to proscriptions against encrypted
amateur digital communication. I suppose that could be done, but I wouldn't
want to do it! ARRL has a hard enough time managing DXCC, which is a much
simpler problem.

73, Paul K6PO



> 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 
> 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
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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

Re: [wsjt-devel] State QSO Parties

[David Gilbert]

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

Re: [wsjt-devel] State QSO Parties

[Robert A. Klahn (AD6I)]

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

Re: [wsjt-devel] State QSO Parties

[David Gilbert]

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

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

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

On 26/09/2019 20:21, John Zantek wrote:

Am I standing out on a dangerous limb (NPI), if each QP sponsor decides, then 
compiles a branch that supports their QP, and distributes it on their QP web 
site?  As a Salmon Run sponsor, I know the desire is significant here (from 
inquiries tosalmon...@wwdxc.org), even if some other states may have said NTY.


John,

changing the interpretation of FT4/FT8/MSK144 payload bits is changing 
the protocol, that special program can no longer use the names 
FT4/FT8/MSK144 for the mode since users of the official programs will 
not be able to interoperate with this special version. It is effectively 
equivalent to not passing all information on air as you need to know 
that a special version of the software is needed before you can 
communicate with it. Not only is the above a problem with 
interoperability but also the signals will sound identical to official 
FT4/FT8/MSK144 signals and will be decoded, incorrectly, unless some 
scrambling is also included, like changing the synchronization symbols, 
so that users of the official modes will not be mislead. JS8CALL is 
similar in these respects, we insisted that the team that created 
JS8CALL from WSJT-X both used a different name for the mode and scramble 
the messages such that the official programs do not decode their message 
that had non-standard interpretations of the payload bits. Note that 
JS8CALL does have a reasonably distinctive characteristic that allows it 
to be distinguished from standard FT8 since T/R periods are not 
alternated, your proposal would not have any such distinctive 
characteristics.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[John Zantek]

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

Ahagot it.  Understood now, thank you, Bill.

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

Am I standing out on a dangerous limb (NPI), if each QP sponsor decides, then 
compiles a branch that supports their QP, and distributes it on their QP web 
site?  As a Salmon Run sponsor, I know the desire is significant here (from 
inquiries to salmon...@wwdxc.org), even if some other states may have said NTY. 
 

Pending a more global solution/new protocol payload, I'm simply looking for 
answers in behalf of our contestants.  You KNOW that the ARRL Radiosport folks, 
as well as many noobs entering the contesting community, et al, would love to 
see it.  I also eagerly await the Dec QST to see what's said about FT8 in the 
2019 FD results.

Thank you & 73
John W7CD




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Ron WV4P]

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

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

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
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[David McIntyre]

There are 3007 counties in the US versus 71 ARRL sections. That's 12 bits
versus 7.

On Thu, Sep 26, 2019 at 10:27 AM 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
>
>
> ___
> 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

Re: [wsjt-devel] State QSO Parties

[John Zantek]

*  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

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

On 26/09/2019 00:02, John Zantek wrote:

index into a table of 64 values (48 states + 14 provinces + DC + DX) takes a 
mere 7 bits to store.

Hi Bill,

Yes, I initially saw that and it's why I attempted to clone the FD table, 
substituting the 39 WA counties for 58 ARRL Sections.  That table obviously 
fits, right?

I'm guessing it wouldn't be wise to have 50 or 60 other tables for the various QSO 
parties.  Texas' table would be the basic 64 values & 254 counties; a resultant 
9 bits requirement?

Be gentle.  My Reptilian brain is being stretched.

73 John W7CD


Hi John,

see my answer to Bill, AE6JV, above.

https://sourceforge.net/p/wsjt/mailman/message/36772019/

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

On 26/09/2019 01:12, Bill Frantz wrote:

On 9/25/19 at 3:52 PM, g4...@classdesign.com (Bill Somerville) wrote:


On 25/09/2019 23:42, Bill Somerville wrote:
whereas the index into a table of 64 values (48 states + 14 
provinces + DC + DX) takes a mere 7 bits to store.


This is actually an interesting problem. We can divide the contesters 
into those activating the counties and those trying to contact them. 
The worst case I've heard is 252 Texas counties, but the 7QP will also 
have a big number.


One other problem is that some of the state QSO parties take place on 
the same weekend, and of course, some people try to make contacts in 
more than one QSO party. If the sum of all counties involved is small 
enough, it might be possible to support this behavior.


Lets assume: For the US state QSO parties, each station only activates 
counties in one QSO party. (We do need to support rovers.) It will 
need to receive locations from all the counties in that QSO party + 
the other states/provinces. People sending to it will need to know 
which table it is using.


We can select the table by the weekend data, and starting week before 
for testing. There might also be a UI affordance which allows manual 
selection for use in closed group testing. (For such testing, I 
suggest ditching the radios and just using the built-in audio of 
several computers in the same room.)


For non-US QSO parties, similar techniques might work. Consider a QSO 
party with the counties of England, Ireland, Scotland, and Wales as 
the activated counties. :-)


73 Bill AE6JV


Hi Bill,

you are missing a critical and fundamental issue. WSJT-X is used to make 
QSOs by exchanging all necessary information on the radio channel. You 
seem to be proposing that users must configure the software for a 
particular interpretation of the information bits being exchanged, that 
is not making an Amateur Radio QSO, at best it is a hybrid QSO with some 
information being passed by some means other than radio. Note that in 
FT4/FT8/MSK144 modes every receiving instance of WSJT-X or other 
applications claiming compatibility will decode exactly the same 
messages as each other given any particular transmitted message, the 
configuration of the software does not change the interpretation of the 
message bits. Unless you can find a way to send the "selector" for your 
proposed set of tables of message fields within the same message that 
sends the table index; then you are not proposing an extension to these 
modes but a different mode that does not pass all information via the 
radio channel.


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.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Jim Brown]

On 9/25/2019 5:12 PM, Bill Frantz wrote:

but the 7QP will also have a big number.


And there's another wrinkle -- 7QP and NEQP (held the same weekend) have 
five character abbreviations (two for state, three for county). But 
there's also the question of whether sponsors of these state QSO parties 
WANT digital operation. The contest club of which I'm a member, the 
Northern California Contest Club, sponsors the largest of the state QSO 
parties, and we rejected RTTY when it was proposed years ago because it 
would have fundamentally changed the nature of the contest. I'd be very 
surprised if we would feel differently about adding FT8 of FT4.


That doesn't mean that we don't like those modes -- indeed, we regularly 
win the large club competition for RTTY Roundup, we MAY have won the 
large club competition for the new CQWW Digi contest; one of our members 
(W0YK) has won the world several times from P40X RTTY DX contests, and 
has been a major mover behind bringing FT8 and FT4 to both RTTY RU and 
the new Digi contest.


It's also important to realize that a major element of most state QSO 
parties is mobiles driving around the state(s) to activate as many 
counties as possible to make it more fun for out of state participants. 
There's a bit of that with 7QP and CQP, but many counties are activated 
by expeditions, set up Field Day style, and, when possible, on county 
lines.


73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Tom Melvin]

>> For non-US QSO parties, similar techniques might work. Consider a QSO party 
>> with the counties of England, Ireland, Scotland, and Wales as the activated 
>> counties. :-)

For RSGB it’s between 2 to 8 characters along with the obligatory signal report 
’59’  :-)

As has been pointed out it’s payload size - suspect will have to wait till the 
next major release FT9? (or FT10, FT11 ….) 

It’s not a simple task even if limited to USA.

Tom

73’s

Tom
GM8MJV (IO85)





On 26 Sep 2019, at 01:12, Bill Frantz  wrote:

> On 9/25/19 at 3:52 PM, g4...@classdesign.com (Bill Somerville) wrote:
> 
>> On 25/09/2019 23:42, Bill Somerville wrote:
>>> whereas the index into a table of 64 values (48 states + 14 provinces + DC 
>>> + DX) takes a mere 7 bits to store.
> 
> This is actually an interesting problem. We can divide the contesters into 
> those activating the counties and those trying to contact them. The worst 
> case I've heard is 252 Texas counties, but the 7QP will also have a big 
> number.
> 
> One other problem is that some of the state QSO parties take place on the 
> same weekend, and of course, some people try to make contacts in more than 
> one QSO party. If the sum of all counties involved is small enough, it might 
> be possible to support this behavior.
> 
> Lets assume: For the US state QSO parties, each station only activates 
> counties in one QSO party. (We do need to support rovers.) It will need to 
> receive locations from all the counties in that QSO party + the other 
> states/provinces. People sending to it will need to know which table it is 
> using.
> 
> We can select the table by the weekend data, and starting week before for 
> testing. There might also be a UI affordance which allows manual selection 
> for use in closed group testing. (For such testing, I suggest ditching the 
> radios and just using the built-in audio of several computers in the same 
> room.)
> 
> For non-US QSO parties, similar techniques might work. Consider a QSO party 
> with the counties of England, Ireland, Scotland, and Wales as the activated 
> counties. :-)
> 
> 73 Bill AE6JV
> 
> ---
> Bill Frantz| When all else fails: Voice   | Periwinkle
> (408)356-8506  | and CW.  | 16345 Englewood Ave
> www.pwpconsult.com |  | Los Gatos, CA 95032
> 
> 
> 
> ___
> 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

Re: [wsjt-devel] State QSO Parties

[Bill Frantz]

On 9/25/19 at 3:52 PM, g4...@classdesign.com (Bill Somerville) wrote:


On 25/09/2019 23:42, Bill Somerville wrote:
whereas the index into a table of 64 values (48 states + 14 
provinces + DC + DX) takes a mere 7 bits to store.


This is actually an interesting problem. We can divide the 
contesters into those activating the counties and those trying 
to contact them. The worst case I've heard is 252 Texas 
counties, but the 7QP will also have a big number.


One other problem is that some of the state QSO parties take 
place on the same weekend, and of course, some people try to 
make contacts in more than one QSO party. If the sum of all 
counties involved is small enough, it might be possible to 
support this behavior.


Lets assume: For the US state QSO parties, each station only 
activates counties in one QSO party. (We do need to support 
rovers.) It will need to receive locations from all the counties 
in that QSO party + the other states/provinces. People sending 
to it will need to know which table it is using.


We can select the table by the weekend data, and starting week 
before for testing. There might also be a UI affordance which 
allows manual selection for use in closed group testing. (For 
such testing, I suggest ditching the radios and just using the 
built-in audio of several computers in the same room.)


For non-US QSO parties, similar techniques might work. Consider 
a QSO party with the counties of England, Ireland, Scotland, and 
Wales as the activated counties. :-)


73 Bill AE6JV

---
Bill Frantz| When all else fails: Voice   | Periwinkle
(408)356-8506  | and CW.  | 16345 
Englewood Ave
www.pwpconsult.com |  | Los Gatos, 
CA 95032




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[John Zantek]

> index into a table of 64 values (48 states + 14 provinces + DC + DX) takes a 
> mere 7 bits to store.

Hi Bill,

Yes, I initially saw that and it's why I attempted to clone the FD table, 
substituting the 39 WA counties for 58 ARRL Sections.  That table obviously 
fits, right?

I'm guessing it wouldn't be wise to have 50 or 60 other tables for the various 
QSO parties.  Texas' table would be the basic 64 values & 254 counties; a 
resultant 9 bits requirement?  

Be gentle.  My Reptilian brain is being stretched. 

73 John W7CD





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

On 25/09/2019 23:42, Bill Somerville wrote:
whereas the index into a table of 64 values (48 states + 14 provinces 
+ DC + DX) takes a mere 7 bits to store.


Oops, not quite correct there. It only takes 6 bits.

I should add that the actual storage is more complex as the DX serial 
numbers must also be allowed and that adds all the permutations of 
digits between 0001 and 7999 to the possible combinations. Those 
combined with the state or province index permutations uses up just 13 
bits of payload in total. Note that is still less than the 15-bits 
needed to store any possible up to 3 character alphabetic string.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Bill Somerville]

On 25/09/2019 21:20, John Zantek wrote:

AKA "All I want for Christmas is something big for WSJT-X 2.2"

I just finished the 2019 Washington Salmon Run (our state QSO party), both as a 
contestant and a coordinator.  My DX Club sponsors the event.  
Seewww.wwdxc.org/salmonrun

This year, we were inundated with inquiries of "Can we use FT8 or FT4?", all of which I 
had to answer "No, sorry, not this year".  I see Nebraska supported WSJT-X for their QSO 
party, but it required a totally separate log.  Our Board felt the Salmon Run is too big and 
popular to create a whole separate category and scoring system, and I didn't want to see the use of 
FreeMsg frames being blasted blindly into the ether with unacknowledged County exchanges.  I felt 
it was just abusive and counter to the vision of WSJT-X's smart design.

I do believe that adding direct support to all the State QSO Parties could be the 'next 
big thing' for WSJT-X.  Adding FD last year was a step in that direction.  So rather than 
just ask, I thought "well, what would it require?"

CQ WAQP W7CD CN87
W7CD K7ABC SPO(Spokane County)
K7ABC W7CD R KITS   (Kitsap County)
W7CD K7ABC RR73

Thus, I submit a blind start:

//  QRegExp message_alphabet {"[- A-Za-z0-9+./?]*"};
   QRegularExpression message_alphabet {"[- @A-Za-z0-9+./?#<>]*"};
   QRegularExpression WA_QSO_party_exchange {
 R"(
 (
AL|AZ|AR|CA|CO|CT|DE|FL|GA  # 48 contiguous states
   |ID|IL|IN|IA|KS|KY|LA|ME|MD
   |MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ
   |NM|NY|NC|ND|OH|OK|OR|PA|RI|SC
   |SD|TN|TX|UT|VT|VA|WA|WV|WI|WY
   |NB|NS|QC|ON|MB|SK|AB|BC|NWT|NF  # VE provinces
   |LB|NU|YT|PEI
   |DC  # District of Columbia
   |DX  # anyone else outside WA
   |ADA|ASO|BEN|CHE|CLAL|CLAR|COL   # 39 WA counties
   |COW|DOU|FER|FRA|GAR|GRAN|GRAY
   |ISL|JEFF|KING|KITS|KITT|KLI
   |LEW|LIN|MAS|OKA|PAC|PEND|PIE
   |SAN|SKAG|SKAM|SNO|SPO|STE|THU
   |WAH|WAL|SHA|WHI|YAK
 )
   )", QRegularExpression::CaseInsensitiveOption | 
QRegularExpression::ExtendedPatternSyntaxOption};


Of course, it's not just that simple, I knowbut I feel strongly enough 
about the subject that I'm willing to try my hand at coding, something I've not 
done since my FORTRAN77 and PDP-11 school days.

True, there are some arguments against putting in the effort.
- Texas has 254 Counties.  My fingers ache just thinking about it.
- Not every State has a QSO Party.  Out west, those states without the support 
resources for their own QP (OR, MT, WY, etc) created the 7th Area QSO Party 
(7QP), which is wildly popular.  It's exchange field requires a field of 5 
characters (2-ltr-State + 3-ltr County).
-Instead of a QRegExp for each QP, a matrix of A through Z would 
support any 5-ltr combo a particular State QP sponsor might devise.  Of course, 
that leaves it to the end user to populate them in Settings/Advanced.  Texans 
would think that insane.  7QP'ers would call it cruel and unusual punishment.

Am I the only Voice in the Wilderness that thinks this would be worth it?  WA 
is happily willing to shift from 4 letter County abbreviations to 3 letter if 
it helps!

73 John W7CD


John,

you are looking at the validation for input of one's state or province 
as per the ARRL RTTY Roundup rules, that is a minor part of the picture 
and of no relevance to extending the possible messages that can be 
encoded with FT4/FT8/MSK144. The far more important part is the way that 
this information is compressed into the available 77 bits of message 
payload. What you must understand is the possible values of state or 
province are effectively stored as an index number, there is no direct 
storage of two, or three characters; that would take far more payload 
space which simply is not available. One  alphabetic character has 26 
possibilities, 27 if a blank is allowed. Two characters have 27 x 27 
combinations if blanks are allowed, three take 27 x 27 x 27 
combinations. 27 x 27 x 27 requires 15-bits to store, whereas the index 
into a table of 64 values (48 states + 14 provinces + DC + DX) takes a 
mere 7 bits to store.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Tom Melvin]

And for QSO parties that are NOT in the USA?

RSGB has a couple they introduced this year - doesn’t support FT? yet but it 
will come.

Pretty sure the abbreviations used for USA states will not match up with other 
countries.  The developers, if they are going to support QSO parties, will be 
looking at the global picture.

Tom

--
73’s

Tom
GM8MJV (IO85)





On 25 Sep 2019, at 22:19, Ron WV4P  wrote:

> As a coordinator for the Tennessee QSO Party we fielded the same questions 
> and had to respond the same. MANY wanted to use FT-X Modes. In kind, I don't 
> think TN would be any issue swapping to 3 Letter. Ron, WV4P 
> 
> On Wed, 25 Sep 2019 at 16:08, John Zantek  wrote:
> AKA "All I want for Christmas is something big for WSJT-X 2.2"
> 
> I just finished the 2019 Washington Salmon Run (our state QSO party), both as 
> a contestant and a coordinator.  My DX Club sponsors the event.  See 
> www.wwdxc.org/salmonrun
> 
> This year, we were inundated with inquiries of "Can we use FT8 or FT4?", all 
> of which I had to answer "No, sorry, not this year".  I see Nebraska 
> supported WSJT-X for their QSO party, but it required a totally separate log. 
>  Our Board felt the Salmon Run is too big and popular to create a whole 
> separate category and scoring system, and I didn't want to see the use of 
> FreeMsg frames being blasted blindly into the ether with unacknowledged 
> County exchanges.  I felt it was just abusive and counter to the vision of 
> WSJT-X's smart design.
> 
> I do believe that adding direct support to all the State QSO Parties could be 
> the 'next big thing' for WSJT-X.  Adding FD last year was a step in that 
> direction.  So rather than just ask, I thought "well, what would it require?"
> 
> CQ WAQP W7CD CN87
>W7CD K7ABC SPO(Spokane County)
> K7ABC W7CD R KITS   (Kitsap County)
>W7CD K7ABC RR73
> 
> Thus, I submit a blind start:
> 
> //  QRegExp message_alphabet {"[- A-Za-z0-9+./?]*"};
>   QRegularExpression message_alphabet {"[- @A-Za-z0-9+./?#<>]*"};
>   QRegularExpression WA_QSO_party_exchange {
> R"(
> (
>AL|AZ|AR|CA|CO|CT|DE|FL|GA  # 48 contiguous states
>   |ID|IL|IN|IA|KS|KY|LA|ME|MD
>   |MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ
>   |NM|NY|NC|ND|OH|OK|OR|PA|RI|SC
>   |SD|TN|TX|UT|VT|VA|WA|WV|WI|WY
>   |NB|NS|QC|ON|MB|SK|AB|BC|NWT|NF  # VE provinces
>   |LB|NU|YT|PEI
>   |DC  # District of Columbia
>   |DX  # anyone else outside WA
>   |ADA|ASO|BEN|CHE|CLAL|CLAR|COL   # 39 WA counties
>   |COW|DOU|FER|FRA|GAR|GRAN|GRAY
>   |ISL|JEFF|KING|KITS|KITT|KLI
>   |LEW|LIN|MAS|OKA|PAC|PEND|PIE
>   |SAN|SKAG|SKAM|SNO|SPO|STE|THU
>   |WAH|WAL|SHA|WHI|YAK 
> )
>   )", QRegularExpression::CaseInsensitiveOption | 
> QRegularExpression::ExtendedPatternSyntaxOption};
> 
> 
> Of course, it's not just that simple, I knowbut I feel strongly enough 
> about the subject that I'm willing to try my hand at coding, something I've 
> not done since my FORTRAN77 and PDP-11 school days.
> 
> True, there are some arguments against putting in the effort.
> - Texas has 254 Counties.  My fingers ache just thinking about it.
> - Not every State has a QSO Party.  Out west, those states without the 
> support resources for their own QP (OR, MT, WY, etc) created the 7th Area QSO 
> Party (7QP), which is wildly popular.  It's exchange field requires a field 
> of 5 characters (2-ltr-State + 3-ltr County).
> -Instead of a QRegExp for each QP, a matrix of A through Z would 
> support any 5-ltr combo a particular State QP sponsor might devise.  Of 
> course, that leaves it to the end user to populate them in Settings/Advanced. 
>  Texans would think that insane.  7QP'ers would call it cruel and unusual 
> punishment.
> 
> Am I the only Voice in the Wilderness that thinks this would be worth it?  WA 
> is happily willing to shift from 4 letter County abbreviations to 3 letter if 
> it helps!
> 
> 73 John W7CD
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

Re: [wsjt-devel] State QSO Parties

[Ron WV4P]

As a coordinator for the Tennessee QSO Party we fielded the same questions
and had to respond the same. MANY wanted to use FT-X Modes. In kind, I
don't think TN would be any issue swapping to 3 Letter. Ron, WV4P

On Wed, 25 Sep 2019 at 16:08, John Zantek  wrote:

> AKA "All I want for Christmas is something big for WSJT-X 2.2"
>
> I just finished the 2019 Washington Salmon Run (our state QSO party), both
> as a contestant and a coordinator.  My DX Club sponsors the event.  See
> www.wwdxc.org/salmonrun
>
> This year, we were inundated with inquiries of "Can we use FT8 or FT4?",
> all of which I had to answer "No, sorry, not this year".  I see Nebraska
> supported WSJT-X for their QSO party, but it required a totally separate
> log.  Our Board felt the Salmon Run is too big and popular to create a
> whole separate category and scoring system, and I didn't want to see the
> use of FreeMsg frames being blasted blindly into the ether with
> unacknowledged County exchanges.  I felt it was just abusive and counter to
> the vision of WSJT-X's smart design.
>
> I do believe that adding direct support to all the State QSO Parties could
> be the 'next big thing' for WSJT-X.  Adding FD last year was a step in that
> direction.  So rather than just ask, I thought "well, what would it
> require?"
>
> CQ WAQP W7CD CN87
>W7CD K7ABC SPO(Spokane County)
> K7ABC W7CD R KITS   (Kitsap County)
>W7CD K7ABC RR73
>
> Thus, I submit a blind start:
>
> //  QRegExp message_alphabet {"[- A-Za-z0-9+./?]*"};
>   QRegularExpression message_alphabet {"[- @A-Za-z0-9+./?#<>]*"};
>   QRegularExpression WA_QSO_party_exchange {
> R"(
> (
>AL|AZ|AR|CA|CO|CT|DE|FL|GA  # 48 contiguous states
>   |ID|IL|IN|IA|KS|KY|LA|ME|MD
>   |MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ
>   |NM|NY|NC|ND|OH|OK|OR|PA|RI|SC
>   |SD|TN|TX|UT|VT|VA|WA|WV|WI|WY
>   |NB|NS|QC|ON|MB|SK|AB|BC|NWT|NF  # VE provinces
>   |LB|NU|YT|PEI
>   |DC  # District of Columbia
>   |DX  # anyone else outside WA
>   |ADA|ASO|BEN|CHE|CLAL|CLAR|COL   # 39 WA counties
>   |COW|DOU|FER|FRA|GAR|GRAN|GRAY
>   |ISL|JEFF|KING|KITS|KITT|KLI
>   |LEW|LIN|MAS|OKA|PAC|PEND|PIE
>   |SAN|SKAG|SKAM|SNO|SPO|STE|THU
>   |WAH|WAL|SHA|WHI|YAK
> )
>   )", QRegularExpression::CaseInsensitiveOption |
> QRegularExpression::ExtendedPatternSyntaxOption};
>
>
> Of course, it's not just that simple, I knowbut I feel strongly enough
> about the subject that I'm willing to try my hand at coding, something I've
> not done since my FORTRAN77 and PDP-11 school days.
>
> True, there are some arguments against putting in the effort.
> - Texas has 254 Counties.  My fingers ache just thinking about it.
> - Not every State has a QSO Party.  Out west, those states without the
> support resources for their own QP (OR, MT, WY, etc) created the 7th Area
> QSO Party (7QP), which is wildly popular.  It's exchange field requires a
> field of 5 characters (2-ltr-State + 3-ltr County).
> -Instead of a QRegExp for each QP, a matrix of A through Z would
> support any 5-ltr combo a particular State QP sponsor might devise.  Of
> course, that leaves it to the end user to populate them in
> Settings/Advanced.  Texans would think that insane.  7QP'ers would call it
> cruel and unusual punishment.
>
> Am I the only Voice in the Wilderness that thinks this would be worth it?
> WA is happily willing to shift from 4 letter County abbreviations to 3
> letter if it helps!
>
> 73 John W7CD
>
>
>
>
>
>
>
> ___
> 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] State QSO Parties

[John Zantek]

AKA "All I want for Christmas is something big for WSJT-X 2.2"

I just finished the 2019 Washington Salmon Run (our state QSO party), both as a 
contestant and a coordinator.  My DX Club sponsors the event.  See 
www.wwdxc.org/salmonrun

This year, we were inundated with inquiries of "Can we use FT8 or FT4?", all of 
which I had to answer "No, sorry, not this year".  I see Nebraska supported 
WSJT-X for their QSO party, but it required a totally separate log.  Our Board 
felt the Salmon Run is too big and popular to create a whole separate category 
and scoring system, and I didn't want to see the use of FreeMsg frames being 
blasted blindly into the ether with unacknowledged County exchanges.  I felt it 
was just abusive and counter to the vision of WSJT-X's smart design.

I do believe that adding direct support to all the State QSO Parties could be 
the 'next big thing' for WSJT-X.  Adding FD last year was a step in that 
direction.  So rather than just ask, I thought "well, what would it require?"

CQ WAQP W7CD CN87
   W7CD K7ABC SPO(Spokane County)
K7ABC W7CD R KITS   (Kitsap County)
   W7CD K7ABC RR73

Thus, I submit a blind start:

//  QRegExp message_alphabet {"[- A-Za-z0-9+./?]*"};
  QRegularExpression message_alphabet {"[- @A-Za-z0-9+./?#<>]*"};
  QRegularExpression WA_QSO_party_exchange {
R"(
(
   AL|AZ|AR|CA|CO|CT|DE|FL|GA  # 48 contiguous states
  |ID|IL|IN|IA|KS|KY|LA|ME|MD
  |MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ
  |NM|NY|NC|ND|OH|OK|OR|PA|RI|SC
  |SD|TN|TX|UT|VT|VA|WA|WV|WI|WY
  |NB|NS|QC|ON|MB|SK|AB|BC|NWT|NF  # VE provinces
  |LB|NU|YT|PEI
  |DC  # District of Columbia
  |DX  # anyone else outside WA
  |ADA|ASO|BEN|CHE|CLAL|CLAR|COL   # 39 WA counties
  |COW|DOU|FER|FRA|GAR|GRAN|GRAY
  |ISL|JEFF|KING|KITS|KITT|KLI
  |LEW|LIN|MAS|OKA|PAC|PEND|PIE
  |SAN|SKAG|SKAM|SNO|SPO|STE|THU
  |WAH|WAL|SHA|WHI|YAK 
)
  )", QRegularExpression::CaseInsensitiveOption | 
QRegularExpression::ExtendedPatternSyntaxOption};

  
Of course, it's not just that simple, I knowbut I feel strongly enough 
about the subject that I'm willing to try my hand at coding, something I've not 
done since my FORTRAN77 and PDP-11 school days.

True, there are some arguments against putting in the effort.
- Texas has 254 Counties.  My fingers ache just thinking about it.
- Not every State has a QSO Party.  Out west, those states without the support 
resources for their own QP (OR, MT, WY, etc) created the 7th Area QSO Party 
(7QP), which is wildly popular.  It's exchange field requires a field of 5 
characters (2-ltr-State + 3-ltr County).
-Instead of a QRegExp for each QP, a matrix of A through Z would 
support any 5-ltr combo a particular State QP sponsor might devise.  Of course, 
that leaves it to the end user to populate them in Settings/Advanced.  Texans 
would think that insane.  7QP'ers would call it cruel and unusual punishment.

Am I the only Voice in the Wilderness that thinks this would be worth it?  WA 
is happily willing to shift from 4 letter County abbreviations to 3 letter if 
it helps!

73 John W7CD







___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel