Greetings, all.  Thank you,  WSJT development team for your amazing work.  I was on 6M last evening, working E's across the U.S., and was really appreciating how in just one year, FT8 has taken over the band, and essentially displaced both SSB and CW for DXing.  In just one year!

Anyway, regarding Mike W9MDB and other's comments regarding the use of FT8, which have been a recurring theme:  So the question really is "What are the bounds of control for the WSJT development team to restrict the use of WSJT-X?".

There seems to be a PoV which holds that, Apple/Steve Jobsian-like, the WSJT team has the right (and, indeed the responsibility, because you cannot trust the Great Unwashed!!) to delimit the use of WSJT down to some unspecified level of detail.   IIRC, this granularity is currently limited to frequency usage.  I also recall a setting buried somewhere in WSJT-X which sets a signal strength threshold, above which the signal will be ignored.  I don't know the back-story behind this signal strength idea, but it hints once again about "control". 

The logical conclusion of this PoV would include check-in of WSJT-X with a central control point for:

    1) Ensuring that the user is authorized by the WSJT-X development team to use the product

    2) Confirming that the proposed frequencies are "Approved" by the WSJT-X development team

    3) Confirming that the proposed station on the other end of the QSO is also authorized by the WSJT-X development team

    4) Confirming that use use of WSJT-X is allowed within some WSJT-X development team specified date/time range

    5) Etcetera: Use your imagination: Has the user donated to the support of the product?  Is the user running a "supported" version within some WSJT-X development team's definition of  the timeframe of what "supported" means?  There is literally no limit to what could be used to restrict its use.

 

I would suggest that this is a profoundly bad path to follow.  The developers are not responsible for the use of the tool, and rather than expending valuable energy on attempting to control its use from their by-definition narrow view of the world, should instead focus on education and inclusion.  For the DXpeditions that are experimenting with the in-development DXpedition mode, rather than being critical of their use, reach out to them for data which could help improve the product, and/or offer to work with them ahead of time to acquire the data and coach them how to use the features.

All IMHO, obviously, but I felt it needed saying.

73,

Steve

NN4X




On 5/9/2018 10:40 AM, Black Michael via wsjt-devel wrote:
There apparently was somebody on 20M FT8 last night in Fox mode from a relatively rare location and caused a mess on 14.074.  Everybody though he was calling simple CQ but was Fox so wasn't hearing them and users were crowding the lower end of 20M trying to get him making even the the Fox/Hound exchange problematic.

I don't think we can leave this up to "operator responsibility" as there are just too many out there.....

So throwing out a few ideas to hopefully open up the discussion

#1 Active solution -- Add a "Fox" setting to the frequency list which is hard-coded for the "standard" bands and would prevent enabling Fox or Hound mode on those entries with an appropriate message.
#2 Passive solution -- Detect Fox/Hound messages during decode and don't display them at all unless you have the modes enabled.  This would not stop older versions from seeing the decoding though.
#3 Simple solution -- Whenever Fox mode is selected a big warning message comes up about band usage.  


de Mike W9MDB


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
 

-- 
Steve Sacco
NN4X
Narcoossee, FL 
EL98jh


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to