Hi Mike
We have also seen problems (rig errors) with Doppler control (for JT4) on
another rig that can't change frequency on transmit (FT817). The intention
was to command the required TX frequency before the PTT goes to transmit
with sufficient time for the rig to respond. We also wondered if there is
any attempts at communication with the rig during the TX sequence, as
sometimes rig errors have also occurred some seconds into the TX period.
73
Charlie
_____
From: Michael Black [mailto:mdblac...@gmail.com]
Sent: 09 July 2015 05:17
To: 'WSJT software development'
Subject: Re: [wsjt-devel] r5700
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.
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.
73
Mike W9MDB
From: Steven Franke [mailto:s.j.fra...@icloud.com]
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 <g4...@classdesign.com> wrote:
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 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
wsjt-devel@lists.sourceforge.net
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
