Still having problems with the HRD tcp bug.
What's of interest to me is that I can run HRD Logger and DM780 both of
which use port 7809 too and they don't seem to have any problems. So I'm
going to try and compare these to hopefully figure out what's going on. If
you want I can capture the netwo
On 05/09/2014 16:29, Michael Black wrote:
Hi Mike,
Still having problems with the HRD tcp bug.
What's of interest to me is that I can run HRD Logger and DM780 both
of which use port 7809 too and they don't seem to have any problems.
So I'm going to try and compare these to hopefully figure o
eforge.net
Subject: Re: [wsjt-devel] HRD tcp bug
On 05/09/2014 16:29, Michael Black wrote:
Hi Mike,
Still having problems with the HRD tcp bug.
What's of interest to me is that I can run HRD Logger and DM780 both of
which use port 7809 too and they don't seem to have any problems. So
is sent HRD no longer seems to want to respond to "get radio".
Could this be a new command that should be used "get radios" instead of "get
radio" ??
Mike W9MDB
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, September 05, 2014 10:52 AM
To: w
The change
will be non-trivial but I should be able to come up with something we
can at least test with to verify we have found the action that triggers
the issue.
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Friday, September 05, 2014 10:52 AM
[mailto:g4...@classdesign.com]
Sent: Friday, September 05, 2014 7:21 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] HRD tcp bug
On 06/09/2014 00:53, Michael Black wrote:
Hi Mike,
OK
current run with rev 4255 but I am running with 10 second socket timeout
modification.
I ran WSJT
omerville [mailto:g4...@classdesign.com]
> Sent: Friday, September 05, 2014 7:21 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] HRD tcp bug
>
> On 06/09/2014 00:53, Michael Black wrote:
> Hi Mike,
> OK…current run with rev 4255 but I am running with 10 secon
I added a semaphore for fun and output the command being sent when acquiring
it.
I then noticed what appears to be the problem. Seems the waitForReadyRead
is misbehaving.
Here's the trace log with my added debug statements. The semaphore is
acquired just before the hrd_->write
It took 8 seconds
On 06/09/2014 19:51, Michael Black wrote:
Hi Mike,
thanks again for your diligent detective work on this issue!
> I added a semaphore for fun and output the command being sent when acquiring
> it.
>
> I then noticed what appears to be the problem. Seems the waitForReadyRead
> is misbehaving.
OK,
Nope...no joy.
It ended up with retries exhausted on "get frequencies"
I'd be interested in trying QT 5.3.1 dlls to see if that fixes it.
How would I test those out?
Sat Sep 6 20:59:23 2014 GMT(C:\JTSDK-QT\src\wsjtx\main.cpp:115)Debug:
"WSJT-X v1.4.0 r4256-dirty by K1JT - Program startup"
S
On 06/09/2014 22:33, Michael Black wrote:
Hi Mike,
> Nope...no joy.
>
> It ended up with retries exhausted on "get frequencies"
Did you paste the correct trace output. What I see looks like the very
first command sent to HRD failed. That may be because the HRD IP server
is messed up from a prior
Hi Bill, Mike,
You should be able to do this pretty easy. I would move the current
JTSDK-QT\qt5 folder to JTSDK-QT\qt5-orig or something as a backup.
Then, use QT5 5.3.x OpenSource Installer, install 5.3.x and tools to
JTSDK-QT\qt5
At that point, you need to update the Tool Chain and QT5 paths i
I'm going to call this a possible fixI've only been running it for a few
minutes.
But...before this every time I started WSJT-X with HRD Logger already
running it would timeout immediately. And anytime I started WSJT-X first
and then HRD Logger WSJT-X would start timing out immediately. I tr
On 07/09/2014 22:22, Michael Black wrote:
Hi Mike,
> I'm going to call this a possible fixI've only been running it for a few
> minutes.
>
> But...before this every time I started WSJT-X with HRD Logger already
> running it would timeout immediately. And anytime I started WSJT-X first
> and th
-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, September 07, 2014 6:44 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] HRD tcp bug
On 07/09/2014 22:22, Michael Black wrote:
Hi Mike,
> I'm going to call this a possible fixI've only been runnin
I did some more investigation. QT's wait functions are brain dead.
And I've got a couple other ideas to try.
Look at the bottom of this email at waitforReadyRead()...you ask for "are
you ready to read?" and inside it returns true if not ready to ready but
d->canWriteNotification is true.
So I mov
OK...I'm running with this patch right now based on the behavior I was
seeing. Been going for an hour with no timeouts.
Once HRD Logbook is running two things happen.
#1 HRD replies slow down a bit. So I see this in the new log output showing
about 2 second times (verified by network capture)
Mon
olm CFI/II
K4SHQ
The best prayer ever said: "Lord please make me the
kind of person my dog thinks I am."
From: Michael Black [mailto:mdblac...@yahoo.com]
Sent: Friday, September 05, 2014 10:29 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] HRD tcp bug
Still havi
I've determined the problem now is with HRD (running 6.2.72.293) and Windows
7 32-bit. So I'm going to report this to HRD.This behavior also shows
up during WSJT-X operations during frequency changes with very slow freq
changes (like 10 seconds for example). This is WSJT-X v1.4.0 r4270-dirty.
On 09/09/2014 13:48, Michael Black wrote:
Hi Mike,
> I've determined the problem now is with HRD (running 6.2.72.293) and Windows
> 7 32-bit. So I'm going to report this to HRD.This behavior also shows
> up during WSJT-X operations during frequency changes with very slow freq
> changes (like 1
ike W9MDB
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Tuesday, September 09, 2014 8:06 AM
To: WSJT software development
Subject: Re: [wsjt-devel] HRD tcp bug
On 09/09/2014 13:48, Michael Black wrote:
Hi Mike,
> I've determined the problem now is
On 09/09/2014 15:28, Michael Black wrote:
Hi Mike,
> Yep...same context# on all 3.
OK, so that's no the problem since HRD logbook and DM780 cooperate.
>
> Here's what I think now that might explain why sometimes it works and
> sometimes not.
> It does appear that HRD spawns a thread for each client
I installed rohitab apimonitor and I don't see HRD doing any "select" at
all.
All it ever does is send/recv after doing setsockopt().
Since it does appear a thread is getting created I guess the thread is never
relinquishing control until its cleared its incoming queue.
I'll bet if you sent a cons
r the command is sent.
WSJT-X doesn't stack commands like that.
Mike W9MDB
From: Dan Malcolm [mailto:dmalcol...@mchsi.com]
Sent: Friday, September 05, 2014 3:47 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] HRD tcp bug
I don't have a fix but I do have an
24 matches
Mail list logo
