|
|
Post by ka2uqw on Aug 27, 2022 12:58:47 GMT
Using the latest JTDX version here I believe, 2.2.159. It seems to control the rig fine, CAT settings are the same as when using WSJT-X. However, on enabling transmit, the rig engages and will not return to receive. It is then necessary to turn the rig off and then back on again to receive. I've tried this multiple times, with the same result.
Interestingly, the same problem occurred with WSJT-X in a recent upgrade, I don't recall which one it was, but it was recent. I reported this to the developers who corrected the problem. They did have me upgrade Hamlib, so I have the most current version of that. Just upgrading Hamlib alone did not fix the issue. I am not sure what change was made to stop the rig from locking in xmit.
I did search the forum for info on this issue and find none.
Any help would be appreciated.
73, Andy, ka2uqw
|
|
|
|
Post by Wolfgang OE1MWW on Aug 28, 2022 8:36:44 GMT
Andy,
"...on enabling TX" is not quite clear - is that a TX cycle, if you call another station?
what happens if you click on 'Tune' button ?
Does your Omni VII go into TX and on the next click on 'Tune' into RX again?
73's de OE1MWW
Wolfgang
|
|
|
|
Post by ka2uqw on Aug 28, 2022 12:01:06 GMT
Hello Wolfgang,
The Omni VII locks in xmit no matter the manner in which I initiate xmit. If I attempt to call another station, it will lock in xmit. If I use TUNE, it will lock up as well. If I use the TUNE button, the rig will lock in xmit and pressing TUNE again will have no effect, the rig remains in xmit until I cycle the rig's power, off and then on again.
This is exactly the behavior WSJT-X exhibited in a recent upgrade of that program, but as I mentioned in a previous post, that issue has now been fixed. So, WSJT-X works just fine with the Omni, but JTDX does not. In settings, all parameters are the same in both programs.
JTDX does receive fine, that is not at issue. But transmitting is not possible due to the lock up of xmit.
Hope my explanation is clearer now.
73,
Andy, ka2uqw
|
|
|
|
Post by w9mdb on Aug 28, 2022 12:11:15 GMT
Bill did this patch
Author: Bill Somerville <bill@classdesign.com>
Date: Sat Sep 11 12:58:48 2021 +0100
Remove a, hopefully, unnecessary unconditional CAT frequency set
this frequency set was causing CAT command rejections on some Icom
rigs when using WSPR auto tune-up with the rig's built-in auto-ATU
anabled. The issue relates to a PTT-set, tune, PTT-reset,
set-frequency sequence where the rig's ATU is still tuning while the
PTT is reset. Since this should only happen in WSPR mode where split
operating is not used it should resolve the issue.
diff --git a/Transceiver/TransceiverBase.cpp b/Transceiver/TransceiverBase.cpp
index 6ae7e2c49..17967502d 100644
--- a/Transceiver/TransceiverBase.cpp
+++ b/Transceiver/TransceiverBase.cpp
@@ -81,8 +81,7 @@ void TransceiverBase::set (TransceiverState const& s,
}
if (s.frequency () // ignore bogus zero frequencies
&& ((s.frequency () != requested_.frequency () // and QSY
- || (s.mode () != UNK && s.mode () != requested_.mode ())) // or mode change
- || ptt_off)) // or just returned to rx
+ || (s.mode () != UNK && s.mode () != requested_.mode ())))) // or mode change
{
do_frequency (s.frequency (), s.mode (), ptt_off);
do_post_frequency (s.frequency (), s.mode ());
(END)
|
|
|
|
Post by Arvo ES1JA on Aug 28, 2022 12:53:12 GMT
Added same patch to JTDX to.
|
|
|
|
Post by ka2uqw on Aug 28, 2022 12:55:16 GMT
Mike, thanks for jumping in on this issue.
|
|
