On 09/07/2015 17:23, Michael Black wrote:
Hi Mike,
> I just stepped through the sequence and I can confirm that even though ptt
> is being set to false it's not actually getting turned off until this
> function is exited.
> So the sequencing of ptt=false then frequency set is not being preserved.
Did the rig actually change frequency before PTT was dropped?

Which thread did you step through? The transceiver control thread is the 
only one that matters since that is where ALL the CAT commands are 
emitted from.
>
> 73
> Mike W9MDB
73
Bill
G4WJS.
>
> -----Original Message-----
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Thursday, July 09, 2015 9:18 AM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] r5700
>
> On 09/07/2015 14:55, Michael Black wrote:
>
> Hi Mike,
>> Could the culprit be this?  I think the ptt call is async to another
>> thread so WSPR_scheduling is being called before ptt=false is actually
> done.
>> A simple sleep after ptt might confirm it's the problem.
>> Another solution would be to expose ptt status so it could be checked.
>>
>> void MainWindow::stopTx2()
>> {
>>     Q_EMIT m_config.transceiver_ptt (false);      //Lower PTT
>>     if (m_mode.mid(0,4)!="WSPR" and m_mode!="Echo" and m_config.watchdog()
> and
>>         m_repeatMsg>=m_watchdogLimit-1) {
>>       on_stopTxButton_clicked();
>>       msgBox("Runaway Tx watchdog");
>>       m_repeatMsg=0;
>>     }
>>     if(m_mode.mid(0,4)=="WSPR" and m_ntr==-1 and !m_tuneup) {
>>       m_wideGraph->setWSPRtransmitted();
>>       WSPR_scheduling ();
>>       m_ntr=0;
>>     }
>> }
> The issue will be something along those lines, but not as you suggest.
> The rig control calls are indeed processed on a separate thread but the
> ordering of actions is strictly preserved so the PTT off command is queued
> before the change frequency command within the WSPR_scheduling() function;
> therefore they are also processed in the rig control thread in that order.
>
> I am not at my PC or in my shack at the moment so cannot look at this until
> later. I suspect there is some way that WSPR_scheduling or the PTT off
> command are being called in the reverse order.
>> 73
>> Mike W9MDB
> 73
> Bill
> G4WJS.
>> -----Original Message-----
>> From: Joe Taylor [mailto:j...@princeton.edu]
>> Sent: Thursday, July 09, 2015 8:43 AM
>> To: WSJT software development
>> Subject: Re: [wsjt-devel] r5700
>>
>> Hi all,
>>
>> I've been working on ISCAT (in "wsjtx_exp") rather than helping to
>> trace the problem with band-hopping Kenwoods.  For what it's worth,
> though:
>> with my TS-2000 I continue to see the same kind of glitches that Steve
>> has been reporting.  I could do more extensive tracing if that would help.
>>
>>      -- Joe


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

Reply via email to