On 24/04/2020 17:14, Black Michael via wsjt-devel wrote:
Whaddya' mean no timeouts?
PollingTransceiver::PollingTransceiver (int poll_interval, QObject *
parent)
: TransceiverBase {parent}
, interval_ {poll_interval * 1000}
, poll_timer_ {nullptr}
, retries_ {0}
poll_timer_
Whaddya' mean no timeouts?
PollingTransceiver::PollingTransceiver (int poll_interval, QObject * parent)
: TransceiverBase {parent} , interval_ {poll_interval * 1000} , poll_timer_
{nullptr} , retries_ {0}
poll_timer_ = new QTimer {this}; // pass ownership to
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 groupas
I've had several reports from the JTDX groupas 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
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
And please give consideration to lengthening the timeout to 3 secondswe'll
get rid of a lot of complaints about timeouts.
Mike
On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville
wrote:
Hi Mike,
OK, hold off from any Hamlib changes to rig_close for now. I will do
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
I have no idea why it's treated differentlybeen 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,
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
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
Hi Mike,
I really dislike arbitrary timeouts, they make software seem unresponsive.
Why is rig_close() not synchronous?
73
Bill
G4WJS.
On 24/04/2020 14:04, Black Michael via wsjt-devel wrote:
Direct control has the same problem. And you don't need a
network-based rig for this problem. I
Direct control has the same problem. And you don't need a network-based rig
for this problem. I duplicated it on my MK706MKIIG over serial just by turning
the rig off, wait for the timeout, turn it back on, and retry.
I think this is why we keep seeing all these random errors for getting
Hi Mike,
I was think about the TCP/IP connection to the rig, the rig_close()
needs to shutdown and close that rather than be still waiting. In that
case the close should be processed promptly. I don't have a FlexRadio or
any other network connected rig.
Another question, what happens when
You have to do that yourself. At the bottom of each email there is a
link to the list's self-service site:
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Neil, KN3ILZ
On 4/23/2020 6:26 PM, Rick wrote:
please unsubscribe me from this email list.
On Thu, Apr 23, 2020 at 3:10 PM
14 matches
Mail list logo
