The rogue behavior I saw was more related to the port going away when the
client crashes.
I don' t think I've seen the 100% CPU when it was just a failed command like
we're talking about.
But impolitely close the port...
I think I'll write a small test program to see if I can reproduce this
behavior and, if so, pass it on to HRD.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Monday, September 01, 2014 9:48 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] TenTec Omni HRD TCP fix
On 01/09/2014 15:34, Michael Black wrote:
Hi Mike,
As one added point..WSJT-X ran all night without losing rig control to HRD.
So HRD Logbook running simultaneously is definitely the culprit that has
been causing me headaches for weeks now.
WSJTX-1.3 just crashes when this happens apparently and that was what
prompted me to try 1.4 since I didn't know why 1.3 was crashing so often.
And it's not just get radio that fails. It's random all depending on when
HRD Logbook does its thing.
That's what I was suspecting.
I got HRD to pass a note to the developers about this so hopefully they'll
fix this. I suspect it's a non-thread-safe routine stomping on a static
buffer.
TBH what concerns me most is the behaviour of HRD after the issue occurs,
that 100% CPU utilization is something I have seen before many times with
HRD and I suspect there is a fundamental flaw in there somewhere with a
rogue thread getting live-locked. Still, that's their problem and maybe your
request might do them a favour if the find the real issue ;)
A single retry on a failed command other than the port going away should
solve this.
When I started on this new HRD interface I looked at he source of the
HRDInterface001.dll that does the TCP/IP client comms for external programs,
which was in the public domain. I was so disenchanted with the code that I
bypassed it and wrote my own portable client module. This allowed me to
communicate with all versions of HRD as well as improve the client
processing. I also noted that there was a bunch of code in HRDInterface001
with an alternative "Send Command" method that had implicit retries - all
that alternative code was commented out in the HRDInterface001 source
archive I have!! I suspect there has been a known issue for a long time and
possibly it is still unresolved.
I will try and commit a change with retries in later, but I suspect that HRD
still may go rogue after this command collision issue so it may not be a
workable solution, we shall see.
Mike W9MDB
73
Bill
G4WJS.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Monday, September 01, 2014 8:30 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] TenTec Omni HRD TCP fix
On 31/08/2014 13:14, Michael Black wrote:
Hi Mike,
thanks for this and the prior post, they contain many useful incites that
should hopefully allow me to get this all working better.
Your patch does allow my to connect to HRD now..
OK.
But I think I found a new problem. It looks like HRD cannot handle two
clients on port 7809 simultaneously.
I captured the network traffic and saw a "get frequencies" in the middle of
the setup going on and it came from HRD Logbook. WSJT-X them times out
right after it.
Hmmm, that's interesting. All my development was done with only the rig
control part of HRD running, I never considered that the logbook might
interfere. All my work with HRD has been done without any serious
documentation and in many cases I had to guess the syntax of the interface
commands. It is quite possible that I need to have some sort of retry
mechanism to cope with bad server responses from HRD when the HRD logbook is
active.
This may explain why WSJTX 1.3 started failing on me too. I recently
started keeping HRD Logbook running for DM780 (though I use Log4OM as my
primary -- DM780 won't talk directly to Log4OM)
So I shut down HRD logbook and all appears well now. At least I've been
running for several minutes without losing rig control.
So this is another bug I'll have to report to HRD. It should be able to
handle numerous clients at once.
It looks kind of like the "get frequencies" stomped on the return packet for
WSJT-X's "get radio"
I do the 'get radio' command before each real command to ensure that the
current radio is still the one I started with, not perfect but I see no
better solution. HRD allows multiple radio connections and the commands seem
to address the one that has current focus in the HRD GUI.
I will have a go at reproducing this communications breakdown with HRD and
see if I can find a way to work around it.
Sorry you are having so many issues with WSJT-X and HRD. Thank you so much
for taking the time to persist with helping to track down these issues.
<trace snipped>
73
Bill
G4WJS.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Saturday, August 30, 2014 3:11 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] TenTec Omni HRD TCP fix
On 29/08/2014 19:04, Michael Black wrote:
Hi Mike,
Yeah.just wanted to let you know what I did.
HRD is going to fix this for the TenTec Omni VII. I had to go a few rounds
with them as they thought it was WSJT-X's fault.
You didn't say why you needed to set a default mode of USB. As far as I can
see the HRD interface for the Omni VII includes mode setting and this
shouldn't be necessary. If mode setting doesn't work correctly; you should
be able to set the WSJT-X configure setting for "Mode" to "None" and it will
assume you have set the mode manually on your transceiver.
I have committed a change (revision 4235) that will not fail on any missing
HRD feature that we require. This shoudl allow you to control your Omni VII
via HRD at least for single frequency non split operation with some other
method than CAT for PTT (i.e. VOX or via a separate COM port control line.)
Please be aware that this will allow you to set split mode operating in
WSJT-X but it will not work as expected because WSJT-X will adjust TX tones
as if the TX frequency were different from the RX frequency. This would mean
you would not be netted with any QSO partner. Until HRD provides a way of
setting split mode and the frequency of the TX VFO this is the best we can
do and split mode working cannot be used with the Omni VII via HRD.
If you can build this version and test on your setup, it would be very much
appreciated.
Mike W9MDB
73
Bill
G4WJS.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, August 29, 2014 12:24 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] TenTec Omni HRD TCP fix
On 23/08/2014 16:06, Michael Black wrote:
Hi Mike,
sorry for the delay in replying, I am now back on line.
I got the TCP working for the TenTec Omni VII on HRD basically just by
ignoring the pull-down menu error.
Diff is attached and in-line here too.
OK, but i have a problem with this approach since the original failure is
designed to flag that the code needs changes to talk to HRD for a new rig
that has unrecognised controls in HRD. The Omni HRD simply doesn't meet the
minimum requirements for WSJT-X as currently implemented. I had not realised
that there were HRD rig integrations that were so primitive :( I need to
address this by reducing the minimum requirements to that level. This will
mean that some WSJT-X configuration settings cannot work such as split
operation, BTW this is already the case for mode setting although I'm not
sure it is correctly implemented just yet.
HRD has a bug report from me which, hopefully, they will eventually fix to
give those parameters. HRD doesn't even show buttons for mode, split, or
PTT for the Omni VII which is their problem.
OK, it will be interesting to see how responsive they are.
I also made a small improvement to the error messages since what was there
was lacking specificity on where the failure was occurring.
This is a good improvement although, if you don't mind, I will implement
with more user friendly text since referring to internal implementation
details about drop downs and buttons may not be helpful to users.
What I did was default the mode to USB if there is no dropdown available for
mode select.
I'm not sure why you needed to do this, mode control appears to be available
for the TenTec Omni using HRD.
Hopefully that's the right thing to do here.
I need to revisit mode setting in HRD, the intent was to allow control of
rigs with no CAT mode control. I see that I have broken that by blindly
setting mode in the initialization. I will fix that in a more generic way.
Thanks for looking at this Mike, it has revealed several issues which I am
working on now.
Mike W9MDB
73
Bill
G4WJS.
----------------------------------------------------------------------------
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
