On Thu, Sep 26, 2019 at 10:03 PM David Gilbert <xda...@cis-broadband.com> 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 <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 >> 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