Re: [wsjt-devel] Possible change to UDP interface - set TX audio offset
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 Sent: 22 January 2019 13:00 To: 'WSJT software development' 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
Re: [wsjt-devel] Possible change to UDP interface - set TX audio offset
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 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
Re: [wsjt-devel] Possible change to UDP interface - set TX audio offset
Here is my up vote on Bill's and Dan response. Sam W2JDB -Original Message- From: Dan Malcolm To: 'WSJT software development' 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
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
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] Possible change to UDP interface - set TX audio offset
I use the UDP interface to integrate WSJT-X (FT8) into my logging software which makes a quick decision whether to call a CQing station based on rules implemented in the logging software. However the inability to set TX audio offset leads to a high risk of causing interference to other stations: * If ‘Hold TX Frequency’ isn’t checked in WSJT-X, then the CQing station is called on his frequency. If he is already interleaving that frequency with another station then there is a risk of interference. * 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. * There is an additional issue in the UK on 60m, where the unofficial FT8 frequency is 5.356MHz to 5.358MHz. The top end of that particular UK sub-band is 5.358MHz, so care has to be taken not to use a TX audio offset above 2.0 KHz. To avoid possible interference I’d like to suggest the ability to set TX audio offset through the UDP interface. Possibly through an additional UDP message, or use of the ‘Delta Frequency’ parameter in the ‘Reply’ message – unless of course that is used for some other purpose. The logging software could then keep a map (built from previous decodes) of clear frequencies and select a new one if necessary. I don’t think this would compromise the ’useful co-operative service’ concept of the UDP interface. I’d be pleased to learn of any existing ways to achieve the functionality I’m looking for within the current WSJT-X implementation. Many thanks & 73 Mike /G3WPH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
