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
<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
