On 09/07/2015 21:30, Michael Black wrote: Hi Mike, > I stepped through the stopTx2() function. Don't other threads keep on > trucking while stepping inside one? Not normally and not at all with Windows and gdb. > > 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. That I agree with but I don't know why yet.
If you want to trace this in gdb try setting break points on each of the do_...() functions in HamlibTranceiver, that are the end product of transceiver control functions and where the actual CAT chatter happens. These are all executed in the transceiver control thread, you can confirm that by using 'info threads' at each breakpoint. > > 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 73 Bill G4WJS. > > > -----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
