Re: [wsjt-devel] r5700

From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Thursday, July 09, 2015 3:30 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] r5700 On 09/07/2015 19:08, Michael Black wrote: Hi Mike, Try this.in mainwindow.cpp replace stopTx2() with the following. It defers the

Re: [wsjt-devel] r5700

t_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

Re: [wsjt-devel] r5700

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

Re: [wsjt-devel] r5700

On 09/07/2015 19:08, Michael Black wrote: Hi Mike, Try this…in mainwindow.cpp replace stopTx2() with the following. It defers the frequency change for 2 seconds which is probably too long but succeeds in moving ptt=0 in front of the frequency change. If you follow the code from MainWindow:

Re: [wsjt-devel] r5700

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

Re: [wsjt-devel] r5700

Mike,I ran your change on top of Bill’s patch. See the attached diff file for the difference between r5700 and my current dirty version.It did not solve the problem.The trace results are here:https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_5.logThe trace starts when I started the program,

Re: [wsjt-devel] r5700

Try this.in mainwindow.cpp replace stopTx2() with the following. It defers the frequency change for 2 seconds which is probably too long but succeeds in moving ptt=0 in front of the frequency change. 73 Mike W9MDB void MainWindow::stopTx2a() { WSPR_scheduling (); } void MainWind

Re: [wsjt-devel] r5700

Sorry - this time, full verbose trace: https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_4.log The TX cycle starts at 16:36:00 and the problem occurs at 16:37:53. I stop the program at 16:38:10. Steve k9an -

Re: [wsjt-devel] r5700

Bill, > On Jul 9, 2015, at 7:43 AM, Bill Somerville wrote: > > On 09/07/2015 08:18, Steven Franke wrote: > Hi Steve, >> >>> On Jul 9, 2015, at 7:04 AM, Bill Somerville >> > wrote: >>> >>> On 09/07/2015 05:16, Michael Black wrote: >>> >>> Hi Mike, I noticed i

Re: [wsjt-devel] r5700

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_sc

Re: [wsjt-devel] r5700

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

Re: [wsjt-devel] r5700

Msg=0; } if(m_mode.mid(0,4)=="WSPR" and m_ntr==-1 and !m_tuneup) { m_wideGraph->setWSPRtransmitted(); WSPR_scheduling (); m_ntr=0; } } 73 Mike W9MDB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Thursday, July 09, 2015 8:43 AM To:

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

Re: [wsjt-devel] r5700

I should have mentioned in my report in the previous email, that WSPR is in band hopping mode 160m > 10m but TX only on 40m > 10m with 35% selected. --- I have been running WSJT-X r5700 in WSPR-mode for 6 hours without any problems: System here: Kenwoord TS-870s with SignaLink USB interface t

Re: [wsjt-devel] r5700

Just to report on the possible kenwood problems: I have been running WSJT-X r5700 in WSPR-mode for 6 hours without any problems: System here: Kenwoord TS-870s with SignaLink USB interface to a MacBook (10.10.4). SignaLink operates in VOX mode and raises PTT via back ACC panel on the TS-870s

Re: [wsjt-devel] r5700

On 09/07/2015 08:39, F1HDI wrote: > > Hi, > Bonjour Jean-Marc, > > Probably Jean-louis (F5DJL) already told you about issue with wsjt-x > and radio sets with microham microkeyer II. > > Lately, we tested wsjtx r 566x with a microkeyer II followed by an > IC7000, everything is fine, but replacing

Re: [wsjt-devel] r5700

On 09/07/2015 08:18, Steven Franke wrote: Hi Steve, On Jul 9, 2015, at 7:04 AM, Bill Somerville > 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 proba

Re: [wsjt-devel] r5700

ot;'WSJT software development'" > Copie à : > Objet : Re: [wsjt-devel] r5700 > > Hi Mike   We have also seen problems (rig errors)  with Doppler control (for JT4)  on another rig that can’t change frequency on transmit (FT817).  The intention was to command the re

