Bill, Many thanks for your speedy response. I think you may have stronger faith than me in the skills and manners of operators if you believe they all check a frequency isn't in use for another QSO before calling a CQing station, especially rare DX. I suspect many operators run logging applications with WSJT-X in a minimised state.
You mention that thousands of QSOs have been initiated using other applications such as JTAlert. it would be really interesting to understand if such applications hold off sending a UDP Reply message to the client if the frequency and period they will use to transmit on is in use for another QSO. If they don't then they could make good use of the functionality I am requesting. I see this extension as a way to enable application developers to provide a higher quality application without compromising the goal of avoiding full automation. One last thought, just because I'm the first person to request the functionality doesn't mean it's a bad idea. Again, thanks & 73 Mike /G3WPH -----Original Message----- From: Bill Somerville <g4...@classdesign.com> Sent: 22 January 2019 12:28 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
