I don't understand the need to QSY both RX and TX to an open frequency. If
you're calling CQ with Call 1st enabled, the program will automatically QSY
the RX to wherever you're called. You just need to set your TX.
On Oct 1, 2017 10:42 AM, "Hiro Ebihara" <ja1...@ybb.ne.jp> wrote:
>
>
> Thanks, Jams-san, these do not help quick QSY of both rx and tx
> freq.together to empty fWF to try calling CQ?
>
>
>
>
>
>
>
> hiro・JA1LZK
>
>
>
>
>
>
>
>
>
> *From:* James Shaver [mailto:n2...@windstream.net]
> *Sent:* Saturday, September 30, 2017 9:38 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Experimental changes in r8125
>
>
>
> Hello, Hiro-san.
>
> The good news is that the functionality of "Lock TX=RX" is still available
> thanks to the update yesterday (thanks, Joe) - the settings now includes an
> option to emulate this behavior "Double-click on call sets Tx and Rx freqs"
> so you should be good to go!
>
> Jim S.
> N2ADV
>
>
>
> On 9/30/2017 8:19 AM, Hiro Ebihara wrote:
>
> HI,
>
>
>
> I need "Lock Tx=Rx" option.
>
> I am temporally handicapped of my left hand as I received surgery
> operation few weeks ago because I had an accident and had my left shoulder
> broken and displaced.
> It is impossible to QSY by pushing control key and click mouse at same
> time.
>
> There may be some people those have the same handicap either temporally or
> permanently.
> Those are need this particular option.
>
>
>
> Hiro/ JA1LZK
>
>
>
>
>
> *From:* Bill Somerville [mailto:g4...@classdesign.com
> <g4...@classdesign.com>]
> *Sent:* Saturday, September 30, 2017 7:36 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Experimental changes in r8125
>
>
>
> On 30/09/2017 03:03, Gary McDuffie wrote:
>
> On Sep 29, 2017, at 1:10 PM, Bill Somerville <g4...@classdesign.com>
> <g4...@classdesign.com> wrote:
>
>
>
> I understand that there will always be a group of users who insist that the
> old "Lock Tx=Rx" option is needed
>
> Bill, you seem to be under the false impression that everyone wants to work
> split and cares about nothing but DX. I believe this is false. I believe
> most people are there just to enjoy making contacts. Every time they get on
> the air is not a contest, and they don’t want it to be. I tried 8144 this
> afternoon and found it a good compromise that should handle both sides of the
> argument fairly well. At least that’s how it behaved in my very limited time
> I had to spend with it today.
>
> Hi Gary,
>
> you quoted a line of my post that has nothing to do with what you go on
> to discuss. I am confused as to which part of my post leads you to believe
> that I "seem to be under the false impression that everyone wants to work
> split and cares about nothing but DX." I have no such impression and I
> don't believe anything I said might imply that. The part you quote was
> about the misfeature, in my opinion, of "Lock Tx=Rx" which causes your Tx
> frequency to be effectively controlled by your QSO partner. I have never
> understood why anyone would want to check that option. A simple example of
> the problem is where your QSO partner decided to move their Tx frequency
> mid QSO and thereby drags you to their frequency choice even if it may be
> right in top of an extant QSO that you can see on the waterfall. I am quite
> happy to see the back of "Lock Tx=Rx", but the problem is that the latest
> changes have reintroduced it in disguise.
>
> My concerns were two fold, firstly that the new default of only moving to
> a callers frequency when replying to a CQ or QRZ call, unless
> CTRL+double-click is used, is wrong and is skewed towards those operating
> in non-weak signal situations on bands like 20m or 40m after dark on FT8. I
> can understand that those getting multiple replies to CQ calls are
> frustrated with the default behaviour of decoded CQ double-clicks but
> losing the old behaviour which has been fine for non-congested situations
> is not helpful, nor intended IMHO, so I was just pointing out that. This
> new default is also a major deviation from WSJT-X behaviour to date where
> the focus has been weak-signal working where QRM is not normally an issue
> to be worked around, in fact QRM would be a show-stopper in these scenarios
> and working at an offset from your QSO partners would not help.
>
> The second problem is see is that the option to supposedly revert to
> dropping onto the frequency of CQ caller when replying was implemented
> incorrectly and instead behaved similarly to the "Lock Tx=Rx" option. You
> clearly did not test the behaviour with "Settings->General->Double-click
> on call set Tx and Rx freqs" very thoroughly in comparison with the prior
> behaviour which I believe it was intended to restore.
>
> 73
> Bill
> G4WJS.
>
>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
>
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
>
> _______________________________________________
>
> wsjt-devel mailing list
>
> wsjt-devel@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> --
>
> 73,
>
>
>
> Jim S.
>
> N2ADV
>
> www.qrz.com/db/N2ADV
>
> https://www.facebook.com/groups/FT8.Digital.Mode/
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
