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
