On 09/07/2015 05:16, Michael Black wrote:
Hi Mike,
I noticed in that log that PTT=true comes before the frequency change
and PTT=false afterwards. Was probably in the prior log too just
didn't notice it. I'm betting the TS-480 can't change frequency while
transmitting which would explain the "busy" indicator. Switching to
VOX delays the audio onset that triggers transmit so that works.
PTT should not be asserted before changing frequency, maybe this is what
is happening if the code to do the "tune up" transmit is not correctly
sequenced. Although this does not explain the instances where the "RX;"
command is getting a busy response, if the "RX;" command cannot be
processed while the rig is in transmit mode we have a much more serious
problem!
There are a couple of changes with "freq" in them and I wonder if one
of those got moved ahead of the ptt=false for WSRP mode. PTT goes to
false after the error occurs. It looks like it's trying to change
frequency for the next transmit period while it's still transmitting
on the last one.
This is why I asked about auto-ATU actions because they can hold the rig
in transmit after a request to return to receive.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Steven Franke [mailto:[email protected]]
*Sent:* Wednesday, July 08, 2015 7:08 PM
*To:* WSJT software development
*Subject:* Re: [wsjt-devel] r5700
Hi Bill,
On Jul 8, 2015, at 11:09 PM, Bill Somerville
<[email protected] <mailto:[email protected]>> wrote:
On 08/07/2015 23:10, Steven Franke wrote:
Hi Steve,
On Jul 8, 2015, at 4:42 PM, Bill Somerville
<[email protected] <mailto:[email protected]>> 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 applied the patch and re-built but the problem persists. I’ve put a
trace file here:
https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_2.log
There are two events that happened after I applied the patch: 23:35:53
and 23:43:53.
The first one did not throw up a window asking me if I wanted to
reconfigure the radio, but the second one did. When I pressed “Cancel”
in that window, the program segfaulted.
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.
The delay after the “IF;” did not help (with delays of 100ms and 400ms).
Steve k9an
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.
<double-if.patch>------------------------------------------------------------------------------
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
[email protected] <mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
