I stepped through the stopTx2() function. Don't other threads keep on trucking while stepping inside one?
I'll try it again inside Transceiver but the log on both Steve's rig and mine (different rigs) also confirms that ptt doesn't turn off until AFTER the freq change. In the case below it transmitted on 17m, then switches to 12M for the rx period. You can see the freq of 2.49246 is getting set before ptt=0 Thu Jul 9 20:21:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:510)Debug: virtual void HamlibTransceiver::do_frequency(Transceiver::Frequency, Transceiver ::MODE) 18104600 mode: USB reversed: false Thu Jul 9 20:21:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=1.81046e+07 Thu Jul 9 20:21:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA Thu Jul 9 20:21:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=1.81046e+07 Thu Jul 9 20:21:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA Thu Jul 9 20:21:58 2015 GMT(C:\JTSDK\src\wsjtx\mainwindow.cpp:4152)Debug: WSPRnet.org status: "Uploading Spot 0/0" Thu Jul 9 20:21:58 2015 GMT(C:\JTSDK\src\wsjtx\wsprnet.cpp:99)Debug: "WSPRnet.org 0 outstanding requests" Thu Jul 9 20:22:00 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:770)Debug: virtual void HamlibTransceiver::do_ptt(bool) rig_set_ptt PTT = true Thu Jul 9 20:22:00 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_ptt: ptt=1 Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:510)Debug: virtual void HamlibTransceiver::do_frequency(Transceiver::Frequency, Transceiver ::MODE) 24924600 mode: USB reversed: false Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=2.49246e+07 Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=2.49246e+07 Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:780)Debug: virtual void HamlibTransceiver::do_ptt(bool) rig_set_ptt PTT = false Thu Jul 9 20:23:53 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_ptt: ptt=0 Thu Jul 9 20:25:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:510)Debug: virtual void HamlibTransceiver::do_frequency(Transceiver::Frequency, Transceiver ::MODE) 14095600 mode: USB reversed: false Thu Jul 9 20:25:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=1.40956e+07 Thu Jul 9 20:25:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA Thu Jul 9 20:25:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: vfo=currVFO freq=1.40956e+07 Thu Jul 9 20:25:54 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_set_freq: set_freq2 vfo=VFOA 73 Mike W9MDB -----Original Message----- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Thursday, July 09, 2015 3:19 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] r5700 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 ------------------------------------------------------------------------------ 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
