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