Here is my up vote on Bill's and Dan response. Sam W2JDB -----Original Message----- From: Dan Malcolm <k4...@outlook.com> To: 'WSJT software development' <wsjt-devel@lists.sourceforge.net> Sent: Tue, Jan 22, 2019 8:19 am Subject: Re: [wsjt-devel] Possible change to UDP interface - set TX audio offset
Just had to but in, in support of what Bill has said. The WSJT-X development team has done us all a great service in improving WSJT-X. The automation that accompanies FT8 are a godsend for that relatively fast paced protocol. However, there can be too much of a good thing. I participate in this hobby because I enjoy it. That means I need to participate, not set up an auto-QSO system that will perform and log QSO's even when I'm sleeping. I think the developers have hit on just the right amount of automation/user participation for FT8. Just my $0.02 worth. 73 __________ Dan – K4SHQ -----Original Message----- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Tuesday, January 22, 2019 6:28 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Possible change to UDP interface - set TX audio offset On 22/01/2019 11:07, Mike Chamberlain wrote: > If ‘Hold TX Frequency’ is checked, to avoid interference it is > necessary to check that the transmit offset frequency last used by my > station is still clear in the period that I wish to use it – that > requires bringing WSJT-X back into focus and a visual inspection, > which is time consuming. Hi Mike, the final part of your point above makes it hard to justify such a change. The WSJT-X UDP protocol was never intended to be a remote control interface to WSJT-X and if it is changed such that WSJT-X can remain minimized for all or part of a QSO then I think that is beyond the scope of the intended use. That combined with many thousands of QSOs having been initiated using the UDP Reply message by JTAlert and other software users yet yours is the first request for a Tx offset setting facility. There is also another objection in that operators must be aware of users of other modes that might suffer QRM from a poor choice of Tx offset, an external application does not see or analyse the waterfall display other than by the information provided in decoded messages. There is no substitute for having an eye on the waterfall display to avoid any deliberate QRM to other users. 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