Re: [wsjt-devel] r5700

On 09/07/2015 01:08, Steven Franke wrote: Hi Bill, Hi Steve, ... I applied the patch and re-built but the problem persists. I’ve put a trace file here: https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_2.log There are two events that happened after I applied the patch: 23:35:53 and 2

Re: [wsjt-devel] r5700

> On Jul 9, 2015, at 7:04 AM, Bill Somerville 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 T

Re: [wsjt-devel] r5700

use they can hold the rig in transmit after a request to return to receive. 73 Mike W9MDB 73 Bill G4WJS. *From:*Steven Franke [mailto:s.j.fra...@icloud.com] *Sent:* Wednesday, July 08, 2015 7:08 PM *To:* WSJT software development *Subject:* Re: [wsjt-devel] r5700 Hi Bill, On Jul 8,

Re: [wsjt-devel] r5700

evelopment' Subject: Re: [wsjt-devel] r5700 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 woul

Re: [wsjt-devel] r5700

uency for the next transmit period while it's still transmitting on the last one. 73 Mike W9MDB From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 7:08 PM To: WSJT software development Subject: Re: [wsjt-devel] r5700 Hi Bill, On Jul

Re: [wsjt-devel] r5700

Hi Bill, > On Jul 8, 2015, at 11:09 PM, Bill Somerville wrote: > > On 08/07/2015 23:10, Steven Franke wrote: > > Hi Steve, >>> On Jul 8, 2015, at 4:42 PM, Bill Somerville wrote: >>> >>> On 08/07/2015 22:03, Steven Franke wrote: Mike and Bill, >>> Hi Steve, I deleted my hamlib directo

Re: [wsjt-devel] r5700

le to run using VOX. I suggest that we see if it affects anyone else before we spend more time on it. Steve k9an > -----Original Message- > From: Steven Franke [mailto:s.j.fra...@icloud.com] > Sent: Wednesday, July 08, 2015 5:10 PM > To: WSJT software development > Subject: R

Re: [wsjt-devel] r5700

On 08/07/2015 23:10, Steven Franke wrote: Hi Steve, On Jul 8, 2015, at 4:42 PM, Bill Somerville wrote: On 08/07/2015 22:03, Steven Franke wrote: Mike and Bill, Hi Steve, I deleted my hamlib directory, downloaded the latest from git, changed the timeout from 200 to 1000 in ts480.c and recom

Re: [wsjt-devel] r5700

5 5:10 PM > To: WSJT software development > Subject: Re: [wsjt-devel] r5700 > > >> On Jul 8, 2015, at 4:42 PM, Bill Somerville wrote: >> >> On 08/07/2015 22:03, Steven Franke wrote: >>> Mike and Bill, >> Hi Steve, >>> I deleted my hamlib directory, d

Re: [wsjt-devel] r5700

Also...if you're curious as to what exposed this problem revert your WJST-X backwards until the problem goes away. Mike W9MDB -Original Message- From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 5:10 PM To: WSJT software development Subject: Re:

Re: [wsjt-devel] r5700

quot;IF", priv->info, KENWOOD_MAX_BUF_LEN, caps->if_len); usleep(10); // perhaps increase this -- 100ms may not be enough return ret; } -Original Message- From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 5:10 PM To: WSJT softwar

Re: [wsjt-devel] r5700

> On Jul 8, 2015, at 4:42 PM, Bill Somerville wrote: > > On 08/07/2015 22:03, Steven Franke wrote: >> Mike and Bill, > Hi Steve, >> I deleted my hamlib directory, downloaded the latest from git, changed the >> timeout from 200 to 1000 in ts480.c and recompiled hamlib. Then I recompiled >> wsjt

Re: [wsjt-devel] r5700

