Dan, The requested extension of the UDP interface isn't to enable an auto QSO system, that functionality is already there in the UDP interface. If I wished to (and I don’t) I can leave my logging software running unattended and it will answer the CQs of stations that I haven't worked on the band before. That is all based on the existing UDP interface.
The request is to enable a response to a QSO to be made in a way that minimises QRM to other users. Like you, I enjoy making QSOs, but I also enjoy writing software. 73, Mike /G3WPH -----Original Message----- From: Dan Malcolm <k4...@outlook.com> Sent: 22 January 2019 13:00 To: 'WSJT software development' <wsjt-devel@lists.sourceforge.net> 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
