Mike,
WSJT-X calls Hamlib API functions which are blocking, there are no
timeouts, it just waits for the function to finish. What is this timeout
you are referring to?
73
Bill
G4WJS.
On 24/04/2020 16:40, Black Michael via wsjt-devel wrote:
I've had several reports from the JTDX group....as I said due to the
new power level calls it is making. And now I'm running into rigs
with 50ms post_write_delay that are too slow and hitting the timeout
and I'm loathe to change that 50ms as most of those were determined by
experimentation and I can't tell which were and which weren't.
I remember seeing quite a few timeouts on the WSJT-X group....I'm not
going to bother to go find them....they weren't horribly common and
now I can see why they were random....all they needed was some delay
and WSJT-X would time out since most everybody uses the default 1
second polling rate..and therefore the 1 second timeout. I seem to
recall some decreasing the polling rate. That's what I've had to tell
the Flex users.
There is no logical reason I can think of to have a 1 second timeout
when it is well known that the underlying hardware has longer timeouts
than that.
Nobody is going to even know there's a 3 or 4 second timeout. Not
that there is a difference between hamlib's timeout and WSJT-X's
timeout. hamlib will time out based on the rig settings. WSJT-X does not.
It should be possible for WSJT-X to use the rig's "timeout" value plus
maybe 200ms. Note that netrigctl has a 2.5 second timeout.
Then I can change rigctld to also use the rig's timeout if it's large
than rigctld's timeout.
Mike
On Friday, April 24, 2020, 09:39:40 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Mike,
the only reports of Hamlib timeouts I have seen are where the
connection is not set up right, e.g. the wrong COM port, baud rate, or
handshaking. Can you point me to a report of a Hamlib timeout that is
not caused by similar misconfiguration?
73
Bill
G4WJS.
On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
And please give consideration to lengthening the timeout to 3
seconds....we'll get rid of a lot of complaints about timeouts.
Mike
On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville
<g4...@classdesign.com> <mailto:g4...@classdesign.com> wrote:
Hi Mike,
OK, hold off from any Hamlib changes to rig_close for now. I will do
some tests when I get some time and work out if WSJT-X is really
calling rig_open twice on the same RIG handle without an intervening
rig_close. I'll get back to you.
73
Bill
G4WJS.
On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
I have no idea why it's treated differently....been that way since
day#1.
I could add a flag to the RIG structure for "close_is_sync" that a
client could set if it wants a synchronous close.
That way we wouldn't break any other apps not expecting it.
Mike
On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville
<g4...@classdesign.com> <mailto:g4...@classdesign.com> wrote:
On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter. The problem
is that hamlib recovers from the timeout but when it's done WSJT-X
has already timed out and shuts down rigctld. And it also looks
like WSJT-X starts another connection before closing the first one
which then gives the invalid configuration error....maybe that's
where a synchronous close would work better....but it looks like
the idea there was a client just tells rigctld "I'm done" and
that's a 1-way conversation. If we make it synchronous then the
client has to stay around to take the answer or else we start
hitting timeouts in rigctld. I'm a bit reluctant to make it
synchronous as I don't know what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client
will be timing out trying to close it.
All timeouts are arbitrary but have to be based on what the
hardware can do. .
Making the timeout = pollrate is arbitrary too. If you made the
polling 10ms everything would time out like crazy.
We've got a lot of rigs that just aren't very fast on CAT and 1
second is too short.
The timeouts aren't hit very often and nobody will even notice it
in WSJT-X if there's a 3-second timeout that almost never gets
triggered.
What they do notice is WSJT-X timing out too quickly. And the more
data we ask from the rigs the more likely we are to hit the 1
second timeout.
Mike
Hi Mike,
if WSJT-X is overlapping rig_open/rig_close calls then it should be
doing it on a separate RIG handle, that should not cause a problem.
I thought the Hamlib API was synchronous, why is the rig_close call
being treated differently, that's very confusing to me.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