And could you please post the trace log too? -Original Message- From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 5:04 PM To: WSJT software development Subject: Re: [wsjt-devel] r5700 Mike and Bill, > On Jul 8, 2015, at 4:34 PM, Michael Black wr

Re: [wsjt-devel] r5700

Can you confirm the frequency is changing even though you see the error? -Original Message- From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 5:04 PM To: WSJT software development Subject: Re: [wsjt-devel] r5700 Mike and Bill, > On Jul 8, 2015, at 4:34

Re: [wsjt-devel] r5700

Mike and Bill, > On Jul 8, 2015, at 4:34 PM, Michael Black wrote: > > Another thought... > > Go inside kenwood.c and add a usleep(50) line 259 -- this will slow down > the ID command. > if (!datasize) { >rig->state.hold_decode = 0; >usleep(50); >/* no reply expected so we

Re: [wsjt-devel] r5700

On 08/07/2015 22:03, Steven Franke wrote: > Mike and Bill, Hi Steve, > I deleted my hamlib directory, downloaded the latest from git, changed the > timeout from 200 to 1000 in ts480.c and recompiled hamlib. Then I recompiled > wsjtx. Same problem - an excerpt from the trace is included below. I b

Re: [wsjt-devel] r5700

Mike, Changing the polling interval did not help. In fact, every time that I’ve run the program this afternoon the problem has occurred reliably after the first transmission. I’m having a hard time understanding how the logic changes that were put in place in r5700 could uncover a problem with

Re: [wsjt-devel] r5700

Another thought... Go inside kenwood.c and add a usleep(50) line 259 -- this will slow down the ID command. if (!datasize) { rig->state.hold_decode = 0; usleep(50); /* no reply expected so we need to write a command that always gives a reply so we can read any error

Re: [wsjt-devel] r5700

Reduce your polling interval to 5 seconds and see if that helps at all. 73 Mike W9MDB -Original Message- From: Steven Franke [mailto:s.j.fra...@icloud.com] Sent: Wednesday, July 08, 2015 4:04 PM To: WSJT software development Subject: [wsjt-devel] r5700 Mike and Bill, I deleted my hamlib

Re: [wsjt-devel] r5700

On 08/07/2015 20:24, Steven Franke wrote: Mike and Bill, Hi Steve, On Jul 8, 2015, at 6:58 PM, Bill Somerville > wrote: On 08/07/2015 19:43, Steven Franke wrote: Bill, Hi Steve, I just updated back to r5700 and the problem that I described yesterday occurre

Re: [wsjt-devel] r5700

Subject: Re: [wsjt-devel] r5700 Mike and Bill, On Jul 8, 2015, at 6:58 PM, Bill Somerville wrote: On 08/07/2015 19:43, Steven Franke wrote: Bill, Hi Steve, I just updated back to r5700 and the problem that I described yesterday occurred after the first transmission. I captured the

Re: [wsjt-devel] r5700

Mike and Bill, > On Jul 8, 2015, at 6:58 PM, Bill Somerville wrote: > > On 08/07/2015 19:43, Steven Franke wrote: >> Bill, > Hi Steve, >> >> I just updated back to r5700 and the problem that I described yesterday >> occurred after the first transmission. I captured the following from the >> t

Re: [wsjt-devel] r5700

Turn 'em all on: WSJT_HAMLIB_TRACE WSJT_HAMLIB_VERBOSE_TRACE WSJT_TRACE_CAT WSJT_TRACE_CAT_POLLS It sounds like it is colliding with another command that is still "in work" and the retry period is too short at 200ms. That will give 3 seconds instead of 600ms total time. Can you compile hamlib

Re: [wsjt-devel] r5700

On 08/07/2015 19:43, Steven Franke wrote: > Bill, Hi Steve, > > I just updated back to r5700 and the problem that I described yesterday > occurred after the first transmission. I captured the following from the > trace file: > > Wed Jul 8 18:35:53 2015 > GMT(/home/radio/Builds/wsjtx/HamlibTransc