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.
73 Mike W9MDB -----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 ------------------------------------------------------------------------------ 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
