I assume you're compiling hamlib -- so change netrigctl.c on this line
.timeout = 3000, /* enough for the worst rig we have */
Make that 5000 or higher and see if that makes it happy. I may change that to
10000 as that is now the worst rig we have.
.timeout = 5000, /* enough for the worst rig we have */
At some point the thing has to timeout to let you know something is wrong. I
won't be implementing ad nauseum retries.
If SparkSDR can't handle it's own timeouts than that's their problem.
Mike W9MDB
On Monday, July 12, 2021, 11:06:29 AM CDT, Alan Hopper
<[email protected]> wrote:
Hi Mike,this is with WSJT-X connecting to the fake rigctld in SparkSDR. It
connects and then if a delay happens some time later (hours in real use) it
will reconnect again but if the delay happens again it does not retry. Maybe be
retry was planned for the initial connect? For long running connections it
would be nice if it kept reconnecting.73 Alan M0NNB
On Mon, Jul 12, 2021 at 4:45 PM Black Michael via wsjt-devel
<[email protected]> wrote:
It should be trying to reconnect twice with 3 second timeout each time.
What rig are you using? You could increase the timeout value by adding a
switch to rigctld
rigctld --set-conf=timeout=10000
You could also try increasing the retry in rigctld.c from 3 to maybe 4 or 5 and
see if that makes it happy.
if (retcode < 0 && !RIG_IS_SOFT_ERRCODE(-retcode))
{
int retry = 3;
Mike W9MDB
On Monday, July 12, 2021, 10:08:36 AM CDT, Alan Hopper
<[email protected]> wrote:
Hi all,I've been doing some testing to try and make the hamlib NET rigctl
connection to SparkSDR as robust as possible. Very infrequently (maybe once in
24hrs) responses from spark are delayed by a few seconds, This causes a time
out at the WSJT-X side which then auto reconnects which is great, however if it
happens a second time the auto retry does not seem to happen (I see no attempt
to reconnect) and a dialog pops up with :-
"Hamlib error: Communication timed outread_string called, rxmax=1024
read_string(): Timed out 3.000 seconds after 0 chars
rig.c(1000):rig_open return(-5) while opening connection to rig
Timestamp: 2021-07-11T20:55:06.057Z"
I've added an artificial delay to test and the auto retry only ever appears to
happen once. A manual retry does work after the second failure.
In the ideal world spark would never send a delayed response but it is often
used on heavily loaded pcs running many WSJT-X instances 24/7. The delays
happen in a low level socket send so I don't think I have any control over it.
I see it in 2.4.0 and 2.5.0rc3, I've not tested with any other versions.
Is this intended behaviour or a bug?
73 Alan M0NNB
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
