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