On 08/07/2015 23:10, Steven Franke wrote:
Hi Steve,
On Jul 8, 2015, at 4:42 PM, Bill Somerville <g4...@classdesign.com> wrote:
On 08/07/2015 22:03, Steven Franke wrote:
Mike and Bill,
Hi Steve,
I deleted my hamlib directory, downloaded the latest from git, changed the
timeout from 200 to 1000 in ts480.c and recompiled hamlib. Then I recompiled
wsjtx. Same problem - an excerpt from the trace is included below. I believe
that the effect of the increased timeout is evident in the 1s interval between
re-tries…
This is something more fundamental than timing or numbers of retries.
Also replying to your other message about not understanding the change
that caused this, I don't think this is a WSJT-X change that has caused
this - something else has changed.
I don’t understand what you mean here Bill. Since the problem disappears when I
go back one revision, isn’t it fair to say that a WSJT-X change has, at least,
uncovered a problem in hamlib or the TS-480 firmware? I hadn’t updated hamlib
when I first saw the problem, and I haven’t updated the TS-480.
I can't disagree with that logic but the change in r5700 should have no
bearing on rig control and I can't see any way it would even change the
timing of any rig control commands. I am mystified as to why there is a
correlation between r5700 and this issue.
I have a hunch that it is something to do with sending two "IF;"
commands in succession. It is a bit tricky stopping that happening as we
only call Hamlib API functions and several are likely to use the "IF;"
alone to retrieve the requested state.
Can you try using "PTT Method" as "VOX" in WSJT-X, that should eliminate
one of the double invocations of the "IF;" command that is likely to
happen just before trying to change the rig state like changing frequency.
I’m running this way now, and it has now done 5 transmissions without a
problem. So far, so good!
OK, that does throw some weight behind my hunch being right.
Unfortunately changing to VOX will have other effects like changing the
point in time where the rig goes into transmit so this test is not
conclusive. Attached is a patch that changes the ordering in the WSJT-X
Hamlib polling sequence, if you could try that it will be a better test
that the double "IF;" command is part of the issue.
I would also be interested in the last test that Mike suggested to add
delay after the "IF;" command is sent and the reply read, you would need
to test that before trying the attached patch.
But why/how does this double “IF” only manifest in r5700 and not in the earlier
revision?
I have absolutely no idea, I can only guess that we were somehow on the
threshold of some very subtle timing issue that is caused by an
apparently unrelated code change.
Steve k9an
...
73
Bill
G4WJS.
73
Bill
G4WJS.
diff --git a/HamlibTransceiver.cpp b/HamlibTransceiver.cpp
index ce2ee6e..77076f4 100644
--- a/HamlibTransceiver.cpp
+++ b/HamlibTransceiver.cpp
@@ -699,6 +699,24 @@ void HamlibTransceiver::poll ()
update_other_frequency (f);
}
+ // do this here before getting the mode to avoid Hamlib calling IF;
+ // twice in succession at the end of the poll sequence on Kenwood
+ // rigs - this is because doing so seems to cause a subtle CAT bug
+ // on at least the TS-480
+ if (RIG_PTT_NONE != rig_->state.pttport.type.ptt && rig_->caps->get_ptt)
+ {
+ ptt_t p;
+ auto rc = rig_get_ptt (rig_.data (), RIG_VFO_CURR, &p);
+ if (-RIG_ENAVAIL != rc && -RIG_ENIMPL != rc) // may fail if
+ // Net rig ctl and target doesn't
+ // support command
+ {
+ error_check (rc, tr ("getting PTT state"));
+ TRACE_CAT_POLL ("rig_get_ptt PTT =" << p);
+ update_PTT (!(RIG_PTT_OFF == p));
+ }
+ }
+
error_check (rig_get_mode (rig_.data (), RIG_VFO_CURR, &m, &w), tr ("getting
current VFO mode"));
TRACE_CAT_POLL ("rig_get_mode mode =" << rig_strrmode (m) << "bw =" << w);
update_mode (map_mode (m));
@@ -731,20 +749,6 @@ void HamlibTransceiver::poll ()
}
}
- if (RIG_PTT_NONE != rig_->state.pttport.type.ptt && rig_->caps->get_ptt)
- {
- ptt_t p;
- auto rc = rig_get_ptt (rig_.data (), RIG_VFO_CURR, &p);
- if (-RIG_ENAVAIL != rc && -RIG_ENIMPL != rc) // may fail if
- // Net rig ctl and target doesn't
- // support command
- {
- error_check (rc, tr ("getting PTT state"));
- TRACE_CAT_POLL ("rig_get_ptt PTT =" << p);
- update_PTT (!(RIG_PTT_OFF == p));
- }
- }
-
#if !WSJT_TRACE_CAT_POLLS
#if WSJT_HAMLIB_TRACE
#if WSJT_HAMLIB_VERBOSE_TRACE
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
