On 15/03/2015 12:45, Joe Taylor wrote: > Hi Bill and all, Hi Joe, > > I haven't yet paid close attention to this thread, and have not yet > tried the new code enhancements. But I want to share a potential concern > about automating QSO procedures by too much. > > How much is "too much"? When I started work on WSJT in 2001 I decided > to resist any temptation to play with "automated" modes -- by which I > mean programmed algorithms that can complete a QSO (according to > normally accepted definitions) without human interaction. I didn't want > my modes -- first FSK441 for meteor scatter, then JT65 for EME -- to be > susceptible to an argument then made by some (even in my own local club) > that "it's only computers talking to computers". > > For this reason I've always required operator decisions to be made about > what has been received, what to transmit next, etc. I am 100% in agreement with you here. I have been very careful to only fix defects rather than add further automation based on messages received. To that end I have only fixed issues where the existing double-click processing of a message "does the wrong thing" when is clearly a standard message in the expected sequence of a "perfect" QSO.
In fact I have reduced automation to a certain extent in some cases. For example the "Halt Tx on 73" setting now only triggers on a standard 73 message or a free text message containing "73" rather than tripping on any free text message. This hopefully will largely stop the annoying behaviour of turning off Tx and popping up a Log QSO window whenever a free text message is sent. The key principle of the operator having to take some action at every step of the QSO to progress the QSO is still very much in place. Lets hope that they also take the time to think about what they have initiated and whether it is the right action at that point ;) > > -- Joe, K1JT 73 Bill G4WJS. > > On 3/14/2015 3:26 PM, Bill Somerville wrote: >> Hi All, >> >> I have just committed the second phase of my changes related to compound >> callsigns to the development branch. Here is the commit message: >> >> ------------------------------------------------------------------------ >> r5055 | bsomervi | 2015-03-14 19:13:18 +0000 (Sat, 14 Mar 2015) | 21 lines >> >> Improved automatic message handling >> >> More consistent and accurate processing of compund callsigns including >> recognizing the user's call in both base and fully qualified form, >> extracting reports from special type one and type two compound call >> messages. Ensure that "CQ DX" message prefixes are recognized and >> processd correctly. >> >> The cycle of double clicking through a QSO has been enhanced to >> recognoize the standard messages correctly and use the correct next >> message. The automatic transmission button "Enable Tx" now does what >> it says and does not double as a stop transmit button. This allows the >> current transmission to complete even if the automatic transmission >> feature is disabled. In line with this the "stop sending after a 73 >> message is sent" feature turns off the automatic transmission enable >> at the start of the sending of a 73 message and also the next message >> is now set up as the CQ message automatically in this scenario. A 73 >> message is now either a standard message containing the word "73" or >> any free text message containing "73" (not necessarily as a distinct >> word"). >> >> ------------------------------------------------------------------------ >> >> This change is a fairly radical reworking of the way incoming messages >> are parsed and the actions taken when messages are double clicked in the >> activity windows. It should handle QSOs by and with compound callsign >> holders far better than previously and has other benefits for all QSO types. >> >> I strongly recommend that testers experiment with using double clicks in >> the activity to progress their QSOs and report back any incorrect >> behaviour of the application. >> >> With these changes I find that having the settings "Double-click on call >> sets Tx enable" and "Disable Tx after sending 73" both checked makes the >> QSO process extremely smooth using just double-clicks on calls and >> responses, only having to revert to specific clicks and typing when I >> want to send a free text message or if my QSO partner sends an out of >> sequence message. >> >> If you are testing these changes; please double check that, when you >> come to log the QSO, the callsign, the report sent and received have >> been correctly transferred to the "Log QSO" pop up dialog. >> >> 73 >> Bill >> G4WJS. >> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
