Bill,
> On Jul 9, 2015, at 7:43 AM, Bill Somerville <g4...@classdesign.com> wrote:
>
> On 09/07/2015 08:18, Steven Franke wrote:
> Hi Steve,
>>
>>> On Jul 9, 2015, at 7:04 AM, Bill Somerville <g4...@classdesign.com
>>> <mailto:g4...@classdesign.com>> wrote:
>>>
>>> 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.
>>
>> I do not have “Tune” selected for any band in the schedule. I do have the
>> antenna tuner engaged so that the rig recalls the stored tuner settings when
>> doing a frequency change.
> Oh! That's a surprise, that probably explains why I can understand how the
> PTT is being asserted before the offending frequency change commands, clearly
> I am looking in the wrong place. OK, I really need that full verbose CAT
> trace with the version with my last patch for the WSJT-X
> HamlibTransceiver.cpp source.
The latest trace (with your patch installed) is here:
https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_3.log
<https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_3.log>
The sequence is as follows:
Started the program at 16:06:43
First TX cycle starts at 16:10:00 (PTT goes high)
The error occurs at the end of the first TX cycle, at 16:11:53
I quit the program at 16:12:11, which triggers the ‘RX’ error that you noticed
earlier.
Again, I do not use tune. The problem always occurs at the very end of a TX
cycle.
Steve k9an
>
> I think now that the band hopping frequency changes are happening prematurely
> and because we sequence un-asserting PTT with asynchronous delays (and VOX
> may well add other delays out of our control at he rig). I now suspect that
> the whole WSPR band hopping scheduling will need to be triggered off a timer
> that allows a generous interval for the previous Tx period to fully complete
> including any delayed action from the rig. I will try and look at this this
> Evening.
>>
>>>>
>>>> 73
>>>> Mike W9MDB
>>> 73
>>> Bill
>>> G4WJS.
> 73
> Bill
> G4WJS.
> ------------------------------------------------------------------------------
> 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